Používa vaša VM VPN hostiteľa? Otestujte to zvnútra hosťa

Skontrolujete verejnú IP adresu hostiteľa, zobrazí sa na nej VPN, a usúdite, že VM je pokrytá. Tento záver test nepodporuje. Hosť má vlastnú smerovaciu tabuľku, vlastný resolver a vlastné rozhrania, a výstupná adresa hostiteľa o nich nič nehovorí.

Test sa musí vykonať vnútri hosťa a musí uviesť, čo meral.

Začnite vnútri hosťa, nie v prehliadači hostiteľa

Najprv zaznamenajte režim siete hypervizora: NAT, bridged, host-only alebo macvtap. V režime NAT hostiteľ smeruje prevádzku hosťa, takže tunel hostiteľa sa môže alebo nemusí uplatniť podľa toho, ako klient inštaluje trasy. V režime bridged je hosť rovnocenným účastníkom fyzickej LAN a tunel hostiteľa je irelevantný. Tieto dva režimy dávajú opačné odpovede pri rovnakej konfigurácii hostiteľa.

Zapíšte režim skôr, než čokoľvek zmeníte, pretože práve on určuje, čo výsledok môže znamenať.

Odošlite jednu požiadavku, ktorej cieľ poznáte

Použite neškodnú požiadavku na službu, ktorá hlási zdrojovú adresu, ktorú videla. Potom skontrolujte vlastné smerovacie rozhodnutie hosťa pre tento cieľ: ip route get 203.0.113.5 vypíše rozhranie a bránu, ktoré hosť použije.

Ak je rozhraním bežná NIC hosťa, prevádzka neprechádza cez tunel vnútri hosťa.

Druhý adaptér, nastavenie proxy alebo klient VPN na strane hosťa môžu zmeniť odpoveď pre jednu aplikáciu a nie pre inú. Testujte aplikáciu, na ktorej vám naozaj záleží, nie všeobecnú požiadavku z shellu.

Resolver skontrolujte samostatne

Zmenená výstupná adresa vám nepovie, ktorý resolver spracoval dané meno hostiteľa. Opýtajte sa na meno explicitne nástrojom, ktorý zodpovedá platforme, a poznamenajte, ktorý server odpovedal. Split DNS znamená, že otázka na resolver a otázka na smerovanie majú odlišné odpovede.

Tieto dve sa môžu rozchádzať oboma smermi a práve ten rozpor je často skutočná chyba.

Na hostiteľovi so systemd resolvectl query pomenúva rozhranie a DNS server za odpoveďou. Staršie konfigurácie zobrazujú server vo výstupe dig. V každom prípade ide o to vidieť, ktorý server odpovedal, nie len či odpoveď prišla.

Testujte politiku zlyhania, nielen úspech

Ak je požiadavkou, aby žiadna prevádzka nešla mimo tunela, úspešná požiadavka nič nepreukazuje. Použite klientom podporovaný kontrolovaný test zlyhania: zastavte tunel podporovaným spôsobom a pozrite sa, či je nová požiadavka hosťa zablokovaná. Nepredpokladajte, že kill switch klienta hostiteľa pokrýva každé virtuálne usporiadanie preposielania. Jeho zdokumentovaný rozsah je jediná vec, na ktorú sa môžete spoľahnúť.

Hosť, ktorý pri páde tunela prepadne na fyzickú NIC, robí presne to, čo režim NAT dovoľuje.

Zaznamenajte režim a rozsah

Zapíšte režim hypervizora, rozhranie a trasu hosťa, resolver a aplikáciu, ktorú ste testovali. Pridajte dátum, pretože obnovenie snímky alebo aktualizácia hypervizora môžu zmeniť všetky štyri.

Ak IPv4 išlo cez tunel, povedzte to. Nerozširujte tvrdenie na IPv6, iný priestor názvov alebo inú VM v inej sieti.