У нас есть сервер, на котором статически маршрутизированы как / 31, так и / 24 в разных / 8. У нас есть шлюз в том же / 24, что и /31.
Входящие соединения с IP-адресами в / 24 работают должным образом, но мы не можем инициировать исходящие соединения. Наш «золотой стандарт» тест (с использованием IP, чтобы избежать проблем с DNS на данном этапе):
curl --interface SOME_IP_IN_THE_24 -v -H 'Host: httpbin.org' 34.230.136.58/ip
Мы используем Ubuntu 16.04, и мы настроили eno1 с одним из / 31, eno1: 1 с другим / 31 и eno1: 2 с одним из IP-адресов из / 24. Когда мы запускаем указанную выше команду, мы все равно получаем IP для eno1.
ip route get из
. Исправьте это, если команда вернула неожиданный маршрут. iptables-save -c
. Адрес источника может быть изменен правилами NAT. Ваша проблема вызвана правилом MASQUERADE. Любой адрес источника перезаписывается на IP-адрес, который вы видите в атрибуте источника маршрута, который был получен командой ip route get
. В этом можно убедиться, используя команды tcpdump
и conntrack -E
. Вероятно, вы также видите увеличение счетчиков этого правила.
Простой способ избежать такого поведения - просто вставить правила ACCEPT в начало цепочки nat / PREROUTING
. Лучший способ изменить набор правил брандмауэра - использовать команды iptables-save
/ iptables-apply
. Ваша цепочка nat / PREROUTING
должна выглядеть так ( iptables-save -t nat
):
# Generated by iptables-save v1.6.2 on Thu Jul 4 19:05:27 2019
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING --src <LOCAL-IP-1> -j ACCEPT
-A POSTROUTING --src <LOCAL-IP-2> -j ACCEPT
...
-A POSTROUTING --src <LOCAL-IP-N> -j ACCEPT
-A POSTROUTING -j MASQUERADE
COMMIT
# Completed on Thu Jul 4 19:05:27 2019