Ako dlho by mal OpenConnect skúšať pripojenie k prerušenému VPN?

--reconnect-timeout odpovedá na jednu úzku otázku: po páde tunela ako dlho tento klientsky proces pokračuje v pokusoch, kým sa vzdá a skončí. Stránka manuálu OpenConnect zaznamenáva túto voľbu s dokumentovanou predvolenou hodnotou 300 sekúnd pre opakované pokusy po strate spojenia alebo po partnerovi, ktorý prestal odpovedať, a číslo je termín pre jedného bežiaceho klienta, nie dôkaz, že VPN zostáva dostupný. Nie je to ani politika udržiavania procesu nažive, a práve tam sa začína väčšina zmätku.

Zmätok rastie, keď je navrchu druhý mechanizmus. Dohľad, ktorý klienta reštartuje, sonda, ktorá pingá bránu, a vstavané okno opakovaných pokusov môžu všetky reagovať na jednu poruchu, a incident potom dáva tri časové osi, ktoré nikto nedokáže zladiť.

Čo okno opätovného pripojenia skutočne obmedzuje

Predstavte si, že prístupová sieť na niekoľko sekúnd zmizne. Klient vidí, že spojenie padlo, alebo prestane počuť odpovede mŕtveho partnera, a začne znovu nadväzovať reláciu, pričom si drží, čo môže. Pokusy pokračujú, kým brána znovu neprijme alebo kým sa okno nevyčerpá, a vyčerpané okno končí nenulovým výstupom. Práve tento výstup, a nie hodnota limitu, je miestom, kde vlastníctvo životného cyklu prechádza na toho, kto proces dohliada.

Okno nič nehovorí o tom, ako často sa sonda spúšťa, a nedokáže predĺžiť overovanie. Ak brána reláciu zrušila alebo účet teraz vyžaduje nový druhý faktor, dlhšie čakanie starú reláciu znovu neplatnou neurobí. Opakovaný pokus uspeje len vtedy, keď sa cesta vráti, brána reláciu stále rozpoznáva a požadované prihlasovacie údaje zostanú použiteľné, takže čítajte to číslo ako termín, nie ako interval životnosti.

Okno tiež neupravuje, čo aplikácie robia, kým beží. V závislosti od platformy a od toho, ako ďaleko porucha postúpila, sa klient môže znova pripájať s trasami ešte nainštalovanými, alebo po ich odstránení. Preto požiadavka vydaná uprostred prerušenia zvyčajne visí až do vypršania limitu, namiesto toho, aby rýchlo zlyhala.

Reštarty dohľadu a opakované pokusy klienta sú dve vrstvy

Nechajte bežiaceho klienta minúť si vlastné okno a správcu služieb reagovať na výstup. Klient v popredí pod systemd s politikou reštartu dáva presne toto rozdelenie: pokusy po obmedzený čas, potom jedno rozhodnutie o reštarte. Výsledkom je jediná časová os, ktorú si ešte viete dodatočne zrekonštruovať.

Klient na pozadí plus nezávislý prieskumník, ktorý spustí ďalšiu kópiu, keď nevidí rozhranie, je vzor, ktorý sa pokazí. Vtedy obidva procesy súperia o ten istý uzol zariadenia, trasy a nastavenia resolvera. Ak naozaj chcete démona, vložte voľbu do príkazového riadka, s ktorým klient skutočne štartuje:

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

Dva detaily na tom riadku majú váhu. --background odpája proces, takže súbor pid sa stáva jediným spoľahlivým úchytom naň, a limit sa míňa len dovtedy, kým ten istý proces žije; dohľad, ktorý ho zabije, nenecháva žiadny rozpočet na pokračovanie.

Úmyselné odpojenia potrebujú vlastný signál. Plánovaná pauza a skutočný výpadok vyzerajú pre naivného pozorovateľa rovnako, obe sa čítajú ako „nepripojené”. Vedzte pauzu cez operáciu zastavenia dohľadu alebo cez značku, ktorej rozumie obal, aby úmyselné zastavenie nespustilo reštart, o ktorý nikto nepožiadal.

Ako zabrániť, aby odovzdanie predbehlo slučku opakovaných pokusov

Bezobslužné zotavenie závisí od prihlasovacích údajov, ktoré sa obnovujú bez prítomnej osoby. Zväzok kľúčov, ktorý sa odomkne len v interaktívnej relácii pracovnej plochy, alebo token, ktorý vždy vyžaduje napísaný kód, nechá klienta uviaznuť vo fáze overovania, hneď ako sa cesta vráti. Vyriešte ten pracovný postup pred predĺžením okna, pretože dlhšie okno len dáva tej istej zablokovanej výzve viac času zlyhať.

Overovanie servera sa nemá uvoľňovať, aby ubudlo výziev. Práve pin alebo kotva dôvery, ktorá validuje bránu, robí automatické opätovné pripojenie bezpečným, a jej vypnutie kvôli vyhnutiu sa otázke o certifikáte mení viditeľné prerušenie na neviditeľné. Zachovajte overenú identitu a radšej opravte výzvu; klient ochotný pripojiť sa k akejkoľvek bráne je horší ako ten, ktorý sa zastaví a čaká.

Prítomnosť rozhrania tiež nie je signálom zdravia. Tunelové zariadenie môže existovať s mŕtvou reláciou za ním a spúšťací proces môže existovať úplne bez tunela. Žiadne z týchto pozorovaní neobstojí pri skutočnej požiadavke. Zdravie musí vychádzať z toho, čo používateľ potrebuje, napríklad z požiadavky, ktorá prechádza tunelom k známej internej službe.

Čo overiť počas výpadku a po ňom

Spustite štyri udalosti ako samostatné testy: prerušenie kratšie ako okno, výpadok dlhší ako ono, zlyhanie overenia a úmyselné zastavenie. Každá by mala skončiť v inom, predvídateľnom stave, a hranica medzi prvými dvoma je celý dôvod na výber hodnoty.

Držte kontroly obrátené von, pretože tabuľka procesov sama o sebe dokazuje veľmi málo. Sledujte, či pid zostáva stabilný počas krátkeho prerušenia, a potom potvrďte, že po dlhom zmizol a bol raz nahradený:

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

Počas krátkeho prerušenia potvrďte, že klient skutočne skúsil znova, a nie že odišiel skoro, a že trasy a položky resolvera sa vrátili bez duplikátov. Pre dlhší výpadok potvrďte čistý výstup a presne jeden reštart po ňom. Pri zlyhaní overenia potvrďte, že klient sa netočí proti bráne, ktorá ho bude ďalej odmietať. Pridajte kontrolu, že pid sa vracia k jednej hodnote, a nie sa hromadí.

Pri úmyselnom zastavení má URL zdravia zostať nedostupná a proces má zostať zastavený. Potom uzavrite slučku zo strany aplikácie: tá istá požiadavka musí zlyhať, kým tunel chýba, a musí uspieť po jeho návrate, zo zdrojovej adresy, ktorú očakáva vaša politika. Zelená ikona tunela nie je dôkaz, ale dokončená požiadavka áno.