Вопрос: Как сделать переадресацию порта с одного ip на другой ip в той же сети?


Я хотел бы сделать некоторые NAT в iptables, Таким образом, все пакеты, поступающие в 192.168.12.87 и порт 80 будут направлены в 192.168.12.77 порт 80,

Как это сделать с помощью iptables?

Или

Какие-нибудь другие способы добиться того же?


59
2018-04-03 17:58


Источник


@Matthewlfe. По какой-то причине мне нужно переслать весь запрос apache из (192.168.12.87) в (192.168.12.77). - sat
@Matthewlfe, у меня два производственных сервера. Один из них связан с открытым статическим IP-адресом. Из-за некоторых проблем с подключением я не могу подключиться к БД и другим системам из 192.168.12.87, Поэтому мне нужно направить весь запрос на 192.168.12.77, - sat
@lain, я не знаком с iptables, И я видел несколько примеров. Но, похоже, требуется два ethernet. Ссылка: revsys.com/writings/quicktips/nat.html - sat
Вы также можете использовать режим прокси в конфигурации вашего веб-сервера для отправки запросов на 192.168.12.77 с 192.168.12.87 (если ваш веб-сервер поддерживает его) - krisFR
askapache.com/htaccess/... - dmourati


Ответы:


Эти правила должны работать, предполагая, что iptables работает на сервере 192.168.12.87 :

#!/bin/sh

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -F
iptables -t nat -F
iptables -X

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77:80
iptables -t nat -A POSTROUTING -p tcp -d 192.168.12.77 --dport 80 -j SNAT --to-source 192.168.12.87

У вас должен быть входящий трафик DNAT на порт 80, но вам также потребуется SNAT-трафик.


Альтернативный (и лучший подход ИМХО):

В зависимости от вашего веб-сервера (Apache, NGinx) вы должны рассмотреть HTTP-прокси на своем внешнем сервере (192.168.12.87):


61
2018-04-03 21:46



Работает, пока ufw отключен, хотя порт разрешен в ufw, но если ufw включен, этот материал пересылки не работает, любая идея? - Sudhir N
Большой вопрос с большим ответом. В другом случае это полезно, если вам нужно временно перенаправить весь трафик, поступающий на одну услугу, скажем squid, на другой ip / port, чтобы выполнить некоторое обслуживание на исходном сервисе без необходимости перенастроить всех клиентов! Очень удобно! - PF4Public
«но вам также понадобится SNAT трафик». -> Ты спас мой день. спасибо - obayhan
Это решение не работает для меня. Мне нужно перейти от eth0 к виртуальной сети (virb0), которая используется гостем KVM. Я попробовал добавить опции -i и -o, но -o не разрешено для предварительной настройки. Какие-либо предложения? - lostiniceland


Причина, кажущаяся очевидной iptables -t nat -A PREROUTING -d 192.168.12.87 -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77 не будет работать, как маршрутизаторы будут перенаправлены.

Вы можете настроить правила, которые приведут к отправке пакетов на 192.168.12.87, чтобы просто быть NATted до 192.168.12.77, но 192.168.12.77 затем отправит ответы непосредственно клиенту. Эти ответы не будут проходить через хост, где правило iptables выполняет NAT, поэтому пакеты в одном направлении переводятся, но пакеты в другом направлении - нет.

Существует три подхода к решению этой проблемы.

  1. На первом хосте не просто DNAT, но и SNAT, так что обратный трафик будет отправлен обратно через первый хост. Правило может выглядеть примерно так: iptables -t NAT -A POSTROUTING -d 192.168.12.77 -p tcp --dport 80 -j SNAT --to-source 192.168.12.87
  2. Вдохните от балансировки нагрузки DSR и DNAT пакетов на уровне Ethernet, а не на уровне IP. Заменив MAC-адрес назначения пакетов MAC-адресом 192.168.12.77 и отправив его по Ethernet без касания IP-уровня, 192.168.12.77 может иметь 192.168.12.87, настроенный на фиктивном интерфейсе, и таким образом иметь возможность прекратить соединение TCP с IP-сервером, известным клиенту.
  3. Используйте наивное (но не работающее) решение на первом хосте. Затем обработайте обратные пакеты на втором хосте, выполнив SNAT в обратном трафике. Правило может выглядеть так: iptables -t nat -A OUTPUT -p tcp --sport 80 -j SNAT --to-source 192.168.12.87

У каждого из этих трех решений есть свои недостатки, поэтому вам нужно тщательно рассмотреть, если вам действительно нужно выполнить эту конкретную пересылку.

  1. Использование SNAT потеряет IP-адрес клиента, поэтому номер хоста 2 будет считать, что все подключения были получены от 192.168.12.87. Кроме того, вы будете использовать пропускную способность через номер хоста 1 для всех пакетов ответа, что приведет к более прямому маршруту с другими подходами.
  2. Подход DSR нарушит все другие связи между двумя узлами. Подход DSR действительно подходит только тогда, когда адрес сервера не является основным IP-адресом любого из хостов. Каждый хост должен иметь первичный IP-адрес, который не является DSR-IP.
  3. Использование отслеживания соединений на одном хосте для перевода в одном направлении, а отслеживание соединений на другом хосте для перевода в другом направлении является уродливым, и есть различные способы его разлома. Например, если номера портов изменены NAT на любом из хостов, нет способа восстановить их. Также не задано, что отслеживание соединений будет работать правильно, если первый пакет, который он видит, является SYN-ACK, а не ACK.

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

Вы также можете забыть об NAT вообще и не пытаться решить проблему на уровне MAC или IP. Вы можете пройти весь путь до уровня HTTP и искать там решение. В этом случае решение, которое вы найдете, является прокси-сервером HTTP. Если вы установите HTTP-прокси на 192.168.12.87 и настройте его соответствующим образом, вы можете перенаправить запросы на 192.168.12.77 и перенаправить ответы. Кроме того, он может вставить заголовок X-Forwarded-For, сохраняющий исходный IP-адрес клиента. Затем сервер 192.168.12.77 должен быть настроен так, чтобы доверять заголовку X-Forwarded-For с 192.168.12.87.


25
2018-04-03 21:44



я удивлен -j MASQUERADE здесь не упоминается; это не обычный подход с DNAT? - remram
@remram я упомянул SNAT вместо MASQUERADE, потому что это то, что говорится в документации. Точная формулировка в документации: It should only be used with dynamically assigned IP (dialup) connections: if you have a static IP address, you should use the SNAT target. - kasperd