Kven bør eige rutene og DNS når openfortivpn koplar til?

Fire trinn stablast på kvarandre i ein fungerande openfortivpn-økt. Klienten autentiserer seg mot gatewayen og startar ei TLS-tilkopling, køyrer deretter PPP inne i den tilkoplinga, mottek deretter ei adresse og DNS-informasjon, og brukar til slutt vertsruter og resolver-innstillingar. Kvart trinn kan vere levande medan det neste ikkje er det, og difor er «tilkopla» eit så glatt ord i støttetrådar.

Avgjerda som fjernar mest forvirring, er kven som eig det siste trinnet. Anten brukar VPN-klienten vertsendringane sjølv, eller så gjer ein annan komponent det, og å blande dei to halvvegs er korleis ruter og resolverfiler endar opp med å skildre ulike økter.

Fire trinn som ser ut som éi tilkopling

Det første trinnet er tilgang. eit namngjeve autentiseringsdomene eller ein eingongskode, og mottek parametrane han treng for å halde fram. Når klienten skriv ut at han er kopla til gatewayen, betyr det at TLS-transporten er oppe. Det betyr ikkje at PPP har forhandla, og det betyr absolutt ikkje at ein intern applikasjon er tilgjengeleg.

Det andre trinnet er PPP-koplinga. Klienten startar ein PPP-prosess mot tunneleininga, og dei to sidene forhandlar om koplingval og adresser. Først etter det veit verten kva lokale og eksterne adresser økta brukar, og først då kan ei rute inn i tunnelen gje meining.

Det tredje trinnet er å bruke informasjonen på verten, og det er her eigarskap betyr noko. Klienten kan leggje til rutene og skrive om resolver-konfigurasjonen, eller han kan få beskjed om å trekkje seg tilbake og overlate begge til det som elles styrer nettverket på den maskina. Prosjektets README skildrar desse som separate ansvar i staden for éin automatisk åtferd.

Kven redigerer rutetabellen

Som standard er klienten eigaren. Han legg til ei rute mot gatewayen gjennom det fysiske grensesnittet, ei rute for peer-en til tunnelen og ruter for nettverka økta har lov til å bruke, og fjernar dei deretter når prosessen avsluttar. Den standarden er praktisk på ein berbar PC med éin nettverkshandsamar og inga anna VPN-programvare.

Vel overleveringa berre når noko anna faktisk eig rutinga. Ein nettverkshandsamarintegrasjon, eit containernamnerom eller ein rutingagent for heile nettstaden veit kanskje allereie korleis dei same prefiksa blir installerte og rydda. Å sende no-routes-valet hindrar då to skribentar i å kjempe om same tabell, noko som er eit kapplaup som viser seg som periodisk tap av eitt subnett i staden for som ein rein feil.

Overlapping er den andre grunnen til å overlevere. Viss dei pusha rutene inneheld eit prefiks som det lokale nettverket allereie brukar, kan ikkje klienten løyse konflikten for deg. Nokon må avgjere om prefikset er tilgjengeleg gjennom tunnelen, gjennom den fysiske koplinga eller gjennom ei meir spesifikk rute, og den avgjerda høyrer til den som eig topologien.

Opprydding er den tredje. Ein klient som krasjar før han fjernar rutene sine, etterlèt eit svart hol som overlever økta, og den neste tilkoplinga kan leggje ein duplikat oppå det. Den som eig rutinga, eig også å kontrollere at dei gamle oppføringane er borte. Gjer den kontrollen til ein del av oppstartsvegen, ikkje eit valfritt oppryddingstrinn.

Kven eig DNS og resolverfila

DNS er den same avgjerda med skarpare kantar. Klienten kan godta DNS-tenarane som gatewayen eller PPP-peeren rapporterer, og skrive dei inn i resolver-konfigurasjonen til verten. På ein enkel maskin er det nøyaktig det du vil ha, fordi interne namn då berre blir løyste så lenge tunnelen er oppe.

På ein moderne Linux-vert kan resolveren styrast av ein lokal stub, og å skrive om resolverfila bak ryggen på den stubben gjev ein konfigurasjon som ser riktig ut og oppfører seg inkonsistent. Viss verten allereie køyrer ein resolverhandsamar, la han eige DNS og fôr han med tenarane til tunnelen gjennom grensesnittet han støttar. Klienten sitt no-dns-val er det riktige valet der, ikkje ein omveg.

Delt DNS er eit separat spørsmål frå kven som skriv fila. Å sende kvar spørjing gjennom tunnelen er enkelt og tregt; å sende berre interne soner gjennom han krev konfigurasjon per domene som dei fleste enkle klientar ikkje tilbyr. Avgjer kva åtferd verten treng før du aktiverer resolverendringane til klienten. Eit feil val her ser ut som eit namneoppløysingsutfall sjølv når tunnelen sjølv er i orden.

Privilegium, beredskap og overleveringa

Å opprette tunneleininga og redigere vertsruter eller resolvertilstand krev forhøgd nettverksmyndigheit. Den vanlege feilen er å konkludere at difor må alt køyre som root, inkludert nettlesaren eller applikasjonen som brukar tunnelen. Hald den privilegerte delen liten: klienten og konfigurasjonsfila hans, eigd av ein administrator, medan brukarapplikasjonar behaldar den normale kontoen sin.

Beredskap bør definerast per forbrukar. Ein rettleiar kan sjå på tenesta som starta når klientprosessen køyrer og tunneleininga finst. Ein sikkerheitskopijobb bør først sjå på VPN-en som brukbar når lagringsendepunktet svarar gjennom tunnelen. Det er ulike kontrollar, og å bruke den svakare til det sterkare føremålet gjev jobbar som startar for tidleg og feilar periodisk. Skriv ned definisjonen som er vald, fordi ein rettleiar og ein jobb som er usamde om beredskap, er ein støttebillett som ventar på å skje.

Test kontrakten med fire observasjonar: gatewayfasen blir fullført, PPP tildeler adresser, den tiltenkte ruta finst, og ein førespurnad til ein intern vert lykkast. Stopp deretter klienten og stadfest at kvar av desse er fjerna eller gjenoppretta. Viss verten framleis løyser interne namn eller framleis held ei rute etter at tunnelen er lukka, er eigarskapsoverleveringa ufullstendig.