NAT of gebrugd VM-netwerk: welke draagt VPN-verkeer?

Bruggen en NAT zijn geen twee manieren om dezelfde gast aan je VPN te koppelen; ze bepalen van wie de pakketten van de gast zijn voordat er überhaupt een tunnel in het spel is. In NAT-modus herschrijft de hypervisor het verkeer van de gast en stuurt het uit vanuit code aan de hostkant, zodat de gast de route volgt die de host die code geeft. In gebrugde modus krijgt de gast een eigen identiteit op de linklaag in het fysieke segment en kiest hij zijn eigen standaardgateway, wat de tunnel van de host voor hem irrelevant maakt, tenzij de LAN-router degene is die tunnelt. Ik ben gestopt de VM als op het VPN te zien en begon het te behandelen als een vraag waar de standaardroute van die gast naartoe wijst. De test hieronder kost een paar minuten per modus en beslecht het zonder giswerk.

NAT houdt de gast achter hypervisorcode, waar de routes van de host gelden

In VirtualBox zit een NAT-gast op 10.0.2.0/24 met een virtuele gateway op 10.0.2.2, een DNS-proxy op 10.0.2.3 en geen eigen route naar het fysieke netwerk. Uitgaande pakketten worden door de NAT-engine gepakt, herschreven zodat de bron de host is, en aan de IP-stack van de host gegeven. Vanaf daar is het verkeer van de gast een hoststroom, en routeopzoeking gebeurt op bestemming: een client met volledige tunnel die 0.0.0.0/1 en 128.0.0.0/1 op de host installeert, vangt het zonder ooit te weten dat er een VM bestaat. Het hoofdstuk van Oracle over VirtualBox-netwerken noemt deze standaardwaarden als je de adressen in je build wilt bevestigen.

Het standaardnetwerk van libvirt komt op dezelfde plek uit vanaf 192.168.122.0/24, waar dnsmasq leases uitgeeft en de host het subnet maskeert, zodat de pakketten van de gast weer bij de routingbeslissing van de host aankomen. De uitzondering is een client die verkeer op proces in plaats van op route kiest. Als de split-tunnel-lijst alleen je browser bevat en niets anders, staat de NAT-engine niet op die lijst, en verlaat de gast de machine zonder tunnel terwijl de browser op de host er nog steeds gedekt uitziet. Zelfde subnet, tegenovergesteld resultaat.

Bruggen geeft de gast zijn eigen plek op het fysieke LAN

Een gebrugde gast krijgt een virtuele NIC die aan een echte adapter hangt, krijgt een eigen MAC-adres en neemt een DHCP-lease van het fysieke netwerk. Zijn standaardgateway is de LAN-router, niet de hypervisor, en zijn frames gaan via die adapter de kabel op. De tunnelroutes van de host staan in de tabel van de host en worden nooit geraadpleegd, omdat de frames van de gast nooit in de IP-stack van de host komen.

Dat snijdt twee kanten op. mDNS en SMB-browsing gaan werken omdat de gast broadcastverkeer van het LAN ziet, en de gast wordt bereikbaar vanaf andere machines in hetzelfde segment zonder hostfirewall ertussen. Bruggen is ook geen manier om een gast door een bestaande tunnel te duwen: een VM aan de WireGuard- of OpenVPN-interface van de host hangen is niet iets wat VirtualBox of libvirt voor je doet. Moet een gebrugde gast door een tunnel, dan moet de tunnel ergens op dat LAN eindigen.

De test die de discussie beslecht

Voer dezelfde controles in beide modi uit en schrijf de antwoorden op:

• Op de host geeft curl -s https://ifconfig.me het openbare v4-adres.
• In de gast hetzelfde commando, plus ip route op Linux of Get-NetRoute -DestinationPrefix 0.0.0.0/0 op Windows voor de standaardgateway.
• Identiteit van de resolver: resolvectl status of cat /etc/resolv.conf in de gast, om te zien of die naar 10.0.2.3 of naar een LAN-server wijst.
• Adresfamilie: ip -6 addr show scope global en één v6-verzoek, omdat een v4-tunnel niets zegt over een globaal v6-adres dat de gast kan hebben.

Overeenkomende openbare adressen betekenen dat de gast op het pad van de host zit. Een gastadres dat overeenkomt met de gewone uitgang van het LAN betekent van niet. De stap die mensen overslaan is de controle: haal de tunnel van de host neer en herhaal het verzoek uit de gast. Blijft de gast browsen, dan was hij nooit afhankelijk van de tunnel van de host, wat de naam van de modus ook suggereert. In NAT-modus hoort de gast internet te verliezen als de tunnel van de host neerligt, tenzij de client is ingesteld om verkeer zonder tunnel toe te staan, wat op zichzelf de moeite van het weten waard is.

Twee signalen liegen. Een geslaagde ping bewijst bereikbaarheid, niet het uitgangspad. En DNS kan worden beantwoord door de 10.0.2.3-proxy via de resolver van de host terwijl TCP een andere route neemt, en zo krijg je een pagina die laadt en een login die nooit voltooit.

Welke modus bij de taak past

De modus is een routingbeslissing, dus kies hem op basis van de eis en niet van de gewoonte:

De eerste rij is waar mensen vastlopen: NAT plus een hostclient met volledige tunnel dekt een gast inderdaad, maar alleen zolang de client op route tunnelt en de uplink van de host die tunnel is. Zet de client op een allowlist alleen voor de browser en de dekking verdwijnt zonder enige fout ergens. De vierde rij is de omgekeerde fout: een gast die voor het gemak gebrugd is en stilletjes SMB of SSH gaat beantwoorden op het kantoor-LAN.

Storingen die op het VPN worden geschoven

Op Windows draait de NAT-vertaling in het VM-proces van VirtualBox, dus een client per app heeft precies dat image op zijn lijst nodig in plaats van een algemene regel voor virtuele machines. Wanneer een clientupdate zijn proceslijst opnieuw opbouwt, verliezen NAT-gasten als eerste de dekking, en het rapport leest als een VM die het LAN wel bereikt maar internet niet, terwijl de host in orde is.

Bruggen naar Wi-Fi is de andere klassieker. Accesspoints sturen zelden frames met een vreemd bron-MAC door, dus een brug naar wlan0 mislukt helemaal of werkt tot clientisolatie op het AP hem begint te laten vallen. VirtualBox biedt de draadloze adapter toch in zijn lijst aan. Staat de host op Wi-Fi en moet de gast gebrugd worden, plan dan een test in plaats van het aan te nemen.

MTU is de derde. Een gebrugde gast houdt de MTU van 1500 byte van het LAN, en als hij zijn eigen WireGuard-client op 1420 draait, stokken grote TLS-handshakes terwijl kleine verzoeken slagen. Onder NAT is de MTU van de tunnel van de host het probleem van de host, maar de gast gelooft nog steeds in 1500, en UDP met de don't-fragment-bit gezet verdwijnt op dezelfde manier.

Leg de modus vast en controleer opnieuw na elke adapterwissel

Noteer de modus, de hostinterface die de brug gebruikt, de standaardgateway van de gast, zijn resolver en zijn v4- en v6-uitgangsadressen. Die registratie maakt de volgende storing goedkoop: wanneer een laptop van de dock naar Wi-Fi gaat, volgt een gebrugde gast de brug naar een andere fysieke adapter en kan hij opnieuw leasen in een ander subnet, terwijl een NAT-gast zijn 10.0.2.x-adres houdt en stil een andere uplink erft.

Voordat je het ticket sluit, bevestig je elk van deze punten:

• Het uitgangsadres van de gast verschilt van dat van de host, dus hij zit niet op de tunnel van de host.
• De resolver is de 10.0.2.3-proxy of een LAN-server, en je weet welke antwoordde.
• Er bestaat geen globaal v6-adres in de gast als het tunnelontwerp alleen v4 is.
• Met de tunnel van de host neer stopt de gast met browsen, of je weet nu dat hij er nooit van afhing.
• De gast ziet geen LAN-broadcastverkeer dat hem niets aangaat.