Kiek laiko „OpenConnect“ turėtų kartoti nutrūkusios VPN bandymus?

--reconnect-timeout atsako į vieną siaurą klausimą: po tunelio kritimo kiek laiko šis kliento procesas dar bando, kol pasiduoda ir išeina. „OpenConnect“ vadovo puslapis fiksuoja šią parinktį su dokumentuota numatytąja 300 sekundžių reikšme pakartotiniams bandymams po prarasto ryšio ar partnerio, kuris nustojo atsakinėti, ir šis skaičius yra vieno veikiančio kliento terminas, o ne įrodymas, kad VPN lieka pasiekiama. Tai taip pat nėra politika palaikyti procesą gyvą, ir būtent čia prasideda didžioji dalis painiavos.

Painiava didėja, kai viršuje atsiranda antras mechanizmas. Priežiūros programa, kuri paleidžia klientą iš naujo, tikrintuvas, kuris pingina šliuzą, ir įmontuotas pakartotinių bandymų langas gali visi reaguoti į vieną gedimą, ir įvykis tada duoda tris laiko juostas, kurių niekas negali suderinti.

Ką iš tikrųjų riboja prisijungimo iš naujo langas

Įsivaizduokite, kad prieigos tinklas kelioms sekundėms dingsta. Klientas mato ryšio kritimą arba nustoja girdėti mirusio partnerio atsakymus ir pradeda iš naujo kurti sesiją, išlaikydamas tiek būsenos, kiek gali. Bandymai tęsiasi, kol šliuzas vėl priima arba kol langas baigiasi, o pasibaigęs langas baigiasi nuliniu išeities kodu. Būtent ši išeitis, o ne skirtasis laikas, yra vieta, kur gyvavimo ciklo nuosavybė pereina tam, kas prižiūri procesą.

Langas nieko nesako apie tai, kaip dažnai paleidžiamas tikrinimas, ir negali pratęsti autentifikacijos. Jei šliuzas atšaukė sesiją arba paskyra dabar reikalauja naujo antrojo veiksnio, ilgesnis laukimas nepadarys senos sesijos vėl galiojančios. Pakartotinis bandymas pavyksta tik tada, kai kelias grįžta, šliuzas vis dar atpažįsta sesiją ir prašomi kredencialai lieka naudojami, todėl skaitykite šį skaičių kaip terminą, o ne kaip gyvybingumo intervalą.

Langas taip pat nereglamentuoja, ką programos daro jam bėgant. Priklausomai nuo platformos ir nuo to, kiek toli nuėjo gedimas, klientas gali jungtis iš naujo su maršrutais, kurie dar įdiegti, arba po to, kai jie buvo pašalinti. Todėl pertraukos viduryje išsiųsta užklausa paprastai kabo iki skirtojo laiko pabaigos, o ne greitai nepavyksta.

Priežiūros programos paleidimai iš naujo ir kliento pakartotiniai bandymai yra du sluoksniai

Leiskite veikiančiam klientui išleisti savo langą, o paslaugų tvarkyklei reaguoti į išėjimą. Priekiniame plane veikiantis klientas pagal systemd su paleidimo iš naujo politika duoda būtent tokį padalijimą: bandymai ribotą laiką, tada vienas paleidimo iš naujo sprendimas. Rezultatas yra viena laiko juosta, kurią dar galite atkurti vėliau.

Fone veikiantis klientas ir nepriklausomas tikrintuvas, kuris paleidžia dar vieną kopiją, kai nemato sąsajos, yra modelis, kuris sugenda. Tada abu procesai varžosi dėl to paties įrenginio mazgo, maršrutų ir sprendėjo nustatymų. Jei tikrai norite tarnybos, įdėkite parinktį į komandų eilutę, su kuria klientas iš tikrųjų startuoja:

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

Šioje eilutėje du dalykai turi svorį. --background atskiria procesą, todėl pid failas tampa vienintele patikima rankena į jį, o skirtasis laikas eikvojamas tik tol, kol tas pats procesas gyvas; priežiūros programa, kuri jį nužudo, nepalieka biudžeto tęsti.

Apgailestaujami atsijungimai turi turėti savo signalą. Suplanuota pauzė ir tikras gedimas atrodo vienodai naiviam stebėtojui, abu skaitomi kaip „neprisijungta“. Valdykite pauzę per priežiūros programos stabdymo operaciją arba žymeklį, kurį supranta apvalkalas, kad sąmoningas sustojimas nesukeltų paleidimo iš naujo, kurio niekas neprašė.

Kaip neleisti perdavimui lenktyniauti su pakartotinių bandymų ciklu

Priežiūra be žmogaus priklauso nuo kredencialų, kurie atsinaujina be žmogaus. Raktų saugykla, kuri atsidaro tik interaktyvioje darbalaukio sesijoje, arba žetonas, kuris visada reikalauja įvesto kodo, paliks klientą autentifikacijos etape, kai kelias grįš. Sutvarkykite tą darbo eigą prieš ilgindami langą, nes ilgesnis langas tik suteikia tam pačiam užblokuotam raginimui daugiau laiko nepavyksti.

Serverio tikrinimo negalima silpninti siekiant sumažinti raginimus. Būtent prisegimas arba pasitikėjimo inkaras, kuris patvirtina šliuzą, daro automatinį prisijungimą iš naujo saugų, o jo išjungimas siekiant išvengti sertifikato klausimo keičia matomą pertrauką į nematomą. Išlaikykite patvirtintą tapatybę ir vietoj to sutaisykite raginimą; klientas, pasirengęs jungtis prie bet kurio šliuzo, yra blogesnis už tą, kuris sustoja ir laukia.

Sąsajos buvimas taip pat nėra sveikatos signalas. Tunelio įrenginys gali egzistuoti su mirusia sesija už jo, o paleidimo procesas gali egzistuoti visai be tunelio. Nė vienas iš šių stebėjimų neatlaiko tikros užklausos. Sveikata turi kilti iš to, ko reikia naudotojui, pavyzdžiui, užklausos, kuri eina per tunelį į žinomą vidinę paslaugą.

Ką tikrinti pertraukos metu ir po jos

Atlikite keturis įvykius kaip atskirus testus: pertrauką, trumpesnę už langą, gedimą, ilgesnį už jį, autentifikacijos klaidą ir sąmoningą sustojimą. Kiekvienas turėtų baigtis skirtingoje, nuspėjamoje būsenoje, o riba tarp pirmųjų dviejų yra visa priežastis pasirinkti reikšmę.

Laikykite patikras nukreiptas į išorę, nes procesų lentelė pati savaime įrodo labai mažai. Stebėkite, ar pid išlieka stabilus trumpos pertraukos metu, tada patvirtinkite, kad po ilgos jis dingo ir buvo pakeistas vieną kartą:

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

Trumpos pertraukos metu patvirtinkite, kad klientas tikrai bandė dar kartą, o ne išėjo anksčiau, ir kad maršrutai bei sprendėjo įrašai grįžo be dublikatų. Ilgesniam gedimui patvirtinkite švarų išėjimą ir lygiai vieną paleidimą iš naujo po jo. Autentifikacijos klaidai patvirtinkite, kad klientas nesisuka prieš šliuzą, kuris toliau jį atmes. Pridėkite patikrą, kad pid grįžta prie vienos reikšmės, o ne kaupiasi.

Sąmoningam sustojimui sveikatos URL turi likti nepasiekiamas, o procesas turi likti sustabdytas. Tada uždarykite ciklą iš programos pusės: ta pati užklausa turi žlugti, kol tunelio nėra, ir pavykti po jo grįžimo, iš šaltinio adreso, kurio tikisi jūsų politika. Žalia tunelio piktograma nėra įrodymas, bet įvykdyta užklausa yra.