Почему порядок адаптеров не определяет маршрут VPN в вашей лаборатории

То, что адаптер 1 стоит первым в списке гипервизора, — лишь порядок отображения, и таблица маршрутизации гостя его не читает. Путь определяют префикс, метрика и любое правило политики, действующее раньше обоих. Поэтому добавление мостового адаптера к лабораторной VM может создать второй маршрут по умолчанию, тогда как старый интерфейс NAT по-прежнему показывается как присутствующий и пронумерованный вторым. В результате получается VM, которая иногда пользуется туннелем, а иногда нет, без каких-либо изменений конфигурации, которые это объясняли бы.

Путь определяют три условия

Три условия таковы: какой префикс более конкретен, что делают метрики при равенстве префиксов и какие правила применил гость после изменения оборудования. На каждый можно ответить одной командой, и ни одно из них не связано с нумерацией гипервизора.

Именно последний пункт и есть решение: если вы не можете сказать, какой префикс побеждает для собственного адреса конечной точки VPN, у вас нет политики маршрутизации, у вас есть топология, которая сегодня работает случайно.

Условие первое: какой префикс побеждает

Маршрут к 10.8.0.0/24 побеждает маршрут по умолчанию для адреса внутри него, независимо от метрик и от порядка адаптеров. Поэтому VPN-клиент, устанавливающий конкретный маршрут, продолжает работать даже когда появляется второй адаптер с меньшей метрикой: конкретность побеждает до того, как учитывается стоимость. Проверьте с помощью ip route show таблицу, которую считаете используемой, и с помощью ip route get 203.0.113.9 ответ, который ядро действительно дало бы для конкретного назначения.

Собственный адрес конечной точки — самый важный тест. Если адрес VPN-сервера разрешается через недавно добавленный мостовой адаптер, туннель может никогда не установиться или установиться и затем потерять собственный транспортный путь. Спрашивайте именно об этом адресе, а не предполагайте, что ответом является интерфейс туннеля.

Условие второе: что метрика делает и чего не делает

Её роль уже, чем ожидают большинство. Метрики разрешают равенство между маршрутами к одному префиксу; они не позволяют более широкому маршруту победить более конкретный. При равенстве предпочтителен меньший номер, а разные операционные системы считают в противоположных направлениях, поэтому советы, скопированные между Linux и Windows, часто противоречат сами себе.

В госте ip route show печатает метрику рядом с каждым маршрутом, а Get-NetRoute в Windows печатает InterfaceMetric плюс метрику маршрута. Читайте и то и другое, потому что действующее предпочтение может быть суммой, а не одним полем. Если существуют два маршрута по умолчанию, это и есть находка: у гостя два выхода, и то, какой победит, зависит от чисел, которые изменение оборудования может изменить.

Условие третье: что гость действительно применил

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

Проверяйте применённое состояние, а не предполагаемое. ip -br link показывает интерфейсы, существующие сейчас, а на хосте с NetworkManager nmcli connection show показывает, какой профиль привязан к какому устройству. Профиль, которому не удалось привязаться, оставляет интерфейс включённым без адресации, что выглядит как проблема маршрутизации, а является проблемой именования. Восстановленные снимки состояния ухудшают это, потому что сохранённое состояние гостя может ссылаться на идентичности адаптеров, которых новое оборудование больше не предоставляет.

Сохраняйте топологию лаборатории воспроизводимой

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

Обычно достаточно назвать четыре роли: частное соединение, управление, внешний транспорт и туннель. Каждая должна в файле соответствовать конкретному адаптеру и конкретному интерфейсу гостя.

Затем проверьте реальное приложение после изменения оборудования, перезапуска или восстановленного снимка состояния и включите маршрут к конечной точке VPN в эту проверку. Если шлюзовая VM должна быть единственным выходом, убедитесь, что у тестовой VM нет непреднамеренного второго маршрута по умолчанию, потому что мостовой адаптер добавляет именно второй маршрут по умолчанию. Проверяйте из гостя, а не из консоли гипервизора, поскольку они могут расходиться в том, какой интерфейс какой.

Документация VirtualBox по сетям описывает режимы адаптеров и то, к чему подключается каждый из них, и именно эту часть стоит прочитать перед добавлением второго. Лаборатория, которая определяет, какой адаптер обслуживает каждую роль, делает изменение маршрута объяснимым. Лаборатория, которая полагается на нумерацию гипервизора, превращает каждое изменение в эксперимент.