Gebruikt een Hyper-V-VM de VPN van de host? Het hangt van de switch af

Installeer een VPN-client op de Hyper-V-host, open daar een browser, en het uitgangsadres verandert; open dezelfde pagina in de VM en die toont misschien het oude adres, of helemaal niets. De gebruikelijke conclusie is dat de VM kapot is, of dat split-tunneling moet worden aangezet. Geen van beide volgt. Een VPN-client is geen eigenschap van de machine; het is een set routes, een virtuele adapter en vaak een filter dat aan specifieke interfaces hangt. Of gastverkeer die machinerie ooit tegenkomt, hangt af van de virtuele switch die de gast gebruikt.

De mythe, ronduit gezegd

Het geloof is dat een VPN op de host de hele machine beschermt, inclusief VM's, omdat een VM alleen een proces op die machine is. Het is een comfortabel geloof, want antivirus en host-firewalls gedragen zich meestal zo. Netwerkpaden niet.

Het frame van een gast wordt alleen door de VPN-stack van de host aangeraakt als de host het routeert of filtert. Schrijf die zin op een plakbriefje, want elk geval hieronder is er een variant van.

Drie switchtypen, drie paden

Een externe switch verbindt een virtuele adapter met een fysieke netwerkkaart, en de gast stuurt frames via die binding met zijn eigen MAC-adres. De gast wordt een gelijke op het fysieke netwerk, met een eigen DHCP-lease, gateway en DNS-servers. De standaardroute van de VPN van de host leeft in de hoststack en verplaatst die frames niet, omdat ze worden gebrugd in plaats van via de host gerouteerd. Daarom is een externe switch over een Wi-Fi-adapter ook een slecht idee: de meeste draadloze stuurprogramma's dragen geen frames voor een tweede MAC-adres.

Een interne switch verbindt gasten met een virtuele adapter van de host. Op zichzelf biedt die geen internetuitgang; een NAT-object op de host zorgt voor vertaling, zoals beschreven in de Hyper-V NAT-handleiding. Nu komen de pakketten van de gast echt in de routering en het NAT-pad van de host, dus de routes en filters van de VPN-client tellen weer mee. Dit is de opstelling waarin de VM de VPN van de host echt volgt, en waarin een kill switch de gast volledig kan afsnijden.

Een privéswitch heeft geen hostadapter en geen uplink. Gasten praten met elkaar en met niets anders, dus als een VM op een privéswitch geen internet heeft, is de ontbrekende router de oorzaak en is de VPN irrelevant.

De standaardswitch is een eigen opstelling

Windows levert een standaardswitch die een interne switch combineert met NAT en een DNS-proxy. Het subnet wordt door de host gekozen, kan na herstarts veranderen en is niet hetzelfde object als een NAT-netwerk dat je zelf maakt. Hem opnieuw opbouwen alsof het een labnetwerk is, is hoe mensen met twee NAT's en een gast zonder route eindigen.

Als de VM op de standaardswitch staat, lees dan het adres dat de gast heeft gekregen en vergelijk het met de NAT-tabel van de host voordat je de VPN-client aanraakt. Een mismatch tussen de gateway van de gast en het NAT-prefix verklaart meer fouten dan welke clientinstelling dan ook.

Vier feiten die de vraag beslechten

Verzamel dit voordat je iets verandert: het switchtype en zijn uplink, de adapter die aan de VM is gekoppeld, het eigen adres, de gateway en DNS van de gast, en de NAT- en standaardroutestatus van de host. De alleen-lezen-opdrachten zijn Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat, en Get-NetRoute -DestinationPrefix 0.0.0.0/0; en in de gast geeft ipconfig /all de rest.

Beslis dan wat de gast moet doen. Als hij buiten de VPN moet blijven, vraag dan de ondersteunde uitzondering van de provider voor precies dat pad, want het uitsluiten van een uitvoerbaar bestand op de host stelt doorgestuurd VM-verkeer niet vrij. Als hij de VPN moet gebruiken, bevestig dan de gedocumenteerde omgang van de client met VM-verkeer in plaats van aan te nemen dat een test in de browser van de host dat dekt.

Een test in de gast is het enige bewijs dat telt. Controleer het uitgangsadres vanaf de gast, los een interne naam op, verbind de VPN opnieuw en herhaal. Het browserresultaat van de host vervangt niets daarvan.

Wat de mythe kost

Mensen zetten de kill switch uit, voegen statische routes toe of verwijderen en maken switches opnieuw alleen om een test te laten slagen. Elke snelkoppeling verandert de faalmodus: de gast kan internet bereiken via een pad dat niemand bedoelde, of de host kan de verbinding verliezen wanneer een externe switch zijn fysieke kaart opnieuw bindt.

Het opnieuw binden van een externe switch onderbreekt de eigen toegang van de host, dus houd een out-of-band-pad open en vermijd het verwijderen van switches terwijl je nog diagnosticeert. Het juiste resultaat is het bedoelde pad van de gast, inclusief hoe die opnieuw verbindt en hoe die faalt, niet een groen vinkje van één paginalading.

Het blijvende antwoord is één regel per VM in de inventaris: welke switch die gebruikt en welke component zijn gateway levert. Als dat opgeschreven staat, is de volgende VPN-wijziging een opzoeking in plaats van een middag gissen.