Пакет ответа на том же интерфейсе, что и входящий в LAN

TL; DR

Нет необходимости в iptables , метках или в ослаблении пересылки / фильтра обратного пути . Вместо правил ip , которые вы использовали, которые не будут соответствовать исходящим пакетам, используйте команды, описанные в предоставленной вами ссылке документации LARTC:

Даже если всегда можно разрешить работу, ослабив Переадресация / фильтр обратного пути , например, sysctl -w net.ipv4.conf.all.rp_filter = 2 и т. Д., Что позволяет всегда избегать асимметричной маршрутизации. Особенно с учетом того, что шлюз (если он действует как брандмауэр со строгим отслеживанием состояния) или ноутбук также могут не допускать этого по аналогичным причинам.Использование iptables и меток для исправления неправильного поведения, безусловно, не поможет понять, как будет вести себя и без того сложная настройка маршрутизации.

Хотя связанная документация использует IP-адрес сервера в качестве источника (для $ IF2 / ens224 : 172.31.196.185) без интерфейса для правила IP, вы указываете входящий интерфейс в правило ( dev означает iif здесь). Вот в чем проблема: это не тот эффект, на который можно рассчитывать. См. Описание iif в ip rule :

iif NAME

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

Хотя это явно не написано, верно и обратное: пакеты , исходящие от этого хоста, будут соответствовать только интерфейсу обратной связи: они не будут соответствовать ни iif ens160 , ни iif ens224 , но только iif lo (да iif означает входящий интерфейс, а iif lo соответствует локально сгенерированному исходящему ] пакетов, считайте, что это переводится как «входящие из локальной системы [туда, где правила маршрутизации укажут]»). Это имеет значение.

Что происходит тогда:

1. Портативный компьютер пытается достичь $ IP2 (он не должен знать, что $ IP2 может быть достигнут через серверные $ IF1 и $ IP1 в той же локальной сети), отправляет пакет через Шлюз ,
2. Шлюз направляет пакет на сервер $ IP2, принадлежащий $ P2_NET, к его интерфейсу $ IF2,
3. Сервер получает пакет, принадлежащий $ P1_NET (с 172.31.190.129 ) на интерфейсе $ IF2,
4. Server Strict Reverse Path rp_filter = 1 проверяет обратный маршрут,

5. Как видно выше, обратный маршрут не соответствует any iif отличается от iif lo : два новых правила не совпадают, поэтому единственное оставшееся правило сопоставления - это правило для основной таблицы маршрутизации: через $ IF1, как проверено с помощью :

    # ip route получить 172.31.190.129 из 172.31.196.185
   172.31.190.129 от 172.31.196.185 dev ens160 uid 0
   тайник
   

6. Обратный путь не использует интерфейс, с которого пришел пакет: пакет отброшен.

По тем же причинам текущая настройка не позволит корректный доступ к Интернету с сервера при использовании $ IP2: опять же, он не будет соответствовать новым правилам и попытается использовать $ IF1 для этого:

# ip route get 8.8.8.8 from 172.31.196.185
8.8.8.8 from 172.31.196.185 via 172.31.190.1 dev ens160 uid 0 
    cache 

Итак, как только два правила удалены и изменены, как описано в LARTC, на:

 ip rule add из таблицы $ IP1 T1
добавление правила IP из таблицы $ IP2 T2

То есть:

# ip rule add from 172.31.190.63 table T1
# ip rule add from 172.31.196.185 table T2

Все будет работать правильно, как покажет поиск маршрута (теперь используется таблица T2 ):

# ip route get 172.31.190.129 from 172.31.196.185
172.31.190.129 from 172.31.196.185 via 172.31.196.1 dev ens224 table T2 uid 0 
    cache 

# ip route get 8.8.8.8 from 172.31.196.185
8.8.8.8 from 172.31.196.185 via 172.31.196.1 dev ens224 table T2 uid 0 
    cache 

Эти 3 варианта также могли сработать (просто поместив правило в таблицу T2 для краткости):

ip rule add from 172.31.196.0/23 table T2
ip rule add from 172.31.196.185 iif lo table T2
ip rule add from 172.31.196.0/23 iif lo table T2

Обратите внимание, что, как описано на странице руководства, iif lo изменит поведение, если Сервер также маршрутизирует другие системы, находящиеся за ним (опять же, правила не соответствует этим системам): лучше не использовать его без необходимости.

Для этого не нужны iptables и метки. Использование меток для изменения интерфейса может вызвать дополнительные проблемы с маршрутизацией, запросами ARP и фильтрацией обратного пути (использование меток обычно требует ослабления rp_filter ), поэтому лучше не использовать их, если этого можно избежать.