vpn.persistent blijft proberen, maar houdt je niet verbonden

NetworkManager biedt één eigenschap, vpn.persistent, en mensen vragen die om vier verschillende vragen tegelijk te beantwoorden. De upstreamdocumentatie is zorgvuldig: persistentie geldt wanneer de VPN-dienst haar ondersteunt en het profiel haar inschakelt, en de verbinding wordt dan gevraagd linkwijzigingen en storingen te overleven tot een expliciete ontkoppeling. Dezelfde documentatie laat ook zien dat de eigenschap standaard false is, wat de meeste herstelplannen niet aannemen. Lees het als een verzoek om een poging, niet als een belofte van een resultaat.

Waartoe de instelling echt verplicht

Een waarde die in een profiel is opgeslagen is een instructie aan de beheerder, en de beheerder moet die instructie doorgeven aan een VPN-plugin die weet wat ermee te doen. Als de geïnstalleerde plugin de eigenschap negeert, wordt het profiel toch geactiveerd en blijft het log stil, wat het slechtste van twee werelden is voor iedereen die later debugt. Niets in een profiel kan een plugin dwingen gedrag te implementeren dat het niet heeft, dus het enige zichtbare resultaat is een afwezigheid.

Daarom is de voorwaarde in de documentatie belangrijker dan de schakelaar. Controleer welke plugin en release je echt hebt, en schrijf de versie naast de verbindingsbeschrijving zodat de volgende persoon die niet opnieuw hoeft te ontdekken. Een herstelbeleid op een niet-geïmplementeerde vlag faalt in productie precies één keer en altijd op het minst gelegen moment.

De eigenschap als poging behandelen zet ook de juiste verwachting voor tests. Je controleert niet of de vlag is gezet; je controleert of er iets gebeurde toen de link wegviel. Dat zijn verschillende experimenten, en slechts één ervan is een middag waard.

Vier vragen die in één samensmelten

Activatie vraagt wat de VPN überhaupt opbrengt. Een NetworkManager-profiel kan aan een basisverbinding worden gekoppeld, een apart beheerde OpenVPN-dienst bezit zijn eigen opstart, en een derde starter aan die opzet toevoegen geeft je twee eigenaren met verschillende ideeën over wie de baas is. Bepaal welke component het opstarten bezit voordat je nog een trigger toevoegt.

Herstel vraagt wat er gebeurt wanneer de link verandert of verdwijnt, en dat is de smalle vraag die vpn.persistent behandelt. Levensvatbaarheid vraagt of de client kan merken dat de andere kant is gestopt met antwoorden, en het keepalive- of herstartgedrag van OpenVPN beantwoordt dat in plaats daarvan; de twee mechanismen worden vaak met hetzelfde woord beschreven en op verschillende plaatsen geïmplementeerd. Test ze apart, met verschillende hulpmiddelen, anders schrijf je het ene gedrag aan het andere toe.

Bedoeling vraagt of opnieuw verbinden überhaupt gewenst is, en dat is de vraag die statuspolling niet kan beantwoorden. Een bewuste stop en een storing leveren dezelfde inactieve toestand op, dus alles wat bij afwezigheid opnieuw verbindt, gokt naar een menselijke beslissing. Gokken is prima tot het moment dat het iemand overruled.

Een checklist die ze gescheiden houdt

Voer de gebeurtenissen in volgorde uit in plaats van de configuratie te lezen en erover te redeneren, en leg vast wat elk ervan toont met een tijdstempel.

Ten eerste, activeer de bedoelde basisverbinding en bevestig dat de VPN omhoogkwam via de trigger die je verwachtte en niet via een mechanisme waarvan je vergeten was dat het geïnstalleerd was. Ten tweede, vergelijk tijdens een goedgekeurde onderbreking de VPN-gebeurtenissen van de beheerder, de hersteltoestand van de eigenaar-client en een nieuwe aanvraag naar een particuliere bron. Ten derde, ontkoppel bewust, wacht en bevestig dat niets het profiel achter je rug opnieuw start.

De derde stap is degene die mensen overslaan, en het is degene die het echte defect het vaakst vindt. Een watchdog die peilt naar een actief profiel en opnieuw verbindt wanneer het ontbreekt, maakt vrolijk de bewuste ontkoppeling van een gebruiker ongedaan. Vanuit de stoel van de gebruiker is dat geen veerkracht; het is een machine die niet zal gehoorzamen. Vraag het hun voordat je er een toevoegt.

Schrijf de resultaten in hetzelfde document als de verbindingsbeschrijving. Een herstelbeleid is slechts zo goed als de laatste keer dat iemand het bewust zag falen. Tijdstempels maken het verschil zichtbaar voor wie de notities daarna leest.

Authenticatie is onderdeel van het herstel

Opnieuw verbinden is geen puur netwerkgebeuren. Als de goedgekeurde stroom een nieuwe uitdaging, een eenmalige code of een geheim nodig heeft dat de activatiecontext niet kan bereiken, kan geen enkele persistentie-instelling het uit het niets produceren.

Dat verklaart een bekend patroon: de verbinding herstelt op een machine met een ontgrendelde sleutelhanger en faalt op dezelfde machine na een herstart. De netwerklaag deed precies wat er gevraagd was en de referentielaag had niets te bieden.

Repareer de referentie-workflow in plaats van het herhaalinterval te verkorten. Snellere herhaalpogingen tegen een prompt die niemand kan beantwoorden veroorzaken logruis en een valse indruk dat er iets wordt geprobeerd.

Persistentie is geen kill switch

De eigenschap probeert de VPN-relatie te behouden of te herstellen. Ze bepaalt niet wat applicaties mogen doen terwijl de VPN uit staat, en ze blokkeert zelf niets.

Als de eis is dat er geen verkeer buiten de tunnel gaat, is dat een apart beleid met zijn eigen mechanisme, zijn eigen tests en zijn eigen faalmodi. Aannemen dat persistentie dat dekt, maakt van een beveiligingsbeslissing een ongeluk.

Leg beide helften vast in de herstelnotities: wat de VPN probeerde en welk applicatieverkeer was toegestaan terwijl de poging liep.