vpn.persistent bliver ved med at prøve, men holder dig ikke forbundet

NetworkManager eksponerer én egenskab, vpn.persistent, og folk beder den besvare fire forskellige spørgsmål på én gang. Dens dokumentation længere oppe er omhyggelig: vedholdenhed gælder, når VPN-tjenesten understøtter den, og profilen aktiverer den, og forbindelsen bliver derefter bedt om at overleve linkændringer og afbrydelser indtil en udtrykkelig afbrydelse. Den samme dokumentation viser også, at egenskaben som standard er false, hvilket ikke er det, de fleste genopretningsplaner antager. Læs det som en anmodning om et forsøg snarere end et løfte om et resultat.

Hvad indstillingen egentlig forpligter til

En værdi gemt i en profil er en instruktion til manageren, og manageren skal give den instruktion videre til et VPN-plugin, der ved, hvad det skal gøre med den. Hvis det installerede plugin ignorerer egenskaben, aktiveres profilen alligevel, og loggen forbliver tavs, hvilket er det værste fra begge verdener for enhver, der senere fejlretter. Intet i en profil kan tvinge et plugin til at implementere adfærd, det ikke har, så det eneste synlige resultat er en fraværelse.

Derfor betyder betingelsen i dokumentationen mere end kontakten. Kontroller, hvilket plugin og hvilken udgave du faktisk har, og skriv versionen ved siden af forbindelsesbeskrivelsen, så den næste person ikke skal genopdage det. En genopretningspolitik bygget på et ikke-implementeret flag fejler præcis én gang i produktion og altid på det mest ubelejlige tidspunkt.

At behandle egenskaben som et forsøg sætter også den rigtige forventning til test. Du tjekker ikke, om flaget er sat; du tjekker, om der skete noget, da linket faldt. Det er forskellige eksperimenter, og kun ét af dem er en eftermiddag værd.

Fire spørgsmål der smeltes sammen til ét

Aktivering spørger, hvad der overhovedet bringer VPN'et op. En NetworkManager-profil kan knyttes til en basisforbindelse, en separat administreret OpenVPN-tjeneste ejer sin egen opstart, og at tilføje en tredje starter til det arrangement giver dig to ejere med forskellige ideer om, hvem der bestemmer. Beslut, hvilken komponent der ejer opstarten, før du tilføjer en ny udløser.

Genopretning spørger, hvad der sker, når linket ændres eller forsvinder, og det er det snævre spørgsmål, som vpn.persistent behandler. Levedygtighed spørger, om klienten kan se, at den anden ende er holdt op med at svare, og det besvarer OpenVPN's keepalive- eller genstartsadfærd i stedet; de to mekanismer beskrives ofte med det samme ord og implementeres forskellige steder. Test dem hver for sig med forskellige værktøjer, ellers tilskriver du den ene adfærd den anden.

Hensigt spørger, om genopkobling overhovedet ønskes, og det er det spørgsmål, som statuspolling ikke kan besvare. Et bevidst stop og en afbrydelse giver den samme inaktive tilstand, så alt, der genopkobler ved fravær, gætter på en menneskelig beslutning. Gætteri er fint lige indtil det overrider nogen.

En tjekliste der holder dem adskilt

Kør hændelserne i rækkefølge i stedet for at læse konfigurationen og ræsonnere om den, og registrér, hvad hver af dem viser, med et tidsstempel.

For det første: aktivér den tilsigtede basisforbindelse, og bekræft, at VPN'et kom op via den udløser, du forventede, og ikke via en mekanisme, du havde glemt var installeret. For det andet: sammenlign under en godkendt afbrydelse managerens VPN-hændelser, den ejende klients genopretningstilstand og en ny anmodning til en privat ressource. For det tredje: afbryd bevidst, vent, og bekræft, at intet genstarter profilen bag din ryg.

Det tredje trin er det, folk springer over, og det er det, der oftest finder den egentlige fejl. En watchdog, der poller efter en aktiv profil og genopkobler, når den mangler, vil muntert fortryde en brugers bevidste afbrydelse. Fra brugerens stol er det ikke robusthed; det er en maskine, der ikke vil adlyde. Spørg dem, før du tilføjer en.

Skriv resultaterne i samme dokument som forbindelsesbeskrivelsen. En genopretningspolitik er kun så god som den sidste gang, nogen så den fejle med vilje. Tidsstempler gør forskellen synlig for enhver, der læser noterne næste gang.

Godkendelse er en del af genopretningen

Genopkobling er ikke en rent netværksmæssig handling. Hvis det godkendte flow kræver en ny udfordring, en engangskode eller en hemmelighed, som aktiveringskonteksten ikke kan nå, kan ingen vedholdenhedsindstilling frembringe den ud af ingenting.

Det forklarer et velkendt mønster: forbindelsen genoprettes på en maskine med en oplåst nøglering og fejler på samme maskine efter en genstart. Netværkslaget gjorde præcis, hvad der blev bedt om, og legitimationslaget havde intet at tilbyde.

Ret legitimationsarbejdsgangen i stedet for at forkorte genforsøgsintervallet. Hurtigere genforsøg mod en prompt, ingen kan besvare, skaber logstøj og et falsk indtryk af, at noget forsøges.

Vedholdenhed er ikke en kill switch

Egenskaben forsøger at bevare eller genoprette VPN-forholdet. Den afgør ikke, hvad applikationer må gøre, mens VPN'et er nede, og den blokerer intet i sig selv.

Hvis kravet er, at ingen trafik forlader tunnelen, er det en separat politik med sin egen mekanisme, sin egen test og sine egne fejltilstande. At antage, at vedholdenhed dækker det, gør en sikkerhedsbeslutning til et uheld.

Registrér begge halvdele i genopretningsnoterne: hvad VPN'et forsøgte, og hvilken applikationstrafik der blev tilladt, mens forsøget var i gang.