В настоящее время я борюсь со следующим сценарием:
Например, когда я пытаюсь выполнить эхо-запрос 172.31.196.185 с ноутбука с IP-адресом 172.31.190.129, я вижу входящие запросы в tcpdump на интерфейсе ens224, но после этого запроса на ответ на других интерфейсах нет.
Вот моя сетевая диаграмма:
+-------------------------+
| |
| Laptop 172.31.190.129 +---------+
| | |
+-------------------------+ |
| +-------------------------+
| | |
+-----------+---------+ | Linux Server |
+----+ | | |
| | LAN 172.31.190.0/23 +-------+ IF1 - default gw |
+------+--+ | | | 172.31.190.63 |
+----------+ | | +---------------------+ | |
| Internet +---+ Gateway | | |
+----------+ | | +---------------------+ | |
+------+--+ | | | |
| | LAN 172.31.196.0/23 +-------+ IF2 |
+----+ | | 172.31.196.185 |
+---------------------+ | |
| |
| |
+-------------------------+
Также у меня есть такой сценарий:
IF1=ens160
IF2=ens224
P1_NET=172.31.190.0/23
P2_NET=172.31.196.0/23
IP1=172.31.190.63
IP2=172.31.196.185
P1=172.31.190.1
P2=172.31.196.1
ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2
ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2
ip rule add from $P1_NET dev $IF1 table T1
ip rule add from $P2_NET dev $IF2 table T2
Которая написана по этой ссылке: https://lartc.org/howto/lartc.rpdb.multiple-links.html
В моем случае я пробовал много разных способов сделать маршрутизацию на основе политик, но ни у кого не получилось ...
Нет необходимости iptables, знаки, ни расслабиться Переадресация обратного пути / фильтр. А не ip rules, который вы использовали, который не подходит для исходящих пакетов, используйте команды, как описано в Документация LARTC предоставленная вами ссылка:
ip rule add from $IP1 table T1 ip rule add from $IP2 table T2
тогда все будет нормально работать.
Даже если всегда можно позволить вещам работать, расслабившись Переадресация обратного пути / фильтр используя например sysctl -w net.ipv4.conf.all.rp_filter=2 и т. д., позволяя тем самым асимметричную маршрутизацию, асимметричной маршрутизации всегда следует избегать. Особенно с учетом того, что Шлюз (если действует как строгий межсетевой экран с отслеживанием состояния) или Ноутбук может также не допустить этого по аналогичным причинам. С помощью iptables и отметки для исправления неправильного поведения, конечно же, не помогут понять, как будет вести себя и без того сложная настройка маршрутизации.
Хотя связанная документация использует IP-адрес сервера в качестве источника (для $ IF2 /Ens224: 172.31.196.185) без интерфейса для правила ip вы указываете входящий интерфейс в правиле (dev средства iif Вот). Вот в чем проблема: это не тот эффект, которого можно ожидать. См. Описание iif в ip rule:
iif НАЗВАНИЕ
выберите соответствующее входящее устройство. Если интерфейс является кольцевым, правило соответствует только пакетам, исходящим от этого хоста.. Это означает, что вы можете создавать отдельные таблицы маршрутизации для перенаправленных и локальных пакетов и, следовательно, полностью разделять их.
Хотя это не совсем ясно написано, верно обратное: пакеты происхождение от этого хоста будет соответствовать только интерфейс обратной петли: они не будут соответствовать iif ens160 ни iif ens224, но только iif lo (да iif средства входящий интерфейс и iif lo соответствует локально сгенерированным исходящий пакетов, считайте, что это переводится как «входящие из локальной системы [туда, куда правила маршрутизации укажут]»). Это имеет значение.
Что происходит потом:
rp_filter=1 проверяет обратный маршрут,Как видно выше, обратный маршрут не совпадает любой iif отличающийся от iif lo: два новых правила не совпадают, поэтому единственное оставшееся правило соответствия - это правило для основной таблицы маршрутизации: через $ IF1, как проверено с помощью:
# ip route get 172.31.190.129 from 172.31.196.185
172.31.190.129 from 172.31.196.185 dev ens160 uid 0
cache
Обратный путь не использует интерфейс, с которого пришел пакет: пакет отброшен.
По тем же причинам текущая настройка не позволит получить правильный доступ в Интернет из Сервер при использовании $ 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 from $IP1 table T1 ip rule add from $IP2 table T2
То есть:
# ip rule add from 172.31.190.63 table T1
# ip rule add from 172.31.196.185 table T2
Все будет работать правильно, как покажет поиск маршрута (теперь используя table 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), поэтому лучше не использовать их, если этого можно избежать.