Hoe lank moet OpenConnect ’n onderbroke VPN aanhou probeer?

--reconnect-timeout beantwoord net een eng vraag: nadat die tonnel wegval, hoe lank hou hierdie kliëntproses aan probeer voordat hy opgee en afsluit. Die OpenConnect-handleiding teken daardie opsie aan met ’n gedokumenteerde verstek van 300 sekondes vir herprobeerpogings ná ’n verlore skakel of ’n eweknie wat ophou antwoord het, en die getal is ’n sperdatum vir een lopende kliënt, nie ’n bewys dat die VPN bereikbaar bly nie. Dit is ook nie ’n beleid om die proses aan die lewe te hou nie, en dit is waar die meeste verwarring begin.

Die verwarring verdubbel sodra ’n tweede meganisme daarbo sit. ’n Toesighouer wat die kliënt herbegin, ’n peiler wat die poort kontak, en die ingeboude herprobeervenster kan almal op een fout reageer, en die voorval lewer dan drie tydlyne wat niemand kan versoen nie.

Wat die herverbindingstydperk werklik beperk

Stel jou voor die toegangsnetwerk verdwyn vir ’n paar sekondes. Die kliënt sien die skakel val, of hou op om dooie-eweknie-antwoorde te hoor, en begin die sessie hervestig terwyl hy hou aan wat hy kan. Herprobeerpogings duur voort totdat die poort weer aanvaar of die venster verstryk, en ’n venster wat verstryk eindig in ’n nie-nul-uitgang. Dit is daardie uitgang, eerder as die tydperkwaarde, waar die eienaarskap van die lewensiklus oorgaan na wie die proses ook al toesig hou.

Die venster sê niks oor hoe dikwels ’n peiling loop nie, en dit kan nie verifikasie verleng nie. As die poort die sessie herroep het, of die rekening nou ’n vars tweede faktor eis, sal meer wag die ou sessie nie weer geldig maak nie. ’n Herprobeerpoging slaag net wanneer die pad terug is, die poort die sessie steeds herken, en die geloofsbriewe wat dit vra bruikbaar bly, so lees die getal as ’n sperdatum eerder as ’n lewendigheidsinterval.

Die venster beheer ook nie wat toepassings doen terwyl dit loop nie. Afhangend van die platform en hoe ver die fout gevorder het, kan die kliënt herverbind met roetes wat nog geïnstalleer is, of nadat hulle onttrek is. Dit is waarom ’n versoek wat midde-in ’n onderbreking uitgereik word, gewoonlik hang tot dit verstryk in plaas van vinnig te misluk.

Toesighouerherstarting en kliëntherprobeerpogings is twee lae

Laat die lopende kliënt sy eie venster spandeer, en laat die diensbestuurder op die uitgang reageer. ’n Voorgrondkliënt onder systemd met ’n herbeginbeleid gee presies daardie verdeling: herprobeerpogings vir ’n begrensde tydperk, dan een herbeginbesluit. Die resultaat is ’n enkele tydlyn wat jy later nog kan rekonstrueer.

’n Kliënt in die agtergrond plus ’n onafhanklike peiler wat nog ’n kopie begin wanneer hy nie ’n koppelvlak sien nie, is die patroon wat verkeerd loop. Albei prosesse ding dan mee om dieselfde toestelknooppunt, roetes en oplosserinstellings. As jy wel ’n daemon wil hê, sit die opsie op die opdragreël waarmee die kliënt werklik begin:

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

Twee besonderhede in daardie reël dra gewig. --background maak die proses los, so word die pid-lêer die enigste betroubare handvatsel daarop, en die tydperk word net spandeer terwyl daardie selfde proses leef; ’n toesighouer wat dit doodmaak, laat geen begroting oor om mee voort te gaan nie.

Doelbewuste ontkoppelings het hul eie sein nodig. ’n Beplande pouse en ’n werklike onderbreking lyk identies vir ’n naïewe wagter, albei lees as „nie gekoppel nie”. Dryf die pouse deur die toesighouer se stopbewerking, of ’n merker wat die omhulsel verstaan, sodat ’n doelbewuste stilstand nie ’n herbegin veroorsaak wat niemand gevra het nie.

Om te verhoed dat die oorhandiging die herprobeerlus verbysnel

Onbewaakte herstel hang af van geloofsbriewe wat sonder ’n persoon se teenwoordigheid hernu. ’n Sleutelring wat net binne ’n interaktiewe lessenaarsessie oopsluit, of ’n teken wat altyd ’n ingetikte kode nodig het, sal die kliënt by die verifikasiestadium laat vasbrand sodra die pad terug is. Besleg daardie werkvloei voordat jy die venster verleng, want ’n langer venster gee net dieselfde geblokkeerde opdrag meer tyd om te misluk.

Bedienerverifikasie moet nie verslap word om vrae te verminder nie. Die pen of vertrouensanker wat die poort valideer, is wat ’n outomatiese herverbinding veilig maak, en om dit te deaktiveer om ’n sertifikaatvraag te vermy, ruil ’n sigbare onderbreking vir ’n onsigbare een. Hou die geverifieerde identiteit en herstel eerder die opdrag; ’n kliënt wat bereid is om aan enige poort te koppel, is slegter as een wat stop en wag.

Koppelvlakteenwoordigheid is ook nie ’n gesondheidsein nie. ’n Tonneltoestel kan bestaan met ’n dooie sessie agter hom, en ’n lanseerproses kan bestaan sonder enige tonnel. Nie een van daardie waarnemings oorleef ’n werklike versoek nie. Gesondheid moet kom uit wat die gebruiker nodig het, soos ’n versoek wat deur die tonnel na ’n bekende interne diens gaan.

Wat om tydens en ná ’n onderbreking te verifieer

Voer vier gebeure as aparte toetse uit: ’n onderbreking korter as die venster, ’n onderbreking langer as dit, ’n verifikasiefout en ’n doelbewuste stop. Elkeen moet in ’n ander, voorspelbare toestand eindig, en die grens tussen die eerste twee is die hele rede waarom ’n waarde gekies word.

Hou die kontroles na buite gerig, want die prosesstabel bewys op sy eie baie min. Kyk of die pid stabiel bly deur die kort onderbreking, en bevestig dan dat dit weg is en een keer vervang is ná die lang een:

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)"

Bevestig tydens die kort onderbreking dat die kliënt werklik herprobeer het eerder as om vroeg uit te gaan, en dat roetes en oplosserinskrywings sonder duplikate teruggekom het. Vir die langer onderbreking, bevestig ’n skoon uitgang en dat presies een herbegin gevolg het. Vir die verifikasiefout, bevestig dat die kliënt nie teen ’n poort draai wat hom sal bly weier nie. Voeg ’n kontrole by dat die pid na ’n enkele waarde terugkeer eerder as om op te hoop.

Vir die doelbewuste stop moet die gesondheids-URL onbereikbaar bly en die proses moet af bly. Sluit dan die lus van die toepassing se kant: dieselfde versoek moet misluk terwyl die tonnel weg is en moet slaag nadat dit terugkeer, vanaf die bronadres wat jou beleid verwag. ’n Groen tonnelikoon is nie bewyse nie, maar ’n voltooide versoek is.