Jak dlouho má OpenConnect zkoušet znovu připojení k přerušené VPN?

--reconnect-timeout odpovídá na jednu úzkou otázku: poté co tunel spadne, jak dlouho tento klientský proces zkouší dál, než to vzdá a ukončí se. Stránka manuálu OpenConnect zaznamenává tuto volbu s dokumentovanou výchozí hodnotou 300 sekund pro opakované pokusy po ztraceném spoji nebo protějšku, který přestal odpovídat, a číslo je lhůta pro jeden běžící klient, nikoli důkaz, že VPN zůstává dostupná. Není to ani zásada pro udržování procesu naživu, a právě tam začíná většina zmatku.

Zmatek se násobí, jakmile je navrchu druhý mechanismus. Dohled, který klienta restartuje, sonda, která pingá bránu, a vestavěné okno opakovaných pokusů mohou všichni reagovat na jednu poruchu a incident pak vydá tři časové osy, které nikdo nedokáže sladit.

Co okno opětovného připojení skutečně omezuje

Představte si, že přístupová síť na několik sekund zmizí. Klient vidí, že spoj padl, nebo přestane slyšet odpovědi mrtvého protějšku a začne znovu navazovat relaci, přičemž si drží, co může. Pokusy pokračují, dokud brána znovu nepřijme nebo dokud okno nevyprší, a vypršené okno končí nenulovým návratovým kódem. Právě v tomto ukončení, a ne v hodnotě limitu, přechází vlastnictví životního cyklu na toho, kdo proces dohlíží.

Okno nic neříká o tom, jak často se sonda spouští, a nedokáže prodloužit ověřování. Pokud brána relaci zrušila nebo účet nyní vyžaduje nový druhý faktor, delší čekání starou relaci znovu platnou neudělá. Opakovaný pokus uspěje jen tehdy, když se cesta vrátí, brána relaci stále rozpoznává a požadované přihlašovací údaje zůstanou použitelné, takže čtěte číslo jako lhůtu, nikoli jako interval životnosti.

Okno také neřídí, co aplikace dělají, dokud běží. V závislosti na platformě a na tom, jak daleko porucha došla, se klient může znovu připojovat se stále nainstalovanými trasami, nebo poté, co byly staženy. Proto požadavek vydaný uprostřed výpadku obvykle visí až do vypršení limitu, místo aby rychle selhal.

Restartování dohledem a opakované pokusy klienta jsou dvě vrstvy

Nechte běžícího klienta utratit jeho vlastní okno a nechte správce služeb reagovat na ukončení. Klient v popředí pod systemd s politikou restartu dává přesně toto rozdělení: pokusy po omezenou dobu, pak jedno rozhodnutí o restartu. Výsledkem je jediná časová osa, kterou lze dodatečně rekonstruovat.

Klient na pozadí plus nezávislá sonda, která spustí další kopii, když nevidí rozhraní, je vzor, který se pokazí. Oba procesy pak soupeří o stejný uzel zařízení, trasy a nastavení resolveru. Pokud přesto chcete démona, dejte volbu na příkazový řádek, se kterým klient skutečně startuje:

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

Dva detaily na tom řádku mají váhu. --background odpoutá proces, takže soubor pid se stává jediným spolehlivým držadlem na něj, a limit se utrácí jen dokud tentýž proces žije; dohled, který ho zabije, nenechá žádný rozpočet na pokračování.

Záměrná odpojení potřebují vlastní signál. Plánovaná pauza a skutečný výpadek vypadají pro naivního pozorovatele stejně, obojí se čte jako „nepřipojeno“. Veďte pauzu přes operaci zastavení dohledu nebo přes značku, které obal rozumí, aby úmyslné zastavení nespustilo restart, o který nikdo nežádal.

Jak zabránit tomu, aby předání předběhlo smyčku pokusů

Bezobslužné zotavení závisí na údajích, které se obnovují bez přítomnosti člověka. Klíčenka, která se odemyká jen v interaktivní relaci plochy, nebo token, který vždy vyžaduje napsaný kód, nechá klienta uvíznout ve fázi ověřování, jakmile se cesta vrátí. Vyřešte tento postup dřív, než okno prodloužíte, protože delší okno jen dává stejné zablokované výzvě více času selhat.

Ověřování serveru se nesmí uvolňovat, aby ubylo výzev. Právě pin nebo kotva důvěry, která validuje bránu, dělá automatické opětovné připojení bezpečným, a vypnutí kvůli vyhnutí se dotazu na certifikát mění viditelné přerušení za neviditelné. Zachovejte ověřenou identitu a raději opravte výzvu; klient ochotný připojit se k jakékoli bráně je horší než ten, který se zastaví a čeká.

Přítomnost rozhraní také není signálem zdraví. Tunelové zařízení může existovat s mrtvou relací za sebou a spouštěcí proces může existovat bez jakéhokoli tunelu. Žádné z těchto pozorování neobstojí u skutečného požadavku. Zdraví musí vycházet z toho, co uživatel potřebuje, například z požadavku, který prochází tunelem k známé interní službě.

Co ověřit během výpadku a po něm

Proveďte čtyři události jako samostatné testy: přerušení kratší než okno, výpadek delší než ono, selhání ověření a úmyslné zastavení. Každá by měla skončit v jiném, předvídatelném stavu a hranice mezi prvními dvěma je celý důvod pro volbu hodnoty.

Držte kontroly obrácené ven, protože tabulka procesů sama o sobě dokazuje velmi málo. Sledujte, zda pid během krátkého výpadku drží stabilně, a poté potvrďte, že po dlouhém zmizel a byl jednou nahrazen:

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

Během krátkého přerušení potvrďte, že klient skutečně zkusil znovu, místo aby předčasně skončil, a že se trasy a položky resolveru vrátily bez duplikátů. U delšího výpadku potvrďte čisté ukončení a přesně jeden restart po něm. U selhání ověření potvrďte, že se klient netočí proti bráně, která ho bude dál odmítat. Přidejte kontrolu, že se pid vrací k jedné hodnotě, místo aby se hromadil.

U úmyslného zastavení má zdravotní URL zůstat nedostupná a proces má zůstat zastavený. Poté uzavřete smyčku ze strany aplikace: stejný požadavek musí selhat, dokud tunel chybí, a musí uspět po jeho návratu, ze zdrojové adresy, kterou vaše zásada očekává. Zelená ikona tunelu není důkaz, ale dokončený požadavek ano.