Koliko dugo OpenConnect treba ponavljati pokušaje za prekinuti VPN?

--reconnect-timeout odgovara na jedno usko pitanje: nakon što tunel padne, koliko dugo ovaj klijentski proces nastavlja pokušavati prije nego što odustane i izađe. Stranica priručnika za OpenConnect bilježi tu opciju s dokumentiranom zadanom vrijednošću od 300 sekundi za pokušaje koji slijede izgubljenu vezu ili partnera koji je prestao odgovarati, a broj je rok za jedan pokrenuti klijent, a ne dokaz da VPN ostaje dostupan. To također nije politika održavanja procesa na životu i tu počinje većina zabune.

Zabuna se pojačava kad se odozgo postavi drugi mehanizam. Nadzornik koji ponovno pokreće klijenta, ispitivač koji pinga pristupnik i ugrađeni prozor za ponovne pokušaje mogu svi reagirati na jedan kvar, a incident tada daje tri vremenske crte koje nitko ne može uskladiti.

Što prozor za ponovno povezivanje zapravo ograničava

Zamislite da pristupna mreža nestane na nekoliko sekundi. Klijent vidi pad veze ili prestane čuti odgovore mrtvog partnera i počne ponovno uspostavljati sesiju držeći ono stanje koje može. Pokušaji se nastavljaju dok pristupnik ponovno ne prihvati ili dok prozor ne istekne, a prozor koji istekne završava izlazom s nenultim kodom. Taj izlaz, a ne vrijednost tajmauta, mjesto je na kojem vlasništvo nad životnim ciklusom prelazi na onoga tko nadzire proces.

Prozor ne govori ništa o tome koliko se često izvodi ispitivanje i ne može produljiti autentifikaciju. Ako je pristupnik opozvao sesiju ili račun sada zahtijeva novi drugi faktor, dulje čekanje neće staru sesiju ponovno učiniti valjanom. Pokušaj uspijeva samo kad se put vrati, pristupnik još prepoznaje sesiju i traženi akreditivi ostanu upotrebljivi, pa čitajte broj kao rok, a ne kao interval živosti.

Prozor također ne upravlja time što aplikacije rade dok traje. Ovisno o platformi i o tome dokle je kvar stigao, klijent se može ponovno povezivati s rutama koje su još instalirane ili nakon što su povučene. Zato zahtjev izdan usred prekida obično visi do isteka tajmauta umjesto da brzo padne.

Ponovna pokretanja nadzornika i pokušaji klijenta dva su sloja

Neka pokrenuti klijent potroši vlastiti prozor, a upravitelj usluge neka reagira na izlaz. Klijent u prednjem planu pod systemd-om s politikom ponovnog pokretanja daje upravo tu podjelu: pokušaji na ograničeno razdoblje, zatim jedna odluka o ponovnom pokretanju. Rezultat je jedna vremenska crta koju još možete rekonstruirati.

Klijent u pozadini plus neovisni ispitivač koji pokreće drugu kopiju kad ne vidi sučelje jest uzorak koji pođe po zlu. Tada se oba procesa natječu za isti čvor uređaja, rute i postavke razrješivača. Ako baš želite demon, stavite opciju na naredbeni redak s kojim se klijent doista pokreće:

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

Dva detalja u tom retku nose težinu. --background odvaja proces, pa datoteka pid postaje jedina pouzdana ručka na njega, a tajmaut se troši samo dok taj isti proces živi; nadzornik koji ga ubije ne ostavlja proračun za nastavak.

Namjerna odspajanja trebaju vlastiti signal. Planirana pauza i stvarni prekid izgledaju jednako naivnom promatraču, oboje se čita kao „nije povezano”. Vodite pauzu preko nadzornikove operacije zaustavljanja ili markera koji omotač razumije, da namjerno zaustavljanje ne pokrene ponovno pokretanje koje nitko nije tražio.

Kako spriječiti da primopredaja pretekne petlju pokušaja

Nadzirani oporavak ovisi o akreditivima koji se obnavljaju bez prisutne osobe. Prsten ključeva koji se otključava samo unutar interaktivne sesije radne površine ili token koji uvijek traži upisan kod ostavit će klijenta na stupnju autentifikacije kad se put vrati. Riješite taj tijek rada prije produljenja prozora, jer dulji prozor samo daje istom blokiranom upitu više vremena da ne uspije.

Provjeru poslužitelja ne treba popuštati da bi se smanjilo upite. Upravo prikvačivanje ili sidro povjerenja koje provjerava pristupnik čini automatsko ponovno povezivanje sigurnim, a isključivanje radi izbjegavanja pitanja o certifikatu mijenja vidljiv prekid za nevidljiv. Zadržite provjereni identitet i radije popravite upit; klijent spreman povezati se s bilo kojim pristupnikom gori je od onoga koji stane i čeka.

Ni prisutnost sučelja nije signal zdravlja. Tunelski uređaj može postojati s mrtvom sesijom iza sebe, a pokretački proces može postojati bez ikakvog tunela. Nijedno od tih opažanja ne izdrži stvarni zahtjev. Zdravlje mora doći iz onoga što korisniku treba, primjerice zahtjeva koji prolazi kroz tunel do poznate interne usluge.

Što provjeriti tijekom i nakon prekida

Provedite četiri događaja kao odvojene testove: prekid kraći od prozora, prekid dulji od njega, neuspjeh autentifikacije i namjerno zaustavljanje. Svaki bi trebao završiti u drugom, predvidljivom stanju, a granica između prva dva cijeli je razlog za odabir vrijednosti.

Držite provjere okrenute prema van, jer tablica procesa sama po sebi dokazuje vrlo malo. Gledajte da pid ostane stabilan tijekom kratkog prekida, zatim potvrdite da je nestao i da je jednom zamijenjen nakon dugog:

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

Tijekom kratkog prekida potvrdite da je klijent doista pokušao ponovno, a ne izašao prerano, i da su se rute i unosi razrješivača vratili bez duplikata. Za dulji prekid potvrdite čist izlaz i točno jedno ponovno pokretanje nakon njega. Za neuspjeh autentifikacije potvrdite da se klijent ne vrti protiv pristupnika koji će ga nastaviti odbijati. Dodajte provjeru da se pid vraća na jednu vrijednost umjesto da se gomila.

Za namjerno zaustavljanje adresa zdravlja treba ostati nedostupna, a proces zaustavljen. Zatim zatvorite petlju s aplikacijske strane: isti zahtjev mora pasti dok tunela nema i mora uspjeti nakon njegova povratka, s izvorišne adrese koju vaša politika očekuje. Zelena ikona tunela nije dokaz, ali dovršen zahtjev jest.