Hvor længe skal OpenConnect blive ved med at forsøge på en afbrudt VPN?

--reconnect-timeout besvarer ét snævert spørgsmål: når tunnelen falder, hvor længe bliver denne klientproces så ved med at forsøge, før den giver op og afslutter. OpenConnects manualside noterer den valgmulighed med en dokumenteret standard på 300 sekunder for nye forsøg efter et tabt link eller en peer, der er holdt op med at svare, og tallet er en tidsfrist for én kørende klient, ikke et bevis for, at VPN’et forbliver tilgængeligt. Det er heller ikke en politik for at holde processen i live, og det er her, størstedelen af forvirringen begynder.

Forvirringen vokser, når en anden mekanisme sidder ovenpå. En supervisor, der genstarter klienten, en prober, der pinger gatewayen, og det indbyggede genforsøgsvindue kan alle reagere på én fejl, og hændelsen giver derefter tre tidslinjer, som ingen kan forene.

Hvad genopkoblingsvinduet egentlig begrænser

Forestil dig, at adgangsnettet forsvinder i et par sekunder. Klienten ser linket falde, eller holder op med at høre svar fra den døde peer, og begynder at genoprette sessionen, mens den holder på det, den kan. Forsøgene fortsætter, indtil gatewayen accepterer igen, eller vinduet løber ud, og et vindue, der løber ud, ender med en ikke-nul-exit. Det er den exit, snarere end timeoutværdien, hvor ejerskabet til livscyklussen overgår til den, der overvåger processen.

Vinduet siger intet om, hvor ofte en sonde kører, og det kan ikke forlænge godkendelsen. Hvis gatewayen har tilbagekaldt sessionen, eller kontoen nu kræver en frisk anden faktor, vil mere ventetid ikke gøre den gamle session gyldig igen. Et nyt forsøg lykkes kun, når forbindelsen vender tilbage, gatewayen stadig genkender sessionen, og de legitimationsoplysninger, den beder om, forbliver brugbare, så læs tallet som en tidsfrist og ikke som et levetidsinterval.

Vinduet styrer heller ikke, hvad applikationer gør, mens det løber. Afhængigt af platformen og af, hvor langt fejlen nåede, kan klienten genopkoble med ruter, der stadig er installeret, eller efter at de er blevet fjernet. Det er derfor, en anmodning, der sendes midt i en afbrydelse, har tendens til at hænge, indtil den timer ud, i stedet for at fejle hurtigt.

Supervisor-genstarter og klientgenforsøg er to lag

Lad den kørende klient bruge sit eget vindue, og lad servicemanageren reagere på exiten. En klient i forgrunden under systemd med en genstartspolitik giver præcis den opdeling: forsøg i en begrænset periode, derefter én genstartsbeslutning. Resultatet er en enkelt tidslinje, som du stadig kan rekonstruere bagefter.

En klient i baggrunden plus en uafhængig poller, der starter en ny kopi, når den ikke kan se en grænseflade, er det mønster, der går galt. Så kæmper begge processer om den samme enhedsnoden, ruter og resolverindstillinger. Hvis du virkelig vil have en daemon, så sæt valgmuligheden på den kommandolinje, klienten faktisk starter med:

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

To detaljer i den linje vejer tungt. --background løsriver processen, så pid-filen bliver det eneste pålidelige håndtag til den, og timeouten bruges kun, så længe netop den proces lever; en supervisor, der dræber den, efterlader ingen budget til at fortsætte.

Tilsigtede afbrydelser har brug for deres eget signal. En planlagt pause og en rigtig afbrydelse ser ens ud for en naiv iagttager, og begge læses som „ikke forbundet”. Styr pausen gennem supervisorens stopoperation eller en markør, som wrapperen forstår, så et bevidst stop ikke udløser en genstart, som ingen bad om.

Sådan undgår du, at overdragelsen overhaler genforsøgsløkken

Uovervåget gendannelse afhænger af legitimationsoplysninger, der fornyes uden en person til stede. En nøglering, der kun låses op i en interaktiv skrivebordssession, eller et token, der altid kræver en indtastet kode, vil strande klienten på godkendelsestrinet, når forbindelsen er tilbage. Få den arbejdsgang på plads, før du forlænger vinduet, for et længere vindue giver kun den samme blokerede prompt mere tid til at fejle.

Serververifikation bør ikke lempes for at reducere prompter. Det pin eller den tillidsanker, der validerer gatewayen, er det, der gør en automatisk genopkobling sikker, og at deaktivere det for at undgå et certifikatspørgsmål bytter en synlig afbrydelse for en usynlig. Behold den verificerede identitet, og reparer i stedet prompten; en klient, der er villig til at forbinde til enhver gateway, er værre end en, der stopper og venter.

Tilstedeværelsen af en grænseflade er heller ikke et sundhedssignal. En tunneleenhed kan eksistere med en død session bag sig, og en launcherproces kan eksistere helt uden en tunnel. Ingen af de observationer holder til en rigtig anmodning. Sundhed skal komme fra det, brugeren har brug for, såsom en anmodning, der går gennem tunnelen til en kendt intern tjeneste.

Hvad du skal verificere under og efter en afbrydelse

Kør fire hændelser som separate tests: en afbrydelse kortere end vinduet, en afbrydelse længere end det, en godkendelsesfejl og et bevidst stop. Hver bør ende i en forskellig, forudsigelig tilstand, og grænsen mellem de to første er hele grunden til at vælge en værdi.

Hold kontrollerne udadvendte, fordi procestabellen beviser meget lidt på egen hånd. Se, om pid’en holder sig stabil gennem den korte afbrydelse, og bekræft derefter, at den er væk og erstattet én gang efter 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)"

Bekræft under den korte afbrydelse, at klienten virkelig forsøgte igen i stedet for at afslutte tidligt, og at ruter og resolverposter kom tilbage uden dubletter. For den længere afbrydelse skal du bekræfte en ren exit og præcis én genstart bagefter. For godkendelsesfejlen skal du bekræfte, at klienten ikke snurrer mod en gateway, der bliver ved med at afvise den. Tilføj en kontrol af, at pid’en vender tilbage til én værdi i stedet for at hobe sig op.

For det bevidste stop bør sundheds-URL’en forblive utilgængelig, og processen bør blive nede. Luk derefter løkken fra applikationssiden: den samme anmodning skal fejle, mens tunnelen er væk, og skal lykkes, efter den vender tilbage, fra den kildeadresse, din politik forventer. Et grønt tunnelikon er ikke bevis, men en fuldført anmodning er.