Använder din VM värdens VPN? Testa inifrån gästen
Värdens utgångsadress säger ingenting om gästens rutter. Registrera nätverksläget, kontrollera gästens rutt och resolver och testa sedan felet.
Du kontrollerar värdens publika IP, den visar VPN och du drar slutsatsen att VM:en är täckt. Den slutsatsen stöds inte av testet. En gäst har sin egen routingtabell, sin egen resolver och sina egna gränssnitt, och värdens utgångsadress säger ingenting om dem.
Testet måste köras inifrån gästen och det måste namnge vad det mätte.
Börja inifrån gästen, inte i värdens webbläsare
Registrera först hypervisorns nätverksläge: NAT, bridged, host-only eller macvtap. I NAT-läge routar värden gästens trafik, så värdens tunnel kan gälla eller inte beroende på hur klienten installerar rutter. I bridged-läge är gästen en jämbördig part på det fysiska LAN:et och värdens tunnel är irrelevant. Dessa två lägen ger motsatta svar från samma värdkonfiguration.
Skriv ner läget innan du ändrar något, eftersom det avgör vad resultatet kan betyda.
Skicka en förfrågan vars destination du känner till
Använd en ofarlig förfrågan till en tjänst som rapporterar den källadress den såg. Kontrollera sedan gästens eget routingbeslut för den destinationen: ip route get 203.0.113.5 skriver ut gränssnittet och gatewayen som gästen kommer att använda.
Om gränssnittet är gästens vanliga NIC går trafiken inte genom en tunnel inuti gästen.
En andra adapter, en proxyinställning eller en VPN-klient på gästsidan kan ändra svaret för en applikation och inte för en annan. Testa den applikation du faktiskt bryr dig om, inte en generisk förfrågan från ett skal.
Kontrollera resolvern separat
En ändrad utgångsadress berättar inte vilken resolver som hanterade värdnamnet. Fråga uttryckligen efter namnet med verktyget som passar plattformen och notera vilken server som svarade. Split DNS betyder att resolverfrågan och routingfrågan har olika svar.
De två kan avvika i båda riktningarna, och avvikelsen är ofta den verkliga buggen.
På en systemd-värd namnger resolvectl query gränssnittet och DNS-servern bakom svaret. Äldre konfigurationer visar servern i utdata från dig. Hur som helst är poängen att se vilken server som svarade, inte bara om ett svar kom.
Testa felpolicyn, inte bara framgången
Om kravet är att ingen trafik ska gå utanför tunneln bevisar en lyckad förfrågan ingenting. Använd det kontrollerade feltest som klienten stöder: stoppa tunneln på det stödda sättet och se om en ny förfrågan från gästen blockeras. Anta inte att värdklientens kill switch täcker varje virtuell vidarebefordran. Dess dokumenterade omfattning är det enda du kan lita på.
En gäst som faller tillbaka på det fysiska NIC:et när tunneln faller gör precis det NAT-läget tillåter.
Registrera läget och omfattningen
Skriv ner hypervisorns läge, gästens gränssnitt och rutt, resolvern och applikationen du testade. Lägg till datumet, eftersom en återställning av en ögonblicksbild eller en hypervisoruppdatering kan ändra alla fyra.
Om IPv4 följde tunneln, säg det. Utöka inte påståendet till IPv6, ett annat namnområde eller en annan VM på ett annat nätverk.