Kdo má vlastnit trasy a DNS, když se openfortivpn připojuje?

Ve fungujícím sezení openfortivpn se na sebe vrství čtyři fáze. Klient se autentizuje na bráně a zahájí TLS spojení, poté v tomto spojení spustí PPP, poté obdrží adresu a informace DNS a nakonec použije trasy hostitele a nastavení resolveru. Každá fáze může být živá, zatímco ta následující ne, a proto je „připojeno“ tak kluzké slovo ve vláknech podpory.

Rozhodnutí, které odstraní většinu zmatku, je, kdo vlastní poslední fázi. Buď VPN klient sám aplikuje změny hostitele, nebo to udělá jiná komponenta, a smíchání obojího napůl je způsob, jakým trasy a soubory resolveru nakonec popisují různá sezení.

Čtyři fáze, které vypadají jako jedno spojení

První fází je přijetí. pojmenovaná doména pro autentizaci nebo jednorázový kód, a obdrží parametry potřebné k pokračování. Když klient vypíše, že je připojen k bráně, znamená to, že TLS transport běží. Neznamená to, že PPP vyjednalo, a rozhodně to neznamená, že je dosažitelná interní aplikace.

Druhou fází je PPP spojení. Klient spustí proces PPP proti tunelovému zařízení a obě strany vyjednají možnosti spojení a adresy. Teprve potom hostitel ví, jaké místní a vzdálené adresy sezení používá, a teprve tehdy může mít trasa směřující do tunelu smysl.

Třetí fází je aplikace těchto informací na hostitele, a právě zde záleží na vlastnictví. Klient může přidat trasy a přepsat konfiguraci resolveru, nebo mu lze nařídit, aby ustoupil a obojí ponechal tomu, co jinak spravuje síť na onom stroji. README projektu to popisuje jako oddělené odpovědnosti, nikoli jako jedno automatické chování.

Kdo upravuje směrovací tabulku

Ve výchozím stavu je vlastníkem klient. Přidá trasu k bráně přes fyzické rozhraní, trasu pro protějšek tunelu a trasy pro sítě, které smí sezení používat, a poté je při ukončení procesu odebere. Tento výchozí stav je pohodlný na notebooku s jediným správcem sítě a bez dalšího VPN softwaru.

Převzetí zvolte jen tehdy, když směrování skutečně vlastní něco jiného. Integrace správce sítě, síťový jmenný prostor kontejneru nebo agent směrování pro celý web už mohou vědět, jak instalovat a uklízet stejné prefixy. Předání volby no-routes pak zabrání dvěma zapisovatelům hádat se o stejnou tabulku, což je závod, který se projeví jako občasná ztráta jedné podsítě, nikoli jako čisté selhání.

Překrytí je druhý důvod k převzetí. Pokud protlačené trasy obsahují prefix, který místní síť už používá, klient konflikt za vás nevyřeší. Někdo musí rozhodnout, zda je tento prefix dosažitelný tunelem, fyzickým spojem, nebo konkrétnější trasou, a toto rozhodnutí patří tomu, kdo vlastní topologii.

Uklízení je třetí. Klient, který spadne před odstraněním svých tras, zanechá černou díru, která přežije sezení, a další spojení na ni může přidat duplikát. Kdo vlastní směrování, vlastní i ověření, že staré záznamy zmizely. Udělejte z této kontroly součást startovní cesty, ne volitelný krok uklízení.

Kdo vlastní DNS a soubor resolveru

DNS je stejné rozhodnutí s ostřejšími hranami. Klient může přijmout DNS servery, které hlásí brána nebo protějšek PPP, a zapsat je do konfigurace resolveru hostitele. Na jednoduchém stroji je to přesně to, co chcete, protože interní jména se pak překládají jen dokud je tunel aktivní.

Na moderním Linux hostiteli může resolver spravovat místní stub, a přepisování souboru resolveru za zády tohoto stubu vytváří konfiguraci, která vypadá správně a chová se nekonzistentně. Pokud hostitel už provozuje správce resolveru, nechte ho vlastnit DNS a napájejte ho servery tunelu přes jeho podporované rozhraní. Klientská volba no-dns je tam správná volba, ne obejití.

Rozdělený DNS je samostatná otázka od toho, kdo soubor píše. Posílat každý dotaz tunelem je jednoduché a pomalé; posílat jím jen interní zóny vyžaduje konfiguraci po doménách, kterou většina jednoduchých klientů nenabízí. Rozhodněte, jaké chování hostitel potřebuje, než povolíte změny resolveru v klientu. Špatná volba zde vypadá jako výpadek překladu jmen, i když je tunel sám v pořádku.

Oprávnění, připravenost a převzetí

Vytvoření tunelového zařízení a úprava tras hostitele nebo stavu resolveru vyžadují zvýšená síťová oprávnění. Častou chybou je usoudit, že proto musí vše běžet jako root, včetně prohlížeče nebo aplikace, která tunel používá. Držte privilegovanou část malou: klient a jeho konfigurační soubor, vlastněné správcem, zatímco uživatelské aplikace si zachovávají běžný účet.

Připravenost by měla být definována pro každého spotřebitele. Supervisor může považovat službu za spuštěnou, když běží klientský proces a existuje tunelové zařízení. Zálohovací úloha by měla považovat VPN za použitelnou jen tehdy, když její úložný koncový bod odpovídá tunelem. To jsou různé kontroly a použití slabší pro silnější účel vytváří úlohy, které startují příliš brzy a občas selhávají. Zapište zvolenou definici, protože supervisor a úloha, které se neshodnou na připravenosti, jsou tiket podpory čekající na vznik.

Otestujte smlouvu čtyřmi pozorováními: fáze brány se dokončí, PPP přidělí adresy, zamýšlená trasa je přítomná a požadavek na interního hostitele uspěje. Poté klienta zastavte a potvrďte, že každé z toho je odstraněno nebo obnoveno. Pokud hostitel po zavření tunelu stále překládá interní jména nebo stále drží trasu, převzetí vlastnictví není úplné.