Wie moet de routes en DNS bezitten wanneer openfortivpn verbinding maakt?

Vier fasen stapelen op elkaar in een werkende openfortivpn-sessie. De client authenticeert bij de gateway en start een TLS-verbinding, voert daarin PPP uit, ontvangt vervolgens een adres en DNS-informatie en past ten slotte hostroutes en resolverinstellingen toe. Elke fase kan leven terwijl de volgende dat niet doet, en daarom is “verbonden” zo'n glibberig woord in supportthreads.

De beslissing die de meeste verwarring wegneemt, is wie de laatste fase bezit. Ofwel de VPN-client past de hostwijzigingen zelf toe, ofwel een ander onderdeel doet dat, en beide halverwege mengen is hoe routes en resolverbestanden uiteindelijk verschillende sessies beschrijven.

Vier fasen die op één verbinding lijken

De eerste fase is toelating. een benoemd authenticatiedomein of een eenmalige code, ontvangt de parameters die nodig zijn om door te gaan. Wanneer de client afdrukt dat hij met de gateway is verbonden, betekent dat dat het TLS-transport actief is. Het betekent niet dat PPP heeft onderhandeld, en zeker niet dat een interne toepassing bereikbaar is.

De tweede fase is de PPP-verbinding. De client start een PPP-proces tegen het tunnelapparaat, en beide zijden onderhandelen over linkopties en adressen. Pas daarna weet de host welke lokale en externe adressen de sessie gebruikt, en pas dan kan een route de tunnel in zinvol zijn.

De derde fase is die informatie op de host toepassen, en daar telt eigendom. De client kan de routes toevoegen en de resolverconfiguratie herschrijven, of hem kan worden gezegd terug te treden en beide over te laten aan wat anders het netwerk op die machine beheert. Het README van het project beschrijft deze als afzonderlijke verantwoordelijkheden in plaats van één automatisch gedrag.

Wie de routingtabel bewerkt

Standaard is de client de eigenaar. Hij voegt een route naar de gateway via de fysieke interface toe, een route voor de peer van de tunnel en routes voor de netwerken die de sessie mag gebruiken, en verwijdert ze weer wanneer het proces stopt. Die standaard is handig op een laptop met één netwerkbeheerder en zonder andere VPN-software.

Kies de overdracht alleen wanneer iets anders echt het routeren bezit. Een netwerkbeheerderintegratie, een containernetwerknaamruimte of een sitebrede routingagent weten misschien al hoe dezelfde prefixes moeten worden geïnstalleerd en opgeruimd. De optie no-routes doorgeven voorkomt dan dat twee schrijvers om dezelfde tabel vechten, wat een race is die zich uit als periodiek verlies van één subnet in plaats van een schone fout.

Overlap is de tweede reden om over te dragen. Als de gepushte routes een prefix bevatten die het lokale netwerk al gebruikt, kan de client het conflict niet voor u oplossen. Iemand moet beslissen of die prefix bereikbaar is via de tunnel, via de fysieke link of via een specifiekere route, en die beslissing hoort bij wie de topologie bezit.

Opruimen is de derde. Een client die crasht voordat hij zijn routes verwijdert, laat een zwart gat achter dat de sessie overleeft, en de volgende verbinding kan er een duplicaat bovenop zetten. Wie het routeren bezit, bezit ook de controle dat de oude vermeldingen weg zijn. Maak die controle deel van het opstartpad, geen optionele opruimstap.

Wie DNS en het resolverbestand bezit

DNS is dezelfde beslissing met scherpere randen. De client kan de DNS-servers accepteren die de gateway of de PPP-peer meldt en ze in de resolverconfiguratie van de host schrijven. Op een eenvoudige machine is dat precies wat u wilt, omdat interne namen dan alleen worden opgelost zolang de tunnel actief is.

Op een moderne Linux-host kan de resolver door een lokale stub worden beheerd, en het resolverbestand achter de rug van die stub herschrijven levert een configuratie op die correct lijkt en zich inconsistent gedraagt. Als de host al een resolverbeheerder draait, laat die dan DNS bezitten en voed hem de servers van de tunnel via zijn ondersteunde interface. De no-dns-optie van de client is daar de juiste keuze, geen omweg.

Gesplitste DNS is een aparte vraag van wie het bestand schrijft. Elke query door de tunnel sturen is eenvoudig en traag; alleen interne zones erdoor sturen vereist configuratie per domein die de meeste eenvoudige clients niet bieden. Bepaal welk gedrag de host nodig heeft voordat u de resolverwijzigingen van de client inschakelt. Een verkeerde keuze hier ziet eruit als een naamresolutiestoring, zelfs wanneer de tunnel zelf in orde is.

Voorrechten, gereedheid en de overdracht

Het tunnelapparaat aanmaken en hostroutes of resolverstatus bewerken vereist verhoogde netwerkautoriteit. De gebruikelijke fout is te concluderen dat daarom alles als root moet draaien, inclusief de browser of de toepassing die de tunnel gebruikt. Houd het bevoorrechte deel klein: de client en zijn configuratiebestand, eigendom van een beheerder, terwijl gebruikerstoepassingen hun normale account behouden.

Gereedheid moet per consument worden gedefinieerd. Een supervisor kan de dienst als gestart beschouwen wanneer het clientproces draait en het tunnelapparaat bestaat. Een back-uptaak zou de VPN pas bruikbaar moeten achten wanneer zijn opslageindpunt via de tunnel antwoordt. Dat zijn verschillende controles, en de zwakkere voor het sterkere doel gebruiken levert taken op die te vroeg starten en periodiek falen. Schrijf de gekozen definitie op, want een supervisor en een taak die het niet eens zijn over gereedheid zijn een supportticket dat staat te gebeuren.

Test het contract met vier observaties: de gatewayfase is voltooid, PPP wijst adressen toe, de beoogde route is aanwezig en een verzoek aan een interne host slaagt. Stop daarna de client en bevestig dat elk daarvan is verwijderd of hersteld. Als de host na het sluiten van de tunnel nog steeds interne namen oplost of nog steeds een route vasthoudt, is de eigendomsoverdracht onvolledig.