VPN увімкнено, а VM недоступна? Маршрут, імовірно, ніколи не був проблемою

Підключіть VPN, і гостьова VM, яка ще хвилину тому відповідала, замовкає. Очевидна історія пишеться сама собою: тунель забрав маршрут, хост тепер надсилає трафік гостьової системи в корпоративну мережу, а виправлення — додати статичний маршрут або перемкнути адаптер у режим мосту. Ця історія іноді правдива. Але це не звичайна причина, і дія за нею насамперед зазвичай ламає щось інше.

Мережа host-only — це програмна мережа, що належить хосту й спільно використовується з його гостьовими системами, окрема від будь-якого фізичного підключення. Ніщо у власному інтерфейсі клієнта VPN не змінює цю мережу, тому перш ніж її торкатися, з'ясуйте, який із чотирьох рівнів справді відмовив.

Маршрут зазвичай усе ще локальний

Запитайте ядро, а не першу сторінку таблиці маршрутизації. У Linux ip route get 192.168.56.10 повідомляє точний маршрут, інтерфейс і адресу джерела, які буде використано, і це інша відповідь, ніж читання маршруту за замовчуванням зі здогадками. Якщо вивід називає інтерфейс host-only, тунель у цьому шляху взагалі не бере участі.

Дві речі справді можуть його зламати, і обидві — проблеми адрес, а не VPN. Віддалена підмережа, що перекриває префікс host-only, змушує перемагати конкретніший маршрут, а клієнт VPN, який встановлює широкий маршрут із нижчою метрикою, може потягнути префікс. Обидві видно в одній команді: інтерфейс, названий у виводі, буде тунелем, а виправлення належить тому, хто володіє цим планом адрес.

Вибір маршруту й допуск пакета — різні рішення

Це та частина, яку розумова модель зазвичай пропускає. Навіть за ідеального локального маршруту клієнт VPN може відхилити пакет. Багато клієнтів застосовують політику локального доступу до мережі, яка вирішує, які призначення дозволені поза тунелем, а підключена підмережа не оновлює цей список автоматично.

Тому збій виглядає однаково з проблемою маршрутизації з боку застосунку й зовсім інакше з боку клієнта. Якщо ip route get називає правильний інтерфейс, а з'єднання все одно завершується тайм-аутом, припиніть редагувати маршрути й натомість прочитайте задокументовану поведінку локального доступу клієнта. Деякі клієнти пропонують список дозволених для локальних підмереж, інші блокують усе, що не є тунелем, а ще інші блокують лише тоді, коли ввімкнено kill switch.

Ця відмінність важлива, бо виправлення не є взаємозамінними. Додавання маршруту не може задовольнити фільтр, а вимкнення фільтра заради доступу до одного гостя — значно більше рішення, ніж підказує симптом.

У гостя є три способи сказати ні

Гість, який може переглядати інтернет, нічого не довів щодо потрібної вам служби. Слухач може бути прив'язаним до 127.0.0.1 усередині гостя, і тоді жоден запит із хоста не зможе надійти, яким би добрим не був шлях. Перевірте за допомогою ss -ltn у гості й подивіться на стовпець локальної адреси, а не лише на порт.

Далі — власний брандмауер гостя. Образ розробки зі строгим налаштуванням за замовчуванням може прийняти пакети хоста й відкинути їх на межі служби, що дає тайм-аут, який виглядає точно як чорна діра маршрутизації. Насамкінець є власна конфігурація служби: вебзастосунок, прив'язаний до певного імені хоста, або список дозволених адрес клієнтів відхилить запит із підмережі host-only, навіть коли надходить кожен пакет.

Пройдіть ці три пункти, перш ніж думати про зміну мережевого режиму VM. Кожен — менша зміна, ніж перебудова підключення гостя, і кожен має чітку перевірку.

Що таке міст насправді і скільки він коштує

Перемикання адаптера в режим мосту не є ремонтом шляху host-only. Це рішення помістити гостя в іншу мережу, зазвичай у фізичну LAN, де він стає видимим для всього іншого, що там живе. Це може бути саме те, чого ви хочете. Але це не те, що робила початкова конфігурація.

Використовуйте його, коли гість справді має бути рівноправним учасником цієї LAN і вплив схвалено. Не використовуйте його через те, що одна служба перестала відповідати, оскільки зміна може вивести гостя з ізоляції, яка робила розробку проти нього безпечною.

Після кожного схваленого виправлення перевіряйте у фіксованому порядку: новий запит від хоста до гостя, потрібний корпоративний ресурс через тунель і очікувану поведінку відмови з вимкненим тунелем. Якщо останнє більше не виконується, виправлення вийшло за межі проблеми.

Розділ VirtualBox про мережу host-only описує програмний інтерфейс з боку хоста й те, чим він відрізняється від підключення мостом; це джерело, яке варто прочитати, перш ніж вважати два режими взаємозамінними.