В настоящее время мы пытаемся направить все пакеты из подсети нашего гостевого vlan (eth1.251) через туннель Wireguard в Интернет. Для этого мы используем маршрутизацию на основе политик с правилом использования таблицы маршрутизации 10, когда трафик поступает из нашей гостевой подсети:
32765: from 10.251.0.0/16 lookup 10
В таблице маршрутизации 10 мы создаем маршрут по умолчанию к нашему туннельному интерфейсу:
default dev wg1 scope link
Все наши клиенты в нашей гостевой сети могут получить доступ к Интернету через туннель Wireguard, что и ожидается, однако клиенты не могут получить доступ к шлюзу гостевой сети (10.251.0.1). TCPDump показывает, что ответ ICMP echo направляется обратно через wg1интерфейс к нашей конечной точке туннеля, что, очевидно, не предусмотрено. Быстрое решение этой проблемы — добавить маршрут scope link для eth1.251гостевого интерфейса vlan в маршрутизацию table 10:
default dev wg1 scope link
10.251.0.0/16 dev eth1.251 proto kernel scope link
Теперь клиент может получить доступ к интерфейсу маршрутизатора и его обслуживанию.
На этом маршрутизаторе есть другой интерфейс eth1 с подсетью 192.168.0.1/16. Когда мы теперь удаляем наш недавно добавленный 10.251.0.0/16маршрут, table 10мы больше не можем достичь интерфейса маршрутизатора 10.251.0.1, однако мывсе еще в состоянии достичьинтерфейс 192.168.0.1от клиента в 10.251.0.0/16подсети. Клиенты (например 192.168.0.2, ) за маршрутизатором в 192.168.0.0/16подсети не могут быть получены из 10.251.0.0/16.
Главный вопрос: Почему мы можем получить доступ к 192.168.0.1IP-адресу интерфейса на нашем маршрутизаторе без явной записи в таблице маршрутизации, но не можем получить доступ к 10.251.0.1IP-адресу интерфейса наших клиентов в гостевой 10.251.0.0/16подсети?
Вот обзор структуры сети. Я думаю, это поможет понять нашу установку.
решение1
Общего объяснения нет, нужно просто следить за тем, что происходит в настройках маршрутизации.
10.251.0.1 — это одновременно адрес локального маршрутизатора и часть 10.251.0.0/16.
При получении пакета наместныйадрес, маршрутизатор соответствуетместныйтаблица, использующая самую первую ip ruleс наименьшим приоритетом: 0, перед правилом для таблицы 10, и совпадает. Помните, что таблицы маршрутизации совпадают понаправления, в то время как обычно пользовательские правила настраиваются для соответствияисточники.
Когда маршрутизатор отвечает, на этот раз локальная таблица не совпадает: 10.251.0.2 не является локальнойместо назначения. Следующее правило проверяется и совпадает from 10.251.0.0/16, ищется в таблице 10 и пакет проходит черезРГ1.
Для 192.168.0.1 получение пакета происходит точно так же, как и раньше сместныйtable. Теперь ответ не соответствует дополнительному правилу, и применяется основная таблица маршрутизации: она работает как обычно: система Linux ответит с любого из своих IP-адресов.
Опять же, для 192.168.0.2: это неместныйIP, поэтому не совпадаетместныйтаблица, но запрос соответствует добавленному правилу: пакеты теряются черезРГ1.
Поэтому копирование части основной таблицы маршрутизации в дополнительную таблицу помогает избежать побочных эффектов.
Многое из этого можно проверить с помощью ip route getправильного синтаксиса, если только не задействованы какие-либо знаки:
Без дополнительной записи в таблице 10:
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1
RTNETLINK answers: Invalid cross-device link
# sysctl -w net.ipv4.conf.eth1/251.rp_filter=2 #relax reverse path filtering
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1
local 10.251.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.2 iif eth1.251 192.168.0.1
local 192.168.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.2 iif eth1.251 192.168.0.2
192.168.0.2 from 10.251.0.2 dev wg1 table 10
cache iif eth1.251
маршрут ответа:
# ip route get from 10.251.0.1 10.251.0.2
10.251.0.2 from 10.251.0.1 dev wg1 table 10 uid 0
cache
# ip route get from 192.168.0.1 10.251.0.2
10.251.0.2 from 192.168.0.1 dev eth1.251 uid 0
cache
При добавлении записи в таблицу 10:
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1 #even with strict reverse path filtering, since the reverse route is correct
local 10.251.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.1 10.251.0.2
10.251.0.2 from 10.251.0.1 dev eth1.251 table 10 uid 0
cache