Hoelang moat OpenConnect in ferbrutsen VPN besykje te ferbinen?

--reconnect-timeout beantwurdet ien smelle fraach: nei’t de tunnel falt, hoelang besiket dit kliïntproses noch foar’t it opjout en ôfslút. De hânliedingside fan OpenConnect registrearret dy opsje mei in dokumintearre standert fan 300 sekonden foar nije besykjen dy’t folgje op in ferlern keppeling of in partner dy’t ophâlden is te antwurdzjen, en it getal is in deadline foar ien rinnende kliïnt, gjin bewiis dat de VPN berikber bliuwt. It is ek gjin belied om it proses libben te hâlden, en dêr begjint it measte betizing.

De betizing groeit as der in twadde meganisme boppe-op sit. In supervisor dy’t de kliïnt op ’e nij start, in probearder dy’t de gateway pingt, en it ynboude werbesykfester kinne allegear op ien flater reagearje, en it ynsidint jout dan trije tiidlinen dy’t nimmen ferienigje kin.

Wat it werferbiningfester eins beheint

Stel jo foar dat it tagongsnetwurk in pear sekonden ferdwynt. De kliïnt sjocht de keppeling falle, of hâldt op mei it hearren fan antwurden fan ’e deade partner, en begjint de sesje op ’e nij op te bouwen wylst er hâldt wat er kin. De besykjen geane troch oant de gateway wer akseptearret of it fester ôfrûn is, en in fester dat ôfrûn is einiget yn in útgong dy’t net nul is. Dy útgong, net de timeoutwearde, is dêr’t it eigendom fan ’e libbenssyklus oergiet nei wa’t it proses ek bewaket.

It fester seit neat oer hoe faak in probe rint, en it kin de autentikaasje net ferlingje. As de gateway de sesje ynlutsen hat, of it akkount freget no in farske twadde faktor, sil langer wachtsjen de âlde sesje net wer jildich meitsje. In nij besykjen slagget allinnich as it paad weromkomt, de gateway de sesje noch ken, en de frege oanmeldgegevens brûkber bliuwe, lês it getal dus as in deadline en net as in libbensduorinterval.

It fester regelet ek net wat applikaasjes dogge wylst it rint. Ofhinklik fan it platfoarm en fan hoe fier de flater kaam, kin de kliïnt wer ferbine mei rûtes dy’t noch ynstallearre binne, of nei’t se fuorthelle binne. Dêrom hinget in fersyk dat midden yn in ûnderbrekking útfierd wurdt, oant it timeout, ynstee fan fluch te mislearjen.

Supervisor-opnijstarts en kliïntwerbesykjen binne twa lagen

Lit de rinnende kliïnt syn eigen fester besteegje, en lit de tsjinstbehearder op ’e útgong reagearje. In kliïnt op ’e foargrûn ûnder systemd mei in opnijstartbelied jout krekt dy splitsing: besykjen foar in beheinde perioade, dan ien opnijstartbeslút. It resultaat is ien tiidline dy’t jo letter noch rekonstruearje kinne.

In kliïnt op ’e eftergrûn plus in ûnôfhinklike poller dy’t in oare kopy start as er gjin ynterface sjocht, is it patroan dat ferkeard giet. Dan stride beide prosessen om deselde apparaatknoop, rûtes en resolver-ynstellingen. As jo echt in daemon wolle, set de opsje op ’e kommandorigel dêr’t de kliïnt eins mei start:

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

Twa details yn dy rigel weagje. --background makket it proses los, sadat it pid-bestân de iennichste betroubere greep dêrop wurdt, en de timeout wurdt allinnich bestege salang dat itselde proses libbet; in supervisor dy’t it deatet, lit gjin budzjet oer om mei troch te gean.

Opsetlike ôfbrekkings hawwe har eigen sinjaal nedich. In plande pauze en in echte ûnderbrekking lykje itselde foar in naïve waarnimmer, beide lêze as „net ferbûn”. Stjoer de pauze oan fia de stopoperaasje fan ’e supervisor, of in marker dy’t de wrapper begrypt, sadat in bewust stilstân gjin opnijstart útlokket dy’t nimmen frege hat.

Foarkomme dat de oerdracht de werbesyk-loop foarbyrint

Unbewekke weromkear hinget ôf fan oanmeldgegevens dy’t fernije sûnder dat der in persoan by is. In kaairing dy’t allinnich yn in ynteraktive buroblêdsesje iepengiet, of in token dat altyd in yntype koad nedich hat, sil de kliïnt by de autentikaasjefaze strâne litte sadree’t it paad werom is. Los dy wurkstream op foar’t jo it fester ferlingje, want in langer fester jout allinnich deselde blokkearre fraach mear tiid om te mislearjen.

Serverferifikaasje moat net fersloppe wurde om fragen te ferminderjen. Krekt it pinjen of it fertrouwensanker dat de gateway falidearret, makket in automatyske werferbining feilich, en it útskeakeljen dêrfan om in sertifikaatfraach te foarkommen ruilet in sichtbere ûnderbrekking foar in ûnsichtbere. Hâld de ferifiearre identiteit en reparearje leaver de fraach; in kliïnt dy’t ree is om mei elke gateway te ferbinen is slimmer as ien dy’t stilstiet en wachtet.

Ek de oanwêzigens fan in ynterface is gjin sûnenssinjaal. In tunnelapparaat kin bestean mei in deade sesje dêrefter, en in lansearproses kin bestean sûnder hokker tunnel dan ek. Gjin fan dy waarnimmings hâldt in echt fersyk út. Sûnens moat komme fan wat de brûker nedich hat, lykas in fersyk dat troch de tunnel nei in bekende ynterne tsjinst giet.

Wat te ferifiearjen ûnder en nei in ûnderbrekking

Run fjouwer barrens as aparte tests: in ûnderbrekking koarter as it fester, in ûnderbrekking langer as dat, in autentikaasjeflater en in bewust stilstân. Elk moat einigje yn in oare, foarsisbere steat, en de grins tusken de earste twa is de hiele reden om in wearde te kiezen.

Hâld de kontrôles nei bûten rjochte, want de prosestabel bewiist op himsels hiel lyts bytsje. Sjoch dat de pid stabyl bliuwt troch de koarte ûnderbrekking, en befêstigje dan dat er fuort is en ien kear ferfongen nei de lange:

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

Under de koarte ûnderbrekking, befêstigje dat de kliïnt echt op ’e nij besocht hat ynstee fan betiid ôf te sluten, en dat rûtes en resolver-ynfieringen sûnder duplikaten weromkamen. Foar de langere ûnderbrekking, befêstigje in skjinne útgong en krekt ien opnijstart dêrnei. Foar de autentikaasjeflater, befêstigje dat de kliïnt net draait tsjin in gateway dy’t him bliuwt wegerjen. Foegje in kontrôle ta dat de pid weromkomt nei ien wearde ynstee fan op te heapjen.

Foar it bewuste stilstân moat de sûnens-URL ûnberikber bliuwe en it proses del bliuwe. Slút dan de loop fan ’e applikaasjekant: itselde fersyk moat mislearje wylst de tunnel fuort is en moat slagje nei’t er weromkomt, fan it boarneadres dat jo belied ferwachtet. In grien tunnelikoan is gjin bewiis, mar in foltôge fersyk is dat wol.