VirtualBox: NAT или мост — где заканчивается VPN виртуальной машины

Два разных вопроса возникают одновременно каждый раз, когда виртуальная машина запускает VPN-клиент, и ответы у них разные. Первый — защищает ли туннель внутри гостя хост, второй — покрывает ли туннель на хосте гостя. Режим адаптера решает оба, сильнее, чем сам VPN-клиент. Адаптер NAT делает хост видимой конечной точкой, а мостовой адаптер выводит гостя в сеть с собственным адресом.

Кто на самом деле завершает шифрованную сессию

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

Чей адрес видит внешняя сеть — это вопрос, на который отвечает режим адаптера. Когда это решено, покрытие перестаёт быть вопросом политики и становится механическим. Всё ниже следует из этих двух фактов.

NAT переписывает гостя, пока он не станет похож на хост

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

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

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

Мост даёт гостю собственную аренду и собственную заметность

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

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

Почему гость не может быть шлюзом хоста

Одалживание туннеля гостя хосту не имеет поддерживаемого переключателя ни в одном из двух крупных гипервизоров. У хоста нет маршрута в туннель гостя и нет правила трансляции, указывающего туда, поэтому трафик гостя и хоста остаётся раздельными потоками с раздельными владельцами. Это направление не работает независимо от режима адаптера.

Рабочие замены — перенаправления и прокси. Локальное перенаправление SSH позволяет хосту подключиться к собственной петле, пока гость несёт поток в туннель, что покрывает службы TCP без установки второго клиента. Заставить собственный IP-трафик хоста вместо этого использовать туннель гостя требует маршрутизатора внутри гостя, а также явного маршрута на хосте и трансляции на хосте. Это небольшой сетевой проект, а не галочка, и он требует плана обратного пути. Когда гость существует только для запуска клиента, поставьте клиент на хост и уберите лишний шаг.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Резолверы и маршруты не пересекают границу

DNS следует за адаптером, который получил опцию, поэтому гость не наследует резолвер туннеля хоста, а хост никогда не узнаёт сервер, навязанный гостю. Навязанные значения dhcp-option DNS действуют для интерфейса, который их принял, и поэтому гость за мостом без клиента не может разрешить внутренние имена. Гость NAT обычно пользуется обработкой DNS гипервизора, и разница видна одной командой в каждом окружении.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

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