Hvem bør eie rutene og DNS når openfortivpn kobler til?

Fire trinn stables på hverandre i en fungerende openfortivpn-økt. Klienten autentiserer seg mot gatewayen og starter en TLS-tilkobling, kjører deretter PPP inne i den tilkoblingen, mottar deretter en adresse og DNS-informasjon, og bruker til slutt vertsruter og resolver-innstillinger. Hvert trinn kan være levende mens det neste ikke er det, og derfor er «tilkoblet» et så glatt ord i støttetråder.

Beslutningen som fjerner mest forvirring, er hvem som eier det siste trinnet. Enten bruker VPN-klienten vertsendringene selv, eller så gjør en annen komponent det, og å blande de to halvveis er hvordan ruter og resolverfiler ender opp med å beskrive forskjellige økter.

Fire trinn som ser ut som én tilkobling

Det første trinnet er adgang. et navngitt autentiseringsdomene eller en engangskode, og mottar parameterne den trenger for å fortsette. Når klienten skriver ut at den er koblet til gatewayen, betyr det at TLS-transporten er oppe. Det betyr ikke at PPP har forhandlet, og det betyr absolutt ikke at en intern applikasjon er tilgjengelig.

Det andre trinnet er PPP-koblingen. Klienten starter en PPP-prosess mot tunneleenheten, og de to sidene forhandler koblingsvalg og adresser. Først etter det vet verten hvilke lokale og eksterne adresser økten bruker, og først da kan en rute inn i tunnelen gi mening.

Det tredje trinnet er å bruke informasjonen på verten, og det er her eierskap betyr noe. Klienten kan legge til rutene og skrive om resolver-konfigurasjonen, eller den kan få beskjed om å trekke seg tilbake og overlate begge til det som ellers styrer nettverket på den maskinen. Prosjektets README beskriver disse som separate ansvar i stedet for én automatisk atferd.

Hvem redigerer rutingtabellen

Som standard er klienten eieren. Den legger til en rute mot gatewayen gjennom det fysiske grensesnittet, en rute for tunnelens peer og ruter for nettverkene økten har lov til å bruke, og fjerner dem deretter når prosessen avsluttes. Den standarden er praktisk på en bærbar PC med én nettverksbehandler og ingen annen VPN-programvare.

Velg overleveringen bare når noe annet faktisk eier rutingen. En nettverksbehandlerintegrasjon, et containernavnerom eller en rutingagent for hele nettstedet vet kanskje allerede hvordan de samme prefiksene installeres og ryddes. Å sende no-routes-alternativet hindrer da to skribenter i å kjempe om samme tabell, noe som er et kappløp som viser seg som periodisk tap av ett subnett i stedet for som en ren feil.

Overlapping er den andre grunnen til å overlevere. Hvis de pusha rutene inneholder et prefiks som det lokale nettverket allerede bruker, kan ikke klienten løse konflikten for deg. Noen må avgjøre om prefikset er tilgjengelig gjennom tunnelen, gjennom den fysiske koblingen eller gjennom en mer spesifikk rute, og den beslutningen tilhører den som eier topologien.

Opprydding er den tredje. En klient som krasjer før den fjerner rutene sine, etterlater et svart hull som overlever økten, og den neste tilkoblingen kan legge en duplikat oppå det. Den som eier rutingen, eier også å kontrollere at de gamle oppføringene er borte. Gjør den kontrollen til en del av oppstartsveien, ikke et valgfritt oppryddingstrinn.

Hvem eier DNS og resolverfilen

DNS er den samme beslutningen med skarpere kanter. Klienten kan godta DNS-serverne som gatewayen eller PPP-peeren rapporterer, og skrive dem inn i vertens resolver-konfigurasjon. På en enkel maskin er det nøyaktig det du vil ha, fordi interne navn da bare løses så lenge tunnelen er oppe.

På en moderne Linux-vert kan resolveren styres av en lokal stub, og å skrive om resolverfilen bak ryggen på den stubben gir en konfigurasjon som ser riktig ut og oppfører seg inkonsistent. Hvis verten allerede kjører en resolverbehandler, la den eie DNS og fôr den med tunnelens servere gjennom grensesnittet den støtter. Klientens no-dns-alternativ er det riktige valget der, ikke en omvei.

Delt DNS er et separat spørsmål fra hvem som skriver filen. Å sende hver spørring gjennom tunnelen er enkelt og tregt; å sende bare interne soner gjennom den krever konfigurasjon per domene som de fleste enkle klienter ikke tilbyr. Bestem hvilken atferd verten trenger før du aktiverer klientens resolverendringer. Et feil valg her ser ut som et navneoppløsningsutfall selv når tunnelen selv er i orden.

Privilegier, beredskap og overleveringen

Å opprette tunneleenheten og redigere vertsruter eller resolvertilstand krever forhøyet nettverksmyndighet. Den vanlige feilen er å konkludere at derfor må alt kjøre som root, inkludert nettleseren eller applikasjonen som bruker tunnelen. Hold den privilegerte delen liten: klienten og konfigurasjonsfilen dens, eid av en administrator, mens brukerapplikasjoner beholder sin normale konto.

Beredskap bør defineres per forbruker. En veileder kan betrakte tjenesten som startet når klientprosessen kjører og tunneleenheten finnes. En sikkerhetskopijobb bør først betrakte VPN-en som brukbar når lagringsendepunktet svarer gjennom tunnelen. Det er forskjellige kontroller, og å bruke den svakere til det sterkere formålet gir jobber som starter for tidlig og feiler periodisk. Skriv ned definisjonen som er valgt, fordi en veileder og en jobb som er uenige om beredskap, er en støttebillett som venter på å skje.

Test kontrakten med fire observasjoner: gatewayfasen fullføres, PPP tildeler adresser, den tiltenkte ruten finnes, og en forespørsel til en intern vert lykkes. Stopp deretter klienten og bekreft at hver av disse er fjernet eller gjenopprettet. Hvis verten fortsatt løser interne navn eller fortsatt holder en rute etter at tunnelen er lukket, er eierskapsoverleveringen ufullstendig.