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

Du sjekkar den offentlege IP-adressa til verten, ho viser VPN, og du konkluderer med at VM-en er dekt. Den konklusjonen blir ikkje støtta av testen. Ein gjest har si eiga rutetabell, sin eigen resolvar og sine eigne grensesnitt, og utgangsadressa til verten seier ingenting om dei.

Testen må køyrast inne i gjesten, og han må nemne kva han målte.

Start inne i gjesten, ikkje i nettlesaren 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 ikkje, avhengig av korleis klienten installerer ruter. I bridged-modus er gjesten ein jamstilt part på det fysiske LAN-et, og tunnelen til verten er irrelevant. Desse to modusane gir motsette svar frå same vertskonfigurasjon.

Skriv ned modusen før du endrar noko, fordi han avgjer kva resultatet kan tyde.

Send éin førespurnad der du kjenner målet

Bruk ein ufarleg førespurnad til ein teneste som rapporterer kjeldeadressa han såg. Kontroller deretter gjestens eigen ruteavgjerd for det målet: ip route get 203.0.113.5 skriv ut grensesnittet og gatewayen som gjesten vil bruke.

Viss grensesnittet er den vanlege NIC-en til gjesten, går trafikken ikkje gjennom ein tunnel inne i gjesten.

Ein ekstra adapter, ei proxy-innstilling eller ein VPN-klient på gjestesida kan endre svaret for éin applikasjon og ikkje for ein annan. Test applikasjonen du faktisk bryr deg om, ikkje ein generisk førespurnad frå eit skal.

Kontroller resolvaren separat

Ei endra utgangsadresse fortel deg ikkje kva resolvar som handsama vertsnamnet. Spør eksplisitt på namnet med verktøyet som passar plattforma, og noter kva server som svara. Split DNS betyr at resolvarspørsmålet og rutingsspørsmålet har ulike svar.

Dei to kan avvike i begge retningar, og avviket er ofte den eigentlege feilen.

På ein systemd-vert nemner resolvectl query grensesnittet og DNS-serveren bak svaret. Eldre oppsett viser serveren i utdataa frå dig. Uansett er poenget å sjå kva server som svara, ikkje berre om eit svar kom.

Test feilpolitikken, ikkje berre suksessen

Viss kravet er at ingen trafikk skal gå utanfor tunnelen, beviser ein vellukka førespurnad ingenting. Bruk den kontrollerte feiltesten som klienten støttar: stopp tunnelen på den støtta måten og sjå om ein ny førespurnad frå gjesten blir blokkert. Ikkje rekn med at kill switch-en til vertsklienten dekkjer kvar virtuell vidaresendingsoppsett. Det dokumenterte omfanget er det einaste du kan stole på.

Ein gjest som fell tilbake til den fysiske NIC-en når tunnelen fell, gjer nøyaktig det NAT-modus tillèt.

Registrer modusen og omfanget

Skriv ned modusen til hypervisoren, grensesnittet og ruta til gjesten, resolvaren og applikasjonen du testa. Legg til datoen, fordi ein gjenoppretting av eit augeblinksbilete eller ei hypervisor-oppdatering kan endre alle fire.

Viss IPv4 følgde tunnelen, sei det. Ikkje utvid påstanden til IPv6, eit anna namnerom eller ein annan VM på eit anna nettverk.