Вариант для распечатки		Пред. тема | След. тема
Форум Информационная безопасность (Firewall и пакетные фильтры)
Изначальное сообщение		[ Отслеживать ]

"Перенаправление трафика (forwarding)"	–1 +/–
Сообщение от WeSTMan (ok), 21-Апр-20, 17:39
Всем привет. Хочу поставить сервер, который будет выступать в роли фильтров между клиентом и сервером. Сервер фильтрации должен менять адрес назначения на адрес сервера и в обратном порядке. Но когда я пытаюсь послать пакет на сервер фильтрации, он приходит, переходит в цепочку FORWARD и дропается самой сетевой картой. Соответственно пакет сервер не принимает. Может какой VPN сделать между сервером и сервером фильтрации? Как я понял, то сетевуха не знает о этих сетях ничего (типа не мне и не я принимаю/отсылаю пакет, поэтому и дропаю). Правила в iptables (По умолчанию все цепочки ACCEPT и включен ip v4 forward) iptables -t nat -A PREROUTING -d IPFilter/32 -p udp --dport 27017 -j DNAT --to-destination IPServer НО, если я поменяю адрес источника клиента на адрес сервера фильтров, то пакет будет передан серверу, но не с IP клиента, а с IP фильтров. А мне нужен, чтобы пересылался IP адрес клиента. Помогите, пожалуйста, с решением вопроса!
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Licha Morada (ok), 21-Апр-20, 19:04	+/–
Какой линукс? Линукс ли? > Всем привет. Хочу поставить сервер, который будет выступать в роли фильтров между > клиентом и сервером. > Сервер фильтрации должен менять адрес назначения на адрес сервера и в обратном > порядке. A? Постарайтесь нарисовать топологию, или придумайте им всем внятные имена и адреса чтобы описать словами. Кто с кем в одной сети, а кто в Интернете? Кто чей default gateway? > Но когда я пытаюсь послать пакет на сервер фильтрации, он приходит, переходит > в цепочку FORWARD и дропается самой сетевой картой. Соответственно пакет сервер > не принимает. Вы хотите слать пакеты UDP с клиента на фильтры, но чтобы потом он попадал на сервер с адресом отправителя клиента? Рекомендую сделать шаг назад и сформулировать, чего вы, собственно, стремитесь достичь. > НО, если я поменяю адрес источника клиента на адрес сервера фильтров, то > пакет будет передан серверу, но не с IP клиента, а с > IP фильтров. А мне нужен, чтобы пересылался IP адрес клиента. > Помогите, пожалуйста, с решением вопроса! Чем смотрите, сниффером на сервере?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2

2. Сообщение от WeSTMan (ok), 21-Апр-20, 20:42	+/–
В принципе ожидал, что будет не совсем понятно. У нас есть 3 участника сети. IP адреса я выбрал похожие, но отличающиеся. 1. Клиент (95.56.21.55) 2. Сервер фильтрации (195.212.54.128) 3. Сервер (176.241.128.77) 1. Клиент посылает UDP запрос, где в адресе отправителя ставит себя, а в адресе получателя ставит сервер фильтрации. Клиент -> Сервер фильтрации (95.56.21.55 -> 195.212.54.128) 2. Сервер фильтрации принимает пакет. Ставит вместо адреса получателя не себя, а адрес сервера. На этом этапе пакет должен уйти на обычный сервер. По факту отправляется от сервера фильтрации к обычному серверу, только адрес отправителя остается клиента. (На этом этапе дропается пакет сетевой картой, почему - хз). Пакеты, который генерирует сервер фильтрации: Клиент -> Сервер (95.56.21.55 -> 176.241.128.77) (НЕ РАБОТАЕТ) Сервер фильтрации -> Сервер (195.212.54.128 -> 176.241.128.77) (Работает, только я не получаю IP клиента. А он обязателен!) Должно получится на выходе из фильтров: Клиент -> Сервер. Только сам сервер фильтрации передает пакет. Клиент ничего не знает об обычном сервере. 3. Обратная цепочка. Проблема находится на сервере фильтрации, так как он не передает пакет обычному серверу, когда его нет не в адресе отправителя, не в адресе получателя! Пакеты перехватываю tshark под Linux. Ubuntu 16.04. Версия IPTables - 1.6.0
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #3

3. Сообщение от Licha Morada (ok), 21-Апр-20, 21:42	+/–
> В принципе ожидал, что будет не совсем понятно. > У нас есть 3 участника сети. IP адреса я выбрал похожие, но > отличающиеся. > 1. Клиент (95.56.21.55) > 2. Сервер фильтрации (195.212.54.128) > 3. Сервер (176.241.128.77) Замечательно, значит, все в Интернете в разных сетях. > 1. Клиент посылает UDP запрос, где в адресе отправителя ставит себя, а > в адресе получателя ставит сервер фильтрации. Клиент -> Сервер фильтрации (95.56.21.55 > -> 195.212.54.128) > 2. Сервер фильтрации принимает пакет. Ставит вместо адреса получателя не себя, а > адрес сервера. Это вы делаете с помощью правила DNAT, которое вы привели. > На этом этапе пакет должен уйти на обычный сервер. По факту отправляется > от сервера фильтрации к обычному серверу, только адрес отправителя остается клиента. > (На этом этапе дропается пакет сетевой картой, почему - хз). Не думаю что оно дропается именно сетевой картой, если интересно, можно покопать. Это ожидаемое поведение, что пакет от сервера фильтрации к обычному серверу, с адресом отправителя клиента, не доходит. Такой пакет имеет все признаки попытки атаки IP spoofing, его мог зарезать кто угодно по дороге, и правильно сделал. > 3. Обратная цепочка. Какая обратная цепочка? Вы хотите чтобы ответ от обычного сервера с адресом получателя клиента тоже проходил через сервер фильтрации? Не вижу как это можно сделать, не вмешиваюсь в работу глобальной маршрутизации, как Ростелеком давеча. > Проблема находится на сервере фильтрации, так как он не передает пакет обычному > серверу, когда его нет не в адресе отправителя, не в адресе > получателя! В принципе ваш Ubuntu можно заставить выпихивать этот пакет наружу, гуглите как проводить атаку IP Spoofing по UDP. Но я бы не расчитывал на то что он дойдёт до обычного сервера. Даже если дойдёт, это дыра в безопасности, по крайней мере у вашего ISP, которую рано или поздно залатают. > Должно получится на выходе из фильтров: Клиент -> Сервер. Поставьте сервер фильтрации в одной и той же локалке где клиент, с приватными адресами, и пусть он подменяет но только адрес получателя но и адрес отправителя. Тогда вся маршрутизация будет работать "нормально", а обычный сервер подмены не заметит т.к. сервер фильтрации и клиент всё равно имеют один и тот-же публичный адрес. Там можт быть нюанс, если пакет прошёл forwarding, но оказывается что egress interface одна и та-же что и ingress interface, система норовит не пересылать пакет на шлюз, а ответить пакетом ICMP Redirect. Не всегда так, зависит от реализации. Кстати, возможно, именно это вы интерпретируете как "дропается сетевой картой".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #4

4. Сообщение от WeSTMan (ok), 21-Апр-20, 22:05	+/–
> Замечательно, значит, все в Интернете в разных сетях. Да > Это вы делаете с помощью правила DNAT, которое вы привели. Да > Не думаю что оно дропается именно сетевой картой, если интересно, можно покопать. Возможно я и ошибаюсь, но в ifconfig на сетевом интерфейсе стоит значение напротив dropped - столько пакетов, сколько я послал UDP. > Это ожидаемое поведение, что пакет от сервера фильтрации к обычному серверу, с > адресом отправителя клиента, не доходит. Такой пакет имеет все признаки попытки > атаки IP spoofing, его мог зарезать кто угодно по дороге, и > правильно сделал. Я не желаю использовать атаку IP spoofing. Если её блокируют, может создать между серверами что-то на подобии VPN? > Какая обратная цепочка? Вы хотите чтобы ответ от обычного сервера с адресом > получателя клиента тоже проходил через сервер фильтрации? Не вижу как это > можно сделать, не вмешиваюсь в работу глобальной маршрутизации, как Ростелеком давеча. Ну тут на самом деле 2 варианта. Либо передавать ответ через сервер и ставить IP адрес источника - сервер фильтрации. Или передать серверу фильтрации, чтобы он сам поставил и отдал клиенту. Задержка меньше между Клиент - срв фильтрации - сервер, нежели клиент - сервер. Вероятно из-за маршрутов. Но не суть. Идея хорошая. > В принципе ваш Ubuntu можно заставить выпихивать этот пакет наружу, гуглите как > проводить атаку IP Spoofing по UDP. Но я бы не расчитывал > на то что он дойдёт до обычного сервера. Я являюсь полным владельцем физического сервера, исключение - провайдер сети. > Даже если дойдёт, это дыра в безопасности, по крайней мере у вашего > ISP, которую рано или поздно залатают. > Поставьте сервер фильтрации в одной и той же локалке где клиент, с > приватными адресами, и пусть он подменяет но только адрес получателя но > и адрес отправителя. Тогда вся маршрутизация будет работать "нормально", а обычный > сервер подмены не заметит т.к. сервер фильтрации и клиент всё равно > имеют один и тот-же публичный адрес. К сожалению, не могу поставить, они в разных местах. Думаю что-то типа VPN сделать. Клиент может быть любой человек на планете с любым IP. > Там можт быть нюанс, если пакет прошёл forwarding, но оказывается что egress > interface одна и та-же что и ingress interface, система норовит не > пересылать пакет на шлюз, а ответить пакетом ICMP Redirect. Не всегда > так, зависит от реализации. Кстати, возможно, именно это вы интерпретируете как > "дропается сетевой картой". Я не могу Вам этого сказать. Уточните более подробную информацию - отвечу. Я хочу реализовать данную топологию из-за защиты, чтобы злоумышленник не знал реального IP адреса сервера. Плюсом - сервер фильтрации имеет большую пропускную способность, чем сервер. И я уверен, что всякие дурочки не смогут забить канал. Не говорю, конечно, о целенаправленных атаках, где море трафика, типо бот нет сети. Надеюсь продолжим дальнейшее общение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #11

5. Сообщение от romanegunkov (ok), 21-Апр-20, 22:07	+/–
Послушайте снифером на конечном сервере. Кажется дропится не на сервере фильтрации, а на конечном. Может даже не дропится, а отсылается клиенту, но получается нестыковка сессии по IP адресам. По сниферу будет видно. Поставьте на конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку отрабатывал, должно заработать. Или для теста маршрут для конкретного клиента пропишите через сервер фильтрации, если опасаетесь дефолт менять или потерять доступ к серверу.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #12

6. Сообщение от WeSTMan (ok), 21-Апр-20, 22:11	+/–
> Послушайте снифером на конечном сервере. Кажется дропится не на сервере фильтрации, а > на конечном. Может даже не дпопится, а отсылается клиенту, но получается > нестыковка сессии по IP адресам. По сниферу будет видно. Поставьте на > конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку > отрабатывал, должно заработать. Конечный сервер ничего не получает. Отлавливал через tshark
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #7

7. Сообщение от romanegunkov (ok), 21-Апр-20, 22:29	+/–
>> Послушайте снифером на конечном сервере. Кажется дропится не на сервере фильтрации, а >> на конечном. Может даже не дпопится, а отсылается клиенту, но получается >> нестыковка сессии по IP адресам. По сниферу будет видно. Поставьте на >> конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку >> отрабатывал, должно заработать. > Конечный сервер ничего не получает. Отлавливал через tshark Чудеса. А в tshark по каким-то критериям отлавливаете? Попробуйте в iptables прописать порт куда перекидывать: --to-destination IPServer:27017
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #8

8. Сообщение от WeSTMan (ok), 21-Апр-20, 22:31	+/–
>>> Послушайте снифером на конечном сервере. Кажется дропится не на сервере фильтрации, а >>> на конечном. Может даже не дпопится, а отсылается клиенту, но получается >>> нестыковка сессии по IP адресам. По сниферу будет видно. Поставьте на >>> конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку >>> отрабатывал, должно заработать. >> Конечный сервер ничего не получает. Отлавливал через tshark > Чудеса. > А в tshark по каким-то критериям отлавливаете? > Попробуйте в iptables прописать порт куда перекидывать: --to-destination IPServer:27017 Все это дело тестировал. tshark -f "port 27017" -i ppp0 Я писал, что пакеты дропаются еще на сервере фильтрации. Я послал 13 пакетов, ввел ifconfig и увидел dropped 13 Хотя все правила ACCEPT и форвардинг работает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #9, #10

9. Сообщение от romanegunkov (ok), 21-Апр-20, 22:45	+/–
>[оверквотинг удален] >>>> отрабатывал, должно заработать. >>> Конечный сервер ничего не получает. Отлавливал через tshark >> Чудеса. >> А в tshark по каким-то критериям отлавливаете? >> Попробуйте в iptables прописать порт куда перекидывать: --to-destination IPServer:27017 > Все это дело тестировал. > tshark -f "port 27017" -i ppp0 > Я писал, что пакеты дропаются еще на сервере фильтрации. > Я послал 13 пакетов, ввел ifconfig и увидел dropped 13 > Хотя все правила ACCEPT и форвардинг работает Может есть правило дропать, или я что-то не понимаю. Посмотрите iptables-save -c
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

10. Сообщение от romanegunkov (ok), 21-Апр-20, 22:51	+/–
И в довесок убедиться cat /proc/sys/net/ipv4/ip_forward cat /proc/sys/net/ipv4/conf/ppp0/forwarding cat /proc/sys/net/ipv4/conf/eth0/forwarding
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

11. Сообщение от Licha Morada (ok), 21-Апр-20, 22:58	+/–
>> Это ожидаемое поведение, что пакет от сервера фильтрации к обычному серверу, с >> адресом отправителя клиента, не доходит. Такой пакет имеет все признаки попытки >> атаки IP spoofing, его мог зарезать кто угодно по дороге, и >> правильно сделал. > Я не желаю использовать атаку IP spoofing. Если её блокируют, может создать > между серверами что-то на подобии VPN? Да, можно. Но если у вас есть доступ на обычный сервер, чтобы настроить VPN и маршрутизацию, то было бы проще научить его принимать пакеты с адресом отправителя фильтрующего сервера. >> В принципе ваш Ubuntu можно заставить выпихивать этот пакет наружу, гуглите как >> проводить атаку IP Spoofing по UDP. Но я бы не расчитывал >> на то что он дойдёт до обычного сервера. > Я являюсь полным владельцем физического сервера, исключение - провайдер сети. Так и зарежет Spoofing атаку провайдер. Какой угодно из N между серверами. >> Там можт быть нюанс, если пакет прошёл forwarding, но оказывается что egress >> interface одна и та-же что и ingress interface, система норовит не >> пересылать пакет на шлюз, а ответить пакетом ICMP Redirect. Не всегда >> так, зависит от реализации. Кстати, возможно, именно это вы интерпретируете как >> "дропается сетевой картой". > Я не могу Вам этого сказать. Уточните более подробную информацию - отвечу. Если интересно, смотрите сниффером на трафик ICMP на фильтрующем сервере. К решению проблены это имеет весьма отдалённое отношение. > Я хочу реализовать данную топологию из-за защиты, чтобы злоумышленник не знал реального > IP адреса сервера. Чтобы не знал адрес какого сервера, "обычного"? Это бесполезно. По вашей схеме, если обычный сервер ответит клиенту помимо фильтрующего сервера, то в злоумышленник увидит его настоящий адрес в заголовках пакета. И вообще эффект Стрейзанд будет. Публикуйте сервис для клиентов на вашем "фильтрующем сервере". Обычный сервер пусть принимает подключения от него и нечего не знает о конкретных клиентах. Если критично различать клиентов по IP, то стройте оверлейную сеть. Пусть они подключаются к "фильтрующему серверу" по VPN, с приватными адресами и аутентификацией, а тот по VPN же будет перенаправлять траффик на приватный адрес обычного сервера. Как обратный прокси на периметере локалки. Если критична задержка, ищите сервера поближе друг к другу и к клиентам. Жонглирование ассиметричными маршрутами с закосом на спуфинг вам только добавит проблем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #14

12. Сообщение от Licha Morada (ok), 21-Апр-20, 23:01	+/–
> Послушайте снифером на конечном сервере. Кажется дропится не на сервере фильтрации, а > на конечном. Может даже не дропится, а отсылается клиенту, но получается > нестыковка сессии по IP адресам. Нет там никакой сессии, UDP же. > Поставьте на > конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку > отрабатывал, должно заработать. Конечный сервер и сервер фильтрации в разных сетях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #13

13. Сообщение от romanegunkov (ok), 21-Апр-20, 23:21	+/–
>> Послушайте снифером на конечном сервере. Кажется дропится не на сервере фильтрации, а >> на конечном. Может даже не дропится, а отсылается клиенту, но получается >> нестыковка сессии по IP адресам. > Нет там никакой сессии, UDP же. Давно это было, может я и забыл какие-то нюансы. Но, кажется, может зависеть от реализации. Если отправить запрос на один адрес, а получить ответ с другого, возможно будет проблемой. А "сессия" в iptables даже для ICMP применяется, правда на SNAT, именно сессия в кавычках. >> Поставьте на >> конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку >> отрабатывал, должно заработать. > Конечный сервер и сервер фильтрации в разных сетях. Да, наводит на мысль, что в обратку SNAT, надо бы. Как тут в примере 5.7 http://linux-ip.net/html/nat-dnat.html Но тут пока до всего этого не дошло. Пока просто до конечного сервака пакет не доходит, как будто форвардинг не работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #15

14. Сообщение от WeSTMan (ok), 21-Апр-20, 23:27	+/–
>[оверквотинг удален] > увидит его настоящий адрес в заголовках пакета. И вообще эффект Стрейзанд > будет. > Публикуйте сервис для клиентов на вашем "фильтрующем сервере". Обычный сервер пусть принимает > подключения от него и нечего не знает о конкретных клиентах. > Если критично различать клиентов по IP, то стройте оверлейную сеть. Пусть они > подключаются к "фильтрующему серверу" по VPN, с приватными адресами и аутентификацией, > а тот по VPN же будет перенаправлять траффик на приватный адрес > обычного сервера. Как обратный прокси на периметере локалки. > Если критична задержка, ищите сервера поближе друг к другу и к клиентам. > Жонглирование ассиметричными маршрутами с закосом на спуфинг вам только добавит проблем. Я могу залить файл pcap для wireshark, там видно весь трафик, который проходит через сервер фильтрации. Отправляю пакет на сервер фильтрации, в ответ получаю Получаю ICMP Destination unreachable (port unreachable) И опять же на сетевом интерфейсе ловлю dropped venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00           inet addr:127.0.0.2  P-t-P:127.0.0.2  Bcast:0.0.0.0  Mask:255.255.255.255           UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1           RX packets:5728 errors:0 dropped:0 overruns:0 frame:0           TX packets:4958 errors:0 dropped:19 overruns:0 carrier:0           collisions:0 txqueuelen:0           RX bytes:330057 (330.0 KB)  TX bytes:421280 (421.2 KB) Отправил 19 пакетов и они все оказались dropped. До конечного сервера пакет так и не дошёл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #16

15. Сообщение от WeSTMan (ok), 21-Апр-20, 23:36	+/–
>[оверквотинг удален] > ответ с другого, возможно будет проблемой. А "сессия" в iptables даже > для ICMP применяется, правда на SNAT, именно сессия в кавычках. >>> Поставьте на >>> конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку >>> отрабатывал, должно заработать. >> Конечный сервер и сервер фильтрации в разных сетях. > Да, наводит на мысль, что в обратку SNAT, надо бы. Как тут > в примере 5.7 http://linux-ip.net/html/nat-dnat.html > Но тут пока до всего этого не дошло. Пока просто до конечного > сервака пакет не доходит, как будто форвардинг не работает. Да, пока пакет не может еще отправится на конечный сервер))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #19

16. Сообщение от Licha Morada (ok), 21-Апр-20, 23:40	+/–
> Отправил 19 пакетов и они все оказались dropped. > До конечного сервера пакет так и не дошёл. Ну, значит dropped. Тогда надо смотреть на флаг ip_forward, таблицу маршрутизации и правила netfilter, как советуют ниже. Если название интерфейса venet0 указывает на то что это живёт в контейнере OpenVZ, то ещё можно смотреть какие правила применяет хостовоая система, можно ожидать что она дропает попытки спуфинга гостевого контейнера. Я про детали OpenVZ не в курсе. В этой ветке, вам совет пересмотреть архитектуру решения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #17, #18

17. Сообщение от WeSTMan (ok), 22-Апр-20, 00:13	+/–
>> Отправил 19 пакетов и они все оказались dropped. >> До конечного сервера пакет так и не дошёл. > Ну, значит dropped. Тогда надо смотреть на флаг ip_forward, таблицу маршрутизации и > правила netfilter, как советуют ниже. > Если название интерфейса venet0 указывает на то что это живёт в контейнере > OpenVZ, то ещё можно смотреть какие правила применяет хостовоая система, можно > ожидать что она дропает попытки спуфинга гостевого контейнера. Я про детали > OpenVZ не в курсе. > В этой ветке, вам совет пересмотреть архитектуру решения. Можете что-нибудь подсказать? Суть такова, чтобы был неизвестный реальный IP сервера и канал выше, чем у сервера. ipv4 forward = 1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #21, #23

18. Сообщение от WeSTMan (ok), 22-Апр-20, 00:19	+/–
>> Отправил 19 пакетов и они все оказались dropped. >> До конечного сервера пакет так и не дошёл. > Ну, значит dropped. Тогда надо смотреть на флаг ip_forward, таблицу маршрутизации и > правила netfilter, как советуют ниже. > Если название интерфейса venet0 указывает на то что это живёт в контейнере > OpenVZ, то ещё можно смотреть какие правила применяет хостовоая система, можно > ожидать что она дропает попытки спуфинга гостевого контейнера. Я про детали > OpenVZ не в курсе. > В этой ветке, вам совет пересмотреть архитектуру решения. iptables -L -v -n Chain INPUT (policy ACCEPT 10115 packets, 552K bytes) pkts bytes target     prot opt in     out     source               destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target     prot opt in     out     source               destination    21  1008 ACCEPT     udp  --  *      *       0.0.0.0/0            DestIP       udp dpt:27017 Chain OUTPUT (policy ACCEPT 9024 packets, 626K bytes) pkts bytes target     prot opt in     out     source               destination iptables -L -v -n -t nat Chain PREROUTING (policy ACCEPT 1296 packets, 61685 bytes) pkts bytes target     prot opt in     out     source               destination     6   288 DNAT       udp  --  *      *       0.0.0.0/0            IPFilter      udp dpt:27017 to:IPServer:27017 Chain POSTROUTING (policy ACCEPT 21 packets, 1248 bytes) pkts bytes target     prot opt in     out     source               destination Chain OUTPUT (policy ACCEPT 20 packets, 1200 bytes) pkts bytes target     prot opt in     out     source               destination
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #24

19. Сообщение от romanegunkov (ok), 22-Апр-20, 00:20	+/–
>[оверквотинг удален] >> для ICMP применяется, правда на SNAT, именно сессия в кавычках. >>>> Поставьте на >>>> конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку >>>> отрабатывал, должно заработать. >>> Конечный сервер и сервер фильтрации в разных сетях. >> Да, наводит на мысль, что в обратку SNAT, надо бы. Как тут >> в примере 5.7 http://linux-ip.net/html/nat-dnat.html >> Но тут пока до всего этого не дошло. Пока просто до конечного >> сервака пакет не доходит, как будто форвардинг не работает. > Да, пока пакет не может еще отправится на конечный сервер)) Дропы на tx, это не значит что не может отправиться, это значит что не может дойти. Сейчас не нашёл описания, но судя по коду в ядре, разные причины могут быть. Походу в роутинге что-то не так. Надо с этим разобраться для начала. Например поднять секондари ip совпадающий с клиентским и походить от него на сервер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #20

20. Сообщение от WeSTMan (ok), 22-Апр-20, 00:25	+/–
>[оверквотинг удален] >>> в примере 5.7 http://linux-ip.net/html/nat-dnat.html >>> Но тут пока до всего этого не дошло. Пока просто до конечного >>> сервака пакет не доходит, как будто форвардинг не работает. >> Да, пока пакет не может еще отправится на конечный сервер)) > Дропы на tx, это не значит что не может отправиться, это значит > что не может дойти. Сейчас не нашёл описания, но судя по > коду в ядре, разные причины могут быть. Походу в роутинге что-то > не так. Надо с этим разобраться для начала. > Например поднять секондари ip совпадающий с клиентским и походить от него на > сервер. Выше приложил вывод iptables, посмотрите, пожалуйста
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #22

21. Сообщение от romanegunkov (ok), 22-Апр-20, 00:35	+/–
>>> Отп > Можете что-нибудь подсказать? Суть такова, чтобы был неизвестный реальный IP сервера и > канал выше, чем у сервера. > ipv4 forward = 1 Вот этот вариант из примера должен подойти, только там опечатка, кажется, для SNAT --to-source, наверное, доджен быть. Full network address translation, as performed with iproute2 can be simulated with both netfilter SNAT and DNAT, with the potential benefit (and attendent resource consumption) of connection tracking. Example 5.7. Simulating full NAT with SNAT and DNAT [root@real-server]# iptables -t nat -A PREROUTING -d 205.254.211.17 -j DNAT --to-destination 192.168.100.17 [root@real-server]# iptables -t nat -A POSTROUTING -s 192.168.100.17 -j SNAT --to-destination 205.254.211.17
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

22. Сообщение от romanegunkov (ok), 22-Апр-20, 00:44	+/–
>[оверквотинг удален] >>>> Но тут пока до всего этого не дошло. Пока просто до конечного >>>> сервака пакет не доходит, как будто форвардинг не работает. >>> Да, пока пакет не может еще отправится на конечный сервер)) >> Дропы на tx, это не значит что не может отправиться, это значит >> что не может дойти. Сейчас не нашёл описания, но судя по >> коду в ядре, разные причины могут быть. Походу в роутинге что-то >> не так. Надо с этим разобраться для начала. >> Например поднять секондари ip совпадающий с клиентским и походить от него на >> сервер. > Выше приложил вывод iptables, посмотрите, пожалуйста Я к тому что для начала просто установить ip связность от клиента к серверу через промежуточный сервер. Именно простого роутинга добейтесь и только потом за iptables беритесь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #27

23. Сообщение от Licha Morada (ok), 22-Апр-20, 01:53	+/–
>> В этой ветке, вам совет пересмотреть архитектуру решения. > Можете что-нибудь подсказать? Суть такова, чтобы был неизвестный реальный IP сервера и > канал выше, чем у сервера. Подсказывать тут особо нечего. Концептуально вам поможет прокси, реализованный тем или иным методом. NAT-ом тоже можно, вам на правильную доку указали. С шириной каналов я бы не стал особо заморачиваться, пока не станет ясно от чего конкретно защищаемся и в каких масштабах оно происходит. Идите от простого с сложному, не пытайтесь все фичи за раз реализовать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

24. Сообщение от Licha Morada (ok), 22-Апр-20, 01:55	+/–
> iptables -L -v -n Никто forward не запрещает. Если у вас OpenVZ, дальше я бы стал копать там. А вообще, policy ACCEPT на публичном сервере это смело.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #25, #26

25. Сообщение от WeSTMan (ok), 22-Апр-20, 07:30	+/–
>> iptables -L -v -n > Никто forward не запрещает. Если у вас OpenVZ, дальше я бы стал > копать там. > А вообще, policy ACCEPT на публичном сервере это смело. ACCEPT везде, пока я не разберусь с маршрутизацией. Далее политики DROP поставлю по умолчанию
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

26. Сообщение от WeSTMan (ok), 22-Апр-20, 08:02	+/–
>> iptables -L -v -n > Никто forward не запрещает. Если у вас OpenVZ, дальше я бы стал > копать там. > А вообще, policy ACCEPT на публичном сервере это смело. Interfaces auto venet0 iface venet0 inet manual         up ifconfig venet0 up         up ifconfig venet0 127.0.0.2         up route add default dev venet0         down route del default dev venet0         down ifconfig venet0 down auto venet0:0 iface venet0:0 inet static         address IPFilter         netmask 255.255.255.255
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #30

27. Сообщение от WeSTMan (ok), 22-Апр-20, 08:22	+/–
>[оверквотинг удален] >>> Дропы на tx, это не значит что не может отправиться, это значит >>> что не может дойти. Сейчас не нашёл описания, но судя по >>> коду в ядре, разные причины могут быть. Походу в роутинге что-то >>> не так. Надо с этим разобраться для начала. >>> Например поднять секондари ip совпадающий с клиентским и походить от него на >>> сервер. >> Выше приложил вывод iptables, посмотрите, пожалуйста > Я к тому что для начала просто установить ip связность от клиента > к серверу через промежуточный сервер. Именно простого роутинга добейтесь и только > потом за iptables беритесь. Может поднять VPN? И через него трафик гонять?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #28

28. Сообщение от romanegunkov (ok), 22-Апр-20, 11:19	+/–
>[оверквотинг удален] >>>> что не может дойти. Сейчас не нашёл описания, но судя по >>>> коду в ядре, разные причины могут быть. Походу в роутинге что-то >>>> не так. Надо с этим разобраться для начала. >>>> Например поднять секондари ip совпадающий с клиентским и походить от него на >>>> сервер. >>> Выше приложил вывод iptables, посмотрите, пожалуйста >> Я к тому что для начала просто установить ip связность от клиента >> к серверу через промежуточный сервер. Именно простого роутинга добейтесь и только >> потом за iptables беритесь. > Может поднять VPN? И через него трафик гонять? Можно, конечно. Реализация несложная, можно разные варианты делать. Вам надо определиться как хотите сделать, нарисовать схему, пройтись по IP связности, сделать подмену IP адресов. VPN может вам дефолт маршрут подсунуть и схема заработает, но лучше добиться понимания элементарной статической маршрутизации, а потом можно какой-нибидь WireGuard прикрутить и прям в нём завести правила iptables, там сможете и на серую сеть перейти, чтобы никаким образм не светануть белым адресом сервера, раз уж это так важно, да и нагрузку он небольую даёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #29

29. Сообщение от WeSTMan (ok), 22-Апр-20, 11:33	+1 +/–
>[оверквотинг удален] >>> потом за iptables беритесь. >> Может поднять VPN? И через него трафик гонять? > Можно, конечно. Реализация несложная, можно разные варианты делать. Вам надо определиться > как хотите сделать, нарисовать схему, пройтись по IP связности, сделать подмену > IP адресов. VPN может вам дефолт маршрут подсунуть и схема заработает, > но лучше добиться понимания элементарной статической маршрутизации, а потом можно какой-нибидь > WireGuard прикрутить и прям в нём завести правила iptables, там сможете > и на серую сеть перейти, чтобы никаким образм не светануть белым > адресом сервера, раз уж это так важно, да и нагрузку он > небольую даёт. Сделал VPN, все заработало. Только приложение критично к задержке и пакетам. Будут ли проблемы, если использовать VPN?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

30. Сообщение от Licha Morada (ok), 22-Апр-20, 18:27	+/–
Вы подтвердите или опровергните. Ваш фильтрующий сервер не виртуальная машина, а какой-то контейнер? Какой, OpenVZ? Если да, то: https://lists.openvz.org/pipermail/users/2016-April/006845.html The filters are following: *a) IP spoofing protection:* Drops packets from guest with source IP address different from the guest's ones. This filter works only all of the following is true: - dhcp for VM is OFF - AutoApply for VM is ON - VM has non-empty list of IP addresses It is set by: /prlctl set VM --de//vice-set net0 --ipfilter yes/ Но, как вы наверное помните, я рекомендовал отказаться от этого метода в пользу более наглядного прокси.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #31

31. Сообщение от WeSTMan (ok), 22-Апр-20, 21:42	+/–
>[оверквотинг удален] > Drops packets from guest with source IP address different from the > guest's ones. > This filter works only all of the following is true: > - dhcp for VM is OFF > - AutoApply for VM is ON > - VM has non-empty list of IP addresses > It is set by: > /prlctl set VM --de//vice-set net0 --ipfilter yes/ > Но, как вы наверное помните, я рекомендовал отказаться от этого метода в > пользу более наглядного прокси. Использую OpenVPN без шифрования. Спасибо за ответы!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

33. Сообщение от dmitriygessus (ok), 24-Май-20, 23:36	+/–
Лучше сразу делать все это при покупке пакета, у вас явно ошибка в установке. У меня Tinc стоит сразу впн  настроили не было проблем. Вам рекомендую все же провести перелинковку впн, если он входит в ваш пакет файрвола.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема