Когда внутренняя машина инициирует исходящее соединение, ее IP-адрес
NAT как основной адрес шлюза, а не адрес, который я пытаюсь
дай это.
Это должно быть решено с помощью:
iptables -t nat -I POSTROUTING 1 -s 10.125.0.2 -o eth0 -j SNAT --to-source <FORWARD_IP>
Он добавлен в начало, поэтому он будет срабатывать первым, определять, что пакет исходит из этой системы, и переводить его в указанный IP-адрес, вместо того, чтобы выбирать адрес из интерфейса.
При получении соединений кажется, что они исходят от
локальный IP-адрес шлюза, а не исходный IP-адрес (должен быть способ обойти
так как это шлюз по умолчанию).
Эта проблема связана со следующим правилом SNAT:
iptables -t nat -A POSTROUTING -j MASQUERADE
это путь слишком широко. Вы используете SNAT все в каждый направлении, которое не является ни эффективным, ни безопасным. Он соответствует всему, включая ваши ДНК-пакеты. Сначала они транслируются по назначению в приватный адрес, затем по этому правилу их источник транслируется в адрес, выбранный из приватного интерфейса, где назначен адрес 10.x.x.x.
Я подозреваю, что вы пытаетесь охватить все общедоступные интерфейсы и все частные сети одним правилом. Хотя в Linux есть списки адресов (наборы IP-адресов), списков интерфейсов нет, поэтому невозможно сделать это правильно с помощью всего лишь одного правила.
Отфильтруйте его с помощью по меньшей мере исходный адрес (например, который адреса для исходного перевода):
iptables -t nat -A POSTROUTING -s 10.125.0.0/24 -j MASQUERADE
Если у вас несколько частных сетей, добавьте больше таких правил.
Я думаю, что лучше создать отдельное правило для каждого общедоступного интерфейса, чтобы пакеты, идущие через частный интерфейс, никогда не могли быть переведены в источник, какой бы адрес источника у них ни был, например. iptables -t nat -A POSTROUTING -s 10.125.0.0/24 -o eth0 -j MASQUERADE и так далее. Таким образом, пакеты от 10.x.x.x до 172.x.x.x тоже не будут транслироваться, и ваши сервисы в обеих сетях будут видеть IP-адреса друг друга напрямую, оставляя возможность выборочной фильтрации их в цепочке фильтров FORWARD.
Если служба прослушивает 0.0.0.0 на шлюзе, соединения на
этот порт не перенаправляется, они идут к этому сервису.
И, наконец, я не совсем понимаю этот момент.Я спросил в комментарии, вы не ответили. Какие соединения, откуда, какой исходный IP?
Обработка DNAT происходит до принятия решения о маршрутизации, поэтому цепочка называется «PREROUTING». Он никогда не проверяет, прослушивает ли какой-либо локальный процесс этот порт. Единственный способ, с помощью которого локальная служба может ответить, — это передать пакету цепочку INPUT. Для этого код маршрутизации должен решить, что он предназначен для локальной машины, поэтому он должен быть либо вообще не транслирован, либо транслирован в какой-то адрес, назначенный этой системой.
Согласно текущим правилам, пакеты, отправленные из частных сетей на общедоступные IP-адреса, должны нет получить перевод, потому что они не приходят через eth0. Поэтому их должны обслуживать местные службы. Но это не зависит от того, запущена локальная служба или нет; если это не так, у вас будет «отказ в соединении».
Если вам нужно, чтобы пакеты из локальной сети на <FORWARD_IP> транслировались по одному и тому же правилу DNAT, отбросьте это -я eth0 соответствовать:
iptables -A PREROUTING -d <REDACTED_FORWARDING_IP>/32 -j DNAT --назначение 10.125.0.2
Однако я против такого широкого правила. На мой взгляд, лучше иметь как можно более жесткие правила DNAT, поэтому вам лучше фильтровать протоколы (tcp/udp) и порты сервисов, которые вы запускаете на 10.125.0.2. Если это веб-сервер, пересылайте только tcp/80 и tcp/443, например: iptables -A PREROUTING -d <EDACTED_FORWARDING_IP>/32 -p tcp -m multiport --dports 80,443 -j DNAT --назначение 10.125.0.2.
В чем проблема? Скажем, вы что-то проверяете пингом. Этот результат пинга будет зависеть от этого внутреннего состояния системы, это система, которую вы пингуете в действительности. Это смущает. Это не то поведение, которое большинство системных администраторов ожидают увидеть при проверке связи с маршрутизатором. Так что лучше оставить пинг для ответа хосту.
