NAT naspram premosnog umrežavanja VM-a: što prenosi VPN promet?

NAT gosti posuđuju tunel hosta samo ako klijent tunelira po ruti; premosni gosti sami usmjeravaju promet. Testirajte gosta, pa odaberite odgovarajući način rada.

Premosni način i NAT nisu dva načina povezivanja istog gosta na vaš VPN; oni odlučuju kome pripadaju paketi gosta prije nego što je uopće uključen tunel . U NAT načinu hipervizor prepisuje promet gosta i ispušta ga iz koda na strani hosta, pa gost ide rutom koju host dodijeli tom kodu. U premosnom načinu gost dobija vlastiti identitet sloja veze na fizičkom segmentu i sam bira zadani pristupnik, što tunel hosta čini nevažnim za njega, osim ako tunel ne pravi usmjerivač na LAN-u. Prestao sam VM promatrati kao dio VPN-a i počeo to gledati kao pitanje kamo pokazuje zadana ruta tog gosta. Test u nastavku traje nekoliko minuta po načinu i rješava stvar bez nagađanja.

NAT drži gosta iza koda hipervizora, gdje vrijede rute hosta

U VirtualBoxu NAT gost sjedi na 10.0.2.0/24 s virtualnim pristupnikom na 10.0.2.2, DNS proxyjem na 10.0.2.3 i bez vlastite rute prema fizičkoj mreži. Odlazne pakete preuzima NAT mehanizam, prepisuje ih tako da izvor bude host i predaje IP stogu hosta. Odatle je promet gosta tok hosta, a pretraga rute ide po odredištu: klijent s punim tunelom koji na hostu postavi 0.0.0.0/1 i 128.0.0.0/1 hvata ga i ne znajući da VM postoji. Oracleovo poglavlje o umrežavanju u VirtualBoxu navodi te zadane vrijednosti ako želite potvrditi adrese na svojoj instalaciji.

Zadana mreža libvirta dolazi na isto mjesto s 192.168.122.0/24, gdje dnsmasq dijeli najmove, a host maskira podmrežu, pa paketi gosta opet stižu do usmjerivačke odluke hosta. Iznimka je klijent koji odabire promet po procesu, a ne po ruti. Ako popis za podijeljeni tunel sadrži samo vaš preglednik, NAT mehanizma nema na tom popisu i gost napušta stroj bez tunela, dok preglednik hosta još izgleda pokriven. Ista podmreža, obrnut rezultat.

Premosni način daje gostu vlastito mjesto na fizičkom LAN-u

Premosni gost dobija virtualni NIC priključen na stvarni adapter, vlastitu MAC adresu i DHCP najam od fizičke mreže. Njegov zadani pristupnik je usmjerivač na LAN-u, ne hipervizor, a okviri idu na žicu kroz taj adapter. Tunelske rute hosta žive u tablici hosta i nikada se ne pitaju, jer okviri gosta nikada ne ulaze u IP stog hosta.

To reže na obje strane. mDNS i SMB pregledavanje počinju raditi jer gost vidi broadcast promet LAN-a, a gost postaje dostupan s drugih strojeva na istom segmentu bez vatrozida hosta između. Premošćivanje također nije način da gosta progurate kroz postojeći tunel: spajanje VM-a na WireGuard ili OpenVPN sučelje hosta nije nešto što VirtualBox ili libvirt radi za vas. Ako premosni gost mora biti u tunelu, tunel mora završiti negdje na tom LAN-u.

Test koji prekida raspravu

Pokrenite iste provjere u oba načina i zapišite odgovore:

  • Na hostu curl -s https://ifconfig.me daje javnu v4 adresu.
  • U gostu ista naredba, plus ip route na Linuxu ili Get-NetRoute -DestinationPrefix 0.0.0.0/0 na Windowsu za zadani pristupnik.
  • Identitet razrješivača: resolvectl status ili cat /etc/resolv.conf u gostu, da vidite pokazuje li na 10.0.2.3 ili na poslužitelj na LAN-u.
  • Obitelj adresa: ip -6 addr show scope global i jedan v6 zahtjev, jer v4 tunel ne govori ništa o globalnoj v6 adresi koju gost može imati.

Podudarne javne adrese znače da je gost na putu hosta. Adresa gosta koja se podudara s uobičajenim izlazom LAN-a znači da nije. Korak koji ljudi preskaču jest kontrola: spustite tunel hosta i ponovite zahtjev gosta. Ako gost nastavi pregledavati, nikada nije ovisio o tunelu hosta, što god ime načina sugeriralo. U NAT načinu gost bi trebao izgubiti internet kad je tunel hosta spušten, osim ako je klijent konfiguriran da dopušta promet izvan tunela, što je samo po sebi vrijedno znati.

Dva signala lažu. Uspješan ping dokazuje dosegljivost, ne izlazni put. A DNS može odgovoriti proxy 10.0.2.3 kroz razrješivač hosta dok TCP ide drugom rutom, i tako dobijete stranicu koja se učita i prijavu koja nikada ne završi.

Koji način odgovara zadatku

Način je usmjerivačka odluka, pa ga birajte prema zahtjevu, a ne prema navici:

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

Prvi red je mjesto gdje se ljudi uhvate: NAT plus klijent s punim tunelom na hostu doista pokriva gosta, ali samo dok klijent tunelira po ruti i dok je veza hosta prema gore taj tunel. Premjestite klijent na popis samo za preglednik i pokrivenost nestaje bez ikakve pogreške. Četvrti red je obrnuta pogreška: gost premošten radi udobnosti tiho počne odgovarati na SMB ili SSH na uredskom LAN-u.

Kvarovi koji se pripisuju VPN-u

Na Windowsu se NAT prevođenje izvodi unutar procesa VirtualBox VM-a, pa klijent za pojedine aplikacije treba upravo tu sliku na svom popisu, a ne opće pravilo za virtualne strojeve. Kad ažuriranje klijenta ponovno izgradi popis dopuštenih procesa, NAT gosti prvi gube pokrivenost, a izvješće izgleda kao VM koji doseže LAN ali ne internet, dok je host u redu.

Premošćivanje na Wi-Fi druga je klasika. Pristupne točke rijetko prosljeđuju okvire sa stranim izvornim MAC-om, pa premošćivanje na wlan0 ili potpuno ne uspije ili radi dok izolacija klijenata na pristupnoj točki ne počne odbacivati. VirtualBox će i dalje ponuditi bežični adapter na svom popisu. Ako je host na Wi-Fi-ju i gost mora biti premošten, planirajte test umjesto da pretpostavljate.

MTU je treći. Premosni gost zadržava MTU LAN-a od 1500 bajtova, a ako pokrene vlastiti WireGuard klijent na 1420, velika TLS rukovanja zapnu dok mali zahtjevi prolaze. Pod NAT-om je MTU tunela hosta problem hosta, ali gost još vjeruje u 1500, a UDP s postavljenim bitom zabrane fragmentiranja upada u istu crnu rupu.

Zapišite način, pa ponovno provjerite nakon svake promjene adaptera

Zabilježite način, sučelje hosta koje most koristi, zadani pristupnik gosta, njegov razrješivač te njegove izlazne adrese v4 i v6. Taj zapis čini sljedeći kvar jeftinim: kad prijenosnik prijeđe s priključne stanice na Wi-Fi, premosni gost slijedi most na drugi fizički adapter i može se ponovno iznajmiti u drugu podmrežu, dok NAT gost zadržava adresu 10.0.2.x i tiho nasljeđuje drugu vezu prema gore.

Prije zatvaranja zahtjeva potvrdite svako od ovoga:

  • Izlazna adresa gosta razlikuje se od izlazne adrese hosta, pa nije na tunelu hosta.
  • Razrješivač je proxy 10.0.2.3 ili poslužitelj na LAN-u i znate koji je odgovorio.
  • U gostu nema globalne v6 adrese ako je dizajn tunela samo v4.
  • Kad je tunel hosta spušten, gost prestaje pregledavati, ili sada znate da nikada nije ovisio o njemu.
  • Gost ne vidi broadcast promet LAN-a koji ne bi trebao vidjeti.

Povezani članci