Sa kohë duhet OpenConnect të vazhdojë të provojë një VPN të ndërprerë?

--reconnect-timeout i përgjigjet një pyetjeje të ngushtë: pasi tuneli bie, sa kohë vazhdon ky proces klienti të provojë para se të dorëzohet dhe të dalë. Faqja e manualit të OpenConnect e regjistron atë opsion me një parazgjedhje të dokumentuar prej 300 sekondash për përpjekjet e reja që pasojnë një lidhje të humbur ose një partner që ka pushuar së përgjigjuri, dhe numri është një afat për një klient që punon, jo provë që VPN-i mbetet i arritshëm. Nuk është as një politikë për ta mbajtur procesin gjallë, dhe pikërisht aty fillon pjesa më e madhe e konfuzionit.

Konfuzioni rritet kur sipër ulet një mekanizëm i dytë. Një mbikëqyrës që rinis klientin, një sondë që bën ping në portë dhe dritarja e integruar e përpjekjeve të reja mund të gjitha të reagojnë ndaj një dështimi, dhe incidenti atëherë jep tri vija kohore që askush nuk mund t’i pajtojë.

Çfarë kufizon në të vërtetë dritarja e rilidhjes

Imagjinoni që rrjeti i aksesit zhduket për disa sekonda. Klienti e sheh lidhjen duke rënë, ose ndalon së dëgjuari përgjigjet e partnerit të vdekur, dhe fillon të rivendosë sesionin duke mbajtur gjendjen që mundet. Përpjekjet vazhdojnë derisa porta të pranojë përsëri ose derisa dritarja të mbarojë, dhe një dritare e mbaruar përfundon me një dalje që nuk është zero. Është pikërisht ajo dalje, e jo vlera e afatit, vendi ku pronësia e ciklit të jetës kalon te kushdo që mbikëqyr procesin.

Dritarja nuk thotë asgjë për atë se sa shpesh ekzekutohet një sondë, dhe nuk mund ta zgjasë vërtetimin. Nëse porta e ka revokuar sesionin, ose llogaria tani kërkon një faktor të dytë të ri, pritja më e gjatë nuk do ta bëjë sesionin e vjetër sërish të vlefshëm. Një përpjekje e re ka sukses vetëm kur rruga kthehet, porta e njeh ende sesionin dhe kredencialet e kërkuara mbeten të përdorshme, prandaj lexojeni numrin si afat dhe jo si interval jetëgjatësie.

Dritarja gjithashtu nuk rregullon atë që bëjnë aplikacionet ndërsa ajo zgjat. Në varësi të platformës dhe sa larg ka shkuar dështimi, klienti mund të rilidhet me rrugët ende të instaluara, ose pasi ato janë hequr. Prandaj një kërkesë e lëshuar në mes të një ndërprerjeje zakonisht varet deri në skadimin e afatit në vend që të dështojë shpejt.

Rinisjet e mbikëqyrësit dhe përpjekjet e klientit janë dy shtresa

Lëreni klientin që punon të shpenzojë dritaren e vet, dhe menaxherin e shërbimeve të reagojë ndaj daljes. Një klient në plan të parë nën systemd me një politikë rinisjeje jep saktësisht atë ndarje: përpjekje për një periudhë të kufizuar, pastaj një vendim i vetëm rinisjeje. Rezultati është një vijë e vetme kohore që mund ta rindërtoni më vonë.

Një klient në sfond plus një sondë e pavarur që nis një kopje tjetër kur nuk sheh një ndërfaqe është modeli që shkon keq. Atëherë të dy proceset konkurrojnë për të njëjtin nyje pajisjeje, rrugët dhe cilësimet e zgjidhësit. Nëse vërtet dëshironi një demon, vendoseni opsionin në rreshtin e komandës me të cilin klienti nis vërtet:

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

Dy hollësi në atë rresht kanë peshë. --background e shkëput procesin, kështu që skedari pid bëhet e vetmja dorezë e besueshme mbi të, dhe afati harxhohet vetëm sa kohë që ai i njëjti proces jeton; një mbikëqyrës që e vret nuk lë buxhet për të vazhduar.

Shkëputjet e qëllimshme kanë nevojë për sinjalin e tyre. Një pauzë e planifikuar dhe një ndërprerje e vërtetë duken njësoj për një vëzhgues naiv, dhe të dyja lexohen si «jo i lidhur». Drejtojeni pauzën përmes operacionit të ndalimit të mbikëqyrësit, ose përmes një shenje që mbështjellja e kupton, që një ndalim i qëllimshëm të mos shkaktojë rinisje që askush nuk e kërkoi.

Të parandalosh që dorëzimi të garojë me ciklin e përpjekjeve

Rimëkëmbja pa mbikëqyrje varet nga kredenciale që ripërtërihen pa një person të pranishëm. Një varg çelësash që hapet vetëm brenda një sesioni interaktiv desktopi, ose një shenjë që gjithmonë kërkon një kod të shtypur, do ta lërë klientin të bllokuar në fazën e vërtetimit sapo rruga të kthehet. Rregullojeni atë rrjedhë pune para se ta zgjasni dritaren, sepse një dritare më e gjatë i jep vetëm të njëjtës kërkesë të bllokuar më shumë kohë për të dështuar.

Verifikimi i serverit nuk duhet lehtësuar për të reduktuar kërkesat. Pikërisht fiksimi ose spiranca e besimit që vërteton portën e bën të sigurt një rilidhje automatike, dhe çaktivizimi i tij për të shmangur një pyetje certifikate shkëmben një ndërprerje të dukshme me një të padukshme. Mbani identitetin e verifikuar dhe rregulloni kërkesën në vend të kësaj; një klient i gatshëm të lidhet me çdo portë është më i keq se një që ndalon dhe pret.

Edhe prania e ndërfaqes nuk është sinjal shëndeti. Një pajisje tuneli mund të ekzistojë me një sesion të vdekur pas saj, dhe një proces nisjeje mund të ekzistojë pa asnjë tunel. Asnjë nga këto vëzhgime nuk i bën ballë një kërkese të vërtetë. Shëndeti duhet të vijë nga ajo që i nevojitet përdoruesit, si një kërkesë që kalon nëpër tunel drejt një shërbimi të brendshëm të njohur.

Çfarë të verifikohet gjatë dhe pas një ndërprerjeje

Ekzekutoni katër ngjarje si teste të veçanta: një ndërprerje më e shkurtër se dritarja, një ndërprerje më e gjatë se ajo, një dështim vërtetimi dhe një ndalim i qëllimshëm. Secila duhet të përfundojë në një gjendje të ndryshme dhe të parashikueshme, dhe kufiri midis dy të parave është e gjithë arsyeja për të zgjedhur një vlerë.

Mbani kontrollet të kthyera nga jashtë, sepse tabela e proceseve vetëm sa provon shumë pak. Vëzhgoni nëse pid mbetet i qëndrueshëm gjatë ndërprerjes së shkurtër, pastaj konfirmoni se pas asaj të gjatë ai iku dhe u zëvendësua një herë:

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

Gjatë ndërprerjes së shkurtër, konfirmoni se klienti vërtet u përpoq përsëri në vend që të dilte herët, dhe se rrugët dhe hyrjet e zgjidhësit u kthyen pa dublikata. Për ndërprerjen më të gjatë, konfirmoni një dalje të pastër dhe saktësisht një rinisje pas saj. Për dështimin e vërtetimit, konfirmoni se klienti nuk rrotullohet kundër një porte që do të vazhdojë ta refuzojë. Shtoni një kontroll që pid kthehet në një vlerë të vetme në vend që të grumbullohet.

Për ndalimin e qëllimshëm, URL-ja e shëndetit duhet të mbetet e paarritshme dhe procesi duhet të mbetet poshtë. Pastaj mbyllni ciklin nga ana e aplikacionit: e njëjta kërkesë duhet të dështojë ndërsa tuneli mungon dhe duhet të ketë sukses pasi ai kthehet, nga adresa burimore që pret politika juaj. Një ikonë e gjelbër tuneli nuk është provë, por një kërkesë e përfunduar është.