Bruger din VM værtens VPN? Test det indefra gæsten
Værtens udgangsadresse siger intet om gæstens ruter. Noter netværkstilstanden, kontroller gæstens rute og resolver, og test derefter fejltilfældet.
Du tjekker værtens offentlige IP, den viser VPN, og du konkluderer, at VM'en er dækket. Den konklusion understøttes ikke af testen. En gæst har sin egen routingtabel, sin egen resolver og sine egne netværksgrænseflader, og værtens udgangsadresse siger intet om dem.
Testen skal køre inde i gæsten, og den skal navngive, hvad den målte.
Start inde i gæsten, ikke i værtens browser
Noter først hypervisorens netværkstilstand: NAT, bridged, host-only eller macvtap. I NAT-tilstand router værten gæstens trafik, så værtens tunnel kan eller kan ikke gælde afhængigt af, hvordan klienten installerer ruter. I bridged-tilstand er gæsten en jævnbyrdig på det fysiske LAN, og værtens tunnel er irrelevant. De to tilstande giver modsatte svar ud fra den samme værtkonfiguration.
Skriv tilstanden ned, før du ændrer noget, fordi den afgør, hvad resultatet kan betyde.
Send én anmodning, hvis destination du kender
Brug en uskadelig anmodning til en tjeneste, der rapporterer den kildeadresse, den så. Kontroller derefter gæstens egen routingbeslutning for den destination: ip route get 203.0.113.5 udskriver det netværkskort og den gateway, som gæsten vil bruge.
Hvis grænsefladen er gæstens normale NIC, går trafikken ikke gennem en tunnel inde i gæsten.
En ekstra adapter, en proxyindstilling eller en VPN-klient på gæstesiden kan ændre svaret for ét program og ikke for et andet. Test det program, du faktisk er interesseret i, ikke en generisk anmodning fra en shell.
Kontroller resolveren separat
En ændret udgangsadresse fortæller ikke, hvilken resolver der håndterede værtsnavnet. Slå navnet op eksplicit med det værktøj, der passer til platformen, og noter, hvilken server der svarede. Delt DNS betyder, at resolver-spørgsmålet og routing-spørgsmålet har forskellige svar.
De to kan divergere i begge retninger, og afvigelsen er ofte den egentlige fejl.
På en systemd-vært resolvectl query navngiver det grænsefladen og DNS-serveren bag svaret. Ældre opsætninger viser serveren i outputtet fra dig — under alle omstændigheder er pointen at se, hvilken server der svarede, ikke bare om et svar kom.
Test fejlpolitikken, ikke kun succesen
Hvis kravet er, at ingen trafik forlader tunnelen, beviser en vellykket anmodning intet. Brug klientens understøttede kontrollerede fejltest: stop tunnelen på den understøttede måde, og se, om en ny anmodning fra gæsten blokeres. Antag ikke, at værtklientens kill switch dækker enhver virtuel videresendelsesopsætning. Dens dokumenterede omfang er det eneste, du kan stole på.
En gæst, der falder tilbage til det fysiske NIC, når tunnelen falder, gør præcis det, NAT-tilstand tillader.
Noter tilstanden og omfanget
Skriv hypervisorens tilstand ned, gæstens grænseflade og rute, resolveren og det program, du testede. Tilføj datoen, fordi en gendannelse af et snapshot eller en hypervisoropdatering kan ændre alle fire.
Hvis IPv4 fulgte tunnelen, så sig det. Udvid ikke påstanden til IPv6, et andet navnerum eller en anden VM på et andet netværk.