NAT или bridged в сети виртуальных машин: что пропускает трафик VPN?

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

Bridged и NAT — не два способа подключить одного и того же гостя к вашему VPN; они решают, кому принадлежат пакеты гостя до того, как в дело вступает туннель. В режиме NAT гипервизор перезаписывает трафик гостя и выпускает его из кода на стороне хоста, поэтому гость едет по тому маршруту, который хост даёт этому коду. В режиме bridged гость получает собственную идентичность канального уровня на физическом сегменте и выбирает собственный шлюз по умолчанию, из-за чего туннель хоста для него неважен, если только туннелированием не занимается сам маршрутизатор LAN. Я перестал считать виртуальную машину находящейся в VPN и стал считать это вопросом о том, куда указывает маршрут по умолчанию у этого гостя. Проверка ниже занимает несколько минут на режим и снимает вопрос без догадок.

NAT держит гостя за кодом гипервизора, где действуют маршруты хоста

В VirtualBox гость NAT живёт в 10.0.2.0/24 с виртуальным шлюзом 10.0.2.2, прокси DNS 10.0.2.3 и без собственного маршрута в физическую сеть. Исходящие пакеты подхватывает механизм NAT, перезаписывает так, что источником становится хост, и передаёт стеку IP хоста. Дальше трафик гостя — это поток хоста, а поиск маршрута идёт по назначению: клиент с полным туннелем, который ставит 0.0.0.0/1 и 128.0.0.0/1 на хосте, перехватывает его, даже не зная о существовании виртуальной машины. Глава Oracle о сетевых возможностях VirtualBox перечисляет эти значения по умолчанию, если вы хотите сверить адреса на своей сборке.

Сеть по умолчанию в libvirt приводит туда же, из 192.168.122.0/24, где dnsmasq выдаёт аренды, а хост выполняет маскарадинг подсети, так что пакеты гостя снова доходят до решения о маршрутизации на хосте. Исключение — клиент, который выбирает трафик по процессу, а не по маршруту. Если список раздельного туннелирования содержит только ваш браузер, механизма NAT в этом списке нет, и гость покидает машину без туннеля, пока браузер на хосте всё ещё выглядит защищённым. Та же подсеть, обратный результат.

Bridged даёт гостю собственное место в физической LAN

Bridged-гость получает виртуальный сетевой адаптер, подключённый к реальному, собственный MAC-адрес и аренду DHCP из физической сети. Его шлюз по умолчанию — маршрутизатор LAN, а не гипервизор, и его кадры уходят в сеть через этот адаптер. Туннельные маршруты хоста лежат в таблице хоста и никогда не запрашиваются, потому что кадры гостя не попадают в стек IP хоста.

Это работает в обе стороны. Просмотр mDNS и SMB начинает работать, потому что гость видит широковещательный трафик LAN, и гость становится доступен с других машин того же сегмента, без брандмауэра хоста посередине. Bridging — это ещё и не способ протолкнуть гостя через существующий туннель: подключить виртуальную машину к интерфейсу WireGuard или OpenVPN хоста за вас не станет ни VirtualBox, ни libvirt. Если bridged-гостя нужно туннелировать, туннель должен заканчиваться где-то в этой LAN.

Проверка, которая закрывает спор

Выполните одни и те же проверки в обоих режимах и запишите ответы:

  • На хосте curl -s https://ifconfig.me показывает публичный адрес v4.
  • В госте — та же команда плюс ip route в Linux или Get-NetRoute -DestinationPrefix 0.0.0.0/0 в Windows для шлюза по умолчанию.
  • Кто отвечает как резолвер: resolvectl status или cat /etc/resolv.conf в госте, чтобы увидеть, указывает ли он на 10.0.2.3 или на сервер LAN.
  • Семейство адресов: ip -6 addr show scope global и один запрос v6, потому что туннель v4 ничего не говорит о глобальном адресе v6, который может быть у гостя.

Совпадающие публичные адреса означают, что гость идёт по пути хоста. Адрес гостя, совпадающий с обычным выходом LAN, означает, что нет. Шаг, который пропускают, — контрольный: опустите туннель хоста и повторите запрос из гостя. Если гость продолжает открывать страницы, он никогда не зависел от туннеля хоста, как бы ни назывался режим. В режиме NAT гость должен потерять интернет при опущенном туннеле хоста, если только клиент не настроен разрешать трафик вне туннеля, что само по себе стоит знать.

Два сигнала лгут. Успешный ping доказывает доступность, а не путь выхода. И DNS может отвечать через прокси 10.0.2.3 силами резолвера хоста, пока TCP идёт другим маршрутом, — так и получается страница, которая загружается, и вход, который не завершается никогда.

Какой режим подходит для задачи

Режим — это решение о маршрутизации, поэтому выбирайте его из требования, а не по привычке:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

Первая строка — там, где люди попадаются: NAT плюс клиент с полным туннелем на хосте действительно покрывает гостя, но только пока клиент туннелирует по маршруту и восходящий канал хоста — это тот самый туннель. Переведите клиент на список разрешённых только для браузера, и покрытие исчезнет без единой ошибки где-либо. Четвёртая строка — обратная ошибка: гость в bridged из удобства, который тихо начинает отвечать по SMB или SSH в офисной LAN.

Сбои, которые валят на VPN

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

Bridging в Wi-Fi — другая классика. Точки доступа редко пересылают кадры с чужим MAC-адресом источника, поэтому мост на wlan0 либо сразу не работает, либо работает, пока изоляция клиентов на точке доступа не начнёт его отбрасывать. VirtualBox всё равно предложит беспроводной адаптер в списке. Если хост в Wi-Fi, а гостя нужно сделать bridged, планируйте проверку, а не полагайтесь на предположение.

MTU — третий. Bridged-гость сохраняет MTU LAN в 1500 байт, и если у него свой клиент WireGuard с 1420, крупные рукопожатия TLS зависают, а мелкие запросы проходят. Под NAT MTU туннеля хоста — забота хоста, но гость по-прежнему верит в 1500, и UDP с выставленным битом don't-fragment уходит в чёрную дыру точно так же.

Запишите режим и перепроверьте после любой смены адаптера

Зафиксируйте режим, интерфейс хоста, который использует мост, шлюз по умолчанию гостя, его резолвер и адреса выхода v4 и v6. Именно эта запись делает следующий сбой дешёвым: когда ноутбук переезжает с док-станции на Wi-Fi, bridged-гость следует за мостом на другой физический адаптер и может получить аренду в другой подсети, а гость NAT сохраняет адрес 10.0.2.x и молча наследует другой восходящий канал.

Прежде чем закрыть тикет, подтвердите каждый пункт:

  • Адрес выхода гостя отличается от адреса выхода хоста, то есть гость не в туннеле хоста.
  • Резолвер — это прокси 10.0.2.3 или сервер LAN, и вы знаете, какой из них ответил.
  • В госте нет глобального адреса v6, если схема туннеля только v4.
  • При опущенном туннеле хоста гость перестаёт открывать страницы — или вы теперь знаете, что он никогда от него не зависел.
  • Гость не видит широковещательный трафик LAN, который ему видеть незачем.

Похожие статьи