VPN v hosťovi a VPN na hostiteľovi: ktorá trasa naozaj vyhrá

Dvaja klienti bežia súčasne, každý presvedčený, že vlastní predvolenú trasu, a príznak prichádza ako niečo zvláštne: jedna aplikácia hosťa funguje, iná sa prekladá na nesprávne miesto. VPN vnútri hosťa a VPN na hostiteľovi môžu existovať vedľa seba, ale len vtedy, keď sa vonkajšia cesta a vnútorná politika zhodnú na tom, kto čo nesie. Spustenie oboch samo o sebe reťaz nevytvorí. Najprv zapíšte pripojenie, potom meňte jednu vec po druhej.

Najprv zapíšte pripojenie hosťa

Hosť sa dostane k svojmu VPN serveru cestou, ktorú mu dal hypervizor: NAT za hostiteľom, most na fyzickú segment alebo sieť len pre hostiteľa s pridaným smerovaním navrchu. Každé pripojenie mení, čo hosť vidí a čo hostiteľ môže urobiť s jeho prevádzkou. Pod NAT sa pakety hosťa javia, akoby prichádzali z hostiteľa, takže vlastný tunel hostiteľa ich môže niesť bez toho, aby o tom hosť čokoľvek vedel. Pod mostom má hosť vlastnú prítomnosť v segmente a vlastnú predvolenú bránu.

Zapíšte pripojenie skôr, než sa dotknete akejkoľvek konfigurácie, spolu s tým, ktorý klient má niesť ktorú aplikáciu. Tá veta vyrieši väčšinu takýchto prípadov, pretože obaja klienti bývajú postavení na odlišných predpokladoch. Hosť, od ktorého sa očakáva použitie tunela hostiteľa, nesmie mať aj vlastnú konkurenčnú predvolenú trasu.

Sledujte koncový bod hosťa smerom von

VPN hosťa potrebuje použiteľnú cestu k vlastnému serveru skôr, než môže fungovať čokoľvek iné. Keď je tunel hostiteľa hore a hosť sedí za NAT, handshake hosťa vychádza tunelom hostiteľa, čo je buď zámer, alebo nehoda, ktorú nikto nezaznamenal. Keď tunel hostiteľa padne a hosť na ňom závisel, hosť stratí konektivitu bez jedinej zmeny na svojej strane. Sledovanie koncového bodu smerom von vám povie, ktorý z tých dvoch prípadov skutočne máte.

Široká trasa v ktoromkoľvek kontexte zachytí prevádzku, ktorú očakával druhý klient. Trasa 0.0.0.0/0 vnútri hosťa a klientský hostiteľ s plným tunelom si obaja nárokujú všetko a vyhrá ten, ktorý sa použije posledný. Prekryvy medzi virtuálnymi sieťami hosťa, miestnou LAN a vzdialenými sieťami majú rovnaký účinok pre privátne prefixy, s poruchami, ktoré pripomínajú problémy s autentifikáciou; správanie prekladu adries je rovnaké ako to opísané pre sieťovanie kontajnerov.

Porovnajte záznam pred a po

Urobte základný stav s vypnutým tunelom hostiteľa alebo v akomkoľvek riadenom stave, ktorý vaša politika dovoľuje, a zapíšte trasu a resolver hosťa. Potom použite kombinovanú konfiguráciu a porovnajte oba záznamy, pričom zachovajte požiadavky na súkromie. Ak priamy základný stav nie je vhodný, zapíšte toto obmedzenie do záznamu namiesto toho, aby ste porovnanie vynechali.

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

Dopyt na trasu pomenuje rozhranie a zdrojovú adresu, ktoré by niesli konkrétny cieľ, a je to najužitočnejší riadok v tomto vyšetrovaní. Výpis pravidiel ukazuje, či politické smerovanie posiela niektoré ciele cez druhú tabuľku. Výstup resolvera ukazuje, či DNS nasledoval tunel hosťa alebo zostal na ceste hostiteľa. Spustite tie isté tri príkazy pred zmenou a po nej a rozdiel pomenuje vinníka.

Udržte vlastníctvo jasné aj cez reštarty

Obmedzenie miestneho prístupu klienta hostiteľa môže blokovať prevádzku do virtuálneho NAT alebo mosta a toto obmedzenie sa pravidelne zamieňa za problém s prihlasovacími údajmi hosťa. Čítajte dokumentované správanie klienta, namiesto toho, aby ste obmedzenie vypnuli, aby test prešiel. Po podporovanej oprave znova otestujte aplikáciu hosťa a politiku zlyhania, ktorú požadujete. Hostiteľ, ktorý sa úspešne pripojí znova, nič nedokazuje o trase ani resolveri hosťa.

Rozhodnite, ktorá strana vlastní predvolenú trasu, a zapíšte to do runbooku. Reštart hosťa alebo prepnutie siete na hostiteľovi, ktoré potichu obráti vlastníctvo, vytvorí hlásenie o chybe týkajúce sa VPN, ktorá nikdy nebola vinná. Usporiadanie by malo prežiť reštart bez toho, aby si niekto pamätal, prečo fungovalo.