Hur länge ska OpenConnect fortsätta försöka med ett brutet VPN?

--reconnect-timeout svarar på en smal fråga: efter att tunneln faller, hur länge fortsätter den här klientprocessen att försöka innan den ger upp och avslutar. OpenConnects manualsida förtecknar det alternativet med en dokumenterad standard på 300 sekunder för nya försök som följer på en förlorad länk eller en peer som slutat svara, och talet är en deadline för en enda körande klient, inte ett bevis på att VPN:et förblir nåbart. Det är inte heller en policy för att hålla processen vid liv, och det är där merparten av förvirringen börjar.

Förvirringen ökar när en andra mekanism sitter ovanpå. En övervakare som startar om klienten, en probe som pingar gatewayen och det inbyggda fönstret för nya försök kan alla reagera på ett och samma fel, och incidenten ger då tre tidslinjer som ingen kan förena.

Vad återanslutningsfönstret faktiskt begränsar

Föreställ dig att åtkomstnätet försvinner i några sekunder. Klienten ser länken falla, eller slutar höra svar från den döda peeren, och börjar återupprätta sessionen medan den håller kvar så mycket tillstånd den kan. Försöken fortsätter tills gatewayen accepterar igen eller fönstret tar slut, och ett fönster som tar slut avslutas med en utgång som inte är noll. Det är den utgången, inte timeoutvärdet, som är platsen där ägarskapet för livscykeln går över till den som övervakar processen.

Fönstret säger ingenting om hur ofta en probe körs, och det kan inte förlänga autentiseringen. Om gatewayen har återkallat sessionen, eller kontot nu kräver en ny andra faktor, gör längre väntan inte den gamla sessionen giltig igen. Ett nytt försök lyckas bara när vägen kommer tillbaka, gatewayen fortfarande känner igen sessionen och inloggningsuppgifterna den begär förblir användbara, så läs talet som en deadline och inte som ett livskraftighetsintervall.

Fönstret styr inte heller vad applikationer gör medan det pågår. Beroende på plattformen och hur långt felet har gått kan klienten återansluta med rutterna fortfarande installerade, eller efter att de tagits bort. Det är därför en begäran som skickas mitt i ett avbrott tenderar att hänga till timeouten i stället för att misslyckas snabbt.

Övervakarens omstarter och klientens nya försök är två lager

Låt den körande klienten göra av med sitt eget fönster, och låt tjänstehanteraren reagera på utgången. En klient i förgrunden under systemd med en omstartspolicy ger exakt den uppdelningen: försök under en begränsad period, sedan ett enda omstartsbeslut. Resultatet är en enda tidslinje som du fortfarande kan rekonstruera efteråt.

En klient i bakgrunden plus en oberoende pollare som startar en annan kopia när den inte ser ett gränssnitt är mönstret som går fel. Då kämpar båda processerna om samma enhetsnod, rutter och resolverinställningar. Om du verkligen vill ha en daemon, sätt alternativet på den kommandorad som klienten faktiskt startar med:

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

Två detaljer på den raden väger tungt. --background kopplar loss processen, så pid-filen blir det enda pålitliga handtaget på den, och timeouten förbrukas bara så länge samma process lever; en övervakare som dödar den lämnar ingen budget för att fortsätta.

Avsiktliga frånkopplingar behöver sin egen signal. En planerad paus och ett verkligt avbrott ser likadana ut för en naiv betraktare, och båda läses som ”inte ansluten”. Styr pausen genom övervakarens stoppoperation, eller en markör som omslaget förstår, så att ett medvetet stopp inte utlöser en omstart som ingen bad om.

Undvika att överlämningen kör ikapp med försöksloopen

Obevakad återhämtning beror på inloggningsuppgifter som förnyas utan en närvarande person. En nyckelring som bara låses upp i en interaktiv skrivbordssession, eller en token som alltid kräver en inmatad kod, kommer att lämna klienten strandad i autentiseringsfasen när vägen är tillbaka. Rensa upp det arbetsflödet innan du förlänger fönstret, för ett längre fönster ger bara samma blockerade uppmaning mer tid att misslyckas.

Serververifieringen bör inte luckras upp för att minska uppmaningar. Det är just den pinnings- eller förtroendeankare som validerar gatewayen som gör en automatisk återanslutning säker, och att stänga av den för att undvika en certifikatfråga byter ett synligt avbrott mot ett osynligt. Behåll den verifierade identiteten och reparera uppmaningen i stället; en klient som är villig att ansluta till vilken gateway som helst är sämre än en som stannar och väntar.

Förekomsten av ett gränssnitt är inte heller en hälsosignal. En tunneleenhet kan finnas med en död session bakom sig, och en startprocess kan finnas helt utan tunnel. Ingen av dessa observationer står emot en verklig begäran. Hälsa måste komma från det användaren behöver, till exempel en begäran som går genom tunneln till en känd intern tjänst.

Vad som ska verifieras under och efter ett avbrott

Kör fyra händelser som separata tester: ett avbrott kortare än fönstret, ett avbrott längre än det, ett autentiseringsfel och ett medvetet stopp. Var och en bör sluta i ett annat, förutsägbart tillstånd, och gränsen mellan de två första är hela skälet till att välja ett värde.

Håll kontrollerna utåtriktade, eftersom processtabellen i sig bevisar väldigt lite. Titta på om pid:en håller sig stabil genom det korta avbrottet, och bekräfta sedan att den är borta och ersatt en gång efter det långa:

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 det korta avbrottet, bekräfta att klienten verkligen försökte igen i stället för att avsluta tidigt, och att rutter och resolverposter kom tillbaka utan dubbletter. För det längre avbrottet, bekräfta en ren utgång och exakt en omstart efteråt. För autentiseringsfelet, bekräfta att klienten inte snurrar mot en gateway som fortsätter att neka den. Lägg till en kontroll att pid:en återgår till ett enda värde i stället för att samlas på hög.

För det medvetna stoppet bör hälso-URL:en förbli onåbar och processen stanna nere. Stäng sedan loopen från applikationssidan: samma begäran måste misslyckas medan tunneln är borta och måste lyckas efter att den kommer tillbaka, från källadressen som din policy förväntar sig. En grön tunnelikon är inte bevis, men en slutförd begäran är det.