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