☰

Как заставить эту сеть работать в этом особом случае?

tag-icon • tag-icon debian networking routing
Как заставить эту сеть работать в этом особом случае?

У меня проблема. Все мои машины находятся за маршрутизатором, который подключен к порту ETH на модеме. Этот порт слишком ограничен в загрузке/выгрузке. Поэтому я попытался подключить два кабеля от маршрутизатора к модему на двух портах. Я много думал над тем, как решить эту проблему, я больше не знаю, что попробовать.

У моего роутера 4 интерфейса:

enp1s0f0   172.16.0.3
enp4s0f1   10.0.0.6
enp1s0f1   192.168.0.3
enp4s0f0   192.168.0.6

Как видите, eth3 и eth4 находятся в одной сети, что странно. Так и должно быть, если я хочу подключиться к модему (192.168.0.1) с помощью двух портов ETH.

Итак, вот что я попробовал:

echo "1   myorg" >> /etc/iproute2/rt_tables #added a custom routing table myorg
sudo ip route add 192.168.0.1 scope link dev enp4s0f0 #don't know if it is really necessary
sudo ip rule add from 192.168.0.6 table myorg
sudo ip route add default via 192.168.0.1 dev enp4s0f0 table myorg #second default gateway through myorg table

В результате я получаю следующие маршруты:

$ ip -4 route show table main
default via 192.168.0.1 dev enp1s0f1 onlink 
10.0.0.0/24 dev enp4s0f1 proto kernel scope link src 10.0.0.6 
172.16.0.0/24 dev enp1s0f0 proto kernel scope link src 172.16.0.3 
192.168.0.0/24 dev enp1s0f1 proto kernel scope link src 192.168.0.3 
192.168.0.0/24 dev enp4s0f0 proto kernel scope link src 192.168.0.6
192.168.0.1 dev enp4s0f0 scope link

$ ip -4 route show table myorg
default via 192.168.0.1 dev enp4s0f0

$ sudo route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 enp1s0f1
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 enp4s0f1
172.16.0.0      0.0.0.0         255.255.255.0   U     0      0        0 enp1s0f0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 enp1s0f1
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 enp4s0f0
192.168.0.1     0.0.0.0         255.255.255.255 UH    0      0        0 enp4s0f0

Я использую ufw в качестве брандмауэра NAT. Я добавил в раздел *nat:

:POSTROUTING ACCEPT - [0:0]
-A POSTROUTING -s 172.16.0.0/24 -o enp1s0f1 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/24 -o enp4s0f0 -j MASQUERADE

Проблема в том, что либо машины в сети 10.0.0.0 получают ответ на ping от модема (шлюз 192.168.0.1), либо машины из сети 172.16.0.0. Может быть и наоборот в зависимости от момента, не знаю почему.

Мой модем видит обоих клиентов 192.168.0.3 и 192.168.0.6 на двух портах ETH.

Итак, возможно ли иметь доступ к WAN на всех машинах и во всех сетях с такой топологией (маршрутизатор с двумя интерфейсами в одной сети)?

решение1

Хотя это явно не прописано, я предполагаю, что цель состоит в том, чтобы разделить трафик таким образом, чтобы:

  • 172.16.0.0/24 трафик проходит через enp1s0f1
  • Трафик 10.0.0.0/24 проходит через enp4s0f0

Как написал OP, для этого нужна маршрутизация на основе политик/источников.iptablesисетевой фильтрредко бывают полезны (по крайней мере, сами по себе):

  • вообще говоряiptablesисетевой фильтрне маршрутизируют и не заботятся о маршрутах. Маршруты стека сетевой маршрутизации. Некоторые изiptables' действия все равно приведут к изменению решений о маршрутизации (как описано в этомсхема)
  • любое действие, выполненное вПОСТРОЕНИЕ, как следует из названия, происходитпослеБыли приняты решения о маршрутизации: слишком поздно менять маршрут. Здесь, поканат/ПОСТРАСТЕНИЕправила нужны, они не изменят маршрут.

В любое времяiptablesможно избежать, чтобы решить проблему маршрутизации, лучше избегать. Иногда этого нельзя избежать (и тогда обычноiptablesиспользуется для добавления метки к пакетам, и эта метка используется в ip ruleзаписи).

Маршруты

Я предполагаю, чтоrp_filter=1установлен на всех интерфейсах, так как это значение по умолчанию для большинства дистрибутивов, чтобы включитьСтрогая переадресация по обратному пути.

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

В своем ответе я не буду отдавать предпочтение той или иной сети: каждая получит свою собственную таблицу маршрутизации. Я забуду таблицу 1 и буду использовать таблицы 10 для LAN 10.0.0.0/24 и 172 для LAN 172.16.0.0/24. Сохраню правила NAT, уберу правила и дополнительные таблицы маршрутизации, а также 192.168.0.1 dev enp4s0f0 scope linkиз main.

  1. Маршруты для 10.0.0.0/24 <--> 10.0.0.6 enp4s0f0 | enp4s0f1 192.168.0.6 <--> 192.168.0.1/default:

     ip rule add from 10.0.0.0/24 lookup 10
 ip route add table 10 10.0.0.0/24 dev enp4s0f1
 ip route add table 10 192.168.0.0/24 dev enp4s0f0 src 192.168.0.6
 ip route add table 10 default via 192.168.0.1

Выше, без дублированной записи маршрута для 10.0.0.0/24, система не смогла бы сама получить доступ к этой локальной сети: она бы решила, что маршрут должен проходить через шлюз по умолчанию, только дляСтрогая переадресация по обратному пути(SRPF) цели, затрудняющие отладку. Это пример плохой вещи, если ее не добавить. Если сомневаетесь, просто дублируйте маршруты.

Другим эквивалентным вариантом вместо дополнительного маршрута могло бы быть изменение приведенного выше правила на:

    ip rule add from 10.0.0.0/24 iif enp4s0f1 lookup 10

поэтому он не будет соответствовать локальному (немаршрутизируемому) трафику, и будет использоваться только основная таблица.

  1. Маршруты для 172.16.0.0/24 <--> 172.16.0.3 enp1s0f0 | enp1s0f1 192.168.0.3 <--> 192.168.0.1/default:

     ip rule add from 172.16.0.0/24 lookup 172
 ip route add table 172 172.16.0.0/24 dev enp1s0f0
 ip route add table 172 192.168.0.0/24 dev enp1s0f1 src 192.168.0.3
 ip route add table 172 default via 192.168.0.1

  2. Также изменить маршрут (ссылку) для локально инициированного исходящего трафика при изменении исходящего IP-адреса источника в системе Linux. Это должно быть необязательно, но следующая часть о ARP flux делает это обязательным:

     ip rule add from 192.168.0.6 lookup 10
 ip rule add from 192.168.0.3 lookup 172

  3. Любой неспециальный случай, включающий переопределенные маршруты из правил, также должен быть продублирован.

Здесь отсутствуют только маршруты между двумя специальными локальными сетями:

в таблице 10 достичь 172.16.0.0/24
в таблице 172 достичь 10.0.0.0/24

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

    ip route add table 10 172.16.0.0/24 dev enp1s0f0
    ip route add table 172 10.0.0.0/24 dev enp4s0f1

При использовании этой модели, если, например, добавить две другие «обычные» внутренние сети, они смогут взаимодействовать между собой (и будут использовать маршрут по умолчанию из основной таблицы для выхода наружу) без дополнительных настроек, но им снова потребуется дублировать свои маршруты в каждой дополнительной таблице маршрутизации для взаимодействия с двумя специальными локальными сетями.

Маршруты теперь в порядке, но все еще есть...

Theпоток ARPпроблема

Linux следуетмодель слабого хозяина. Это касается IP-маршрутизации, а также способа, которым Linux отвечает на запросы ARP: с любого интерфейса для любого IP, но, конечно, используя собственный MAC-адрес интерфейса. Поскольку это может происходить на всех интерфейсах одновременно, когда несколько интерфейсов находятся в одной локальной сети, обычно побеждает самый быстрый. Затем информация ARP кэшируется на удаленной системе и остается там некоторое время. В конце концов кэш истекает, происходит то же самое, с возможным другим результатом. Так как же это вызывает проблему? Вот пример:

  • Маршрутизатор (модем) отправляет ARP-запрос на 192.168.0.6, чтобы отправить обратно маршрутизированный и преобразованный с помощью NAT (Linux) ответ на трафик, изначально отправленный с 10.0.0.0/24.
  • Linux отвечает наenp1s0f1(enp1s0f1выиграл гонку) используяenp1s0f1MAC-адрес в ответе сообщает, что он имеет вид 192.168.0.6.
  • В течение нескольких секунд или нескольких минут будущие входящие IP-пакеты от маршрутизатора для 192.168.0.6 поступают наenp1s0f1,
  • в то же времявыходпакеты из 192.168.0.6 уходят с помощьюenp4s0f0.

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

К счастью, чтобы предотвратить это, Linux предоставляет настройку, которая должна использоваться только вместе с политикой маршрутизации, чтобы ARP следовал тем же правилам, которые определены маршрутизацией:arp_filter.

arp_filter - БУЛЕВ

1 - Позволяет иметь несколько сетевых интерфейсов в одной подсети и иметь ARP для каждогоинтерфейсбыть дан ответ на основебудет ли ядро ​​направлять пакет с IP-адреса ARP на этот интерфейс(поэтомунеобходимо использовать маршрутизацию на основе источникачтобы это работало). Другими словами, это позволяет контролировать, какие карты (обычно 1) будут отвечать на ARP-запрос.

sysctl -w net.ipv4.conf.enp4s0f0.arp_filter=1
sysctl -w net.ipv4.conf.enp1s0f1.arp_filter=1

Теперь поведение ARP правильное, если настройки были только что установлены, следует принудительно очистить кэш ARPсверстники(здесь: модем) путем обнаружения дублирующего адреса с помощьюarping(отiputils/iputils-arping), который будет транслироваться пирам и заставлять их обновлять свой кэш:

arping -c 5 -I enp4s0f0 -D -s 192.168.0.6 192.168.0.6 &
arping -c 5 -I enp1s0f1 -D -s 192.168.0.3 192.168.0.3

Обратите внимание, что два правила в пункте 3 предыдущей части теперь являются обязательными, поскольку IP-адреса 192.168.0.3 и 192.168.0.6 должны совпадать в правилах маршрутизации политики для правильного разрешения ARP с помощью arp_filter=1.

Как отлаживать

ip route getочень полезно для проверки маршрутов и фильтрации обратного пути:

новый тестовый пример для пункта 4 выше:

# ip route get from 10.0.0.111 iif enp4s0f0 172.16.0.111
172.16.0.111 from 10.0.0.111 dev enp1s0f0 table 10 
    cache iif enp4s0f0 
# ip route get from 172.16.0.111 iif enp1s0f0 to 10.0.0.111
10.0.0.111 from 172.16.0.111 dev enp4s0f1 table 172 
    cache iif enp1s0f0

при удалении правил или маршрутов:

# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp4s0f0 table 10 
    cache iif enp4s0f1 
# ip rule del from 10.0.0.0/24 lookup 10
# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp1s0f1
    cache iif enp4s0f1
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
local 192.168.0.6 from 192.168.0.1 dev lo table local
    cache <local> iif enp4s0f0
# ip rule delete from 192.168.0.6 lookup 10
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
RTNETLINK answers: Invalid cross-device link

Это показывает, как результаты изменяются в зависимости от (отсутствия) правил и дополнительных маршрутов. Последний результат — это сообщение об ошибке, сообщающее, что проверка переадресации обратного пути не удалась (=> сброс).

Тогда естьip neigh (самые полезные навглядетьсясистемы) для проверки записей ARP tcpdumpи т. д.

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