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 описывает программный интерфейс со стороны хоста и то, чем он отличается от подключения мостом; это источник, который стоит прочитать, прежде чем считать два режима взаимозаменяемыми.