NAT ili premosni VM mrežni način: što prenosi VPN promet?

NAT gosti posuđuju tunel hosta samo kad klijent tunelira prema ruti; premosni gosti sami usmjeravaju. Testirajte gosta pa odaberite odgovarajući način.

Premošćivanje i NAT nisu dva načina povezivanja istog gosta s vašim VPN-om; oni odlučuju čije su pakete gosta prije nego što ikakav tunel uopće uđe u igru. U NAT načinu hipervizor prepisuje promet gosta i šalje ga iz koda na strani hosta, pa gost ide rutom koju host daje tom kodu. U premosnom načinu gost dobiva vlastiti identitet na sloju veze u fizičkom segmentu i sam bira svoj zadani pristupnik, što tunel hosta čini nevažnim za njega, osim ako je LAN usmjernik taj koji tunelira. Prestao sam VM promatrati kao da je na VPN-u i počeo sam to tretirati 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 motor, prepisuje ih tako da je izvor host i predaje ih IP stogu hosta. Odande je promet gosta tok hosta, a pretraga rute ide po odredištu: klijent punog tunela koji instalira 0.0.0.0/1 i 128.0.0.0/1 na hostu hvata ga, a da nikad ne zna da VM postoji. Oracleovo poglavlje o VirtualBox mrežama navodi te zadane vrijednosti ako želite potvrditi adrese u svojoj instalaciji.

libvirtova zadana mreža dolazi na isto mjesto s 192.168.122.0/24, gdje dnsmasq dijeli leaseove, a host maskira podmrežu, pa paketi gosta ponovno dolaze do odluke o usmjeravanju na hostu. Iznimka je klijent koji odabire promet po procesu, a ne po ruti. Ako popis split-tunnela sadrži samo vaš preglednik i ništa drugo, NAT motor nije na tom popisu, i gost napušta stroj bez tunela dok preglednik na hostu i dalje izgleda pokriveno. Ista podmreža, suprotan rezultat.

Premošćivanje daje gostu vlastito mjesto na fizičkom LAN-u

Premosni gost dobiva virtualnu mrežnu karticu prikopčanu na stvarni adapter, dobiva vlastitu MAC adresu i uzima DHCP lease iz fizičke mreže. Njegov zadani pristupnik je LAN usmjernik, ne hipervizor, a njegovi okviri idu na žicu kroz taj adapter. Rute tunela hosta žive u tablici hosta i nikad se ne konzultiraju, jer okviri gosta nikad ne ulaze u IP stog hosta.

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

Test koji završava 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 LAN poslužitelj.
  • 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 odgovara uobičajenom izlazu LAN-a znači da nije. Korak koji ljudi preskaču je kontrola: spustite tunel hosta i ponovite zahtjev iz gosta. Ako gost nastavi pregledavati, nikad 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 bez tunela, što je samo po sebi vrijedno znanja.

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

Koji način odgovara poslu

Način je odluka o usmjeravanju, pa ga odaberite 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 redak je mjesto gdje ljudi upadnu: NAT plus klijent punog tunela na hostu doista pokriva gosta, ali samo dok klijent tunelira po ruti i dok je uzlazna veza hosta taj tunel. Premjestite klijent na popis dopuštenih samo za preglednik i pokrivenost nestaje bez ikakve pogreške bilo gdje. Četvrti redak je obrnuta pogreška: gost premošten zbog praktičnosti koji tiho počne odgovarati na SMB ili SSH na uredu LAN-u.

Kvarovi koji se pripisuju VPN-u

Na Windowsu se NAT prijevod izvršava unutar VirtualBox VM procesa, pa klijent po aplikaciji treba točno tu sliku na svom popisu umjesto općeg pravila za virtualne strojeve. Kad klijentsko ažuriranje ponovno izgradi popis procesa, NAT gosti prvi gube pokrivenost, a izvještaj se čita kao VM koji dolazi do LAN-a ali ne do interneta dok je host u redu.

Premošćivanje na Wi-Fi je drugi klasik. Pristupne točke rijetko prosljeđuju okvire sa stranim izvornim MAC-om, pa premosnica na wlan0 ili potpuno ne uspije ili radi dok je izolacija klijenata na AP-u ne počne odbacivati. VirtualBox će ipak ponuditi bežični adapter na svom popisu. Ako je host na Wi-Fi-ju, a gost mora biti premošten, planirajte to testirati umjesto pretpostaviti.

MTU je treći. Premosni gost zadržava LAN-ovih 1500 bajtova MTU-a, a ako vrti vlastiti WireGuard klijent na 1420, velika TLS rukovanja zapnu dok mali zahtjevi prolaze. Pod NAT-om je MTU tunela hosta problem hosta, ali gost i dalje vjeruje u 1500, a UDP s postavljenim don't-fragment bitom nestaje na isti način.

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

Zapišite način, sučelje hosta koje premosnica koristi, zadani pristupnik gosta, njegov razrješivač i njegove v4 i v6 izlazne adrese. Taj zapis čini sljedeći kvar jeftinim: kad prijenosnik prijeđe s dok-a na Wi-Fi, premošteni gost slijedi premosnicu na drugi fizički adapter i može ponovno uzeti lease u drugoj podmreži, dok NAT gost zadržava svoju 10.0.2.x adresu i tiho nasljeđuje drugu uzlaznu vezu.

Prije zatvaranja tiketa, potvrdite svaku od ovih:

  • Izlazna adresa gosta razlikuje se od izlazne adrese hosta, pa nije na tunelu hosta.
  • Razrješivač je 10.0.2.3 proxy ili LAN poslužitelj, i znate koji je odgovorio.
  • U gostu ne postoji globalna v6 adresa ako je koncept tunela samo v4.
  • S tunelom hosta spuštenim gost prestaje pregledavati, ili sada znate da nikad nije ovisio o njemu.
  • Gost ne vidi LAN broadcast promet koji ga se ne tiče.

Povezani članci