Назад | Перейти на главную страницу

Поведение ядра 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. Но странно то, что это не так.

Если я пингую машину в своей домашней локальной сети (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 через другой интерфейс, он будет иметь более конкретную маску, чем два других маршрута.