Používá váš VM VPN hostitele? Otestujte to zevnitř hosta

Zkontrolujete veřejnou IP adresu hostitele, ukáže se VPN a vy usoudíte, že VM je pokrytá. Tento závěr test nepodporuje. Host má vlastní směrovací tabulku, vlastní resolver a vlastní rozhraní, a výstupní adresa hostitele o nich nic neříká.

Test musí proběhnout uvnitř hosta a musí pojmenovat, co měřil.

Začněte uvnitř hosta, ne v prohlížeči hostitele

Nejprve zaznamenejte síťový režim hypervizoru: NAT, bridged, host-only nebo macvtap. V režimu NAT hostitel směruje provoz hosta, takže tunel hostitele může a nemusí platit podle toho, jak klient instaluje trasy. V režimu bridged je host rovnocenným účastníkem fyzické LAN a tunel hostitele nemá význam. Tyto dva režimy dávají opačné odpovědi při stejné konfiguraci hostitele.

Zapište režim dřív, než cokoli změníte, protože určuje, co výsledek může znamenat.

Odešlete jeden požadavek, jehož cíl znáte

Použijte neškodný požadavek na službu, která hlásí zdrojovou adresu, kterou viděla. Potom zkontrolujte vlastní rozhodnutí hosta o trase pro tento cíl: ip route get 203.0.113.5 vypíše rozhraní a bránu, které host použije.

Pokud je rozhraním běžná síťová karta hosta, provoz nejde přes tunel uvnitř hosta.

Druhý adaptér, nastavení proxy nebo VPN klient na straně hosta mohou změnit odpověď pro jednu aplikaci a ne pro jinou. Testujte aplikaci, na které vám skutečně záleží, ne obecný požadavek z shellu.

Zkontrolujte resolver zvlášť

Změněná výstupní adresa neříká, který resolver zpracoval jméno hostitele. Zeptejte se na jméno výslovně nástrojem, který odpovídá platformě, a poznamenejte, který server odpověděl. Rozdělený DNS znamená, že otázka resolveru a otázka směrování mají různé odpovědi.

Tyto dvě se mohou rozejít oběma směry a rozdíl je často skutečná chyba.

Na hostiteli se systemd resolvectl query pojmenuje rozhraní a server DNS za odpovědí. Starší sestavy ukazují server ve výstupu dig — v každém případě jde o to vidět, který server odpověděl, ne jen zda odpověď dorazila.

Testujte politiku selhání, ne jen úspěch

Pokud je požadavkem, aby žádný provoz nevycházel mimo tunel, úspěšný požadavek nic nedokazuje. Použijte podporovaný řízený test selhání v klientovi: zastavte tunel podporovaným způsobem a podívejte se, zda je nový požadavek hosta zablokován. Nepředpokládejte, že kill switch klienta hostitele pokrývá každé virtuální schéma předávání. Jeho dokumentovaný rozsah je jediné, na co se můžete spolehnout.

Host, který po pádu tunelu přejde zpět na fyzickou síťovou kartu, dělá přesně to, co režim NAT dovoluje.

Zaznamenejte režim a rozsah

Zapište režim hypervizoru, rozhraní a trasu hosta, resolver a aplikaci, kterou jste testovali. Přidejte datum, protože obnovení snímku nebo aktualizace hypervizoru mohou změnit všechny čtyři.

Pokud IPv4 šla přes tunel, řekněte to. Nerozšiřujte tvrzení na IPv6, jiný jmenný prostor nebo jiný VM v jiné síti.