Назад | Перейти на главную страницу

Не удается подключиться к серверу ipsec, запущенному в докере за брандмауэром

У меня есть установка, которую я не считаю очень сложной, но не могу заставить ее работать.

Рабочая установка: Сервер ipsec, работающий в докере, подключенном напрямую к Интернету. Клиенты могут подключиться.

Не работает настройка: Сервер ipsec, работающий в докере, подключенном к Интернету за брандмауэром. у меня есть node1 на сервере esxi, который действует как internet gateway и node2 работает на том же сервере esxi, на котором ipsec server running in a docker.

Я открыл порты 500 и 4500 в узле 1 (интернет-шлюз) и перенаправил на узел 2 (запущен сервер ipsec в докере).
Проблема, с которой я столкнулся, заключается в том, что клиенты не могут подключиться.

Ниже приведено правило брандмауэра iptables

-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 500 -j ACCEPT
-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 4500 -j ACCEPT
-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 53 -j ACCEPT

Не могу определить, чего еще не хватает. Может ли кто-нибудь посоветовать, верна ли моя установка и почему она не работает?

Ваши правила iptables из комментариев к вопросу:

-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 500 -j ACCEPT 
-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 4500 -j ACCEPT 
-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 53 -j ACCEPT

Я действительно не понимаю, зачем вам переадресовывать порт 53: сделать DNS-сервер вашей внутренней сети видимым для всех в Интернете требует атак с подменой DNS - не лучшая идея. После подключения к VPN вы сможете безопасно получить к нему доступ через канал VPN без каких-либо правил брандмауэра на хосте интернет-шлюза. Я бы рекомендовал вам удалить правило FORWARD для UDP-порта 53, если у вас нет для этого действительно веской причины.

Правила ACCEPT в таблице фильтров iptables FORWARD позволяют системе маршрутизировать только трафик, который уже правильно адресован месту назначения. Поскольку ваш IPsec-сервер имеет адрес 192.168. *. *, Ваши клиенты не могут использовать этот адрес для доступа к нему через Интернет.

Вместо этого вам необходимо настроить клиентов на использование общедоступного IP-адреса сервера интернет-шлюза, а серверу шлюза нужны некоторые правила DNAT для перенаправления входящего трафика IPsec на сервер IPsec.

Эти правила необходимы на сервере интернет-шлюза в дополнение к уже имеющимся у вас правилам FORWARD:

-t nat -A PREROUTING -i <internet-side NIC> -p udp -m udp --dport 500 -j DNAT --to-destination 192.168.2.37:500
-t nat -A PREROUTING -i <internet-side NIC> -p udp -m udp --dport 4500 -j DNAT --to-destination 192.168.2.37:4500

Поскольку для IPsec, похоже, нет автоматического отслеживания соединений, вам также могут понадобиться обратные правила для исходящего трафика:

-t nat -A POSTROUTING -o <internet-side NIC> -s 192.168.2.37/32 -p udp -m udp --sport 500 -j SNAT --to-source <public IP>
-t nat -A POSTROUTING -o <internet-side NIC> -s 192.168.2.37/32 -p udp -m udp --sport 4500 -j SNAT --to-source <public IP> 

(На самом деле я не уверен насчет этой части: сначала попробуйте без этих правил и отслеживайте исходящие ответы на интерфейсе хоста интернет-шлюза, выходящем в Интернет. Если исходящие пакеты IPsec имеют 192.168.2.37 в качестве исходного IP-адреса, добавьте указанный выше 2 правила SNAT. Если исходный IP-адрес уже изменяется на общедоступный IP-адрес хоста интернет-шлюза, значит, правило DNAT успешно отслеживает соединение, и вам не понадобятся правила SNAT.)

Когда VPN-трафик от клиента достигает хоста интернет-шлюза (изначально используя его IP-адрес в качестве пункта назначения), входящий трафик сначала проходит через таблицу PREROUTING. Правила DNAT в них заменят адрес назначения. Затем входящий трафик проходит проверку маршрутизации: поскольку правило DNAT просто заменило IP-адрес назначения, трафик больше не адресуется самому хосту интернет-шлюза, поэтому он проходит через таблицу маршрутизации, а затем таблицу фильтров FORWARD. После этого он выходит из «внутреннего» интерфейса хоста интернет-шлюза по направлению к хосту IPsec.

Хост IPsec будет получать пакеты со своим собственным адресом 192.168.2.37 в заголовках IP-пакетов, но внутри зашифрованного содержимого будет исходный общедоступный IP-адрес сервера интернет-шлюза. Хост IPsec должен знать NAT_TRAVERSAL, чтобы справиться с этим успешно.

Когда узел IPsec отвечает, узел интернет-шлюза должен будет заменить исходный IP-адрес исходящих пакетов IPsec на действительный общедоступный IP-адрес.