У нас есть сервер, на котором статически маршрутизированы как / 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 <dst> from <SOME_IP_IN_THE_24> команда. Исправьте это, если команда вернула неожиданный маршрут.iptables-save -c. Исходный адрес может быть переопределен правилами NAT.Ваша проблема вызвана правилом MASQUERADE. Любой исходный адрес перезаписывается на IP-адрес, который вы видите в исходном атрибуте маршрута, который был получен ip route get <dst> команда. В этом можно убедиться, используя 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