Kako dolgo naj OpenConnect ponavlja poskuse za prekinjen VPN?

--reconnect-timeout odgovarja na eno ozko vprašanje: po padcu tunela kako dolgo ta odjemalski proces še poskuša, preden obupa in izstopi. Stran priročnika OpenConnect zabeleži to možnost z dokumentirano privzeto vrednostjo 300 sekund za ponovne poskuse po izgubljeni povezavi ali partnerju, ki je prenehal odgovarjati, in število je rok za enega delujočega odjemalca, ne dokaz, da VPN ostaja dosegljiv. Prav tako ni politika ohranjanja procesa pri življenju, in prav tam se začne večina zmede.

Zmeda se poveča, ko se nad tem usede drug mehanizem. Nadzornik, ki znova zažene odjemalca, preiskovalec, ki pinga prehod, in vgrajeno okno ponovnih poskusov se lahko vsi odzovejo na eno napako, dogodek pa nato da tri časovnice, ki jih nihče ne more uskladiti.

Kaj okno ponovnega povezovanja dejansko omejuje

Predstavljajte si, da dostopno omrežje za nekaj sekund izgine. Odjemalec vidi padec povezave ali neha slišati odgovore mrtvega partnerja in začne znova vzpostavljati sejo, pri čemer zadrži, kolikor stanja lahko. Poskusi se nadaljujejo, dokler prehod znova ne sprejme ali dokler okno ne poteče, izteklo okno pa se konča z izhodom, ki ni nič. Prav ta izhod, ne vrednost časovne omejitve, je mesto, kjer lastništvo življenjskega cikla preide na tistega, ki proces nadzoruje.

Okno ne pove ničesar o tem, kako pogosto se izvaja preiskava, in ne more podaljšati overjanja. Če je prehod preklical sejo ali račun zdaj zahteva nov drugi dejavnik, daljše čakanje stare seje ne bo znova naredilo veljavne. Ponovni poskus uspe le, ko se pot vrne, prehod sejo še prepozna in zahtevane poverilnice ostanejo uporabne, zato to število berite kot rok in ne kot interval živosti.

Okno tudi ne ureja, kaj aplikacije počnejo, medtem ko teče. Glede na platformo in glede na to, kako daleč je prišla napaka, se odjemalec lahko znova povezuje, ko so poti še nameščene, ali potem, ko so bile umaknjene. Zato zahteva, izdana sredi prekinitve, običajno visi do izteka časovne omejitve, namesto da bi hitro spodletela.

Ponovni zagoni nadzornika in ponovni poskusi odjemalca so dve plasti

Pustite delujočemu odjemalcu, da porabi svoje okno, upravitelju storitev pa, da se odzove na izhod. Odjemalec v ospredju pod systemd s politiko ponovnega zagona da natanko to delitev: poskusi za omejeno obdobje, nato ena odločitev o ponovnem zagonu. Rezultat je ena časovnica, ki jo lahko pozneje še rekonstruirate.

Odjemalec v ozadju in neodvisni poizvedovalec, ki zažene še eno kopijo, ko ne vidi vmesnika, je vzorec, ki se pokvari. Takrat se oba procesa potegujeta za isto vozlišče naprave, poti in nastavitve razreševalnika. Če res želite demona, vstavite možnost v ukazno vrstico, s katero se odjemalec dejansko zažene:

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

Dve podrobnosti v tej vrstici imata težo. --background loči proces, zato datoteka pid postane edini zanesljiv prijem zanj, časovna omejitev pa se porabi le, dokler ta isti proces živi; nadzornik, ki ga ubije, ne pusti proračuna za nadaljevanje.

Namerne prekinitve potrebujejo svoj signal. Načrtovan premor in resnična prekinitev sta za naivnega opazovalca enaka, oba se bereta kot »ni povezano«. Premor vodite prek operacije zaustavitve nadzornika ali oznake, ki jo ovoj razume, da namerna zaustavitev ne sproži ponovnega zagona, ki ga nihče ni zahteval.

Kako preprečiti, da bi predaja prehitela zanko ponovnih poskusov

Nenadzorovano okrevanje je odvisno od poverilnic, ki se obnavljajo brez prisotne osebe. Obroč ključev, ki se odklene le v interaktivni seji namizja, ali žeton, ki vedno zahteva vtipkano kodo, bo odjemalca pustil obtičati na stopnji overjanja, ko se pot vrne. Uredite ta potek dela, preden podaljšate okno, ker daljše okno le daje isti blokirani zahtevi več časa za neuspeh.

Preverjanja strežnika ne smete omiliti, da bi zmanjšali zahteve. Prav pripeta vrednost ali sidro zaupanja, ki potrjuje prehod, naredi samodejno ponovno povezovanje varno, in če ga izklopite, da bi se izognili vprašanju o potrdilu, zamenjate vidno prekinitev za nevidno. Ohranite preverjeno identiteto in raje popravite zahtevo; odjemalec, pripravljen povezati se s katerim koli prehodom, je slabši od tistega, ki se ustavi in čaka.

Tudi prisotnost vmesnika ni signal zdravja. Tunelska naprava lahko obstaja z mrtvo sejo za seboj, zagonski proces pa lahko obstaja brez kakršnega koli tunela. Nobeno od teh opažanj ne zdrži resnične zahteve. Zdravje mora izhajati iz tega, kar uporabnik potrebuje, na primer iz zahteve, ki gre skozi tunel do znane notranje storitve.

Kaj preveriti med prekinitvijo in po njej

Izvedite štiri dogodke kot ločene teste: prekinitev, krajšo od okna, izpad, daljši od njega, napako overjanja in namerno zaustavitev. Vsak bi se moral končati v drugem, predvidljivem stanju, meja med prvima dvema pa je ves razlog za izbiro vrednosti.

Držite preverjanja obrnjena navzven, ker tabela procesov sama po sebi dokaže zelo malo. Opazujte, ali pid ostane stabilen med kratko prekinitvijo, nato potrdite, da je po dolgi izginil in bil enkrat zamenjan:

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

Med kratko prekinitvijo potrdite, da je odjemalec res poskusil znova, in ne, da je izstopil zgodaj, ter da so se poti in vnosi razreševalnika vrnili brez dvojnikov. Za daljši izpad potrdite čist izhod in natanko en ponovni zagon za njim. Za napako overjanja potrdite, da se odjemalec ne vrti proti prehodu, ki ga bo še naprej zavračal. Dodajte preverjanje, da se pid vrne na eno vrednost, namesto da se kopiči.

Za namerno zaustavitev mora URL zdravja ostati nedosegljiv, proces pa ustavljen. Nato zaprite zanko s strani aplikacije: ista zahteva mora spodleteti, dokler tunela ni, in mora uspeti po njegovi vrnitvi, z izvornega naslova, ki ga pričakuje vaša politika. Zelena ikona tunela ni dokaz, končana zahteva pa je.