Koristi li vaša VM VPN hosta? Testirajte to iz unutrašnjosti gosta

Provjerite javnu IP adresu hosta, ona pokazuje VPN, i zaključite da je VM pokriven. Taj zaključak test ne podržava. Gost ima vlastitu tablicu rutiranja, vlastiti resolver i vlastita sučelja, a izlazna adresa hosta ne govori ništa o njima.

Test se mora izvesti unutar gosta i mora navesti šta je izmjerio.

Počnite unutar gosta, a ne u pregledniku hosta

Prvo zabilježite mrežni način hipervizora: NAT, bridged, host-only ili macvtap. U načinu NAT host rutira promet gosta, pa se tunel hosta može primijeniti ili ne, ovisno o tome kako klijent instalira rute. U načinu bridged gost je ravnopravan na fizičkoj LAN mreži i tunel hosta nije relevantan. Ta dva načina daju suprotne odgovore iz iste konfiguracije hosta.

Zapišite način prije nego što bilo šta promijenite, jer on određuje šta rezultat može značiti.

Pošaljite jedan zahtjev čije odredište poznajete

Upotrijebite bezopasan zahtjev prema servisu koji prijavljuje izvornu adresu koju je vidio. Zatim provjerite vlastitu odluku gosta o ruti za to odredište: ip route get 203.0.113.5 ispisuje sučelje i pristupnik koje će gost koristiti.

Ako je sučelje normalna mrežna kartica gosta, promet ne prolazi kroz tunel unutar gosta.

Drugi adapter, postavka proxyja ili VPN klijent na strani gosta mogu promijeniti odgovor za jednu aplikaciju, a ne za drugu. Testirajte aplikaciju do koje vam je stvarno stalo, a ne generički zahtjev iz ljuske.

Provjerite resolver odvojeno

Promijenjena izlazna adresa ne govori koji je resolver obradio ime hosta. Zatražite ime izričito alatom koji odgovara platformi i zabilježite koji je poslužitelj odgovorio. Podijeljeni DNS znači da pitanje resolvera i pitanje rute imaju različite odgovore.

Ta dva se mogu razlikovati u oba smjera, a razlika je često stvarna greška.

Na hostu sa systemd resolvectl query navodi sučelje i DNS poslužitelj iza odgovora. Starije postavke prikazuju poslužitelj u izlazu naredbe dig — u svakom slučaju cilj je vidjeti koji je poslužitelj odgovorio, a ne samo da li je odgovor stigao.

Testirajte politiku kvara, a ne samo uspjeh

Ako je zahtjev da nikakav promet ne izlazi izvan tunela, uspješan zahtjev ništa ne dokazuje. Upotrijebite podržani kontrolirani test kvara kod klijenta: zaustavite tunel na podržani način i pogledajte da li se novi zahtjev gosta blokira. Ne pretpostavljajte da kill switch klijenta hosta pokriva svaki virtualni raspored prosljeđivanja. Njegov dokumentirani obuhvat jedino je na što se možete osloniti.

Gost koji se vrati na fizičku mrežnu karticu kada tunel padne radi upravo ono što način NAT dopušta.

Zabilježite način i obuhvat

Zapišite način hipervizora, sučelje i rutu gosta, resolver i aplikaciju koju ste testirali. Dodajte datum, jer vraćanje snimke ili ažuriranje hipervizora može promijeniti sva četiri.

Ako je IPv4 slijedio tunel, recite to. Ne proširujte tvrdnju na IPv6, drugi imenski prostor ili drugu VM na drugoj mreži.