Cât timp ar trebui OpenConnect să mai încerce un VPN căzut?

--reconnect-timeout răspunde la o singură întrebare îngustă: după ce tunelul cade, cât timp continuă acest proces client să încerce înainte de a renunța și a ieși. Pagina de manual a OpenConnect înregistrează această opțiune cu o valoare implicită documentată de 300 secunde pentru reîncercările care urmează unei legături pierdute sau unui peer care a încetat să răspundă, iar numărul este un termen limită pentru un singur client în execuție, nu o dovadă că VPN-ul rămâne accesibil. Nu este nici o politică de menținere a procesului în viață, și de acolo începe cea mai mare parte a confuziei.

Confuzia crește când deasupra se așază un al doilea mecanism. Un supraveghetor care repornește clientul, un sondor care face ping la gateway și fereastra de reîncercări încorporată pot reacționa toate la o singură defecțiune, iar incidentul produce atunci trei cronologii pe care nimeni nu le poate împăca.

Ce limitează de fapt fereastra de reconectare

Imaginați-vă că rețeaua de acces dispare pentru câteva secunde. Clientul vede legătura căzând sau nu mai aude răspunsurile peer-ului mort și începe să restabilească sesiunea păstrând starea de care este capabil. Încercările continuă până când gateway-ul acceptă din nou sau fereastra se epuizează, iar o fereastră epuizată se termină cu o ieșire diferită de zero. Acea ieșire, nu valoarea timpului limită, este locul unde proprietatea ciclului de viață trece la cel care supraveghează procesul.

Fereastra nu spune nimic despre cât de des rulează o sondă și nu poate prelungi autentificarea. Dacă gateway-ul a revocat sesiunea sau contul cere acum un al doilea factor nou, o așteptare mai lungă nu va face sesiunea veche din nou validă. O reîncercare reușește doar când calea revine, gateway-ul încă recunoaște sesiunea și acreditările cerute rămân utilizabile, așa că citiți numărul ca termen limită și nu ca interval de vitalitate.

Fereastra nu guvernează nici ce fac aplicațiile în timp ce rulează. În funcție de platformă și de cât de departe a mers defecțiunea, clientul se poate reconecta cu rutele încă instalate sau după ce acestea au fost retrase. De aceea o cerere emisă la mijlocul unei întreruperi tinde să atârne până la expirarea timpului limită în loc să eșueze rapid.

Repornirile supraveghetorului și reîncercările clientului sunt două straturi

Lăsați clientul în execuție să își consume propria fereastră, iar managerul de servicii să reacționeze la ieșire. Un client în prim-plan sub systemd cu o politică de repornire oferă exact această împărțire: reîncercări pentru o perioadă limitată, apoi o singură decizie de repornire. Rezultatul este o singură cronologie pe care o puteți reconstrui ulterior.

Un client în fundal plus un sondor independent care pornește o altă copie când nu vede o interfață este tiparul care merge prost. Atunci ambele procese se luptă pentru același nod de dispozitiv, aceleași rute și aceleași setări ale resolverului. Dacă vreți cu adevărat un demon, puneți opțiunea pe linia de comandă cu care clientul chiar pornește:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Două detalii de pe acea linie cântăresc greu. --background desprinde procesul, așa că fișierul pid devine singura prindere de încredere asupra lui, iar timpul limită se consumă doar cât timp același proces trăiește; un supraveghetor care îl ucide nu lasă niciun buget pentru continuare.

Deconectările intenționate au nevoie de propriul semnal. O pauză planificată și o cădere reală arată identic pentru un observator naiv, ambele fiind citite ca „neconectat”. Conduceți pauza prin operația de oprire a supraveghetorului sau printr-un marcaj pe care îl înțelege ambalajul, ca o oprire deliberată să nu declanșeze o repornire pe care nimeni nu a cerut-o.

Cum să împiedicați predarea să concureze bucla de reîncercări

Recuperarea nesupravegheată depinde de acreditări care se reînnoiesc fără o persoană prezentă. O legătură de chei care se deschide doar într-o sesiune interactivă de desktop, sau un token care cere mereu un cod tastat, va lăsa clientul blocat la etapa de autentificare imediat ce calea revine. Rezolvați acel flux înainte de a lungi fereastra, pentru că o fereastră mai lungă oferă doar aceleiași solicitări blocate mai mult timp să eșueze.

Verificarea serverului nu trebuie relaxată pentru a reduce solicitările. Exact fixarea sau ancora de încredere care validează gateway-ul face o reconectare automată sigură, iar dezactivarea ei pentru a evita o întrebare despre certificat schimbă o întrerupere vizibilă cu una invizibilă. Păstrați identitatea verificată și reparați solicitarea în schimb; un client dispus să se conecteze la orice gateway este mai rău decât unul care se oprește și așteaptă.

Nici prezența interfeței nu este un semnal de sănătate. Un dispozitiv de tunel poate exista cu o sesiune moartă în spate, iar un proces de lansare poate exista fără niciun tunel. Niciuna dintre aceste observații nu rezistă unei cereri reale. Sănătatea trebuie să vină din ce are nevoie utilizatorul, cum ar fi o cerere care traversează tunelul către un serviciu intern cunoscut.

Ce de verificat în timpul și după o întrerupere

Rulați patru evenimente ca teste separate: o întrerupere mai scurtă decât fereastra, o cădere mai lungă decât ea, o eroare de autentificare și o oprire deliberată. Fiecare ar trebui să se termine într-o stare diferită și previzibilă, iar granița dintre primele două este întregul motiv pentru alegerea unei valori.

Țineți verificările îndreptate spre exterior, pentru că tabelul proceselor singur dovedește foarte puțin. Urmăriți dacă pid-ul rămâne stabil în timpul întreruperii scurte, apoi confirmați că a dispărut și a fost înlocuit o dată după cea lungă:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

În timpul întreruperii scurte, confirmați că clientul a reîncercat într-adevăr în loc să iasă devreme, și că rutele și intrările resolverului au revenit fără duplicate. Pentru căderea mai lungă, confirmați o ieșire curată și exact o repornire după ea. Pentru eroarea de autentificare, confirmați că clientul nu se învârte împotriva unui gateway care îl va refuza în continuare. Adăugați o verificare că pid-ul revine la o singură valoare în loc să se acumuleze.

Pentru oprirea deliberată, URL-ul de sănătate trebuie să rămână inaccesibil, iar procesul să rămână oprit. Apoi închideți bucla din partea aplicației: aceeași cerere trebuie să eșueze cât timp tunelul lipsește și trebuie să reușească după ce acesta revine, de la adresa sursă pe care o așteaptă politica voastră. O pictogramă verde de tunel nu este dovadă, dar o cerere finalizată este.