Поведение ядра Linux при контакте со сталкивающимися подсетями
Я использую openconnect для соединения с моим офисом VPN. Они продвигают некоторые довольно дрянные/агрессивные правила маршрутизации, выделяющие ВСЕ частные пространства IP-адресов>. <
После того, как я подключаю к своему офису VPN, моя основная таблица маршрутизации содержит эти маршруты (это содержит намного больше на самом деле, но это - сталкивающиеся подсети):
192.168.0.0/24 dev p4p1 proto kernel scope link src 192.168.0.200
192.168.0.0/16 dev tun0 scope link
Как Вы видите, весь трафик к 192.168.0.0/16 должен быть направлен через tun0. Странная вещь, хотя то, что это не.
Если я проверяю с помощью ping-запросов машину в своей домашней LAN (192.168.0.0/24), пакет ICMP достигает машины, и обычно все работает хорошо, таким образом, я предполагаю, что пакеты к 192.168.0.0/24 не проходят соединение VPN.
Мой вопрос следующий, как заключает сделку о ядре Linux со сталкивающимися подсетями? Я подозреваю, что это принимает решение использовать самый точный маршрут, в этом случае 192.168.0.0/24. Вы могли указать на меня на документ, который описывает это, или обеспечьте некоторые подсказки?
На самом деле это не конфликт. Одна подсеть имеет более конкретную маску
192.168.0.0/24 has more specific mask than 192.168.0.0/16
. Например, шлюз по умолчанию - это шлюз по умолчанию, потому что он имеет менее конкретную маску /0.
. Если вы добавите маршрут к 192.168.0.3/32 через другой интерфейс, он будет иметь более конкретную маску, чем другие два маршруты.