Bruker VM-en VPN-en til verten? Test det inne i gjesten

Du sjekker den offentlige IP-adressen til verten, den viser VPN, og du konkluderer med at VM-en er dekket. Den konklusjonen støttes ikke av testen. En gjest har sin egen rutetabell, sin egen resolver og sine egne grensesnitt, og utgangsadressen til verten sier ingenting om dem.

Testen må kjøres inne i gjesten, og den må navngi hva den målte.

Start inne i gjesten, ikke i nettleseren på verten

Registrer nettverksmodusen til hypervisoren først: NAT, bridged, host-only eller macvtap. I NAT-modus ruter verten trafikken til gjesten, så tunnelen til verten kan gjelde eller ikke, avhengig av hvordan klienten installerer ruter. I bridged-modus er gjesten en jevnbyrdig part på det fysiske LAN-et, og tunnelen til verten er irrelevant. Disse to modusene gir motsatte svar fra samme vertskonfigurasjon.

Skriv ned modusen før du endrer noe, fordi den avgjør hva resultatet kan bety.

Send én forespørsel der du kjenner målet

Bruk en ufarlig forespørsel til en tjeneste som rapporterer kildeadressen den så. Kontroller deretter gjestens egen rutebeslutning for det målet: ip route get 203.0.113.5 skriver ut grensesnittet og gatewayen som gjesten vil bruke.

Hvis grensesnittet er gjestens vanlige NIC, går trafikken ikke gjennom en tunnel inne i gjesten.

En ekstra adapter, en proxy-innstilling eller en VPN-klient på gjestesiden kan endre svaret for én applikasjon og ikke for en annen. Test applikasjonen du faktisk bryr deg om, ikke en generisk forespørsel fra et skall.

Kontroller resolveren separat

En endret utgangsadresse forteller deg ikke hvilken resolver som håndterte vertsnavnet. Spør eksplisitt på navnet med verktøyet som passer plattformen, og noter hvilken server som svarte. Split DNS betyr at resolver-spørsmålet og rutingsspørsmålet har forskjellige svar.

De to kan avvike i begge retninger, og avviket er ofte den egentlige feilen.

På en systemd-vert navngir resolvectl query grensesnittet og DNS-serveren bak svaret. Eldre oppsett viser serveren i utdataene fra dig. Uansett er poenget å se hvilken server som svarte, ikke bare om et svar kom.

Test feilpolitikken, ikke bare suksessen

Hvis kravet er at ingen trafikk skal gå utenfor tunnelen, beviser en vellykket forespørsel ingenting. Bruk den kontrollerte feiltesten som klienten støtter: stopp tunnelen på den støttede måten og se om en ny forespørsel fra gjesten blir blokkert. Ikke anta at kill switch-en til vertsklienten dekker enhver virtuell videresendingsoppsett. Det dokumenterte omfanget er det eneste du kan stole på.

En gjest som faller tilbake til den fysiske NIC-en når tunnelen faller, gjør nøyaktig det NAT-modus tillater.

Registrer modusen og omfanget

Skriv ned modusen til hypervisoren, grensesnittet og ruten til gjesten, resolveren og applikasjonen du testet. Legg til datoen, fordi en gjenoppretting av et øyeblikksbilde eller en hypervisor-oppdatering kan endre alle fire.

Hvis IPv4 fulgte tunnelen, si det. Ikke utvid påstanden til IPv6, et annet navnerom eller en annen VM på et annet nettverk.