Доступность различных интерфейсов без указания маршрута в отдельной таблице маршрутизации
В настоящее время мы пытаемся направить все пакеты из подсети нашего гостевого vlan (eth1.251) через туннель для защиты от проводов в Интернет. Для этого мы используем маршрутизацию на основе политик с правилом использования таблицы маршрутизации 10, когда трафик идет из нашей гостевой подсети:
32765: from 10.251.0.0/16 lookup 10
В таблице маршрутизации 10 мы создаем маршрут по умолчанию к нашему туннельному интерфейсу:
default dev wg1 scope link
Все наши клиенты в нашей гостевой сети могут получить доступ к Интернету через туннель проводной защиты, который ожидается, однако клиент не может достичь шлюза для гостевой сети. (10.251.0.1). TCPDump показывает, что эхо-ответ ICMP направляется обратно через wg1 интерфейс с нашей конечной точкой туннеля, что явно не предназначено. Быстрое решение для этого - добавить маршрут ссылки области для 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.1 interface ip на нашем маршрутизаторе без явной записи в таблице маршрутизации, но не 10.251.0.1 ip интерфейса от наших клиентов в гостевой 10.251.0.0/16 подсеть?
Вот обзор сетевой структуры. Думаю, это помогает понять нашу установку.
Общего объяснения нет, просто нужно следить за тем, что происходит в настройках маршрутизации.
10.251.0.1 - это адрес локального маршрутизатора и часть 10.251.0.0/16.
При получении пакета на местный адрес, маршрутизатор соответствует местный таблица с использованием самого первого ip rule с наименьшим предпочтением: 0 перед правилом для таблицы 10 и соответствует. Помните, что таблицы маршрутизации совпадают направления, хотя обычно настраиваемые правила настраиваются так, чтобы соответствовать источники.
Когда маршрутизатор отвечает, на этот раз локальная таблица не совпадает: 10.251.0.2 не является локальным место назначения. Следующее правило проверяется и соответствует from 10.251.0.0/16, просматривает таблицу 10, и пакет проходит wg1.
Для 192.168.0.1 получение пакета точно такое же, как и раньше, с местный стол. Теперь ответ не соответствует дополнительному правилу, и применяется основная таблица маршрутизации: она работает как обычно: система Linux ответит с любого из своих IP-адресов.
Опять же, для 192.168.0.2: это не местный IP, поэтому не соответствует местный таблицу, но запрос соответствует добавленному правилу: пакеты теряются через wg1.
Так что копирование части основной таблицы маршрутизации в дополнительную таблицу во избежание побочных эффектов помогает.
Многие из этого можно проверить с помощью 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