Čo vlastne route-nopull v OpenVPN zabráni serveru posielať

Dali ste route-nopull do klientskeho profilu, aby tunel nezhltol vašu predvolenú trasu, a teraz je kancelárska podsiete nedostupná, zatiaľ čo klient stále tvrdí, že je pripojený. Obe pozorovania sú pravdivé a nič zlyhalo. Prepínač hovorí klientovi, aby preskočil trasy a položky DHCP, ktoré server posiela, čo je užšia inštrukcia, než väčšina ľudí pri pridaní očakáva. Čo zostáva, je funkčný tunel bez názoru na to, ktoré ciele ho majú používať.

Táto medzera je celé rozhodnutie, o ktorom tento článok je. Buď sieť popisuje server, alebo klient, a prepínač odovzdáva túto prácu klientovi bez toho, aby za vás niečo z nej urobil.

Čo prepínač pri pripojení vypne

Klient OpenVPN, ktorý ťahá, zvyčajne po autentifikácii prevezme od servera balík: trasy, presmerovanie predvolenej brány, servery DNS a niekoľko ladiacich direktív. Keď je route-nopull v platnosti, klient stále prijíma reláciu, stále overuje certifikáty, stále vyjednáva šifry a keepalive a stále dvíha rozhranie. Čo zahadzuje, je aplikácia posielaných riadkov route a posielaných riadkov dhcp-option, vrátane DNS.

Zmatek pochádza zo zeleného indikátora vedľa mŕtvej aplikácie. Tunel existuje; mapovanie cieľov na tento tunel nie. Nič na stavovom paneli klienta nerozlišuje „pripojené a smeruje“ od „pripojené a nečinné“, pretože z pohľadu tunela sú to oba rovnaké stavy.

Prečo živý tunel napriek tomu nemusí smerovať nič

Rozhranie sa objaví s vlastnou adresou a na spojení bod-bod často nemá nič konkrétnejšie ako trasu hostiteľa k partnerovi. Súkromná podsiete sa stane dostupnou len vtedy, keď nejaká trasa ukazuje na toto rozhranie so správnym prefixom, a pri vypnutom posielaní tá trasa nikdy nepríde. Stiahnutý profil zvyčajne tiež nepomôže, pretože bol napísaný s predpokladom, že server dodá presne tieto informácie. Preto môže rozhranie vyzerať zdravo, zatiaľ čo podsiete zostáva tmavá.

Čítanie profilu teda dokazuje veľmi málo. Čítajte bežiaci stav, na pripojenom stroji:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Adresa bez trasy podsiete v druhom príkaze je podpisom tohto problému. Tretí príkaz potom odpovedá na otázku, ktorá používateľov naozaj zaujíma, pretože hlási rozhranie, ktoré by jadro zvolilo pre konkrétny cieľ, namiesto zoznamu, o ktorom ste dúfali, že ho použije. Ak odpovedá cez vaše fyzické spojenie, tunel vôbec nie je na ceste.

Preklad mien zlyháva zo súvisiaceho dôvodu, nie z oddeleného. Posielané položky dhcp-option DNS sa preskakujú tým istým prepínačom, takže dopyty na interných hostiteľov idú k tomu resolveru, ktorý poskytla miestna sieť. Ten resolver nemá zónu pre kanceláriu, takže dopyt zlyhá alebo vráti verejnú odpoveď, a zlyhanie vyzerá ako problém servera, keď je to problém konfigurácie klienta. Testovanie adresy pred menom je to, čo oboje oddeľuje.

Voľba medzi prepínačom a filtrom prefixov

Obe možnosti riešia rôzne podoby tej istej sťažnosti a práve zlá voľba vytvára stav pripojené-ale-nepoužiteľné. Jedna nahrádza posielanú politiku ako celok, druhá ju upravuje podľa prefixu. Tabuľka uvádza krátku verziu a odsek za ňou pokrýva časť, ktorá ľudí prekvapí.

pull-filter je porovnávač prefixov s tromi slovesami, takže môže prijať rodinu riadkov, ticho ich ignorovať alebo úplne odmietnuť pripojenie, keď sa prefix objaví. Práve to posledné správanie je hodné poznania: pravidlo odmietnutia mení nezhodu v politike na neúspešný handshake namiesto tichého vynechania. Manuál OpenVPN 2.6 uvádza prijímané prefixy a presnú sémantiku každého slovesa.

Častou strednou cestou je odmietnuť iba redirect-gateway a nechať kancelárske trasy a DNS prísť podľa zámeru. To udržiava posielanie funkčné pre časti, ktorým server rozumie lepšie ako vy, a zároveň bráni tomu jedinému riadku, ktorý by prevzal vašu predvolenú trasu.

Ručné pridanie trás a resolvera

Ak prepínač ponecháte, profil musí povedať to, čo by povedal server. Klientske direktívy route sa aplikujú po nadviazaní spojenia, takže fungujú vedľa prepínača namiesto toho, aby ich blokoval. Dajte ich do profilu, nie do interaktívneho príkazového riadka, inak ďalšie opätovné pripojenie funkčný stav nezopakuje.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

Riadok DNS stojí v nepríjemnej pozícii: je to klientska direktíva, ale niektorí klienti ju aplikujú iba cez integráciu DNS platformy, ktorá ju môže prepísať, keď sa spojenie zmení. Na hostiteľovi so systemd je nastavenie resolvera priamo na rozhraní tunela predvídateľnejšie než dúfať, že klient vyhrá súťaž priorít:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Doména smerovania je rovnako dôležitá ako adresa. Bez nej sa dopyty na verejné mená môžu posielať aj internému resolveru a každý interný resolver, ktorý odmieta rekurziu, pokazí prehliadanie, zatiaľ čo súkromná zóna zostane funkčná. S ňou sa k resolveru tunela smerujú iba mená pod touto príponou a všetko ostatné ide po fyzickom spojení.

Kontrola výsledku: adresa, meno a vonkajšia cesta

Tri testy oddeľujú možné poruchy. Získajte súkromnú adresu podľa IP, potom toho istého hostiteľa podľa mena, potom bežnú verejnú stránku. Fungujúca IP s nefunkčným menom ukazuje na resolver; nefunkčná IP s fungujúcim menom ukazuje na smerovanie; ak zlyhajú obe, zvyčajne tunel nie je na ceste.

Potom sa pozerajte von, nie dovnútra. Vlastná trasa koncového bodu tunela musí zmenu prežiť a každé blokujúce zlyhanie musí byť obmedzené na tunel bez zachytenia koncového bodu. Klient, ktorý po páde tunela ďalej prehliada, je problém politiky, nie smerovania, a neprejaví sa v žiadnom z troch testov vyššie.

Zapíšte konečný zoznam do dokumentácie profilu: trasy, resolver, domény a dôvod, prečo každý existuje. Opätovné pripojenie, ktoré zopakuje tú istú tabuľku, je jediným dôkazom, že miestna politika je úplná. Ak aplikácie stále zlyhávajú so zdvihnutým tunelom a všetkými tromi testami prejdenými, ďalším miestom pohľadu je trieda problémov pripojené-ale-offline, nie už overené certifikáty.