NAT или bridged мрежа виртуелних машина: шта пропушта VPN саобраћај?
NAT гости позајмљују тунел хоста само ако клијент тунелира по рути; bridged гости сами рутирају. Тестирајте госта и затим изаберите режим који одговара.
Bridged и NAT нису два начина да се исти гост прикључи на ваш VPN; они одлучују коме припадају пакети госта пре него што се било који тунел уопште појави. У NAT режиму хипервизор преписује саобраћај госта и емитује га из кода на страни хоста, па гост иде рутом коју хост да том коду. У bridged режиму гост добија сопствени идентитет на слоју везе на физичком сегменту и бира сопствени подразумевани gateway, због чега му је тунел хоста небитан, осим ако тунелира сам LAN рутер. Престао сам да третирам VM као да је на VPN-у и почео сам то да третирам као питање где показује подразумевана рута тог госта. Тест испод траје неколико минута по режиму и решава ствар без нагађања.
NAT држи госта иза кода хипервизора, где важе руте хоста
У VirtualBox-у NAT гост стоји на 10.0.2.0/24 са виртуелним gateway-ом на 10.0.2.2, DNS proxy-јем на 10.0.2.3 и без сопствене руте ка физичкој мрежи. Одлазне пакете преузима NAT механизам, преписује их тако да извор буде хост и предаје их IP стек-у хоста. Одатле је саобраћај госта ток хоста, а претрага руте иде по одредишту: клијент са пуним тунелом који на хосту постави 0.0.0.0/1 и 128.0.0.0/1 хвата га а да никада не сазна да VM постоји. Oracle-ово поглавље о умрежавању у VirtualBox-у наводи те подразумеване вредности ако желите да проверите адресе у својој верзији.
libvirt-ова подразумевана мрежа стиже на исто место из 192.168.122.0/24, где dnsmasq дели закупе а хост маскира подмрежу, па пакети госта поново долазе до одлуке о рутирању на хосту. Изузетак је клијент који бира саобраћај по процесу, а не по рути. Ако листа за делимично тунелирање садржи само ваш прегледач, NAT механизам није на тој листи, па гост излази са машине без тунела док прегледач на хосту и даље изгледа покривено. Иста подмрежа, обрнут резултат.
Bridged даје госту сопствено место на физичком LAN-у
Bridged гост добија виртуелну мрежну картицу прикључену на стварни адаптер, добија сопствену MAC адресу и узима DHCP закуп из физичке мреже. Његов подразумевани gateway је LAN рутер, не хипервизор, а његови оквири иду на жицу кроз тај адаптер. Руте тунела хоста живе у табели хоста и никада се не консултују, јер оквири госта никада не улазе у IP стек хоста.
То сече на обе стране. mDNS и SMB прегледање почињу да раде јер гост види broadcast саобраћај LAN-а, а гост постаје доступан са других машина на истом сегменту без firewall-а хоста између. Bridging такође није начин да прогурате госта кроз постојећи тунел: качење VM-а на WireGuard или OpenVPN интерфејс хоста није нешто што VirtualBox или libvirt раде за вас. Ако bridged гост мора да буде тунелиран, тунел мора да се заврши негде на том LAN-у.
Тест који завршава расправу
Покрените исте провере у оба режима и запишите одговоре:
- На хосту,
curl -s https://ifconfig.meдаје јавну v4 адресу. - У госту, иста команда, плус
ip routeна Linux-у илиGet-NetRoute -DestinationPrefix 0.0.0.0/0на Windows-у за подразумевани gateway. - Идентитет резолвера:
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 proxy преко резолвера хоста док TCP иде другом рутом, и тако добијете страницу која се учита и пријаву која се никада не заврши.
Који режим одговара задатку
Режим је одлука о рутирању, па га бирајте по захтеву, а не по навици:
| Requirement | Mode that fits |
|---|---|
| Every guest flow must exit through the host tunnel | NAT, with a host client that tunnels by route, verified from inside the guest |
| The guest needs its own VPN account or profile | Bridged, or NAT with a client running inside the guest, not both |
| The guest must serve SSH, SMB, or a dev server to the LAN | Bridged; NAT needs a port forward, which does not change the outbound path |
| The guest must stay invisible to the LAN | NAT; a bridged guest is another host on the segment |
| The guest needs a real public IPv6 address | Bridged; VirtualBox NAT mode has no IPv6 forwarding |
| Isolation from the LAN with access to the host | Host-only adapter, not NAT |
Први ред је место где људи упадну: NAT плус клијент са пуним тунелом на хосту заиста покрива госта, али само док клијент тунелира по рути и док је узводни линк хоста тај тунел. Пребаците клијент на листу дозвољених само за прегледач и покривеност нестаје без икакве грешке било где. Четврти ред је обрнута грешка, гост у bridged режиму из комодитета који тихо почне да одговара на SMB или SSH у канцеларијском LAN-у.
Кварови који се приписују VPN-у
На Windows-у се NAT превод извршава унутар процеса VirtualBox VM-а, па клијенту по апликацијама треба баш тај image на листи, а не опште правило за виртуелне машине. Када ажурирање клијента поново изгради листу дозвољених процеса, NAT гости први изгубе покривеност, а пријава звучи као VM који достиже LAN али не интернет, док је хост у реду.
Bridging на Wi-Fi је друга класика. Приступне тачке ретко прослеђују оквире са туђом изворном MAC адресом, па bridge на wlan0 или одмах не успе, или ради док изолација клијената на AP-у не почне да га одбацује. VirtualBox ће и даље понудити бежични адаптер на листи. Ако је хост на Wi-Fi-ју а гост мора да буде bridged, планирајте тест уместо да претпостављате.
MTU је трећи. Bridged гост задржава LAN MTU од 1500 бајтова, а ако покреће сопствени WireGuard клијент на 1420, велики TLS руковања запну док мали захтеви пролазе. Под NAT-ом је MTU тунела хоста проблем хоста, али гост и даље верује у 1500, а UDP са постављеним don't-fragment битом завршава у црној рупи на исти начин.
Запишите режим па проверите поново после сваке промене адаптера
Забележите режим, интерфејс хоста који bridge користи, подразумевани gateway госта, његов резолвер и излазне адресе v4 и v6. Тај запис је оно што следећи квар чини јефтиним: када лаптоп пређе са dock-а на Wi-Fi, bridged гост прати bridge на други физички адаптер и може поново да се закучи у другу подмрежу, док NAT гост задржава адресу 10.0.2.x и тихо наслеђује другачији узводни линк.
Пре затварања тикета, потврдите сваку од ових ставки:
- Излазна адреса госта разликује се од излазне адресе хоста, па гост није на тунелу хоста.
- Резолвер је 10.0.2.3 proxy или LAN сервер, и знате који је од њих одговорио.
- У госту не постоји глобална v6 адреса ако је дизајн тунела само v4.
- Са спуштеним тунелом хоста гост престаје да претражује, или сада знате да никада није зависио од њега.
- Гост не види broadcast саобраћај LAN-а који нема шта да види.