Vem bör äga rutterna och DNS när openfortivpn ansluter?

Fyra steg staplas på varandra i en fungerande openfortivpn-session. Klienten autentiserar sig mot gatewayen och startar en TLS-anslutning, kör sedan PPP inuti den anslutningen, tar sedan emot en adress och DNS-information och tillämpar slutligen värdrutter och resolverinställningar. Varje steg kan vara levande medan nästa inte är det, och därför är ”ansluten” ett så halt ord i supporttrådar.

Beslutet som tar bort det mesta av förvirringen är vem som äger det sista steget. Antingen tillämpar VPN-klienten värdändringarna själv, eller så gör en annan komponent det, och att blanda de två halvvägs är hur rutter och resolverfiler till slut beskriver olika sessioner.

Fyra steg som ser ut som en enda anslutning

Det första steget är tillträde. en namngiven autentiseringsdomän eller en engångskod, och tar emot de parametrar den behöver för att fortsätta. När klienten skriver ut att den är ansluten till gatewayen betyder det att TLS-transporten är uppe. Det betyder inte att PPP har förhandlat, och det betyder absolut inte att en intern applikation går att nå.

Det andra steget är PPP-länken. Klienten startar en PPP-process mot tunneenheten, och de två sidorna förhandlar länkval och adresser. Först efter det vet värden vilka lokala och avlägsna adresser sessionen använder, och först då kan en rutt in i tunneln vara meningsfull.

Det tredje steget är att tillämpa informationen på värden, och det är här ägandet spelar roll. Klienten kan lägga till rutterna och skriva om resolverkonfigurationen, eller så kan den få order att backa och lämna båda till det som annars hanterar nätverket på den maskinen. Projektets README beskriver dessa som separata ansvar i stället för ett enda automatiskt beteende.

Vem redigerar routingtabellen

Som standard är klienten ägaren. Den lägger till en rutt mot gatewayen via det fysiska gränssnittet, en rutt för tunnelns peer och rutter för de nätverk som sessionen får använda, och tar sedan bort dem när processen avslutas. Den standarden är bekväm på en bärbar dator med en enda nätverkshanterare och ingen annan VPN-programvara.

Välj överlämningen bara när något annat verkligen äger routingen. En nätverkshanterarintegration, ett containernätverksnamnrymd eller en routingagent för hela webbplatsen vet kanske redan hur samma prefix installeras och städas. Att skicka no-routes-alternativet hindrar då två skribenter från att slåss om samma tabell, vilket är ett lopp som visar sig som periodisk förlust av ett subnät i stället för som ett rent fel.

Överlappning är den andra anledningen att lämna över. Om de pushade rutterna innehåller ett prefix som det lokala nätverket redan använder kan klienten inte lösa konflikten åt dig. Någon måste avgöra om prefixet går att nå via tunneln, via den fysiska länken eller via en mer specifik rutt, och det beslutet tillhör den som äger topologin.

Städning är det tredje. En klient som kraschar innan den tar bort sina rutter lämnar ett svart hål som överlever sessionen, och nästa anslutning kan lägga en dubblett ovanpå det. Den som äger routingen äger också att kontrollera att de gamla posterna är borta. Gör den kontrollen till en del av startvägen, inte ett valfritt städsteg.

Vem äger DNS och resolverfilen

DNS är samma beslut med skarpare kanter. Klienten kan acceptera de DNS-servrar som gatewayen eller PPP-peeren rapporterar och skriva dem i värdens resolverkonfiguration. På en enkel maskin är det precis vad du vill ha, eftersom interna namn då bara löses så länge tunneln är uppe.

På en modern Linux-värd kan resolvern hanteras av en lokal stub, och att skriva om resolverfilen bakom den stubben ger en konfiguration som ser korrekt ut och beter sig inkonsekvent. Om värden redan kör en resolverhanterare, låt den äga DNS och mata den med tunnelns servrar via dess gränssnitt som stöds. Klientens no-dns-alternativ är rätt val där, inte en kringgång.

Delad DNS är en separat fråga från vem som skriver filen. Att skicka varje fråga genom tunneln är enkelt och långsamt; att skicka bara interna zoner genom den kräver konfiguration per domän som de flesta enkla klienter inte erbjuder. Bestäm vilket beteende värden behöver innan du aktiverar klientens resolverändringar. Ett fel val här ser ut som ett namnupplösningsavbrott även när själva tunneln är okej.

Behörighet, beredskap och överlämningen

Att skapa tunneenheten och redigera värdrutter eller resolvertillstånd kräver förhöjd nätverksbehörighet. Det vanliga misstaget är att dra slutsatsen att därför måste allt köras som root, inklusive webbläsaren eller applikationen som använder tunneln. Håll den privilegierade delen liten: klienten och dess konfigurationsfil, ägda av en administratör, medan användarapplikationer behåller sitt normala konto.

Beredskap bör definieras per konsument. En övervakare kan betrakta tjänsten som startad när klientprocessen körs och tunneenheten finns. Ett säkerhetskopieringsjobb bör bara betrakta VPN:en som användbar när dess lagringsendpunkt svarar genom tunneln. Det är olika kontroller, och att använda den svagare för det starkare syftet ger jobb som startar för tidigt och fallerar periodiskt. Skriv ned den valda definitionen, eftersom en övervakare och ett jobb som inte är överens om beredskap är en supportbiljett som väntar på att inträffa.

Testa kontraktet med fyra observationer: gatewayfasen slutförs, PPP tilldelar adresser, den avsedda rutten finns och en begäran till en intern värd lyckas. Stoppa sedan klienten och bekräfta att var och en av dessa har tagits bort eller återställts. Om värden fortfarande löser interna namn eller fortfarande håller en rutt efter att tunneln stängts är ägarskapsöverlämningen ofullständig.