De VPN op de host of in de VM draaien? Beslissingsdraaiboek

De tunnel in de gast bouwen en hem op de host bouwen veranderen allebei het adres dat een browser rapporteert, en daar houdt de gelijkenis op. Een gast-eigendom-tunnel houdt zijn sleutels, zijn standaardroute en zijn resolver in de gastkernel, terwijl de host versleutelde pakketten naar één extern adres stuurt. Een host-eigendom-tunnel is het spiegelbeeld: de hostclient houdt de sessie vast en past routes en beleid toe, en de gast leent wat eruit komt. Kies de verkeerde eigenaar en elk later symptoom stuurt je naar de verkeerde machine. Twee opdrachten beslechten de vraag in ongeveer een minuut, en de rest van dit draaiboek is wat je met het antwoord doet.

Bepaal de eigenaar voordat je de client aanraakt

De regel gaat over waar de ciphertext wordt geproduceerd, niet over welke machine een VPN-pictogram toont. Als de gast hem produceert, heeft de gast een werkende route naar de VPN-server nodig en verder niets van de host. Als de host hem produceert, moet het pad van de gast via de host elk beleid overleven dat de hostclient aan lokaal verkeer oplegt.

Drie vragen kiezen de plaatsing meestal voor je. Moet het verkeer van de gast een bedrijfsclient op de host overleven? Dan hoort de tunnel in de gast. Hebben meerdere gasten één inloggegeven en één uitgangsadres nodig? Dan hoort hij op de host, met doorsturen met opzet ingericht. Moet het verkeer van de gast volledig buiten de VPN van de host blijven? Dan is een tunnel in de gast de enige opstelling die je dat door de constructie geeft.

Schrijf het antwoord als één regel naast de VM-naam: guest-owned of host-owned. In een lab van zes machines bespaart die notitie meer tijd dan welke stap hieronder ook, want ze weerhoudt je ervan een tunnel te onderzoeken die nooit in de machine zat waarop je bent ingelogd.

WSL1 en WSL2 zijn tegengestelde gevallen

WSL1 is geen virtuele machine, dus de plaatsingsvraag vervliegt grotendeels. De Linux-binary's draaien tegen de netwerkstack van Windows via een vertaallaag, en een Linux-VPN-client heeft geen onafhankelijke interfaces om te configureren. Wat werkt is een tunnel aan de Windows-kant, waarbij de distributie het resultaat gebruikt zonder iets te bezitten.

WSL2 is het omgekeerde. Het draait een echte kernel in een lichte hulp-VM achter een virtuele Hyper-V-switch, en de adresruimte wordt via NAT vertaald door een adapter aan de hostkant. Een Linux-client in de distributie gedraagt zich dus als op een fysieke Linux-doos: hij maakt tun0 of wg0 aan, installeert zijn eigen routes en werkt. De fout zit aan de hostkant. Wanneer een Windows-VPN-client verbindt met een beleid dat verkeer op lokale netwerken blokkeert, behandelt hij het WSL2-subnet als een niet-vertrouwd lokaal netwerk en snijdt het NAT-pad door. De distributie verliest dan DNS en uitgaande toegang terwijl zijn eigen tunnel nog gezond is: wg show meldt een handshake, ip route ziet er correct uit, en curl blijft hangen.

Welke oplossing je kunt gebruiken hangt af van de Windows-build. De oudere is een uitzondering in de hostclient voor het WSL-subnet, toegevoegd onder de instellingen voor lokaal netwerk of gesplitste tunnel van de client. De nieuwere, op Windows 11-builds die het ondersteunen, is gespiegeld netwerken: zet networkingMode=mirrored in de sectie [wsl2] van %UserProfile%\.wslconfig, voer wsl --shutdown uit, en de distributie deelt de interfaces van de host in plaats van een privaat NAT-subnet. De gespiegelde modus verandert ook het gedrag van localhost en inkomende poorten, dus behandel hem als een migratie en niet als een schakelaar.

NAT, bridge en wat de host kan zien

Onder NAT worden de tunnelpakketten van de gast geadresseerd aan het openbare adres van de VPN-server en verlaten ze de hostadapter als versleuteld UDP of TCP. De host ziet één stroom en het bytetotaal ervan, niets over de bestemmingen erin. Onder een bridge-adapter heeft de gast zijn eigen identiteit op laag 2 op het fysieke LAN, neemt hij zijn eigen DHCP-lease en ziet hij er voor elk MAC-gebaseerd beleid uit als een tweede apparaat. Geen van beide modi laat de host de tunnelpayload lezen; de gebrugde gast is simpelweg veel zichtbaarder voor het netwerk eromheen.

Er zit ook een ondergrens aan de isolatie. Een gast kan zich niet verstoppen voor de machine die zijn geheugen bezit, en wie de host beheert kan sleutels uit het RAM van de gast lezen. Wat een tunnel in de gast je geeft, is een routeringsgrens en een malwaregrens, geen bescherming tegen de persoon die de laptop vasthoudt. De gedocumenteerde adaptermodi zijn het waard open te hebben terwijl je kiest, want de modus verandert zowel wat de host ziet als wat het LAN ziet.

Draaiboek: plaats hem, configureer hem, bewijs het

Voer deze vier controles op volgorde uit in een verse gast-shell, en stop bij de eerste die niet overeenkomt met de eigenaar die je hebt opgeschreven.

1. ip route get 1.1.1.1 dat tun0 of wg0 teruggeeft betekent gast-eigendom, en eth0 met een private volgende hop betekent host-eigendom.
2. resolvectl query example.com, of lees /etc/resolv.conf waar de gast geen resolverservice draait. Een tunnel die verkeer maar geen DNS draagt, is de meest voorkomende half geconfigureerde toestand.
3. Vergelijk de uitgangen: curl -4 -s https://ifconfig.me in de gast tegen curl.exe -4 -s https://ifconfig.me op de host. Verschillende adressen betekenen dat de gast de tunnel bezit, en een host op de VPN met een gast die de thuisprovider toont is het geval waarin niets werd geërfd.
4. Herhaal beide met -6. Een tunnel met alleen v4 lekt v6 tenzij de client het blokkeert of routeert, en veel clients laten v6 standaard op de fysieke interface.

Voor een ontwerp met een host-gateway, waarbij meerdere gasten één tunnel delen, moet de host doorsturen en vertalen. Op een Linux-host zijn dat drie stukken, en de gast valt stil terug op zijn gewone route wanneer een ervan ontbreekt:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Aan de WireGuard-kant moet de AllowedIPs van de hostpeer het gastsubnet bevatten, bijvoorbeeld 192.168.122.0/24, anders komen de retourpakketten nooit aan en lijkt de opstelling op een firewallprobleem. Een Windows-host bereikt hetzelfde resultaat met Internet Connection Sharing of een NAT-regel op de Hyper-V-switch, en heeft dezelfde controle van het retourpad nodig.

Wanneer de opzet nog open is, dekt deze tabel de meest voorkomende arrangementen:

Twee tunnels, twee gasten en de conflicten ertussen

Wanneer je twee uitgangen tegelijk nodig hebt, is het patroon dat standhoudt één tunnel per gast. Elke VM houdt zijn eigen standaardroute en resolver, de host blijft op het gewone netwerk, en de twee tunnels kibbelen nooit over dezelfde routingtabel. Twee gasten aan elkaar bruggen bundelt hun routes ook niet: het virtuele netwerk levert een pad, en elke client moet nog steeds worden verteld dat dit lokale verkeer de tunnel mag omzeilen.

Een hosttunnel en een gasttunnel samen draaien is legitiem, en bewust nesten is soms precies wat je wilt, waarbij de gast via zijn eigen tunnel naar buiten gaat en die tunnel via die van de host. Wat er een storing van maakt, is dat niemand heeft opgeschreven welk eindpunt via welke laag bereikt moet worden. Houd een lijst van twee kolommen bij met bestemming en eigenaar, en een routeconflict wordt een opzoeking in plaats van een middag ontdekken.

Verifieer en laat het herstel dan bij de eigenaar

Test van binnenuit de gast met een vers applicatieproces: verkeer, naamresolutie, beide adresfamilies en wat er gebeurt als de tunnel wegvalt. Het VPN-pictogram van de host zegt niets over de dekking van de gast, en dat is de meest voorkomende valse bevestiging in dit hele gebied.

Herstel hoort ook bij de eigenaar. Een gast-eigendom-tunnel wordt hersteld door de eigen client van de gast en de routes die hij schreef. Een host-eigendom-ontwerp wordt hersteld door de opstartvolgorde van de host, en de doorstuurregels overleven geen herstart tenzij een unit of een opstarttaak ze opnieuw toepast. Een herstelde snapshot is een uitrol, geen ongedaanmaking, want hij brengt oude inloggegevens en oude routes mee terug met de schijf. Voordat je het werk klaar noemt, bevestig je dat de eigenaar nog steeds overeenkomt met de regel die je opschreef, dat DNS en beide adresfamilies in de gast oplossen, dat een dode tunnel een bruikbaar netwerk achterlaat in plaats van een zwart gat, en dat een herstart of snapshot-herstel dezelfde toestand reproduceren.