NAT ili bridged mreža VM-a: koja nosi VPN saobraćaj?
NAT gosti posuđuju tunel hosta samo ako klijent tunelira po ruti; bridged gosti sami rutiraju. Testirajte gosta, pa izaberite režim koji odgovara.
Bridged i NAT nisu dva načina da prikačite istog gosta na svoj VPN; oni odlučuju kome pripadaju paketi gosta pre nego što se tunel uopšte pojavi. U NAT režimu hipervizor prepisuje saobraćaj gosta i emituje ga iz koda na strani hosta, pa gost ide rutom koju host da tom kodu. U bridged režimu gost dobija sopstveni identitet na sloju veze na fizičkom segmentu i bira sopstveni podrazumevani gateway, zbog čega mu je tunel hosta nebitan, osim ako tunelira sam LAN ruter. Prestao sam da tretiram VM kao da je na VPN-u i počeo sam to da tretiram kao pitanje gde pokazuje podrazumevana ruta tog gosta. Test ispod traje nekoliko minuta po režimu i rešava stvar bez nagađanja.
NAT drži gosta iza koda hipervizora, gde važe rute hosta
U VirtualBox-u NAT gost stoji na 10.0.2.0/24 sa virtuelnim gateway-om na 10.0.2.2, DNS proxy-jem na 10.0.2.3 i bez sopstvene rute ka fizičkoj mreži. Odlazne pakete preuzima NAT mehanizam, prepisuje ih tako da izvor bude host i predaje ih IP steku hosta. Odatle je saobraćaj gosta tok hosta, a pretraga rute ide po odredištu: klijent sa punim tunelom koji na hostu postavi 0.0.0.0/1 i 128.0.0.0/1 hvata ga a da nikada ne sazna da VM postoji. Oracle-ovo poglavlje o umrežavanju u VirtualBox-u navodi te podrazumevane vrednosti ako želite da proverite adrese na svojoj verziji.
libvirt-ova podrazumevana mreža stiže na isto mesto iz 192.168.122.0/24, gde dnsmasq deli zakupe a host maskira podmrežu, pa paketi gosta ponovo dolaze do odluke o rutiranju na hostu. Izuzetak je klijent koji bira saobraćaj po procesu, a ne po ruti. Ako lista za delimično tuneliranje sadrži samo vaš pregledač, NAT mehanizam nije na toj listi, pa gost izlazi sa mašine bez tunela dok pregledač na hostu i dalje izgleda pokriveno. Ista podmreža, obrnut rezultat.
Bridged daje gostu sopstveno mesto na fizičkom LAN-u
Bridged gost dobija virtuelnu mrežnu karticu prikačenu na stvarni adapter, dobija sopstvenu MAC adresu i uzima DHCP zakup iz fizičke mreže. Njegov podrazumevani gateway je LAN ruter, ne hipervizor, a njegovi frejmovi idu na žicu kroz taj adapter. Rute tunela hosta žive u tabeli hosta i nikada se ne konsultuju, jer frejmovi gosta nikada ne ulaze u IP stek hosta.
To seče na obe strane. mDNS i SMB pregledanje počinju da rade jer gost vidi broadcast saobraćaj LAN-a, a gost postaje dostupan sa drugih mašina na istom segmentu bez firewall-a hosta između. Bridging takođe nije način da progurate gosta kroz postojeći tunel: kačenje VM-a na WireGuard ili OpenVPN interfejs hosta nije nešto što VirtualBox ili libvirt rade za vas. Ako bridged gost mora da bude tuneliran, tunel mora da se završi negde na tom LAN-u.
Test koji završava raspravu
Pokrenite iste provere u oba režima i zapišite odgovore:
- Na hostu,
curl -s https://ifconfig.medaje javnu v4 adresu. - U gostu, ista komanda, plus
ip routena Linux-u iliGet-NetRoute -DestinationPrefix 0.0.0.0/0na Windows-u za podrazumevani gateway. - Identitet rezolvera:
resolvectl statusilicat /etc/resolv.confu gostu, da vidite da li pokazuje na 10.0.2.3 ili na LAN server. - Familija adresa:
ip -6 addr show scope globali jedan v6 zahtev, jer v4 tunel ne govori ništa o globalnoj v6 adresi koju gost može da ima.
Iste javne adrese znače da je gost na putu hosta. Adresa gosta koja se poklapa sa uobičajenim izlazom LAN-a znači da nije. Korak koji ljudi preskaču je kontrola: spustite tunel hosta i ponovite zahtev iz gosta. Ako gost nastavi da pretražuje, nikada nije zavisio od tunela hosta, kako god se režim zvao. U NAT režimu gost treba da izgubi internet kada je tunel hosta spušten, osim ako je klijent podešen da dozvoli saobraćaj van tunela, što je samo po sebi vredno znanja.
Dva signala lažu. Uspešan ping dokazuje dostupnost, ne izlaznu putanju. A DNS može da odgovori kroz 10.0.2.3 proxy preko rezolvera hosta dok TCP ide drugom rutom, i tako dobijete stranicu koja se učita i prijavu koja se nikada ne završi.
Koji režim odgovara zadatku
Režim je odluka o rutiranju, pa ga birajte po zahtevu, a ne po navici:
| 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 |
Prvi red je mesto gde ljudi upadnu: NAT plus klijent sa punim tunelom na hostu zaista pokriva gosta, ali samo dok klijent tunelira po ruti i dok je uzvodni link hosta taj tunel. Prebacite klijent na listu dozvoljenih samo za pregledač i pokrivenost nestaje bez ikakve greške bilo gde. Četvrti red je obrnuta greška, gost u bridged režimu iz komocije koji tiho počne da odgovara na SMB ili SSH u kancelarijskom LAN-u.
Kvarovi koji se pripisuju VPN-u
Na Windows-u se NAT translacija izvršava unutar procesa VirtualBox VM-a, pa klijentu po aplikacijama treba baš taj image na listi, a ne opšte pravilo za virtuelne mašine. Kada ažuriranje klijenta ponovo izgradi listu dozvoljenih procesa, NAT gosti prvi izgube pokrivenost, a prijava zvuči kao VM koji doseže LAN ali ne internet, dok je host u redu.
Bridging na Wi-Fi je druga klasika. Pristupne tačke retko prosleđuju frejmove sa tuđom izvornom MAC adresom, pa bridge na wlan0 ili odmah ne uspe, ili radi dok izolacija klijenata na AP-u ne počne da ga odbacuje. VirtualBox će i dalje ponuditi bežični adapter na listi. Ako je host na Wi-Fi-ju a gost mora da bude bridged, planirajte test umesto da pretpostavljate.
MTU je treći. Bridged gost zadržava LAN MTU od 1500 bajtova, a ako pokreće sopstveni WireGuard klijent na 1420, veliki TLS handshake-ovi zapinju dok mali zahtevi prolaze. Pod NAT-om je MTU tunela hosta problem hosta, ali gost i dalje veruje u 1500, a UDP sa postavljenim don't-fragment bitom završava u crnoj rupi na isti način.
Zapišite režim pa proverite ponovo posle svake promene adaptera
Zabeležite režim, interfejs hosta koji bridge koristi, podrazumevani gateway gosta, njegov rezolver i izlazne adrese v4 i v6. Taj zapis je ono što sledeći kvar čini jeftinim: kada laptop pređe sa dock-a na Wi-Fi, bridged gost prati bridge na drugi fizički adapter i može da se ponovo zakuči u drugu podmrežu, dok NAT gost zadržava adresu 10.0.2.x i tiho nasleđuje drugačiji uzvodni link.
Pre zatvaranja tiketa, potvrdite svaku od ovih stavki:
- Izlazna adresa gosta razlikuje se od izlazne adrese hosta, pa gost nije na tunelu hosta.
- Rezolver je 10.0.2.3 proxy ili LAN server, i znate koji je od njih odgovorio.
- U gostu ne postoji globalna v6 adresa ako je dizajn tunela samo v4.
- Sa spuštenim tunelom hosta gost prestaje da pretražuje, ili sada znate da nikada nije zavisio od njega.
- Gost ne vidi broadcast saobraćaj LAN-a koji nema šta da vidi.