☰

Ответный пакет на том же интерфейсе, что и входящий в локальной сети

tag-icon • tag-icon linux networking linux-networking iproute2 policy-routing
Ответный пакет на том же интерфейсе, что и входящий в локальной сети

В настоящее время я борюсь со следующей ситуацией:

  • У меня есть сервер с 2 интерфейсами в 2 отдельных подсетях LAN. IF1, IF2
  • У меня есть ноутбук, IP-адрес которого находится в первой подсети.
  • Когда я пытаюсь подключиться с этого конкретного ноутбука ко второму IP-адресу сервера, я вообще не получаю ответа.

Например, когда я пытаюсь выполнить ping 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

Я перепробовал много разных способов создания маршрутизации на основе политик в моем случае, но ни один из них не удался...

решение1

TL;DR

Нет необходимости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 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. СерверСтрогий обратный путьrp_filter=1проверяет обратный маршрут,

  5. Как показано выше, обратный маршрутне совпадаетлюбое 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

  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 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), поэтому лучше не использовать их, если этого можно избежать.

Связанный контент