VPN v hostu a VPN na hostiteli: která trasa vlastně vyhraje

Dva klienti běží současně, každý přesvědčený, že vlastní výchozí trasu, a příznak přichází jako něco podivného: jedna aplikace hosta funguje, jiná se překládá na špatné místo. VPN uvnitř hosta a VPN na hostiteli mohou existovat vedle sebe, ale jen když se vnější cesta a vnitřní politika shodnou na tom, kdo co nese. Spuštění obou samo o sobě řetěz nevytvoří. Nejprve zapište připojení, potom měňte jednu věc po druhé.

Nejprve zapište připojení hosta

Host se dostane ke svému VPN serveru cestou, kterou mu dal hypervizor: NAT za hostitelem, most na fyzický segment nebo síť jen pro hostitele s přidaným směrováním navrch. Každé připojení mění, co host vidí a co hostitel může udělat s jeho provozem. Pod NAT se pakety hosta jeví, jako by přicházely z hostitele, takže je vlastní tunel hostitele může nést, aniž by o tom host cokoli věděl. Pod mostem má host vlastní přítomnost na segmentu a vlastní výchozí bránu.

Zapište připojení dřív, než se dotknete jakékoli konfigurace, spolu s tím, který klient má nést kterou aplikaci. Tahle věta vyřeší většinu těchto případů, protože oba klienti bývají postaveni na různých předpokladech. Host, od kterého se očekává použití tunelu hostitele, nesmí mít také vlastní konkurenční výchozí trasu.

Sledujte koncový bod hosta směrem ven

VPN hosta potřebuje použitelnou cestu k vlastnímu serveru, dřív než může cokoli jiného fungovat. Když je tunel hostitele nahoře a host sedí za NAT, handshake hosta vychází tunelem hostitele, což je buď záměr, nebo nehoda, kterou nikdo nezaznamenal. Když tunel hostitele spadne a host na něm závisel, host ztratí konektivitu bez jediné změny na své straně. Sledování koncového bodu směrem ven vám řekne, který z těch dvou případů skutečně máte.

Široká trasa v kterémkoli kontextu zachytí provoz, který očekával druhý klient. Trasa 0.0.0.0/0 uvnitř hosta a klientský hostitel s plným tunelem si oba nárokují vše a vyhraje ten, který se použije poslední. Překryvy mezi virtuálními sítěmi hosta, místní LAN a vzdálenými sítěmi mají stejný účinek pro privátní prefixy, s poruchami, které připomínají problémy s autentizací; chování překladu adres je stejné jako to popsané pro síťování kontejnerů.

Porovnejte záznam před a po

Pořiďte základní stav s vypnutým tunelem hostitele nebo v jakémkoli řízeném stavu, který vaše politika dovoluje, a zapište trasu a resolver hosta. Pak použijte kombinovanou konfiguraci a oba záznamy porovnejte, přičemž zachovejte požadavky na soukromí. Pokud přímý základní stav není vhodný, zapište toto omezení do záznamu místo toho, abyste srovnání vynechali.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

Dotaz na trasu pojmenuje rozhraní a zdrojovou adresu, které by nesly konkrétní cíl, a je to nejužitečnější řádek v tomto vyšetřování. Výpis pravidel ukazuje, zda politické směrování posílá některé cíle přes druhou tabulku. Výstup resolveru ukazuje, zda DNS následoval tunel hosta, nebo zůstal na cestě hostitele. Spusťte stejné tři příkazy před změnou a po ní a rozdíl pojmenuje viníka.

Udržte vlastnictví jasné i přes restarty

Omezení místního přístupu klienta hostitele může blokovat provoz do virtuálního NAT nebo mostu a toto omezení se pravidelně zaměňuje za problém s přihlašovacími údaji hosta. Čtěte dokumentované chování klienta, místo abyste omezení vypnuli, aby test prošel. Po podporované opravě znovu otestujte aplikaci hosta a politiku selhání, kterou požadujete. Hostitel, který se úspěšně připojí znovu, nic nedokazuje o trase ani resolveru hosta.

Rozhodněte, která strana vlastní výchozí trasu, a zapište to do runbooku. Restart hosta nebo přepnutí sítě na hostiteli, které tiše obrátí vlastnictví, vytvoří hlášení o chybě týkající se VPN, která nikdy nebyla vinna. Uspořádání by mělo přežít restart, aniž by si kdokoli pamatoval, proč fungovalo.