Те, що адаптер 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 щодо мереж описує режими адаптерів і те, до чого підключається кожен із них, і саме цю частину варто прочитати перед додаванням другого. Лабораторія, яка визначає, який адаптер обслуговує кожну роль, робить зміну маршруту пояснюваною. Лабораторія, яка покладається на нумерацію гіпервізора, робить кожну зміну експериментом.

Схожі статті