Hvem bør eje ruter og DNS, når openfortivpn forbinder?

Fire trin stablet oven på hinanden i en fungerende openfortivpn-session. Klienten autentificerer sig ved gatewayen og starter en TLS-forbindelse, kører derefter PPP inde i den forbindelse, modtager derefter en adresse og DNS-oplysninger og anvender til sidst værtsruter og resolverindstillinger. Hvert trin kan være levende, mens det næste ikke er, og derfor er “forbundet” et så glat ord i supporttråde.

Den beslutning, der fjerner det meste af forvirringen, er, hvem der ejer det sidste trin. Enten anvender VPN-klienten selv ændringerne på værten, eller også gør en anden komponent det, og at blande de to halvvejs er, hvordan ruter og resolverfiler ender med at beskrive forskellige sessioner.

Fire trin, der ligner én forbindelse

Det første trin er adgang. et navngivet godkendelsesdomæne eller en engangskode og modtager de parametre, den skal bruge for at fortsætte. Når klienten udskriver, at den er forbundet til gatewayen, betyder det, at TLS-transporten er oppe. Det betyder ikke, at PPP har forhandlet, og det betyder bestemt ikke, at en intern applikation kan nås.

Det andet trin er PPP-forbindelsen. Klienten starter en PPP-proces mod tunneleenheden, og de to sider forhandler linkindstillinger og adresser. Først derefter ved værten, hvilke lokale og fjernadresser sessionen bruger, og først da giver en rute ind i tunnelen mening.

Det tredje trin er at anvende oplysningerne på værten, og det er her, ejerskab betyder noget. Klienten kan tilføje ruterne og overskrive resolverkonfigurationen, eller den kan få besked om at træde tilbage og overlade begge til hvad der ellers styrer netværket på den maskine. Projektets README beskriver disse som separate ansvarsområder snarere end én automatisk adfærd.

Hvem redigerer routingtabellen

Som standard er klienten ejeren. Den tilføjer en rute mod gatewayen gennem det fysiske interface, en rute til tunnelens peer og ruter til de netværk, sessionen må bruge, og fjerner dem derefter, når processen afsluttes. Den standard er bekvem på en laptop med én netværksadministrator og ingen anden VPN-software.

Vælg overdragelsen kun, når noget andet reelt ejer routing. En netværksadministratorintegration, et containernavnerum eller en siteomfattende routingagent ved måske allerede, hvordan de samme præfikser installeres og ryddes op. At sende no-routes-indstillingen forhindrer derefter to skribenter i at slås om den samme tabel, hvilket er et kapløb, der viser sig som periodisk tab af et undernet snarere end som en ren fejl.

Overlapning er den anden grund til at overdrage. Hvis de push'ede ruter indeholder et præfiks, som det lokale netværk allerede bruger, kan klienten ikke løse konflikten for dig. Nogen skal beslutte, om præfikset kan nås gennem tunnelen, gennem det fysiske link eller gennem en mere specifik rute, og den beslutning tilhører den, der ejer topologien.

Oprydning er den tredje. En klient, der crasher, før den fjerner sine ruter, efterlader et sort hul, der overlever sessionen, og den næste forbindelse kan tilføje en dublet oven på det. Den, der ejer routing, ejer også at kontrollere, at de gamle poster er væk. Gør den kontrol til en del af opstartsvejen, ikke et valgfrit oprydningstrin.

Hvem ejer DNS og resolverfilen

DNS er den samme beslutning med skarpere kanter. Klienten kan acceptere de DNS-servere, som gatewayen eller PPP-peeren rapporterer, og skrive dem ind i værtens resolverkonfiguration. På en simpel maskine er det præcis, hvad du vil have, fordi interne navne så kun opløses, mens tunnelen er oppe.

På en moderne Linux-vært kan resolveren styres af en lokal stub, og at overskrive resolverfilen bag den stubs ryg giver en konfiguration, der ser korrekt ud og opfører sig inkonsekvent. Hvis værten allerede kører en resolvermanager, så lad den eje DNS og fodre den med tunnelens servere gennem dens understøttede interface. Klientens no-dns-indstilling er det rigtige valg der, ikke en undvigelse.

Opdelt DNS er et separat spørgsmål fra, hvem der skriver filen. At sende hver forespørgsel gennem tunnelen er enkelt og langsomt; at sende kun interne zoner gennem den kræver konfiguration pr. domæne, som de fleste enkle klienter ikke tilbyder. Beslut, hvilken adfærd værten har brug for, før du aktiverer klientens resolverændringer. Et forkert valg her ser ud som et navneopløsningsudfald, selv når tunnelen selv er fin.

Privilegier, parathed og overdragelsen

Oprettelse af tunneleenheden og redigering af værtsruter eller resolvertilstand kræver forhøjet netværksautoritet. Den almindelige fejl er at konkludere, at alt derfor skal køre som root, inklusive browseren eller applikationen, der bruger tunnelen. Hold den privilegerede del lille: klienten og dens konfigurationsfil, ejet af en administrator, mens brugerapplikationer beholder deres normale konto.

Parathed bør defineres pr. forbruger. En supervisor kan betragte tjenesten som startet, når klientprocessen kører, og tunneleenheden findes. Et backupjob bør først betragte VPN'en som brugbar, når dets lagerendepunkt svarer gennem tunnelen. Det er forskellige kontroller, og at bruge den svagere til det stærkere formål giver job, der starter for tidligt og fejler periodisk. Skriv den valgte definition ned, fordi en supervisor og et job, der er uenige om parathed, er en supportbillet, der venter på at ske.

Test kontrakten med fire observationer: gatewayfasen fuldføres, PPP tildeler adresser, den tilsigtede rute findes, og en anmodning til en intern vært lykkes. Stop derefter klienten, og bekræft, at hver af disse er fjernet eller gendannet. Hvis værten stadig opløser interne navne eller stadig holder en rute, efter tunnelen er lukket, er ejerskabsoverdragelsen ufuldstændig.