NAT sau bridged pentru rețeaua VM: care variantă transportă traficul VPN?

Oaspeții NAT împrumută tunelul gazdei doar dacă clientul tunelează după rută; oaspeții bridged se rutează singuri. Testați oaspetele, apoi alegeți modul potrivit.

Bridged și NAT nu sunt două moduri de a atașa același oaspete la VPN-ul dvs.; ele decid cine deține pachetele oaspetelui înainte de implicarea oricărui tunel. În modul NAT, hipervizorul rescrie traficul oaspetelui și îl emite din cod din partea gazdei, așa că oaspetele merge pe orice rută pe care gazda o dă acelui cod. În modul bridged, oaspetele primește propria identitate de nivel legătură pe segmentul fizic și își alege propriul gateway implicit, ceea ce face tunelul gazdei irelevant pentru el, dacă nu cumva routerul LAN este cel care tunelează. Am încetat să mai tratez VM-ul ca fiind în VPN și am început să îl tratez ca o întrebare despre unde indică ruta implicită a acelui oaspete. Testul de mai jos durează câteva minute pe mod și lămurește problema fără presupuneri.

NAT ține oaspetele în spatele codului hipervizorului, unde se aplică rutele gazdei

În VirtualBox, un oaspete NAT stă în 10.0.2.0/24, cu un gateway virtual la 10.0.2.2, un proxy DNS la 10.0.2.3 și nicio rută proprie către rețeaua fizică. Pachetele de ieșire sunt preluate de motorul NAT, rescrise astfel încât sursa să fie gazda și trimise stivei IP a gazdei. De acolo, traficul oaspetelui este un flux al gazdei, iar căutarea rutei se face după destinație: un client cu tunel complet care instalează 0.0.0.0/1 și 128.0.0.0/1 pe gazdă îl captează fără să știe vreodată că există un VM. Capitolul despre rețelistică din VirtualBox al Oracle listează aceste valori implicite dacă vreți să confirmați adresele pe build-ul dvs.

Rețeaua implicită a libvirt ajunge în același loc din 192.168.122.0/24, unde dnsmasq distribuie închirieri și gazda maschează subrețeaua, așa că pachetele oaspetelui ajung din nou la decizia de rutare a gazdei. Excepția este un client care alege traficul după proces, nu după rută. Dacă lista de tunelare parțială conține browserul dvs. și nimic altceva, motorul NAT nu este pe acea listă, iar oaspetele iese din mașină fără tunel, în timp ce browserul gazdei încă pare acoperit. Aceeași subrețea, rezultat opus.

Bridged îi dă oaspetelui propriul loc în LAN-ul fizic

Un oaspete bridged primește o placă de rețea virtuală atașată la un adaptor real, capătă propria adresă MAC și ia o închiriere DHCP din rețeaua fizică. Gateway-ul său implicit este routerul LAN, nu hipervizorul, iar cadrele sale ies pe fir prin acel adaptor. Rutele tunelului gazdei stau în tabela gazdei și nu sunt niciodată consultate, pentru că cadrele oaspetelui nu intră niciodată în stiva IP a gazdei.

Asta taie în ambele direcții. Navigarea mDNS și SMB începe să funcționeze pentru că oaspetele vede traficul broadcast din LAN, iar oaspetele devine accesibil din alte mașini de pe același segment, fără firewall de gazdă între ele. Bridging-ul nu este nici o cale de a împinge un oaspete printr-un tunel existent: atașarea unui VM la interfața WireGuard sau OpenVPN a gazdei nu este ceva ce VirtualBox sau libvirt face pentru dvs. Dacă un oaspete bridged trebuie tunelat, tunelul trebuie să se termine undeva în acel LAN.

Testul care închide discuția

Rulați aceleași verificări în ambele moduri și notați răspunsurile:

  • Pe gazdă, curl -s https://ifconfig.me dă adresa publică v4.
  • În oaspete, aceeași comandă, plus ip route pe Linux sau Get-NetRoute -DestinationPrefix 0.0.0.0/0 pe Windows pentru gateway-ul implicit.
  • Identitatea resolverului: resolvectl status sau cat /etc/resolv.conf în oaspete, ca să vedeți dacă indică spre 10.0.2.3 sau spre un server din LAN.
  • Familia de adrese: ip -6 addr show scope global și o cerere v6, pentru că un tunel v4 nu spune nimic despre o adresă v6 globală pe care oaspetele ar putea să o aibă.

Adrese publice identice înseamnă că oaspetele este pe calea gazdei. O adresă a oaspetelui care corespunde ieșirii obișnuite a LAN-ului înseamnă că nu este. Pasul pe care oamenii îl sar este controlul: opriți tunelul gazdei și repetați cererea din oaspete. Dacă oaspetele continuă să navigheze, nu a depins niciodată de tunelul gazdei, oricât ar sugera numele modului. În modul NAT, oaspetele ar trebui să piardă internetul cu tunelul gazdei oprit, dacă clientul nu este configurat să permită trafic fără tunel, ceea ce merită știut în sine.

Două semnale mint. Un ping reușit dovedește accesibilitatea, nu calea de ieșire. Iar DNS-ul poate fi răspuns de proxy-ul 10.0.2.3 prin resolverul gazdei în timp ce TCP ia o altă rută, și așa ajungeți la o pagină care se încarcă și la o autentificare care nu se termină niciodată.

Care mod se potrivește sarcinii

Modul este o decizie de rutare, așa că alegeți-l după cerință, nu după obișnuință:

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

Primul rând este locul unde oamenii se prind: NAT plus un client cu tunel complet pe gazdă acoperă într-adevăr un oaspete, dar numai cât timp clientul tunelează după rută și uplink-ul gazdei este acel tunel. Mutați clientul pe o listă permisă doar pentru browser și acoperirea dispare fără nicio eroare nicăieri. Al patrulea rând este greșeala inversă, un oaspete bridged din comoditate care începe în liniște să răspundă la SMB sau SSH în LAN-ul biroului.

Eșecuri puse pe seama VPN-ului

Pe Windows, traducerea NAT rulează în procesul VM al VirtualBox, așa că un client per aplicație are nevoie de exact acea imagine în listă, nu de o regulă generală pentru mașini virtuale. Când o actualizare a clientului reconstruiește lista proceselor permise, oaspeții NAT pierd primii acoperirea, iar raportul sună ca un VM care ajunge în LAN dar nu pe internet, în timp ce gazda este în regulă.

Bridging-ul către Wi-Fi este celălalt caz clasic. Punctele de acces rareori trimit mai departe cadre cu un MAC sursă străin, așa că un bridge pe wlan0 ori eșuează de tot, ori merge până când izolarea clienților din AP începe să îl arunce. VirtualBox va oferi totuși adaptorul wireless în listă. Dacă gazda este pe Wi-Fi și oaspetele trebuie bridged, planificați un test în loc să presupuneți.

MTU este al treilea. Un oaspete bridged păstrează MTU-ul de 1500 de octeți al LAN-ului, iar dacă rulează propriul client WireGuard la 1420, schimburile de chei TLS mari se blochează în timp ce cererile mici reușesc. Sub NAT, MTU-ul tunelului gazdei este problema gazdei, dar oaspetele încă crede în 1500, iar UDP cu bitul don't-fragment setat ajunge în gaură neagră la fel.

Notați modul și reverificați după orice schimbare de adaptor

Consemnați modul, interfața gazdei pe care o folosește bridge-ul, gateway-ul implicit al oaspetelui, resolverul său și adresele de ieșire v4 și v6. Această evidență este ce face următorul eșec ieftin: când un laptop trece de la dock la Wi-Fi, un oaspete bridged urmează bridge-ul către alt adaptor fizic și se poate reînchiria în altă subrețea, în timp ce un oaspete NAT își păstrează adresa 10.0.2.x și moștenește în tăcere alt uplink.

Înainte de a închide tichetul, confirmați fiecare dintre acestea:

  • Adresa de ieșire a oaspetelui diferă de adresa de ieșire a gazdei, deci nu este pe tunelul gazdei.
  • Resolverul este proxy-ul 10.0.2.3 sau un server din LAN, și știți care dintre ele a răspuns.
  • Nu există adresă v6 globală în oaspete dacă proiectul tunelului este doar v4.
  • Cu tunelul gazdei oprit, oaspetele nu mai navighează, sau acum știți că nu a depins niciodată de el.
  • Oaspetele nu vede trafic broadcast din LAN pe care nu are ce căuta.

Articole similare