Kui kaua peaks OpenConnect katkenud VPN-i uuesti proovima?

--reconnect-timeout vastab ühele kitsale küsimusele: pärast tunneli kukkumist kui kaua see kliendiprotsess veel proovib, enne kui alla annab ja väljub. OpenConnecti käsiraamatu leht märgib selle valiku dokumenteeritud vaikeväärtusega 300 sekundit korduskatseile, mis järgnevad kadunud lingile või partnerile, kes lakkas vastamast, ja number on tähtaeg ühele töötavale kliendile, mitte tõestus, et VPN jääb kättesaadavaks. See ei ole ka protsessi elus hoidmise poliitika, ja just sealt algab suurem osa segadusest.

Segadus kasvab, kui peal istub teine mehhanism. Supervisor, mis kliendi uuesti käivitab, gatewayd pingiv kontrollija ja sisseehitatud korduskatse aken võivad kõik ühele rikkele reageerida, ja juhtum annab siis kolm ajajoont, mida keegi ei suuda ühitada.

Mida taasühenduse aken tegelikult piirab

Kujutage ette, et juurdepääsuvõrk kaob paariks sekundiks. Klient näeb lingi kadumist või lakkab surnud partneri vastuseid kuulmast ning alustab sessiooni taastamist, hoides nii palju olekut kui suudab. Katsed jätkuvad, kuni gateway uuesti vastu võtab või aken lõpeb, ja lõppenud aken lõpeb nullist erineva väljumiskoodiga. Just see väljumine, mitte ajalõpu väärtus, on koht, kus elutsükli omandiõigus läheb üle sellele, kes protsessi jälgib.

Aken ei ütle midagi selle kohta, kui tihti kontrollija töötab, ega suuda autentimist pikendada. Kui gateway on sessiooni tühistanud või konto nõuab nüüd uut teist tegurit, ei tee pikem ootamine vana sessiooni uuesti kehtivaks. Korduskatse õnnestub ainult siis, kui tee taastub, gateway tunneb sessiooni endiselt ära ja nõutud mandaat jääb kasutatavaks, seega lugege seda numbrit tähtajana, mitte elujõulisuse intervallina.

Aken ei reguleeri ka seda, mida rakendused selle ajal teevad. Sõltuvalt platvormist ja sellest, kui kaugele rike jõudis, võib klient taasühenduda marsruutidega, mis on veel paigaldatud, või pärast nende eemaldamist. Sellepärast jääb katkestuse keskel väljastatud päring tavaliselt rippuma kuni ajalõpu lõpuni, selle asemel et kiiresti ebaõnnestuda.

Supervisori taaskäivitused ja kliendi korduskatsed on kaks kihti

Laske töötaval kliendil kulutada oma aken ja laske teenusehalduril väljumisele reageerida. Esiplaanil töötav klient systemd all taaskäivitamispoliitikaga annab täpselt selle jaotuse: katsed piiratud aja jooksul, seejärel üks taaskäivitamise otsus. Tulemuseks on üks ajajoon, mille saate hiljemgi rekonstrueerida.

Taustal töötav klient pluss sõltumatu küsitleja, mis käivitab teise koopia, kui ei näe liidest, on muster, mis läheb valesti. Siis võistlevad mõlemad protsessid sama seadmesõlme, marsruutide ja resolveri seadete pärast. Kui te tõesti tahate deemonit, pange valik käsureale, millega klient tegelikult algab:

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

Sellel real on kaal kaks detaili. --background eraldab protsessi, nii et pid-failist saab ainus usaldusväärne käepide selle küljes, ja ajalõpp kulub ainult seni, kuni seesama protsess elab; supervisor, mis selle tapab, ei jäta jätkamiseks eelarvet.

Sihipärased lahtiühendamised vajavad oma signaali. Kavandatud paus ja tõeline katkestus näevad naiivse vaatleja jaoks ühesugused välja, mõlemad loetakse kui „ei ole ühendatud”. Juhtige pausi supervisori peatamistoimingu või wrapperi mõistetava markeri kaudu, et tahtlik seiskamine ei käivitaks taaskäivitust, mida keegi ei küsinud.

Kuidas hoida üleandmist korduskatse tsükliga võidu jooksmast

Järelevalveta taastamine sõltub mandaadist, mis uueneb ilma kohal oleva inimeseta. Võtmehoidja, mis avatakse ainult interaktiivses töölaua sessioonis, või token, mis nõuab alati sisestatud koodi, jätab kliendi autentimisetapil kinni, kui tee on tagasi. Lahendage see töövoog enne akna pikendamist, sest pikem aken annab ainult samale blokeeritud viibale rohkem aega ebaõnnestuda.

Serveri kontrollimist ei tohiks lõdvendada viipade vähendamiseks. Just gatewayd valideeriv pin või usaldusankur muudab automaatse taasühenduse turvaliseks, ja selle väljalülitamine sertifikaadiküsimuse vältimiseks vahetab nähtava katkestuse nähtamatu vastu. Hoidke kinnitatud identiteet ja parandage selle asemel viip; klient, mis on valmis ühenduma mis tahes gatewayga, on halvem kui see, mis peatub ja ootab.

Ka liidese olemasolu ei ole tervisesignaal. Tunnelseade võib eksisteerida surnud sessioga selle taga, ja käivitaja protsess võib eksisteerida ilma igasuguse tunnelita. Ükski neist vaatlustest ei pea tõelisele päringule vastu. Tervis peab tulema sellest, mida kasutaja vajab, näiteks päring, mis läbib tunneli teadaolevasse sisemisse teenusesse.

Mida katkestuse ajal ja pärast seda kontrollida

Käivitage neli sündmust eraldi testidena: aknast lühem katkestus, sellest pikem katkestus, autentimise rike ja tahtlik seiskamine. Igaüks peaks lõppema erinevas, etteaimatavas olekus, ja kahe esimese vaheline piir on kogu põhjus väärtuse valimiseks.

Hoidke kontrollid suunatud väljapoole, sest protsessitabel tõestab iseenesest väga vähe. Jälgige, et pid püsiks lühikese katkestuse ajal stabiilne, seejärel kinnitage, et see on kadunud ja asendatud üks kord pärast pikka:

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

Lühikese katkestuse ajal kinnitage, et klient tõesti proovis uuesti, mitte ei väljunud vara, ja et marsruudid ja resolveri kirjed tulid tagasi ilma duplikaatideta. Pikema katkestuse puhul kinnitage puhas väljumine ja täpselt üks taaskäivitus selle järel. Autentimise rikke puhul kinnitage, et klient ei keerle gateway vastu, mis jätkab selle tagasilükkamist. Lisage kontroll, et pid naaseb ühele väärtusele, mitte ei kuhju.

Tahtliku seiskamise puhul peaks tervise-URL jääma kättesaamatuks ja protsess alla. Seejärel sulgege tsükkel rakenduse poolelt: sama päring peab ebaõnnestuma, kui tunnelit pole, ja õnnestuma pärast selle naasmist, lähteaadressilt, mida teie poliitika eeldab. Roheline tunneli ikoon ei ole tõestus, aga lõpetatud päring on.