Использует ли ваша VM VPN хоста? Проверьте изнутри гостя

Вы проверяете публичный IP хоста, он показывает VPN, и делаете вывод, что VM защищена. Этот вывод не подтверждается такой проверкой. У гостя есть собственная таблица маршрутизации, собственный резолвер и собственные интерфейсы, и адрес выхода хоста ничего о них не говорит.

Проверка должна выполняться внутри гостя и должна называть, что именно измерено.

Начните внутри гостя, а не в браузере хоста

Сначала запишите режим сети гипервизора: NAT, bridged, host-only или macvtap. В режиме NAT хост маршрутизирует трафик гостя, поэтому туннель хоста может применяться или нет в зависимости от того, как клиент устанавливает маршруты. В режиме bridged гость является равноправным участником физической LAN, а туннель хоста не имеет значения. Эти два режима дают противоположные ответы при одной и той же конфигурации хоста.

Запишите режим до того, как что-либо менять, потому что именно он определяет, что может означать результат.

Сделайте один запрос, пункт назначения которого вам известен

Используйте безобидный запрос к сервису, который сообщает адрес источника, который он увидел. Затем проверьте собственное решение гостя о маршрутизации для этого пункта назначения: ip route get 203.0.113.5 печатает интерфейс и шлюз, которые будет использовать гость.

Если интерфейс — обычный NIC гостя, трафик не идёт через туннель внутри гостя.

Второй адаптер, настройка прокси или VPN-клиент на стороне гостя могут изменить ответ для одного приложения и не изменить для другого. Проверяйте приложение, которое действительно важно, а не общий запрос из оболочки.

Проверьте резолвер отдельно

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

Эти два могут расходиться в любую сторону, и именно это расхождение часто и есть настоящая ошибка.

На хосте с systemd resolvectl query называет интерфейс и DNS-сервер, стоящие за ответом. Более старые конфигурации показывают сервер в выводе dig. В любом случае суть в том, чтобы увидеть, какой сервер ответил, а не просто пришёл ли ответ.

Проверяйте политику отказа, а не только успех

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

Гость, который при падении туннеля возвращается на физический NIC, делает ровно то, что разрешает режим NAT.

Запишите режим и область

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

Если IPv4 шёл через туннель, так и скажите. Не распространяйте утверждение на IPv6, другое пространство имён или другую VM в другой сети.