- Перенаправление трафика (forwarding), Licha Morada, 19:04 , 21-Апр-20 (1)
Какой линукс? Линукс ли?> Всем привет. Хочу поставить сервер, который будет выступать в роли фильтров между > клиентом и сервером. > Сервер фильтрации должен менять адрес назначения на адрес сервера и в обратном > порядке. A? Постарайтесь нарисовать топологию, или придумайте им всем внятные имена и адреса чтобы описать словами. Кто с кем в одной сети, а кто в Интернете? Кто чей default gateway? > Но когда я пытаюсь послать пакет на сервер фильтрации, он приходит, переходит > в цепочку FORWARD и дропается самой сетевой картой. Соответственно пакет сервер > не принимает. Вы хотите слать пакеты UDP с клиента на фильтры, но чтобы потом он попадал на сервер с адресом отправителя клиента? Рекомендую сделать шаг назад и сформулировать, чего вы, собственно, стремитесь достичь. > НО, если я поменяю адрес источника клиента на адрес сервера фильтров, то > пакет будет передан серверу, но не с IP клиента, а с > IP фильтров. А мне нужен, чтобы пересылался IP адрес клиента. > Помогите, пожалуйста, с решением вопроса! Чем смотрите, сниффером на сервере?
- Перенаправление трафика (forwarding), WeSTMan, 20:42 , 21-Апр-20 (2)
В принципе ожидал, что будет не совсем понятно. У нас есть 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
- Перенаправление трафика (forwarding), Licha Morada, 21:42 , 21-Апр-20 (3)
> В принципе ожидал, что будет не совсем понятно. > У нас есть 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. Не всегда так, зависит от реализации. Кстати, возможно, именно это вы интерпретируете как "дропается сетевой картой".
- Перенаправление трафика (forwarding), WeSTMan, 22:05 , 21-Апр-20 (4)
> Замечательно, значит, все в Интернете в разных сетях.Да > Это вы делаете с помощью правила 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 адреса сервера. Плюсом - сервер фильтрации имеет большую пропускную способность, чем сервер. И я уверен, что всякие дурочки не смогут забить канал. Не говорю, конечно, о целенаправленных атаках, где море трафика, типо бот нет сети. Надеюсь продолжим дальнейшее общение.
- Перенаправление трафика (forwarding), Licha Morada, 22:58 , 21-Апр-20 (11)
>> Это ожидаемое поведение, что пакет от сервера фильтрации к обычному серверу, с >> адресом отправителя клиента, не доходит. Такой пакет имеет все признаки попытки >> атаки IP spoofing, его мог зарезать кто угодно по дороге, и >> правильно сделал. > Я не желаю использовать атаку IP spoofing. Если её блокируют, может создать > между серверами что-то на подобии VPN?Да, можно. Но если у вас есть доступ на обычный сервер, чтобы настроить VPN и маршрутизацию, то было бы проще научить его принимать пакеты с адресом отправителя фильтрующего сервера. >> В принципе ваш Ubuntu можно заставить выпихивать этот пакет наружу, гуглите как >> проводить атаку IP Spoofing по UDP. Но я бы не расчитывал >> на то что он дойдёт до обычного сервера. > Я являюсь полным владельцем физического сервера, исключение - провайдер сети. Так и зарежет Spoofing атаку провайдер. Какой угодно из N между серверами. >> Там можт быть нюанс, если пакет прошёл forwarding, но оказывается что egress >> interface одна и та-же что и ingress interface, система норовит не >> пересылать пакет на шлюз, а ответить пакетом ICMP Redirect. Не всегда >> так, зависит от реализации. Кстати, возможно, именно это вы интерпретируете как >> "дропается сетевой картой". > Я не могу Вам этого сказать. Уточните более подробную информацию - отвечу. Если интересно, смотрите сниффером на трафик ICMP на фильтрующем сервере. К решению проблены это имеет весьма отдалённое отношение. > Я хочу реализовать данную топологию из-за защиты, чтобы злоумышленник не знал реального > IP адреса сервера. Чтобы не знал адрес какого сервера, "обычного"? Это бесполезно. По вашей схеме, если обычный сервер ответит клиенту помимо фильтрующего сервера, то в злоумышленник увидит его настоящий адрес в заголовках пакета. И вообще эффект Стрейзанд будет. Публикуйте сервис для клиентов на вашем "фильтрующем сервере". Обычный сервер пусть принимает подключения от него и нечего не знает о конкретных клиентах. Если критично различать клиентов по IP, то стройте оверлейную сеть. Пусть они подключаются к "фильтрующему серверу" по VPN, с приватными адресами и аутентификацией, а тот по VPN же будет перенаправлять траффик на приватный адрес обычного сервера. Как обратный прокси на периметере локалки. Если критична задержка, ищите сервера поближе друг к другу и к клиентам. Жонглирование ассиметричными маршрутами с закосом на спуфинг вам только добавит проблем.
- Перенаправление трафика (forwarding), WeSTMan, 23:27 , 21-Апр-20 (14)
>[оверквотинг удален] > увидит его настоящий адрес в заголовках пакета. И вообще эффект Стрейзанд > будет. > Публикуйте сервис для клиентов на вашем "фильтрующем сервере". Обычный сервер пусть принимает > подключения от него и нечего не знает о конкретных клиентах. > Если критично различать клиентов по 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. До конечного сервера пакет так и не дошёл.
- Перенаправление трафика (forwarding), Licha Morada, 23:40 , 21-Апр-20 (16)
> Отправил 19 пакетов и они все оказались dropped. > До конечного сервера пакет так и не дошёл.Ну, значит dropped. Тогда надо смотреть на флаг ip_forward, таблицу маршрутизации и правила netfilter, как советуют ниже. Если название интерфейса venet0 указывает на то что это живёт в контейнере OpenVZ, то ещё можно смотреть какие правила применяет хостовоая система, можно ожидать что она дропает попытки спуфинга гостевого контейнера. Я про детали OpenVZ не в курсе. В этой ветке, вам совет пересмотреть архитектуру решения.
- Перенаправление трафика (forwarding), WeSTMan, 00:13 , 22-Апр-20 (17)
>> Отправил 19 пакетов и они все оказались dropped. >> До конечного сервера пакет так и не дошёл. > Ну, значит dropped. Тогда надо смотреть на флаг ip_forward, таблицу маршрутизации и > правила netfilter, как советуют ниже. > Если название интерфейса venet0 указывает на то что это живёт в контейнере > OpenVZ, то ещё можно смотреть какие правила применяет хостовоая система, можно > ожидать что она дропает попытки спуфинга гостевого контейнера. Я про детали > OpenVZ не в курсе. > В этой ветке, вам совет пересмотреть архитектуру решения.Можете что-нибудь подсказать? Суть такова, чтобы был неизвестный реальный IP сервера и канал выше, чем у сервера. ipv4 forward = 1
- Перенаправление трафика (forwarding), romanegunkov, 00:35 , 22-Апр-20 (21)
>>> Отп > Можете что-нибудь подсказать? Суть такова, чтобы был неизвестный реальный 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
- Перенаправление трафика (forwarding), Licha Morada, 01:53 , 22-Апр-20 (23)
>> В этой ветке, вам совет пересмотреть архитектуру решения. > Можете что-нибудь подсказать? Суть такова, чтобы был неизвестный реальный IP сервера и > канал выше, чем у сервера.Подсказывать тут особо нечего. Концептуально вам поможет прокси, реализованный тем или иным методом. NAT-ом тоже можно, вам на правильную доку указали. С шириной каналов я бы не стал особо заморачиваться, пока не станет ясно от чего конкретно защищаемся и в каких масштабах оно происходит. Идите от простого с сложному, не пытайтесь все фичи за раз реализовать.
- Перенаправление трафика (forwarding), WeSTMan, 00:19 , 22-Апр-20 (18)
>> Отправил 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
- Перенаправление трафика (forwarding), Licha Morada, 01:55 , 22-Апр-20 (24)
> iptables -L -v -n Никто forward не запрещает. Если у вас OpenVZ, дальше я бы стал копать там. А вообще, policy ACCEPT на публичном сервере это смело.
- Перенаправление трафика (forwarding), WeSTMan, 07:30 , 22-Апр-20 (25)
>> iptables -L -v -n > Никто forward не запрещает. Если у вас OpenVZ, дальше я бы стал > копать там. > А вообще, policy ACCEPT на публичном сервере это смело.ACCEPT везде, пока я не разберусь с маршрутизацией. Далее политики DROP поставлю по умолчанию
- Перенаправление трафика (forwarding), WeSTMan, 08:02 , 22-Апр-20 (26)
>> 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
- Перенаправление трафика (forwarding), Licha Morada, 18:27 , 22-Апр-20 (30)
Вы подтвердите или опровергните. Ваш фильтрующий сервер не виртуальная машина, а какой-то контейнер? Какой, 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/ Но, как вы наверное помните, я рекомендовал отказаться от этого метода в пользу более наглядного прокси.
- Перенаправление трафика (forwarding), WeSTMan, 21:42 , 22-Апр-20 (31)
>[оверквотинг удален] > 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 без шифрования. Спасибо за ответы!
- Перенаправление трафика (forwarding), romanegunkov, 22:07 , 21-Апр-20 (5)
Послушайте снифером на конечном сервере. Кажется дропится не на сервере фильтрации, а на конечном. Может даже не дропится, а отсылается клиенту, но получается нестыковка сессии по IP адресам. По сниферу будет видно. Поставьте на конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку отрабатывал, должно заработать.Или для теста маршрут для конкретного клиента пропишите через сервер фильтрации, если опасаетесь дефолт менять или потерять доступ к серверу.
- Перенаправление трафика (forwarding), WeSTMan, 22:11 , 21-Апр-20 (6)
> Послушайте снифером на конечном сервере. Кажется дропится не на сервере фильтрации, а > на конечном. Может даже не дпопится, а отсылается клиенту, но получается > нестыковка сессии по IP адресам. По сниферу будет видно. Поставьте на > конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку > отрабатывал, должно заработать.Конечный сервер ничего не получает. Отлавливал через tshark
- Перенаправление трафика (forwarding), romanegunkov, 22:29 , 21-Апр-20 (7)
>> Послушайте снифером на конечном сервере. Кажется дропится не на сервере фильтрации, а >> на конечном. Может даже не дпопится, а отсылается клиенту, но получается >> нестыковка сессии по IP адресам. По сниферу будет видно. Поставьте на >> конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку >> отрабатывал, должно заработать. > Конечный сервер ничего не получает. Отлавливал через tshark Чудеса. А в tshark по каким-то критериям отлавливаете? Попробуйте в iptables прописать порт куда перекидывать: --to-destination IPServer:27017
- Перенаправление трафика (forwarding), WeSTMan, 22:31 , 21-Апр-20 (8)
>>> Послушайте снифером на конечном сервере. Кажется дропится не на сервере фильтрации, а >>> на конечном. Может даже не дпопится, а отсылается клиенту, но получается >>> нестыковка сессии по IP адресам. По сниферу будет видно. Поставьте на >>> конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку >>> отрабатывал, должно заработать. >> Конечный сервер ничего не получает. Отлавливал через tshark > Чудеса. > А в tshark по каким-то критериям отлавливаете? > Попробуйте в iptables прописать порт куда перекидывать: --to-destination IPServer:27017 Все это дело тестировал. tshark -f "port 27017" -i ppp0 Я писал, что пакеты дропаются еще на сервере фильтрации. Я послал 13 пакетов, ввел ifconfig и увидел dropped 13 Хотя все правила ACCEPT и форвардинг работает
- Перенаправление трафика (forwarding), romanegunkov, 22:45 , 21-Апр-20 (9)
>[оверквотинг удален] >>>> отрабатывал, должно заработать. >>> Конечный сервер ничего не получает. Отлавливал через tshark >> Чудеса. >> А в tshark по каким-то критериям отлавливаете? >> Попробуйте в iptables прописать порт куда перекидывать: --to-destination IPServer:27017 > Все это дело тестировал. > tshark -f "port 27017" -i ppp0 > Я писал, что пакеты дропаются еще на сервере фильтрации. > Я послал 13 пакетов, ввел ifconfig и увидел dropped 13 > Хотя все правила ACCEPT и форвардинг работает Может есть правило дропать, или я что-то не понимаю. Посмотрите iptables-save -c - Перенаправление трафика (forwarding), romanegunkov, 22:51 , 21-Апр-20 (10)
И в довесок убедитьсяcat /proc/sys/net/ipv4/ip_forward cat /proc/sys/net/ipv4/conf/ppp0/forwarding cat /proc/sys/net/ipv4/conf/eth0/forwarding
- Перенаправление трафика (forwarding), Licha Morada, 23:01 , 21-Апр-20 (12)
> Послушайте снифером на конечном сервере. Кажется дропится не на сервере фильтрации, а > на конечном. Может даже не дропится, а отсылается клиенту, но получается > нестыковка сессии по IP адресам.Нет там никакой сессии, UDP же. > Поставьте на > конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку > отрабатывал, должно заработать. Конечный сервер и сервер фильтрации в разных сетях.
- Перенаправление трафика (forwarding), romanegunkov, 23:21 , 21-Апр-20 (13)
>> Послушайте снифером на конечном сервере. Кажется дропится не на сервере фильтрации, а >> на конечном. Может даже не дропится, а отсылается клиенту, но получается >> нестыковка сессии по IP адресам. > Нет там никакой сессии, UDP же.Давно это было, может я и забыл какие-то нюансы. Но, кажется, может зависеть от реализации. Если отправить запрос на один адрес, а получить ответ с другого, возможно будет проблемой. А "сессия" в iptables даже для ICMP применяется, правда на SNAT, именно сессия в кавычках. >> Поставьте на >> конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку >> отрабатывал, должно заработать. > Конечный сервер и сервер фильтрации в разных сетях. Да, наводит на мысль, что в обратку SNAT, надо бы. Как тут в примере 5.7 http://linux-ip.net/html/nat-dnat.html Но тут пока до всего этого не дошло. Пока просто до конечного сервака пакет не доходит, как будто форвардинг не работает.
- Перенаправление трафика (forwarding), WeSTMan, 23:36 , 21-Апр-20 (15)
>[оверквотинг удален] > ответ с другого, возможно будет проблемой. А "сессия" в iptables даже > для ICMP применяется, правда на SNAT, именно сессия в кавычках. >>> Поставьте на >>> конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку >>> отрабатывал, должно заработать. >> Конечный сервер и сервер фильтрации в разных сетях. > Да, наводит на мысль, что в обратку SNAT, надо бы. Как тут > в примере 5.7 http://linux-ip.net/html/nat-dnat.html > Но тут пока до всего этого не дошло. Пока просто до конечного > сервака пакет не доходит, как будто форвардинг не работает.Да, пока пакет не может еще отправится на конечный сервер))
- Перенаправление трафика (forwarding), romanegunkov, 00:20 , 22-Апр-20 (19)
>[оверквотинг удален] >> для ICMP применяется, правда на SNAT, именно сессия в кавычках. >>>> Поставьте на >>>> конечном сервере default gw через сервер фильтрации, чтобы DNAT в обратку >>>> отрабатывал, должно заработать. >>> Конечный сервер и сервер фильтрации в разных сетях. >> Да, наводит на мысль, что в обратку SNAT, надо бы. Как тут >> в примере 5.7 http://linux-ip.net/html/nat-dnat.html >> Но тут пока до всего этого не дошло. Пока просто до конечного >> сервака пакет не доходит, как будто форвардинг не работает. > Да, пока пакет не может еще отправится на конечный сервер)) Дропы на tx, это не значит что не может отправиться, это значит что не может дойти. Сейчас не нашёл описания, но судя по коду в ядре, разные причины могут быть. Походу в роутинге что-то не так. Надо с этим разобраться для начала. Например поднять секондари ip совпадающий с клиентским и походить от него на сервер.
- Перенаправление трафика (forwarding), WeSTMan, 00:25 , 22-Апр-20 (20)
>[оверквотинг удален] >>> в примере 5.7 http://linux-ip.net/html/nat-dnat.html >>> Но тут пока до всего этого не дошло. Пока просто до конечного >>> сервака пакет не доходит, как будто форвардинг не работает. >> Да, пока пакет не может еще отправится на конечный сервер)) > Дропы на tx, это не значит что не может отправиться, это значит > что не может дойти. Сейчас не нашёл описания, но судя по > коду в ядре, разные причины могут быть. Походу в роутинге что-то > не так. Надо с этим разобраться для начала. > Например поднять секондари ip совпадающий с клиентским и походить от него на > сервер.Выше приложил вывод iptables, посмотрите, пожалуйста
- Перенаправление трафика (forwarding), romanegunkov, 00:44 , 22-Апр-20 (22)
>[оверквотинг удален] >>>> Но тут пока до всего этого не дошло. Пока просто до конечного >>>> сервака пакет не доходит, как будто форвардинг не работает. >>> Да, пока пакет не может еще отправится на конечный сервер)) >> Дропы на tx, это не значит что не может отправиться, это значит >> что не может дойти. Сейчас не нашёл описания, но судя по >> коду в ядре, разные причины могут быть. Походу в роутинге что-то >> не так. Надо с этим разобраться для начала. >> Например поднять секондари ip совпадающий с клиентским и походить от него на >> сервер. > Выше приложил вывод iptables, посмотрите, пожалуйста Я к тому что для начала просто установить ip связность от клиента к серверу через промежуточный сервер. Именно простого роутинга добейтесь и только потом за iptables беритесь.
- Перенаправление трафика (forwarding), WeSTMan, 08:22 , 22-Апр-20 (27)
>[оверквотинг удален] >>> Дропы на tx, это не значит что не может отправиться, это значит >>> что не может дойти. Сейчас не нашёл описания, но судя по >>> коду в ядре, разные причины могут быть. Походу в роутинге что-то >>> не так. Надо с этим разобраться для начала. >>> Например поднять секондари ip совпадающий с клиентским и походить от него на >>> сервер. >> Выше приложил вывод iptables, посмотрите, пожалуйста > Я к тому что для начала просто установить ip связность от клиента > к серверу через промежуточный сервер. Именно простого роутинга добейтесь и только > потом за iptables беритесь.Может поднять VPN? И через него трафик гонять?
- Перенаправление трафика (forwarding), romanegunkov, 11:19 , 22-Апр-20 (28)
>[оверквотинг удален] >>>> что не может дойти. Сейчас не нашёл описания, но судя по >>>> коду в ядре, разные причины могут быть. Походу в роутинге что-то >>>> не так. Надо с этим разобраться для начала. >>>> Например поднять секондари ip совпадающий с клиентским и походить от него на >>>> сервер. >>> Выше приложил вывод iptables, посмотрите, пожалуйста >> Я к тому что для начала просто установить ip связность от клиента >> к серверу через промежуточный сервер. Именно простого роутинга добейтесь и только >> потом за iptables беритесь. > Может поднять VPN? И через него трафик гонять?Можно, конечно. Реализация несложная, можно разные варианты делать. Вам надо определиться как хотите сделать, нарисовать схему, пройтись по IP связности, сделать подмену IP адресов. VPN может вам дефолт маршрут подсунуть и схема заработает, но лучше добиться понимания элементарной статической маршрутизации, а потом можно какой-нибидь WireGuard прикрутить и прям в нём завести правила iptables, там сможете и на серую сеть перейти, чтобы никаким образм не светануть белым адресом сервера, раз уж это так важно, да и нагрузку он небольую даёт.
- Перенаправление трафика (forwarding), WeSTMan, 11:33 , 22-Апр-20 (29) +1
>[оверквотинг удален] >>> потом за iptables беритесь. >> Может поднять VPN? И через него трафик гонять? > Можно, конечно. Реализация несложная, можно разные варианты делать. Вам надо определиться > как хотите сделать, нарисовать схему, пройтись по IP связности, сделать подмену > IP адресов. VPN может вам дефолт маршрут подсунуть и схема заработает, > но лучше добиться понимания элементарной статической маршрутизации, а потом можно какой-нибидь > WireGuard прикрутить и прям в нём завести правила iptables, там сможете > и на серую сеть перейти, чтобы никаким образм не светануть белым > адресом сервера, раз уж это так важно, да и нагрузку он > небольую даёт.Сделал VPN, все заработало. Только приложение критично к задержке и пакетам. Будут ли проблемы, если использовать VPN?
- Перенаправление трафика (forwarding), dmitriygessus, 23:36 , 24-Май-20 (33)
Лучше сразу делать все это при покупке пакета, у вас явно ошибка в установке. У меня Tinc стоит сразу впн настроили не было проблем. Вам рекомендую все же провести перелинковку впн, если он входит в ваш пакет файрвола.
|