Wéi laang soll OpenConnect eng ofgebrach VPN weider versichen?

--reconnect-timeout äntwert op eng schmuel Fro: nodeems den Tunnel fällt, wéi laang probéiert dëse Client-Prozess weider, ier en opgëtt an erausgeet. D'Handbuchsäit vun OpenConnect registréiert déi Optioun mat engem dokumentéierte Standard vun 300 Sekonnen fir Wiederhuelungen, déi op e verluerene Link oder e Peer folgen, dee opgehalen huet ze äntweren, an d'Zuel ass eng Frist fir ee lafende Client, keen Beweis, datt d'VPN erreechbar bleift. Et ass och keng Politik, de Prozess lieweg ze halen, an do fänkt de gréissten Deel vun der Duercherneen un.

D'Duercherneen wächst, soubal en zweete Mechanismus drop sëtzt. En Iwwerwaacher, deen de Client nei start, en Tester, deen de Gateway pingt, an d'agebaut Wiederhuelungsfënster kënnen alleguer op ee Fehler reagéieren, an den Tëschefall gëtt dann dräi Zäitlinnen, déi keen zesummebréngen kann.

Wat d'Reconnect-Fënster tatsächlech begrenzt

Stellt Iech vir, den Access-Netzwierk verschwënnt fir e puer Sekonnen. De Client gesäit de Link falen, oder hält op, Äntwerten vum doudege Peer ze héieren, a fänkt un, d'Sessioun nei opzebauen, andeems en de Staat hält, deen en kann. D'Wiederhuelunge ginn weider, bis de Gateway erëm akzeptéiert oder d'Fënster eriwwer ass, an eng Fënster, déi eriwwer ass, ennt mat engem Ausgang deen net null ass. Dee Ausgang, net de Timeout-Wäert, ass d'Plaz, wou d'Eegentum um Liewenszyklus op dejenegen iwwergeet, deen de Prozess iwwerwaacht.

D'Fënster seet näischt doriwwer, wéi dacks en Test leeft, an et kann d'Authentifikatioun net verlängeren. Wann de Gateway d'Sessioun zréckgezunn huet, oder d'Konto elo en neien zweete Faktor verlaangt, da mécht méi Laang waarden déi al Sessioun net erëm gülteg. Eng Wiederhuelung klappt nëmme wann de Wee zréckkënnt, de Gateway d'Sessioun nach erkennt an déi gefrote Identitéitsdaten benotzbar bleiwen, also liest d'Zuel als Frist an net als Liewensdauerintervall.

D'Fënster reegelt och net, wat d'Applikatiounen maachen, wärend se leeft. Ofhängeg vun der Plattform a wéi wäit de Fehler komm ass, kann de Client sech nei verbannen, wärend d'Route nach installéiert sinn, oder nodeems se erofgeholl goufen. Dofir hänkt eng Ufro, déi mëttlerweil vun enger Ënnerbriechung gestallt gëtt, bis zum Timeout, amplaz séier ze scheiteren.

Iwwerwaacher-Neistarts an Client-Wiederhuelunge sinn zwou Schichten

Loosst de lafende Client seng eege Fënster verbrauchen, an loosst de Servicemanager op den Ausgang reagéieren. En Client am Virdergrond ënner systemd mat enger Neistartspolitik gëtt genee déi Deelung: Wiederhuelunge fir eng begrenzt Period, duerno eng eenzeg Neistartsentscheedung. D'Resultat ass eng eenzeg Zäitlinn, déi Dir duerno nach rekonstruéiere kënnt.

En Client am Hannergrond plus en onofhängege Poller, deen eng aner Kopie start, wann en keng Interface gesäit, ass de Muster, dee schief geet. Dann streiden déi zwee Prozesser ëm dee selwechten Apparatknoten, d'Routen an d'Resolver-Astellungen. Wann Dir wierklech en Daemon wëllt, setzt d'Optioun op d'Kommandozeil, mat där de Client tatsächlech start:

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

Zwee Detailer an där Zeil weien. --background trennt de Prozess of, sou datt d'pid-Datei deen eenzegen zouverlässegen Halt dodrës gëtt, an den Timeout gëtt nëmme verbraucht, soulaang dee selwechte Prozess lieft; en Iwwerwaacher, deen en ëmbréngt, léisst kee Budget fir weiderzemaachen.

Absichtlech Trenne brauchen hire eege Signal. Eng geplangte Paus an en echte Fehler gesinn gläich aus fir en naive Beobachter, béid ginn als „net verbonnen" gelies. Steiert d'Paus iwwer d'Stopoperatioun vum Iwwerwaacher, oder iwwer eng Markéierung, déi de Wrapper versteet, sou datt en absichtlechen Halt keen Neistart ausléist, deen keen gefrot huet.

Verhënneren, datt d'Iwwergab mam Wiederhuelungszyklus wetteifert

Onbewaacht Erhuelung hänkt vun Identitéitsdaten of, déi sech ouni eng Persoun present erneieren. E Schlësselrank, deen nëmmen an enger interaktiver Desktop-Sessioun opgeet, oder en Token, deen ëmmer en agetippte Code verlaangt, wäert de Client an der Authentifikatiounsphas hänken, soubal de Wee zréck ass. Kläert dee Workflow, ier Dir d'Fënster verlängert, well eng méi laang Fënster gëtt nëmme vun der selwechter blockéierter Ufro méi Zäit fir ze scheiteren.

D'Serververifikatioun soll net geluecht ginn, fir Ufroen ze reduzéieren. Genee d'Pinne oder de Vertrauensanker, deen de Gateway validéiert, mécht en automatesche Reconnect sécher, an en auszeschalten, fir eng Zertifikatsfro ze vermeiden, tauscht eng sichtbar Ënnerbriechung géint eng onsichtbar. Hält d'verifizéiert Identitéit a fléckt amplaz d'Ufro; en Client, dee bereet ass, sech mat engem Gateway ze verbannen, ass méi schlëmm wéi enen, deen ophält an waart.

D'Präsenz vun enger Interface ass och kee Gesondheetssignal. En Tunnelapparat kann existéieren mat enger doudeger Sessioun hannendrun, an e Startprozess kann existéieren ouni iergendeen Tunnel. Keng vun dësen Observatiounen hält enger echter Ufro stand. Gesondheet muss aus deem kommen, wat de Benotzer brauch, zum Beispill eng Ufro, déi duerch den Tunnel an en bekannten internen Service geet.

Wat wärend an no enger Ënnerbriechung ze verifiéieren ass

Féiert véier Evenementer als getrennte Tester aus: eng Ënnerbriechung méi kuerz wéi d'Fënster, en Ausfall méi laang wéi se, en Authentifikatiounsfehler an en absichtlechen Halt. Jiddwereen soll an engem aneren, viraussiichtlechen Zoustand ophalen, an d'Grenz tëscht den éischten zwee ass de ganzen Grond fir e Wäert ze wielen.

Hält d'Kontrollen no baussen geriicht, well d'Prozesstabel eleng ganz wéineg beweist. Kuckt, ob d'pid duerch de kuerzen Ausfall stabil bleift, a bestätegt dann, datt se nom laangen fort an eng Kéier ersat ass:

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

Wärend der kuerzer Ënnerbriechung bestätegt, datt de Client wierklech nach eng Kéier probéiert huet amplaz fréi erauszegoen, an datt d'Routen an d'Resolver-Andräg ouni Duplikater zréckkoumen. Fir den Ausfall méi laang, bestätegt en proppere Ausgang an genau ee Neistart duerno. Fir den Authentifikatiounsfehler, bestätegt, datt de Client net géint en Gateway dréint, deen en weider ofleent. Füügt eng Kontroll derbäi, datt d'pid zréck op ee Wäert kënnt amplaz sech ze stapelen.

Fir den absichtlechen Halt soll d'Gesondheets-URL onerreechbar bleiwen an de Prozess soll ënnen bleiwen. Da schléisst d'Schleef vun der Applikatiounssäit: déi selwecht Ufro muss feelen, wärend den Tunnel fort ass, a muss no senger Réckkoum geléngen, vun der Quelladress, déi Är Politik erwaart. E gréngen Tunnel-Ikon ass keen Beweis, awer eng ofgeschlossen Ufro ass et.