vpn.persistent fortsätter försöka, men håller dig inte ansluten

NetworkManager exponerar en egenskap, vpn.persistent, och folk ber den svara på fyra olika frågor samtidigt. Dess uppströmsdokumentation är noggrann: varaktighet gäller när VPN-tjänsten stöder den och profilen aktiverar den, och anslutningen ombeds sedan överleva länkändringar och avbrott till en uttrycklig frånkoppling. Samma dokumentation visar också att egenskapen har standardvärdet false, vilket de flesta återställningsplaner inte förutsätter. Läs det som en begäran om ett försök, inte ett löfte om ett resultat.

Vad inställningen faktiskt förbinder sig till

Ett värde som sparats i en profil är en instruktion till hanteraren, och hanteraren måste lämna den instruktionen till ett VPN-insticksprogram som vet vad det ska göra med den. Om det installerade insticksprogrammet ignorerar egenskapen aktiveras profilen ändå och loggen förblir tyst, vilket är det sämsta av två världar för alla som senare felsöker. Ingenting i en profil kan tvinga ett insticksprogram att implementera beteende som det inte har, så det enda synliga resultatet är frånvaro.

Därför är villkoret i dokumentationen viktigare än strömbrytaren. Kontrollera vilket insticksprogram och vilken utgåva du faktiskt har, och skriv versionen bredvid anslutningsbeskrivningen så att nästa person inte behöver upptäcka den igen. En återställningspolicy byggd på en icke-implementerad flagga misslyckas exakt en gång i produktion och alltid i det minst lägliga ögonblicket.

Att behandla egenskapen som ett försök sätter också rätt förväntan på testning. Du kontrollerar inte om flaggan är satt; du kontrollerar om något hände när länken föll. Det är olika experiment, och bara ett av dem är en eftermiddag värt.

Fyra frågor som smälter samman till en

Aktivering frågar vad som överhuvudtaget får upp VPN:en. En NetworkManager-profil kan knytas till en basanslutning, en separat hanterad OpenVPN-tjänst äger sin egen start, och att lägga till en tredje startare i det upplägget ger dig två ägare med olika uppfattningar om vem som bestämmer. Bestäm vilken komponent som äger starten innan du lägger till en ny utlösare.

Återställning frågar vad som händer när länken ändras eller försvinner, och det är den snäva frågan som vpn.persistent hanterar. Livskraft frågar om klienten kan upptäcka att den andra sidan slutade svara, och det besvarar OpenVPN:s keepalive- eller omstartsbeteende i stället; de två mekanismerna beskrivs ofta med samma ord och implementeras på olika ställen. Testa dem separat, med olika verktyg, annars tillskriver du ett beteende det andra.

Avsikt frågar om återanslutning alls är önskvärd, och det är frågan som statusavfrågning inte kan svara på. Ett medvetet stopp och ett avbrott ger samma inaktiva tillstånd, så allt som återansluter vid frånvaro gissar om ett mänskligt beslut. Gissande är bra ända till det ögonblick det kör över någon.

En checklista som håller dem åtskilda

Kör händelserna i ordning i stället för att läsa konfigurationen och resonera om den, och registrera vad var och en visar med en tidsstämpel.

För det första, aktivera den avsedda basanslutningen och bekräfta att VPN:en kom upp via utlösaren du förväntade dig och inte via en mekanism du hade glömt var installerad. För det andra, jämför under ett godkänt avbrott hanterarens VPN-händelser, ägarklientens återställningstillstånd och en ny begäran till en privat resurs. För det tredje, koppla från medvetet, vänta och bekräfta att ingenting startar om profilen bakom din rygg.

Det tredje steget är det som folk hoppar över, och det är det som oftast hittar det verkliga felet. En vakthund som avfrågar en aktiv profil och återansluter när den saknas kommer glatt att ångra en användares medvetna frånkoppling. Från användarens stol är det inte robusthet; det är en maskin som inte lyder. Fråga dem innan du lägger till en.

Skriv resultaten i samma dokument som anslutningsbeskrivningen. En återställningspolicy är bara så bra som den senaste gången någon såg den misslyckas med avsikt. Tidsstämplar gör skillnaden synlig för alla som läser anteckningarna nästa gång.

Autentisering är en del av återställningen

Återanslutning är inte en rent nätverksmässig handling. Om flödet som godkänts behöver en ny utmaning, en engångskod eller en hemlighet som aktiveringskontexten inte kan nå, kan ingen varaktighetsinställning producera den ur ingenting.

Det förklarar ett känt mönster: anslutningen återställs på en maskin med olåst nyckelring och misslyckas på samma maskin efter omstart. Nätverkslagret gjorde precis det som efterfrågades, och autentiseringslagret hade ingenting att erbjuda.

Rätta till arbetsflödet för autentiseringsuppgifter i stället för att förkorta återförsöksintervallet. Snabbare återförsök mot en uppmaning som ingen kan svara på skapar loggbuller och en falsk känsla av att något försöks.

Varaktighet är inte en kill switch

Egenskapen försöker bevara eller återställa VPN-relationen. Den avgör inte vad applikationer får göra medan VPN:en är nere, och den blockerar ingenting själv.

Om kravet är att ingen trafik lämnar tunneln är det en separat policy med sin egen mekanism, sina egna tester och sina egna feltillstånd. Att anta att varaktighet täcker det gör ett säkerhetsbeslut till en olycka.

Registrera båda halvorna i återställningsanteckningarna: vad VPN:en försökte och vilken applikationstrafik som tilläts medan försöket pågick.