Как перенаправить запросы на мой внешний IP-адрес / порт на другой внешний IP-адрес / порт в Linux без изменения исходного IP-адреса?

Я могу использовать следующие команды, но они меняют исходный IP-адрес:

iptables -t nat -A PREROUTING -p tcp --dport port -j DNAT --to-destination dest_ip:port
iptables -t nat -A POSTROUTING -j MASQUERADE

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

Если я удалю iptables -t nat -A POSTROUTING -j MASQUERADE, Я не могу получить никакого ответа. Как я могу решить эту проблему?

Все IP-адреса являются внешними IP-адресами.

Используя PREROUTING править без MASQUERADE Правило сделает то, о чем вы просили. Это все равно не сработает, но это по другой причине.

Если у вас есть клиент 192.0.2.1 которые отправляют SYN-пакет на ваш сервер на 198.51.100.2, то ваше первое правило может изменить адрес назначения этого пакета на другой сервер на 203.0.113.3 и пересылать как таковой.

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

Однако вы столкнетесь с другой проблемой. Как только пакет прибывает в 203.0.113.3 SYN-ACK будет отправлен обратно на 192.0.2.1. Он будет направлен непосредственно клиенту, минуя первую машину, применившую DNAT правило.

Клиент, отправляющий SYN из 192.0.2.1 к 198.51.100.2 увидит SYN-ACK от 203.0.113.3 к 192.0.2.1. Это не будет соответствовать никакому TCP-соединению на клиенте, и клиент ответит пакетом RST. Как только пакет RST достигает 203.0.113.3 TCP-соединение закрывается на стороне сервера.

Всего было передано четыре пакета, и соединение было закрыто на стороне сервера до того, как полностью установилось. Эти четыре пакета будут повторяться столько раз, сколько клиент повторно передает SYN, пока не истечет время ожидания.

Есть несколько способов обойти эту проблему:

Направлять весь трафик из 203.0.113.3 через 198.51.100.2 чтобы он был переведен на обратном пути. К сожалению, это сделает общедоступный IP 203.0.113.3 бесполезен для других целей.
Назначьте вторичный IP-адрес 203.0.113.3, вы могли бы, например, дать это 10.0.113.3 как дополнительный IP-адрес. На 198.51.100.2 ты DNAT к 10.0.113.3 и использовать туннель, чтобы 203.0.113.3 чтобы получить пакеты на соответствующий хост назначения. На 203.0.113.3 вы используете политику маршрутизации, чтобы гарантировать, что пакеты с исходным IP 10.0.113.3 маршрутизируется обратно через туннель, а другие пакеты маршрутизируются через ваш шлюз по умолчанию.
Прекратите использовать NAT и вместо этого используйте подход балансировки нагрузки DSR для отправки пакетов из 198.51.100.2 к 203.0.113.3. Если эти двое не подключены напрямую и между ними нет маршрутизатора, снова потребуется туннель. Но на этот раз пакеты внутри туннеля сохраняют исходный адрес назначения и 203.0.113.3 не потребуется политика маршрутизации, вместо этого он будет отправлять правильные ответы непосредственно клиенту. Недостатком этого является то, что 203.0.113.3 нужно будет назначить 198.51.100.2 в качестве вторичного IP-адреса и, следовательно, 198.51.100.2 и 203.0.113.3 не смогут общаться друг с другом, но они все равно будут нормально общаться со всеми.
Если вам нужна только поддержка HTTP, вы можете использовать прокси вместо NAT. Тогда вы можете использовать X-Forwarded-For позволить 203.0.113.3 знать исходный IP клиента. Веб-сервер на 203.0.113.3 тогда нужно будет доверять X-Forwarded-For на любых соединениях, исходящих из 198.51.100.2 и игнорировать его при подключениях с других клиентских IP-адресов.