Hvor lenge bør OpenConnect fortsette å prøve på en brutt VPN?

--reconnect-timeout svarer på ett smalt spørsmål: etter at tunnelen faller, hvor lenge denne klientprosessen fortsetter å prøve før den gir opp og avslutter. OpenConnects manualside fører opp dette alternativet med en dokumentert standard på 300 sekunder for nye forsøk som følger en tapt lenke eller en peer som har sluttet å svare, og tallet er en frist for én kjørende klient, ikke et bevis på at VPN-en forblir tilgjengelig. Det er heller ikke en policy for å holde prosessen i live, og det er der mesteparten av forvirringen begynner.

Forvirringen øker når en annen mekanisme sitter oppå. En supervisor som starter klienten på nytt, en prober som pinger gatewayen, og det innebygde vinduet for nye forsøk kan alle reagere på én feil, og hendelsen gir da tre tidslinjer som ingen kan forene.

Hva gjentilkoblingsvinduet faktisk begrenser

Tenk deg at tilgangsnettet forsvinner i noen sekunder. Klienten ser at lenken faller, eller slutter å høre svar fra den døde peer-en, og begynner å gjenopprette økten mens den holder på så mye tilstand den kan. Forsøkene fortsetter til gatewayen godtar igjen eller vinduet går ut, og et vindu som går ut ender i en utgang som ikke er null. Det er den utgangen, ikke tidsavbruddsverdien, som er stedet der eierskapet til livssyklusen overføres til den som overvåker prosessen.

Vinduet sier ingenting om hvor ofte en prober kjøres, og det kan ikke forlenge autentiseringen. Hvis gatewayen har tilbakekalt økten, eller kontoen nå krever en fersk andre faktor, vil lengre venting ikke gjøre den gamle økten gyldig igjen. Et nytt forsøk lykkes bare når banen kommer tilbake, gatewayen fortsatt kjenner igjen økten, og påloggingsinformasjonen den ber om forblir brukbar, så les tallet som en frist og ikke som et levetidsintervall.

Vinduet styrer heller ikke hva applikasjoner gjør mens det løper. Avhengig av plattformen og hvor langt feilen kom, kan klienten koble til på nytt med rutene fortsatt installert, eller etter at de ble fjernet. Det er derfor en forespørsel som sendes midt i en avbrytelse, henger til tidsavbruddet i stedet for å feile raskt.

Supervisor-restarter og klientens nye forsøk er to lag

La den kjørende klienten bruke sitt eget vindu, og la tjenestebehandleren reagere på utgangen. En klient i forgrunnen under systemd med en restartpolicy gir nøyaktig den delingen: forsøk i en begrenset periode, deretter én restartbeslutning. Resultatet er én tidslinje du fortsatt kan rekonstruere etterpå.

En klient i bakgrunnen pluss en uavhengig poller som starter en ny kopi når den ikke ser et grensesnitt, er mønsteret som går galt. Da konkurrerer begge prosessene om den samme enhetsnoden, rutene og resolver-innstillingene. Hvis du virkelig vil ha en daemon, sett alternativet på kommandolinjen klienten faktisk starter med:

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

To detaljer på den linjen veier tungt. --background løsriver prosessen, så pid-filen blir det eneste pålitelige håndtaket på den, og tidsavbruddet brukes bare så lenge den samme prosessen lever; en supervisor som dreper den, etterlater ingen budsjett for å fortsette.

Tilsiktede frakoblinger trenger sitt eget signal. En planlagt pause og en ekte avbrytelse ser like ut for en naiv observatør, og begge leses som «ikke tilkoblet». Styr pausen gjennom supervisorens stoppoperasjon, eller en markør som innpakningen forstår, slik at en bevisst stans ikke utløser en restart ingen ba om.

Unngå at overleveringen kappløper med forsøksløkken

Uovervåket gjenoppretting avhenger av påloggingsinformasjon som fornyes uten en person til stede. En nøkkelring som bare låses opp i en interaktiv skrivebordsøkt, eller et token som alltid krever en inntastet kode, vil strande klienten på autentiseringstrinnet når banen er tilbake. Rydd opp i den arbeidsflyten før du forlenger vinduet, for et lengre vindu gir bare den samme blokkerte forespørselen mer tid til å feile.

Serververifisering bør ikke lempes for å redusere forespørsler. Det er nettopp pinningen eller tillitsankeret som validerer gatewayen som gjør en automatisk gjentilkobling trygg, og å deaktivere det for å unngå et sertifikatspørsmål bytter en synlig avbrytelse mot en usynlig. Behold den verifiserte identiteten og reparer forespørselen i stedet; en klient som er villig til å koble til hvilken som helst gateway, er verre enn en som stopper og venter.

Tilstedeværelsen av et grensesnitt er heller ikke et sunnhetssignal. En tunneleenhet kan eksistere med en død økt bak seg, og en oppstartsprosess kan eksistere helt uten tunnel. Ingen av disse observasjonene tåler en ekte forespørsel. Helse må komme fra det brukeren trenger, for eksempel en forespørsel som går gjennom tunnelen til en kjent intern tjeneste.

Hva som skal verifiseres under og etter en avbrytelse

Kjør fire hendelser som separate tester: en avbrytelse kortere enn vinduet, en avbrudd lengre enn det, en autentiseringsfeil og en bevisst stans. Hver bør ende i en annen, forutsigbar tilstand, og grensen mellom de to første er hele grunnen til å velge en verdi.

Hold kontrollene utadvendte, fordi prosesstabellen beviser svært lite på egen hånd. Se om pid-en holder seg stabil gjennom den korte avbrytelsen, og bekreft deretter at den er borte og erstattet én gang 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 avbrytelsen, bekreft at klienten virkelig prøvde på nytt i stedet for å avslutte tidlig, og at ruter og resolver-oppføringer kom tilbake uten duplikater. For det lengre avbruddet, bekreft en ren utgang og nøyaktig én restart etterpå. For autentiseringsfeilen, bekreft at klienten ikke spinner mot en gateway som vil fortsette å avvise den. Legg til en kontroll på at pid-en går tilbake til én verdi i stedet for å hope seg opp.

For den bevisste stansen bør helse-URL-en forbli utilgjengelig og prosessen bli nede. Lukk deretter løkken fra applikasjonssiden: den samme forespørselen må feile mens tunnelen er borte og må lykkes etter at den kommer tilbake, fra kildeadressen policyen din forventer. Et grønt tunnelikon er ikke bevis, men en fullført forespørsel er det.