vpn.persistent continuă să încerce, dar nu te ține conectat

NetworkManager expune o proprietate, vpn.persistent, iar oamenii îi cer să răspundă la patru întrebări diferite deodată. Documentația sa de origine este atentă: persistența se aplică atunci când serviciul VPN o acceptă și profilul o activează, iar conexiunea este apoi rugată să supraviețuiască schimbărilor de legătură și întreruperilor până la o deconectare explicită. Aceeași documentație arată și că proprietatea are valoarea implicită false, ceea ce majoritatea planurilor de recuperare nu presupun. Citește-o ca pe o cerere de încercare, nu ca pe o promisiune a unui rezultat.

La ce se angajează de fapt setarea

O valoare stocată într-un profil este o instrucțiune pentru manager, iar managerul trebuie să transmită acea instrucțiune unui plugin VPN care știe ce să facă cu ea. Dacă pluginul instalat ignoră proprietatea, profilul se activează totuși și jurnalul rămâne tăcut, ceea ce este cel mai rău din ambele lumi pentru oricine va depana mai târziu. Nimic din interiorul unui profil nu poate forța un plugin să implementeze un comportament pe care nu îl are, așa că singurul rezultat vizibil este o absență.

De aceea condiția din documentație contează mai mult decât comutatorul. Verifică ce plugin și ce versiune ai de fapt, și scrie versiunea lângă descrierea conexiunii ca următoarea persoană să nu trebuiască să o descopere din nou. O politică de recuperare construită pe un steag neimplementat eșuează exact o dată în producție și întotdeauna în cel mai incomod moment.

Tratarea proprietății ca o încercare stabilește și așteptarea corectă pentru teste. Nu verifici dacă steagul este setat; verifici dacă s-a întâmplat ceva când legătura a căzut. Sunt experimente diferite, și doar unul dintre ele merită o după-amiază.

Patru întrebări contopite într-una

Activarea întreabă ce ridică VPN-ul în primul rând. Un profil NetworkManager poate fi legat de o conexiune de bază, un serviciu OpenVPN gestionat separat are propria pornire, iar adăugarea unui al treilea lansator la acea configurare îți dă doi proprietari cu idei diferite despre cine conduce. Decide ce componentă deține pornirea înainte de a adăuga un alt declanșator.

Recuperarea întreabă ce se întâmplă când legătura se schimbă sau dispare, și aceasta este întrebarea îngustă pe care o abordează vpn.persistent. Viabilitatea întreabă dacă clientul poate observa că celălalt capăt a încetat să răspundă, iar în locul ei răspunde comportamentul keepalive sau de repornire al OpenVPN; cele două mecanisme sunt adesea descrise cu același cuvânt și implementate în locuri diferite. Testează-le separat, cu instrumente diferite, altfel vei atribui un comportament celuilalt.

Intenția întreabă dacă reconectarea este dorită măcar, și aceasta este întrebarea la care sondajul de stare nu poate răspunde. O oprire deliberată și o întrerupere produc aceeași stare inactivă, așa că orice se reconectează la absență ghicește o decizie umană. Ghicitul este în regulă până în momentul în care trece peste cineva.

O listă de verificare care le ține separate

Execută evenimentele în ordine în loc să citești configurația și să raționezi despre ea, și notează ce arată fiecare cu o marcă de timp.

În primul rând, activează conexiunea de bază dorită și confirmă că VPN-ul a pornit prin declanșatorul așteptat și nu printr-un mecanism despre care ai uitat că este instalat. În al doilea rând, în timpul unei întreruperi aprobate, compară evenimentele VPN ale managerului, starea de recuperare a clientului proprietar și o cerere nouă către o resursă privată. În al treilea rând, deconectează deliberat, așteaptă și confirmă că nimic nu repornește profilul în spatele tău.

Al treilea pas este cel pe care oamenii îl sar, și el găsește cel mai des defectul real. Un câine de pază care sondează un profil activ și se reconectează când acesta lipsește va anula bucuros o deconectare intenționată a utilizatorului. Din scaunul utilizatorului asta nu este reziliență; este o mașină care nu va asculta. Întreabă-i înainte de a adăuga unul.

Scrie rezultatele în același document ca descrierea conexiunii. O politică de recuperare valorează cât ultima dată când cineva a văzut-o eșuând intenționat. Mărcile de timp fac diferența vizibilă pentru oricine va citi notele mai departe.

Autentificarea face parte din recuperare

Reconectarea nu este un act pur de rețea. Dacă fluxul aprobat are nevoie de o provocare nouă, un cod de unică folosință sau un secret la care contextul de activare nu poate ajunge, nicio setare de persistență nu îl poate produce din nimic.

Asta explică un tipar familiar: conexiunea se recuperează pe o mașină cu inelul de chei deblocat și eșuează pe aceeași mașină după o repornire. Stratul de rețea a făcut exact ce i s-a cerut, iar stratul de credențiale nu avea nimic de oferit.

Repară fluxul de credențiale în loc să scurtezi intervalul de reîncercare. Reîncercări mai rapide împotriva unui prompt la care nimeni nu poate răspunde generează zgomot în jurnal și o impresie falsă că se încearcă ceva.

Persistența nu este un kill switch

Proprietatea încearcă să păstreze sau să restaureze relația VPN. Nu decide ce pot face aplicațiile în timp ce VPN-ul este oprit și nu blochează nimic de la sine.

Dacă cerința este ca niciun trafic să nu iasă în afara tunelului, aceea este o politică separată cu propriul mecanism, propriile teste și propriile moduri de eșec. A presupune că persistența acoperă asta transformă o decizie de securitate într-un accident.

Notează ambele jumătăți în notele de recuperare: ce a încercat VPN-ul și ce trafic de aplicații a fost permis în timpul încercării.