NAT enfront de la xarxa pontada de VM: quina porta el trànsit de VPN?
Els convidats NAT manllevien el túnel de l’amfitrió només si el client fa túnel per ruta; els convidats pontats s’encaminen ells mateixos. Proveu el convidat i trieu el mode que hi encaixi.
El pont i NAT no són dues maneres de connectar el mateix convidat a la vostra VPN; decideixen qui és l’amo dels paquets del convidat abans que hi intervingui cap túnel . En mode NAT l’hipervisor reescriu el trànsit del convidat i l’emet des de codi del costat de l’amfitrió, de manera que el convidat viatja per la ruta que l’amfitrió doni a aquest codi. En mode pont el convidat rep la seva pròpia identitat d’enllaç al segment físic i tria la seva porta d’enllaç per defecte, cosa que fa irrellevant el túnel de l’amfitrió tret que el router de la LAN sigui qui construeix el túnel. Vaig deixar de tractar la VM com si fos dins de la VPN i vaig començar a tractar-ho com una pregunta sobre on apunta la ruta per defecte del convidat. La prova de sota triga uns quants minuts per mode i ho resol sense endevinar.
NAT manté el convidat darrere del codi de l’hipervisor, on manen les rutes de l’amfitrió
A VirtualBox un convidat NAT se situa a 10.0.2.0/24 amb una porta d’enllaç virtual a 10.0.2.2, un proxy DNS a 10.0.2.3 i cap ruta pròpia cap a la xarxa física. Els paquets sortints els agafa el motor NAT, els reescriu perquè l’origen sigui l’amfitrió i els passa a la pila IP de l’amfitrió. Des d’allà el trànsit del convidat és un flux de l’amfitrió, i la consulta de ruta és per destinació: un client de túnel complet que instal·la 0.0.0.0/1 i 128.0.0.0/1 a l’amfitrió l’atrapa sense saber mai que existeix una VM. El capítol de xarxes de VirtualBox d’Oracle llista aquests valors per defecte si voleu confirmar les adreces a la vostra instal·lació.
La xarxa per defecte de libvirt arriba al mateix lloc des de 192.168.122.0/24, on dnsmasq reparteix concessions i l’amfitrió emmascara la subxarxa, així que els paquets del convidat tornen a la decisió d’encaminament de l’amfitrió. L’excepció és un client que tria el trànsit per procés en lloc de per ruta. Si la llista de túnel dividit només conté el vostre navegador, el motor NAT no hi és, i el convidat surt de la màquina sense túnel mentre el navegador de l’amfitrió encara sembla cobert. Mateixa subxarxa, resultat oposat.
El pont dona al convidat el seu propi lloc a la LAN física
Un convidat pontat rep una NIC virtual connectada a un adaptador real, obté la seva pròpia adreça MAC i agafa una concessió DHCP de la xarxa física. La seva porta d’enllaç per defecte és el router de la LAN, no l’hipervisor, i les seves trames surten al cable per aquell adaptador. Les rutes del túnel de l’amfitrió viuen a la taula de l’amfitrió i no es consulten mai, perquè les trames del convidat no entren mai a la pila IP de l’amfitrió.
Això talla en tots dos sentits. La navegació mDNS i SMB comença a funcionar perquè el convidat veu el trànsit de difusió de la LAN, i el convidat es fa accessible des d’altres màquines del mateix segment sense cap tallafoc de l’amfitrió entremig. El pont tampoc no és una manera d’empènyer un convidat per un túnel existent: connectar una VM a la interfície WireGuard o OpenVPN de l’amfitrió no és una cosa que VirtualBox o libvirt facin per vosaltres. Si un convidat pontat ha d’anar per túnel, el túnel ha d’acabar en algun lloc d’aquella LAN.
La prova que acaba la discussió
Feu les mateixes comprovacions en tots dos modes i anoteu les respostes:
- A l’amfitrió,
curl -s https://ifconfig.medona l’adreça v4 pública. - Al convidat, la mateixa ordre, més
ip routea Linux oGet-NetRoute -DestinationPrefix 0.0.0.0/0a Windows per a la porta d’enllaç per defecte. - Identitat del resolutor:
resolvectl statusocat /etc/resolv.confal convidat, per veure si apunta a 10.0.2.3 o a un servidor de la LAN. - Família d’adreces:
ip -6 addr show scope globali una petició v6, perquè un túnel v4 no diu res sobre una adreça v6 global que el convidat pugui tenir.
Adreces públiques coincidents volen dir que el convidat va pel camí de l’amfitrió. Una adreça de convidat que coincideix amb la sortida habitual de la LAN vol dir que no. El pas que la gent s’estalvia és el control: baixeu el túnel de l’amfitrió i repetiu la petició del convidat. Si el convidat continua navegant, mai no va dependre del túnel de l’amfitrió, digui el que digui el nom del mode. En mode NAT el convidat hauria de perdre internet amb el túnel de l’amfitrió baixat, tret que el client estigui configurat per permetre trànsit sense túnel, cosa que val la pena saber per si sola.
Dos senyals menteixen. Un ping correcte demostra abastabilitat, no camí de sortida. I el DNS pot ser respost pel proxy 10.0.2.3 a través del resolutor de l’amfitrió mentre TCP agafa una altra ruta, i així obteniu una pàgina que carrega i un inici de sessió que no s’acaba mai.
Quin mode encaixa amb la feina
El mode és una decisió d’encaminament, així que trieu-lo pel requisit i no pel costum:
| 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 |
La primera fila és on la gent cau: NAT més un client de túnel complet a l’amfitrió sí que cobreix un convidat, però només mentre el client fa túnel per ruta i l’enllaç de l’amfitrió és aquell túnel. Moveu el client a una llista només per al navegador i la cobertura desapareix sense cap error enlloc. La quarta fila és l’error invers: un convidat pontat per comoditat que comença a respondre SMB o SSH a la LAN de l’oficina sense dir-ho.
Fallades que es carreguen a la VPN
A Windows la traducció NAT s’executa dins del procés de la VM de VirtualBox, així que un client per aplicació necessita aquella imatge exacta a la seva llista en lloc d’una regla general per a màquines virtuals. Quan una actualització del client refà la llista de processos permesos, els convidats NAT perden la cobertura primer, i l’informe es llegeix com una VM que arriba a la LAN però no a internet mentre l’amfitrió està bé.
El pont a Wi-Fi és l’altra clàssica. Els punts d’accés rarament reenvien trames amb una MAC d’origen aliena, així que un pont a wlan0 o falla del tot o funciona fins que l’aïllament de clients del punt d’accés comença a descartar-lo. VirtualBox encara oferirà l’adaptador sense fil a la seva llista. Si l’amfitrió és a Wi-Fi i el convidat ha d’anar pontat, planifiqueu provar-ho en lloc de suposar-ho.
L’MTU és el tercer. Un convidat pontat manté l’MTU de 1500 bytes de la LAN, i si fa córrer el seu propi client WireGuard a 1420, les grans negociacions TLS s’encallen mentre les peticions petites passen. Sota NAT l’MTU del túnel de l’amfitrió és problema de l’amfitrió, però el convidat encara creu en 1500, i l’UDP amb el bit de no fragmentar activat cau al mateix forat negre.
Anoteu el mode i torneu a comprovar-ho després de qualsevol canvi d’adaptador
Registreu el mode, la interfície de l’amfitrió que fa servir el pont, la porta d’enllaç per defecte del convidat, el seu resolutor i les seves adreces de sortida v4 i v6. Aquest registre és el que fa barata la propera fallada: quan un portàtil passa de l’estació d’acoblament al Wi-Fi, un convidat pontat segueix el pont cap a un altre adaptador físic i pot tornar a agafar concessió en una altra subxarxa, mentre un convidat NAT conserva la seva adreça 10.0.2.x i hereta en silenci un altre enllaç.
Abans de tancar el tiquet, confirmeu cadascuna d’aquestes coses:
- L’adreça de sortida del convidat difereix de la de l’amfitrió, així que no és al túnel de l’amfitrió.
- El resolutor és el proxy 10.0.2.3 o un servidor de la LAN, i sabeu quin ha respost.
- No hi ha cap adreça v6 global al convidat si el disseny del túnel és només v4.
- Amb el túnel de l’amfitrió baixat, el convidat deixa de navegar, o ara sabeu que mai no hi va dependre.
- El convidat no veu trànsit de difusió de la LAN que no li toqui veure.