Iptables: переадресация порта с другого сервера, кроме шлюза - PullRequest
Новая
       41

Iptables: переадресация порта с другого сервера, кроме шлюза

0 голосов
/ 06 июля 2011

Вот ситуация.У нас есть несколько серверов в нашей интрасети 192.168.1.0/24 Один из них является шлюзом по умолчанию для всех из них и имеет два интерфейса ($ GATEWAY_INTERNAL_IP и $ GATEWAY_EXTERNAL_IP).

У нас также есть другой сервер PUBLICHOST2, который имеет дваIP также $ PUBLICHOST_EXTERNAL_IP и $ PUBLICHOST_INTERNAL_IP.

У нас есть третий сервер SERVER, который имеет только один IP $ PRIVIP и связывается с портом $ PORT.

То, что мы хотим, - это возможность пересылкипорт $ PORT на $ PUBLICHOST_EXTERNAL_IP для размещения SERVER на $ PRIVIP.

Но когда мы выполняем переадресацию портов, используя iptables на PUBLICHOST2, SERVER получает запрос, но ответ проходит через шлюз, и соединение не удается.

Как мы можем правильно выполнить настройку, чтобы ответ мог возвращаться через PUBLICHOST2?

Спасибо

Ответы [ 3 ]

1 голос
/ 06 июля 2011

Возможно, вам потребуется установить переадресацию для интерфейса.Попробуйте команду tne. 

sysctl -w net.ipv4.conf.eth0.forwarding=1

Если вам нужна дополнительная помощь, обратитесь к документации по маршруту обратного маршрута или Shorewall FAQ .

0 голосов
/ 26 мая 2015

Я пытался сделать что-то подобное. Пройдя через несколько учебных пособий, которые, казалось, никогда не работали, пока я не подключил Wiresharked к соединению, чтобы обнаружить, что адрес назначения все еще был установлен на внешний IP-адрес (точно так же, как вы описали), я попытался использовать цепочку POSTROUTING, чтобы изменить IP-адрес источника для сервера: 

iptables -t nat -A POSTROUTING -p <tcp/udp> --dport <destination_port> -j SNAT --to <$PUBLICHOST_INTERNAL_IP>

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

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

С этим решением следует иметь в виду следующее: если вы когда-нибудь измените внутренний IP-адрес сервера брандмауэра, вам потребуется обновить указанное выше правило POSTROUTING. (Излишне говорить, что, вероятно, лучше всего, если сервер брандмауэра имеет статически назначенный внутренний IP-адрес).

0 голосов
/ 06 июля 2011

Ну вот что получается:

  • Client1 отправляет запрос в PublicHost
  • Поступают запросы, и правила iptables перенаправляют трафик (PAT) на сервер по правильному AppPort
  • Сервер отправляет ответ на Client1, который будет маршрутизирован шлюзом
  • Шлюз выполняет NAT и заменяет исходный IP своим собственным
  • Client1 или Client1sGateway получает IP-пакет со шлюзом в качестве источника, но ожидал IP-адрес PublicHost в поле источника IP-пакета.
  • В конечном итоге Client1 повторно отправляет SYN / ACK (кроме случаев, когда вы используете synproxy) в PublicHost, а затем сбрасывает соединение, когда истекает таймер, связанный с сетью.

Теперь, если вы хотите это исправить, вам следует направить весь TCP-трафик, идущий вне сервера и с портом источника AppPort, в PublicHost.

Если это не работает, PublicHost неправильно настроен. Обязательно протестируйте конфигурацию с помощью tcpdump.

...