vpn.persistent held fram med å prøve, men held deg ikkje tilkopla

NetworkManager eksponerer éin eigenskap, vpn.persistent, og folk ber han svare på fire ulike spørsmål samstundes. Dokumentasjonen oppstraums er nøye: varigheit gjeld når VPN-tenesta støttar han og profilen aktiverer han, og tilkoplinga vert deretter bedd om å overleve lenkeendringar og avbrot til ei eksplisitt fråkopling. Den same dokumentasjonen viser òg at eigenskapen har standardverdien false, noko dei fleste gjenopprettingsplanar ikkje føreset. Les det som ei oppmoding om eit forsøk, ikkje eit løfte om eit resultat.

Kva innstillinga faktisk forpliktar seg til

Ein verdi lagra i ein profil er ein instruks til behandlaren, og behandlaren må gje den instruksen vidare til ein VPN-plugin som veit kva han skal gjere med han. Viss den installerte plugin-en ignorerer eigenskapen, vert profilen likevel aktivert og loggen held seg stille, noko som er det verste av to verder for alle som seinare feilsøkjer. Ingenting i ein profil kan tvinge ein plugin til å implementere åtferd han ikkje har, så det einaste synlege resultatet er fråvær.

Difor er vilkåret i dokumentasjonen viktigare enn brytaren. Sjekk kva plugin og utgåve du faktisk har, og skriv versjonen ved sida av tilkoplingsteksten slik at neste person ikkje må oppdage han på nytt. Ein gjenopprettingspolicy bygd på eit ikkje-implementert flagg feilar nøyaktig éin gong i produksjon og alltid på det minst passande tidspunktet.

Å handsame eigenskapen som eit forsøk set òg den rette forventninga til testing. Du sjekkar ikkje om flagget er sett; du sjekkar om noko skjedde då lenka fall. Det er ulike eksperiment, og berre eitt av dei er ein ettermiddag verdt.

Fire spørsmål som smeltar saman til eitt

Aktivering spør kva som i det heile får VPN-en opp. Ein NetworkManager-profil kan knytast til ei grunnkopling, ei separat styrt OpenVPN-teneste eig si eiga oppstart, og å leggje til ein tredje oppstartar i det oppsettet gjev deg to eigarar med ulike oppfatningar om kven som styrer. Bestem kva komponent som eig oppstarten før du legg til ein ny utløysar.

Gjenoppretting spør kva som skjer når lenka endrar seg eller forsvinn, og det er det smale spørsmålet som vpn.persistent handsamar. Levedyktigheit spør om klienten kan oppdage at den andre enden slutta å svare, og det svarar OpenVPN sin keepalive- eller omstartåtferd på i staden; dei to mekanismane vert ofte skildra med same ord og implementerte på ulike stader. Test dei separat, med ulike verktøy, elles tilskriv du éi åtferd den andre.

Hensikt spør om gjenoppkopling i det heile er ønskt, og det er spørsmålet statusavspørjing ikkje kan svare på. Ein medviten stopp og eit avbrot gjev same inaktive tilstand, så alt som koplar til på nytt ved fråvær, gissar på ei menneskeleg avgjerd. Gissing er greitt heilt til det overkøyrer nokon.

Ei sjekkliste som held dei frå kvarandre

Køyr hendingane i rekkjefølgje i staden for å lese konfigurasjonen og resonnere om han, og registrer kva kvar av dei viser med eit tidsstempel.

For det første, aktiver den tiltenkte grunnkoplinga og stadfest at VPN-en kom opp via utløysaren du venta og ikkje via ein mekanisme du hadde gløymt var installert. For det andre, samanlikn under eit godkjent avbrot VPN-hendingane til behandlaren, gjenopprettingstilstanden til eigarklienten og ein ny førespurnad til ein privat ressurs. For det tredje, kople frå med vilje, vent og stadfest at ingenting startar profilen på nytt bak ryggen din.

Det tredje steget er det folk hoppar over, og det er det som oftast finn den verkelege feilen. Ein vakthund som avspør etter ein aktiv profil og koplar til på nytt når han manglar, vil muntert angre ei medviten fråkopling frå brukaren. Frå stolen til brukaren er det ikkje robustheit; det er ein maskin som ikkje vil lyda. Spør dei før du legg til ein.

Skriv resultata i same dokumentet som tilkoplingsteksten. Ein gjenopprettingspolicy er berre så god som den siste gongen nokon såg han feile med vilje. Tidsstempel gjer skilnaden synleg for alle som les notata neste gong.

Autentisering er ein del av gjenopprettinga

Gjenoppkopling er ikkje ei reint nettverksmessig handling. Viss den godkjende flyten treng ei ny utfordring, ein eingongskode eller ein løyndom som aktiveringskonteksten ikkje kan nå, kan ingen varigheitsinnstilling produsere han ut av ingenting.

Det forklarar eit kjent mønster: tilkoplinga kjem att på ein maskin med ulåst nøkkelring og feilar på same maskin etter omstart. Nettverkslaget gjorde nøyaktig det som vart bedt om, og legitimasjonslaget hadde ingenting å tilby.

Ret opp legitimasjonsarbeidsflyten i staden for å korte ned nytt-forsøk-intervallet. Raskare nye forsøk mot ein førespurnad ingen kan svare på skapar loggstøy og eit falskt inntrykk av at noko vert forsøkt.

Varigheit er ikkje ein kill switch

Eigenskapen prøver å halde på eller gjenopprette VPN-forholdet. Han avgjer ikkje kva applikasjonar kan gjere medan VPN-en er nede, og han blokkerer ingenting av seg sjølv.

Viss kravet er at ingen trafikk forlèt tunnelen, er det ein eigen policy med sin eigen mekanisme, sine eigne testar og sine eigne feilmodus. Å tru at varigheit dekkjer det, gjer ei tryggingsavgjerd til ei ulukke.

Registrer båe halvdelane i gjenopprettingsnotata: kva VPN-en forsøkte, og kva applikasjonstrafikk som var tillaten medan forsøket gjekk føre seg.