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

Iptables + NAT и петля переадресации портов с одним сетевым интерфейсом

Я устанавливаю сервер доступа OpenVPN за своим NAT-сервером в AWS. В настоящее время у моего сервера NAT один сетевой интерфейс, и я пытаюсь перенаправить некоторые порты на сервер доступа OpenVPN.

Переадресация портов работает, и я могу подключиться к своему серверу доступа OpenVPN через браузер или клиент OpenVPN (установить соединение VPN).

Теперь проблема в том, что OpenVPN Access Server использует порты 443 и 943 для HTTPS. Но когда я пытаюсь получить доступ к веб-сайтам HTTPS при подключении к VPN, все сертификаты HTTPS становятся недействительными, поскольку соединение HTTPS перенаправляется обратно в OpenVPN AS.

Вот мои правила IPTABLES:

iptables -t nat -A POSTROUTING -o eth0 -s 172.16.0.0/24 -j MASQUERADE

iptables -A FORWARD -m state -p tcp -d 172.16.0.213 --dport 943 --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 943 -j DNAT --to-destination 172.16.0.213:943
iptables -t nat -A POSTROUTING -p tcp -d 172.16.0.213 --dport 943 -j SNAT --to-source 172.16.0.213

iptables -A FORWARD -m state -p tcp -d 172.16.0.213 --dport 443 --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 172.16.0.213:443
iptables -t nat -A POSTROUTING -p tcp -d 172.16.0.213 --dport 443 -j SNAT --to-source 172.16.0.213

iptables -t nat -A PREROUTING -p udp -i eth0 -d 172.16.0.213 --dport 1194 -j DNAT --to-destination 172.16.0.213:1194

Вывод iptables -t nat -L:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             anywhere             tcp dpt:https to:172.16.0.213:443
DNAT       udp  --  anywhere             ip-172-16-0-213.eu-west-1.compute.internal  udp dpt:openvpn to:172.16.0.213:1194
DNAT       tcp  --  anywhere             anywhere             tcp dpt:943 to:172.16.0.213:943

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
SNAT       tcp  --  anywhere             ip-172-16-0-213.eu-west-1.compute.internal  tcp dpt:https to:172.16.0.213
SNAT       tcp  --  anywhere             ip-172-16-0-213.eu-west-1.compute.internal  tcp dpt:943 to:172.16.0.213
MASQUERADE  all  --  ip-172-16-0-0.eu-west-1.compute.internal/24  anywhere

Можно ли еще сделать это с одним сетевым интерфейсом и решить с помощью iptables?

По сути, я хочу сказать, что «iptables, пожалуйста, не выполняйте перенаправление портов изнутри наружу», в настоящее время перенаправление портов входит в «цикл».

Спасибо за любую помощь и идеи!

iptables -t nat -I PREROUTING  -i eth1 -p tcp --dport 443 -j DNAT --to 192.168.0.1:943
iptables -t nat -I POSTROUTING -o eth1 -p tcp -d 192.168.0.1 --dport 943 -j MASQUERADE

Замените 443 общедоступным портом для прослушивания, 192.168.0.1 другим вашим сервером и 943 прослушивающим портом другого сервера. Заменить eth1 с вашим интерфейсом. Имейте в виду, что некоторые конфигурации имеют виртуальные интерфейсы, поэтому может потребоваться что-то вроде vlan1 или ppp0.

Первая строка - это основное правило пересылки пакетов. Но поскольку пакеты будут иметь неповрежденный адрес источника, это приведет к асимметричной маршрутизации, которая нарушится из-за этого сетевого фильтра с отслеживанием состояния. Отсюда следует вторая строка - замените адрес источника пакета на один из этого сервера. Это дает соединению небольшой обходной путь, заставляя его дважды проходить через этот сервер, но избавляет от асимметрии, позволяющей этому работать.

Это решение полагается на порты, используемые для определения того, какие соединения из первого правила используются вторым. Это будет нормально с вашей простой настройкой, но для всех, кто пытается реализовать это в маршрутизаторе, также имея за ним пользователей, пытающихся получить доступ к тому же ресурсу, стоит отметить, что MARK следует использовать функцию netfilter, чтобы сообщить второму MASQUERADE строка, которую он должен обрабатывать, а не только порт. Имея MASQUERADE применительно ко всему может привести к нежелательному поведению.

Вам следует пересмотреть, требуются ли какие-либо правила DNAT. Вы не указали причину для этого. То же самое и с правилами SNAT, поскольку они заставляют все соединения отображаться локальными без какой-либо ясной причины.

Если требуются DNAT, используйте connmark, чтобы пометить и восстановить пакеты, поступающие из интерфейса openvpn-as tun в цепочке PREROUTING таблицы mangle, и добавьте -m mark ! --mark <the mark you set> условие на вашем nat PREROUTING порт 443 DNAT правило. Это предотвратит обратное DNAT-соединение исходящих соединений на ваше устройство.


Отредактировано на основе вашей сети:

Удалите все правила SNAT. Вы не можете проверять соединения на сервере openvpn-as с этим.

Убедитесь, что сервер openvpn-as направляет соединения обратно через ваш шлюз. Установите либо маршрут по умолчанию к шлюзу (простой), либо маршрут политики (сложный).

Измените все правила DNAT, чтобы игнорировать диапазон локальных источников, т.е. ! -s 172.16.0.0/24. Если openvpn-as также не выполняет MASQUERADE или SNAT, вам может потребоваться добавить диапазоны IP-адресов VPN, а также дополнительные ! -s base/mask за диапазон.