Почему гостевой VPN не работает за NAT VirtualBox?

Браузер внутри виртуальной машины работает, а VPN-клиент на том же госте не может передавать данные. У гостя явно есть связность, значит сбой в том, что требует внешний протокол VPN, и в том, что пропустит виртуальный NAT. Исход определяют три условия: какой процесс владеет VPN, как выглядит внешний обмен на проводе и тот ли режим адаптера, о котором вы думаете. Назвать условие, которое можно изменить, — это и есть всё решение.

Найдите процесс VPN, прежде чем винить сеть

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

Запишите режим адаптера гостя сейчас, до любых изменений. Это единственное значение объясняет большую часть дальнейшего, и именно о нём вас позже спросят первым делом.

Внешний обмен определяет совместимость

Руководство по сетям VirtualBox перечисляет ограничения NAT, которые здесь важны: он не пропускает протоколы, кроме TCP и UDP, GRE назван неподдерживаемым, а PPTP приведён как пострадавший пример. PPTP использует TCP-обмен управления и GRE для данных, поэтому управляющее соединение может установиться, а путь данных не может пересечь ту же границу. Это два разных доказательства, и только одно из них о переносе трафика. Разрешить TCP-порт 47 в правиле брандмауэра — не то же самое, что разрешить IP-протокол 47, и эти два постоянно путают.

Держите ограничение привязанным к этой схеме NAT, а не к каждому устройству, использующему слово NAT. Физический маршрутизатор может пропускать GRE без жалоб, пока виртуальный NAT его отбрасывает, а другой гипервизор сам решает, что пересылать. Там, где организация предлагает одобренный транспорт внутри TCP или UDP, используйте его поддерживаемый клиент и профиль для этого пути. Совместимость — одно из нескольких требований, и она не устанавливает ни доверия к серверу, ни разрешения учётной записи, ни работающих частных маршрутов.

Что на самом деле меняет мост

Мост передаёт MAC-адрес гостя физическому сегменту вместо того, чтобы скрывать его за преобразованием. Затем гость получает адрес от любого DHCP-сервера, обслуживающего этот сегмент, отвечает на ARP для этого адреса и предстаёт перед вышестоящим коммутатором как ещё один порт. Это убирает путь виртуального преобразования, что и есть причина, по которой старый рецепт его рекомендует, и одновременно меняет ещё три вещи. Адресация теперь приходит из локального сегмента, а не от гипервизора, раскрытие означает, что гость виден этому сегменту, а допуск зависит от порта коммутатора и его политики. Любое из этого может быть причиной отказаться от изменения, и ни одно не о протоколе VPN.

Мостование не устанавливает отсутствующий плагин, не поставляет недоступного секретного агента и не исправляет отказ аутентификации. Оно также не делает устаревший протокол хорошим выбором, а там, где у оператора есть поддерживаемая замена, решением является именно она, а не смена гипервизора. Переадресация порта — совершенно третья роль: она публикует входящую службу и ничего не делает для внешнего протокола исходящего клиента.

Два туннеля, два следа доказательств

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

Сохраняйте первое сообщение об ошибке, а не последнее, потому что самая ранняя ошибка называет уровень. Меняйте одну поддерживаемую сетевую схему за раз, с тем же профилем гостя и теми же учётными данными, чтобы сравнение что-то значило. По ошибке решите, какой этап сломался: локальная интеграция, транспорт, аутентификация или доступ к ресурсам после подъёма туннеля. У каждого из них свой владелец, и только один — вопрос гипервизора.

Какое условие действительно вас блокирует

Теперь решение сужается до трёх вопросов с разными ответами. Если внешний протокол вне TCP и UDP, ограничением является режим NAT, и путь вперёд — мост или одобренный транспорт TCP/UDP. Если внешний обмен завершается, а путь данных нет, ограничение то же, что видно во втором доказательстве. Если туннель поднимается, а ресурсы не отвечают, проблема уже прошла гипервизор и находится в маршрутизации или политике.

Запишите ответ рядом с режимом адаптера, иначе следующий человек повторит тот же день. После любой правки проверьте реальное приложение и разрешение имён внутри гостя, затем переподключитесь и проверьте политику отказа. Работающая веб-страница через туннель доказывает только то, что работает веб-путь, а это меньшее утверждение, чем кажется в тот момент.