vpn.persistent fortsetter å prøve, men holder deg ikke tilkoblet

NetworkManager eksponerer én egenskap, vpn.persistent, og folk ber den svare på fire forskjellige spørsmål samtidig. Dokumentasjonen oppstrøms er nøye: vedvarendehet gjelder når VPN-tjenesten støtter den og profilen aktiverer den, og tilkoblingen blir deretter bedt om å overleve lenkeendringer og avbrudd til en eksplisitt frakobling. Den samme dokumentasjonen viser også at egenskapen har standardverdien false, noe de fleste gjenopprettingsplaner ikke forutsetter. Les det som en anmodning om et forsøk, ikke et løfte om et resultat.

Hva innstillingen faktisk forplikter seg til

En verdi lagret i en profil er en instruks til behandleren, og behandleren må gi den instruksen videre til en VPN-plugin som vet hva den skal gjøre med den. Hvis den installerte plugin-en ignorerer egenskapen, aktiveres profilen likevel og loggen forblir stille, noe som er det verste av to verdener for alle som senere feilsøker. Ingenting i en profil kan tvinge en plugin til å implementere atferd den ikke har, så det eneste synlige resultatet er fravær.

Derfor er betingelsen i dokumentasjonen viktigere enn bryteren. Sjekk hvilken plugin og utgivelse du faktisk har, og skriv versjonen ved siden av tilkoblingsbeskrivelsen slik at neste person ikke må gjenoppdage den. En gjenopprettingspolicy bygget på et ikke-implementert flagg feiler nøyaktig én gang i produksjon og alltid på det minst passende tidspunktet.

Å behandle egenskapen som et forsøk setter også riktig forventning til testing. Du sjekker ikke om flagget er satt; du sjekker om noe skjedde da lenken falt. Det er forskjellige eksperimenter, og bare ett av dem er en ettermiddag verdt.

Fire spørsmål som smelter sammen til ett

Aktivering spør hva som i det hele tatt får VPN-en opp. En NetworkManager-profil kan knyttes til en grunnforbindelse, en separat administrert OpenVPN-tjeneste eier sin egen oppstart, og å legge til en tredje oppstarter i det oppsettet gir deg to eiere med ulike oppfatninger om hvem som bestemmer. Bestem hvilken komponent som eier oppstarten før du legger til en ny utløser.

Gjenoppretting spør hva som skjer når lenken endres eller forsvinner, og det er det smale spørsmålet som vpn.persistent behandler. Levedyktighet spør om klienten kan oppdage at den andre enden sluttet å svare, og det besvarer OpenVPNs keepalive- eller omstartsatferd i stedet; de to mekanismene beskrives ofte med samme ord og implementeres på forskjellige steder. Test dem separat, med forskjellige verktøy, ellers tilskriver du én atferd den andre.

Hensikt spør om gjenoppkobling i det hele tatt er ønsket, og det er spørsmålet statusavspørring ikke kan svare på. En bevisst stopp og et avbrudd gir samme inaktive tilstand, så alt som kobler til på nytt ved fravær, gjetter på en menneskelig beslutning. Gjetting er greit helt til det overkjører noen.

En sjekkliste som holder dem fra hverandre

Kjør hendelsene i rekkefølge i stedet for å lese konfigurasjonen og resonnere om den, og registrer hva hver av dem viser med et tidsstempel.

For det første, aktiver den tiltenkte grunnforbindelsen og bekreft at VPN-en kom opp via utløseren du forventet og ikke via en mekanisme du hadde glemt var installert. For det andre, sammenlign under en godkjent avbrytelse behandlerens VPN-hendelser, gjenopprettingstilstanden til den eierklienten og en ny forespørsel til en privat ressurs. For det tredje, koble fra bevisst, vent og bekreft at ingenting starter profilen på nytt bak ryggen din.

Det tredje trinnet er det folk hopper over, og det er det som oftest finner den virkelige feilen. En vakthund som avspørrer etter en aktiv profil og kobler til på nytt når den mangler, vil muntert angre en bevisst frakobling fra brukeren. Fra brukerens stol er det ikke robusthet; det er en maskin som ikke vil adlyde. Spør dem før du legger til en.

Skriv resultatene i samme dokument som tilkoblingsbeskrivelsen. En gjenopprettingspolicy er bare så god som den siste gangen noen så den feile med vilje. Tidsstempler gjør forskjellen synlig for alle som leser notatene neste gang.

Autentisering er en del av gjenopprettingen

Gjenoppkobling er ikke en rent nettverksmessig handling. Hvis flyten som er godkjent trenger en ny utfordring, en engangskode eller en hemmelighet som aktiveringskonteksten ikke kan nå, kan ingen vedvarendehetsinnstilling produsere den ut av ingenting.

Det forklarer et kjent mønster: tilkoblingen gjenopprettes på en maskin med ulåst nøkkelring og feiler på samme maskin etter omstart. Nettverkslaget gjorde nøyaktig det som ble bedt om, og legitimasjonslaget hadde ingenting å tilby.

Rett opp legitimasjonsarbeidsflyten i stedet for å forkorte nytt-forsøk-intervallet. Raskere nye forsøk mot en forespørsel ingen kan svare på skaper loggstøy og et falskt inntrykk av at noe forsøkes.

Vedvarendehet er ikke en kill switch

Egenskapen prøver å bevare eller gjenopprette VPN-forholdet. Den avgjør ikke hva applikasjoner kan gjøre mens VPN-en er nede, og den blokkerer ingenting av seg selv.

Hvis kravet er at ingen trafikk forlater tunnelen, er det en egen policy med sin egen mekanisme, sine egne tester og sine egne feilmoduser. Å anta at vedvarendehet dekker det, gjør en sikkerhetsbeslutning til en ulykke.

Registrer begge halvdeler i gjenopprettingsnotatene: hva VPN-en forsøkte, og hvilken applikasjonstrafikk som var tillatt mens forsøket pågikk.