Kor lenge bør OpenConnect halde fram med å prøve på ein broten VPN?

--reconnect-timeout svarar på eitt smalt spørsmål: etter at tunnelen fell, kor lenge held denne klientprosessen fram med å prøve før han gir opp og avsluttar. Manualsida til OpenConnect fører opp dette alternativet med ein dokumentert standard på 300 sekund for nye forsøk som følgjer ei tapt lenkje eller ein peer som har slutta å svare, og talet er ein frist for éin køyrande klient, ikkje eit prov på at VPN-en blir verande tilgjengeleg. Det er heller ikkje ein politikk for å halde prosessen i live, og det er der mesteparten av forvirringa byrjar.

Forvirringa aukar når ein annan mekanisme sit oppå. Ein supervisor som startar klienten på nytt, ein probar som pingar gatewayen, og det innebygde vindauget for nye forsøk kan alle reagere på éin feil, og hendinga gir då tre tidslinjer som ingen kan sameine.

Kva attilkoplingsvindauget faktisk avgrensar

Tenk deg at tilgangsnettet forsvinn i nokre sekund. Klienten ser at lenkja fell, eller sluttar å høyre svar frå den døde peer-en, og byrjar å gjenopprette økta medan han held på så mykje tilstand han kan. Forsøka held fram til gatewayen godtar igjen eller vindauget går ut, og eit vindauge som går ut endar i ein utgang som ikkje er null. Det er den utgangen, ikkje tidsavgrensinga, som er staden der eigarskapet til livssyklusen blir overført til den som overvakar prosessen.

Vindauget seier ingenting om kor ofte ein probar blir køyrd, og det kan ikkje forlengje autentiseringa. Viss gatewayen har trekt tilbake økta, eller kontoen no krev ein fersk andre faktor, vil lengre venting ikkje gjere den gamle økta gyldig igjen. Eit nytt forsøk lukkast berre når banen kjem tilbake, gatewayen framleis kjenner igjen økta, og påloggingsinformasjonen han ber om blir verande brukbar, så les talet som ein frist og ikkje som eit levetidsintervall.

Vindauget styrer heller ikkje kva program gjer medan det går. Avhengig av plattformen og kor langt feilen kom, kan klienten kople til på nytt med rutene framleis installerte, eller etter at dei vart fjerna. Det er grunnen til at ein førespurnad som blir send midt i ei avbryting, heng til tidsavgrensinga i staden for å feile raskt.

Supervisor-restartar og klientforsøk er to lag

Lat den køyrande klienten bruke sitt eige vindauge, og lat tenestebehandlaren reagere på utgangen. Ein klient i forgrunnen under systemd med ein restartpolitikk gir nøyaktig den delinga: forsøk i ein avgrensa periode, deretter éi restartavgjerd. Resultatet er éi tidslinje du framleis kan rekonstruere etterpå.

Ein klient i bakgrunnen pluss ein uavhengig pollar som startar ein ny kopi når han ikkje ser eit grensesnitt, er mønsteret som går gale. Då kjempar begge prosessane om den same eininga, rutene og resolver-innstillingane. Viss du verkeleg vil ha ein daemon, set alternativet på kommandolinja klienten faktisk startar med:

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

To detaljar på den linja veg tungt. --background loyser prosessen, så pid-fila blir det einaste pålitelege handtaket på han, og tidsavgrensinga blir berre brukt så lenge den same prosessen lever; ein supervisor som drep han, lèt ikkje att noko budsjett for å halde fram.

Tilsikta fråkoplingar treng sitt eige signal. Ein planlagd pause og ei ekte avbryting ser like ut for ein naiv observatør, og begge blir lesne som «ikkje tilkopla». Styr pausen gjennom stoppoperasjonen til supervisoren, eller ein markør som innpakkinga forstår, slik at ein medviten stans ikkje utløyser ein restart ingen bad om.

Unngå at overleveringa kappast med forsøksløkka

Uovervaka gjenoppretting er avhengig av påloggingsinformasjon som blir fornya utan ein person til stades. Ei nøkkelring som berre blir låst opp i ei interaktiv skrivebordsøkt, eller eit token som alltid krev ein innskriven kode, vil strande klienten på autentiseringstrinnet når banen er tilbake. Rydd opp i den arbeidsflyten før du forlengjer vindauget, for eit lengre vindauge gir berre den same blokkerte førespurnaden meir tid til å feile.

Serververifisering bør ikkje lempast på for å redusere førespurnader. Det er nettopp pinninga eller tillitsankeret som validerer gatewayen som gjer ein automatisk attilkopling trygg, og å slå det av for å unngå eit sertifikatspørsmål byter ei synleg avbryting mot ei usynleg. Hald på den verifiserte identiteten og reparer førespurnaden i staden; ein klient som er villig til å kople til kva gateway som helst, er verre enn ein som stoppar og ventar.

Tilstadeveringa av eit grensesnitt er heller ikkje eit sunnheitssignal. Ei tunneleining kan eksistere med ei død økt bak seg, og ein oppstartsprosess kan eksistere heilt utan tunnel. Ingen av desse observasjonane toler ein ekte førespurnad. Helse må kome frå det brukaren treng, til dømes ein førespurnad som går gjennom tunnelen til ein kjend intern teneste.

Kva som skal verifiserast under og etter ei avbryting

Køyr fire hendingar som separate testar: ei avbryting kortare enn vindauget, eit avbrot lengre enn det, ein autentiseringsfeil og ein medviten stans. Kvar bør ende i ein annan, føreseieleg tilstand, og grensa mellom dei to første er heile grunnen til å velje ein verdi.

Hald kontrollane utovervendte, fordi prosesstabellen beviser svært lite på eiga hand. Sjå om pid-en held seg stabil gjennom den korte avbrytinga, og stadfest deretter at han er borte og erstatta éin gong etter den 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 den korte avbrytinga, stadfest at klienten verkeleg prøvde på nytt i staden for å avslutte tidleg, og at ruter og resolver-oppføringar kom tilbake utan duplikat. For det lengre avbrotet, stadfest ein rein utgang og nøyaktig éin restart etterpå. For autentiseringsfeilen, stadfest at klienten ikkje snurrar mot ein gateway som vil halde fram med å avvise han. Legg til ein kontroll på at pid-en går tilbake til éin verdi i staden for å hope seg opp.

For den medvitne stansen bør helse-URL-en bli verande utilgjengeleg og prosessen bli verande nede. Lukk deretter løkka frå programsida: den same førespurnaden må feile medan tunnelen er borte og må lukkast etter at han kjem tilbake, frå kjeldeadressa politikken din ventar. Eit grønt tunnelikon er ikkje bevis, men ein fullført førespurnad er det.