Kto by mal vlastniť trasy a DNS, keď sa openfortivpn pripája?

Vo fungujúcom sedení openfortivpn sa na seba vrstvia štyri fázy. Klient sa autentizuje na bráne a začne TLS spojenie, potom v tomto spojení spustí PPP, potom prijme adresu a informácie DNS a nakoniec použije trasy hostiteľa a nastavenia resolvera. Každá fáza môže byť živá, kým nasledujúca nie je, a preto je „pripojené“ také klzké slovo vo vláknach podpory.

Rozhodnutie, ktoré odstráni väčšinu zmätku, je, kto vlastní poslednú fázu. Buď VPN klient sám aplikuje zmeny hostiteľa, alebo to urobí iná komponenta, a miešanie oboch na pol cesty je spôsob, akým trasy a súbory resolvera napokon opisujú rôzne sedenia.

Štyri fázy, ktoré vyzerajú ako jedno spojenie

Prvá fáza je prijatie. pomenovaná autentizačná doména alebo jednorazový kód, a získa parametre potrebné na pokračovanie. Keď klient vypíše, že je pripojený k bráne, znamená to, že TLS transport beží. Neznamená to, že PPP vyjednalo, a určite to neznamená, že interná aplikácia je dostupná.

Druhá fáza je PPP spojenie. Klient spustí proces PPP proti tunelovému zariadeniu a obe strany vyjednajú možnosti spojenia a adresy. Až potom hostiteľ vie, aké miestne a vzdialené adresy sedenie používa, a až vtedy môže mať trasa smerujúca do tunela zmysel.

Tretia fáza je aplikovanie týchto informácií na hostiteľa, a práve tu záleží na vlastníctve. Klient môže pridať trasy a prepísať konfiguráciu resolvera, alebo mu možno prikázať, aby ustúpil a oboje nechal tomu, čo inak spravuje sieť na tom stroji. README projektu to opisuje ako oddelené zodpovednosti, nie ako jedno automatické správanie.

Kto upravuje smerovaciu tabuľku

Predvolene je vlastníkom klient. Pridá trasu k bráne cez fyzické rozhranie, trasu pre partnera tunela a trasy pre siete, ktoré sedenie smie používať, a potom ich pri ukončení procesu odoberie. Tento predvolený stav je pohodlný na notebooku s jediným správcom siete a bez ďalšieho VPN softvéru.

Prevezmite odovzdanie len vtedy, keď smerovanie skutočne vlastní niečo iné. Integrácia správcu siete, sieťový menný priestor kontajnera alebo agent smerovania pre celý web už môžu vedieť, ako nainštalovať a vyčistiť tie isté prefixy. Odovzdanie voľby no-routes potom zabráni dvom zapisovateľom hádať sa o tú istú tabuľku, čo je pretek, ktorý sa prejaví ako občasná strata jednej podsiete, nie ako čisté zlyhanie.

Prekrytie je druhý dôvod na odovzdanie. Ak protlačené trasy obsahujú prefix, ktorý miestna sieť už používa, klient konflikt za vás nevyrieši. Niekto musí rozhodnúť, či je tento prefix dostupný cez tunel, cez fyzické spojenie alebo cez konkrétnejšiu trasu, a to rozhodnutie patrí tomu, kto vlastní topológiu.

Čistenie je tretie. Klient, ktorý spadne pred odstránením svojich trás, zanechá čiernu dieru, ktorá prežije sedenie, a ďalšie spojenie na ňu môže pridať duplikát. Kto vlastní smerovanie, vlastní aj overenie, že staré záznamy zmizli. Urobte z tejto kontroly súčasť štartovacej cesty, nie voliteľný krok čistenia.

Kto vlastní DNS a súbor resolvera

DNS je to isté rozhodnutie s ostrejšími hranami. Klient môže prijať DNS servery, ktoré hlási brána alebo partner PPP, a zapísať ich do konfigurácie resolvera hostiteľa. Na jednoduchom stroji je to presne to, čo chcete, pretože interné mená sa potom prekladajú len dovtedy, kým je tunel aktívny.

Na modernom Linux hostiteľovi môže resolver spravovať miestny stub, a prepisovanie súboru resolvera za chrbtom tohto stubu vytvára konfiguráciu, ktorá vyzerá správne a správa sa nekonzistentne. Ak hostiteľ už prevádzkuje správcu resolvera, nechajte ho vlastniť DNS a napájajte ho servermi tunela cez jeho podporované rozhranie. Voľba no-dns klienta je tam správna voľba, nie obchádzka.

Rozdelený DNS je samostatná otázka od toho, kto píše súbor. Posielať každý dotaz cez tunel je jednoduché a pomalé; posielať cez neho iba interné zóny vyžaduje konfiguráciu pre každú doménu, ktorú väčšina jednoduchých klientov neponúka. Rozhodnite, aké správanie hostiteľ potrebuje, skôr než povolíte zmeny resolvera v klientovi. Nesprávna voľba tu vyzerá ako výpadok prekladu mien, aj keď je tunel sám v poriadku.

Oprávnenia, pripravenosť a odovzdanie

Vytvorenie tunelového zariadenia a úprava trás hostiteľa alebo stavu resolvera vyžadujú zvýšené sieťové oprávnenia. Častou chybou je usúdiť, že preto musí všetko bežať ako root, vrátane prehliadača alebo aplikácie, ktorá tunel používa. Držte privilegovanú časť malú: klient a jeho konfiguračný súbor, ktoré vlastní administrátor, zatiaľ čo používateľské aplikácie si zachovávajú bežný účet.

Pripravenosť by sa mala definovať pre každého spotrebiteľa. Supervisor môže považovať službu za spustenú, keď beží proces klienta a existuje tunelové zariadenie. Zálohovacia úloha by mala považovať VPN za použiteľnú len vtedy, keď jej úložný koncový bod odpovedá cez tunel. To sú rôzne kontroly a použitie slabšej na silnejší účel vytvára úlohy, ktoré začínajú príliš skoro a občas zlyhávajú. Zapíšte zvolenú definíciu, pretože supervisor a úloha, ktoré sa nezhodujú na pripravenosti, sú tiket podpory čakajúci na vznik.

Otestujte zmluvu štyrmi pozorovaniami: fáza brány sa dokončí, PPP pridelí adresy, zamýšľaná trasa je prítomná a požiadavka na interného hostiteľa uspeje. Potom klienta zastavte a potvrďte, že každé z toho je odstránené alebo obnovené. Ak hostiteľ po zavretí tunela stále prekladá interné mená alebo stále drží trasu, odovzdanie vlastníctva nie je úplné.