Gebruikt je VM de VPN van de host? Test het binnen de gast

Je controleert het publieke IP van de host, het toont de VPN en je concludeert dat de VM gedekt is. Die conclusie wordt door de test niet ondersteund. Een gast heeft zijn eigen routetabel, zijn eigen resolver en zijn eigen interfaces, en het exitadres van de host zegt daar niets over.

De test moet binnen de gast draaien en moet benoemen wat hij heeft gemeten.

Begin binnen de gast, niet in de browser van de host

Leg eerst de netwerkmodus van de hypervisor vast: NAT, bridged, host-only of macvtap. In NAT-modus routeert de host het verkeer van de gast, dus de tunnel van de host kan wel of niet gelden, afhankelijk van hoe de client de routes installeert. In bridged-modus is de gast een gelijkwaardige peer op de fysieke LAN en is de tunnel van de host irrelevant. Die twee modi geven tegengestelde antwoorden bij dezelfde hostconfiguratie.

Schrijf de modus op voordat je iets verandert, want die bepaalt wat het resultaat kan betekenen.

Doe één verzoek waarvan je de bestemming kent

Gebruik een onschuldig verzoek naar een dienst die het bronadres rapporteert dat hij zag. Controleer daarna de eigen routeringsbeslissing van de gast voor die bestemming: ip route get 203.0.113.5 drukt de interface en de gateway af die de gast gaat gebruiken.

Als de interface de normale NIC van de gast is, gaat het verkeer niet door een tunnel binnen de gast.

Een tweede adapter, een proxy-instelling of een VPN-client aan de gastzijde kan het antwoord voor de ene toepassing veranderen en niet voor de andere. Test de toepassing die je echt belangrijk vindt, niet een generiek verzoek vanuit een shell.

Controleer de resolver apart

Een gewijzigd exitadres vertelt je niet welke resolver de hostnaam heeft afgehandeld. Vraag de naam expliciet op met het hulpprogramma dat bij het platform past en noteer welke server heeft geantwoord. Split DNS betekent dat de resolvervraag en de routeringsvraag verschillende antwoorden hebben.

Die twee kunnen in beide richtingen uiteenlopen, en die divergentie is vaak de echte bug.

Op een systemd-host noemt resolvectl query de interface en de DNS-server achter het antwoord. Oudere configuraties tonen de server in de uitvoer van dig. Hoe dan ook, het punt is te zien welke server antwoordde, niet alleen of er een antwoord kwam.

Test het faalbeleid, niet alleen het succes

Als de eis is dat er geen verkeer buiten de tunnel uitgaat, bewijst een geslaagd verzoek niets. Gebruik de door de client ondersteunde gecontroleerde faaltest: stop de tunnel op de ondersteunde manier en kijk of een nieuw verzoek van de gast wordt geblokkeerd. Ga er niet van uit dat de kill switch van de hostclient elke virtuele doorstuurregeling dekt. De gedocumenteerde reikwijdte is het enige waarop je kunt vertrouwen.

Een gast die terugvalt op de fysieke NIC wanneer de tunnel wegvalt, doet precies wat NAT-modus toestaat.

Leg de modus en de reikwijdte vast

Schrijf de modus van de hypervisor op, de interface en route van de gast, de resolver en de toepassing die je hebt getest. Voeg de datum toe, want een snapshot-herstel of een hypervisor-update kan alle vier veranderen.

Als IPv4 de tunnel volgde, zeg dat dan. Breid de bewering niet uit naar IPv6, een andere namespace of een andere VM op een ander netwerk.