Cik ilgi OpenConnect jāmēģina atkārtoti pieslēgties pārtrauktam VPN?

--reconnect-timeout atbild uz vienu šauru jautājumu: pēc tuneļa krišanas cik ilgi šis klienta process turpina mēģināt, pirms padodas un iziet. OpenConnect rokasgrāmatas lapa reģistrē šo opciju ar dokumentētu noklusējuma vērtību 300 sekundes atkārtotiem mēģinājumiem pēc zaudētas saites vai partnera, kas pārstāja atbildēt, un šis skaitlis ir termiņš vienam darbojošam klientam, nevis pierādījums, ka VPN paliek sasniedzams. Tas arī nav politika procesa uzturēšanai dzīvu, un tieši šeit sākas lielākā daļa apjukuma.

Apjukums pieaug, kad virsū sēž otrs mehānisms. Uzraugs, kas restartē klientu, pārbaudītājs, kas pingē vārteju, un iebūvētais atkārtoto mēģinājumu logs var visi reaģēt uz vienu kļūmi, un incidents tad dod trīs laika līnijas, ko neviens nevar saskaņot.

Ko atkārtotas savienošanas logs patiešām ierobežo

Iedomājieties, ka piekļuves tīkls uz dažām sekundēm pazūd. Klients redz saites pārrāvumu vai pārstāj dzirdēt mirušā partnera atbildes un sāk atjaunot sesiju, paturot tik daudz stāvokļa, cik var. Mēģinājumi turpinās, līdz vārteja atkal pieņem vai līdz logs beidzas, un beidzies logs beidzas ar izeju, kas nav nulle. Tieši šī izeja, nevis taimauta vērtība, ir vieta, kur dzīves cikla īpašumtiesības pāriet tam, kas uzrauga procesu.

Logs neko nepasaka par to, cik bieži darbojas pārbaudītājs, un tas nevar pagarināt autentifikāciju. Ja vārteja ir atsaukusi sesiju vai kontam tagad nepieciešams jauns otrais faktors, ilgāka gaidīšana nepadarīs veco sesiju atkal derīgu. Atkārtots mēģinājums izdodas tikai tad, kad ceļš atgriežas, vārteja joprojām atzīst sesiju un pieprasītie akreditācijas dati paliek lietojami, tāpēc lasiet šo skaitli kā termiņu, nevis kā dzīvotspējas intervālu.

Logs arī nereglamentē, ko lietojumprogrammas dara tā darbības laikā. Atkarībā no platformas un no tā, cik tālu kļūme ir tikusi, klients var atkārtoti savienoties ar maršrutiem, kas vēl ir instalēti, vai pēc to noņemšanas. Tāpēc pārtraukuma vidū izsūtīts pieprasījums parasti karājas līdz taimauta beigām, nevis ātri neizdodas.

Uzrauga restartēšana un klienta atkārtotie mēģinājumi ir divi slāņi

Ļaujiet darbojošam klientam iztērēt savu logu, un ļaujiet pakalpojumu pārvaldniekam reaģēt uz izeju. Priekšplānā esošs klients zem systemd ar restartēšanas politiku dod tieši šo sadalījumu: mēģinājumi ierobežotu laiku, pēc tam viens restartēšanas lēmums. Rezultāts ir viena laika līnija, ko vēlāk vēl varat rekonstruēt.

Fona klients kopā ar neatkarīgu pārbaudītāju, kas palaiž vēl vienu kopiju, kad neredz saskarni, ir modelis, kas noiet greizi. Tad abi procesi sacenšas par to pašu ierīces mezglu, maršrutiem un risinātāja iestatījumiem. Ja tiešām vēlaties dēmonu, ievietojiet opciju komandrindā, ar kuru klients faktiski startē:

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

Šajā rindā divas detaļas nes svaru. --background atdala procesu, tāpēc pid fails kļūst par vienīgo uzticamo rokturi tam, un taimauts tiek tērēts tikai tik ilgi, kamēr tas pats process ir dzīvs; uzraugs, kas to nogalina, neatstāj budžetu turpināšanai.

Tīšiem atvienojumiem vajadzīgs savs signāls. Plānota pauze un īsts pārtraukums naivam novērotājam izskatās vienādi, abi tiek lasīti kā „nav savienots”. Vadiet pauzi caur uzrauga apturēšanas operāciju vai marķieri, ko saprot ietinējs, lai apzināta apstāšanās neizraisītu restartu, ko neviens nav prasījis.

Kā neļaut nodošanai sacensties ar atkārtoto mēģinājumu cilpu

Neuzraudzīta atjaunošanās ir atkarīga no akreditācijas datiem, kas atjaunojas bez klātienes personas. Atslēgu piederums, kas atveras tikai interaktīvā darbvirsmas sesijā, vai tokens, kas vienmēr prasa ievadītu kodu, atstās klientu autentifikācijas posmā, tiklīdz ceļš atgriežas. Sakārtojiet šo darbplūsmu pirms loga pagarināšanas, jo garāks logs tikai dod tam pašam bloķētajam uzvednei vairāk laika neizdoties.

Servera pārbaudi nevajadzētu mīkstināt, lai samazinātu uzvednes. Tieši piespraude vai uzticības enkurs, kas validē vārteju, padara automātisku atkārtotu savienošanu drošu, un tā izslēgšana, lai izvairītos no sertifikāta jautājuma, apmaina redzamu pārtraukumu pret neredzamu. Saglabājiet pārbaudīto identitāti un labojiet uzvedni; klients, kas gatavs savienoties ar jebkuru vārteju, ir sliktāks par to, kas apstājas un gaida.

Saskarnes klātbūtne arī nav veselības signāls. Tuneļa ierīce var pastāvēt ar mirušu sesiju aiz tās, un palaišanas process var pastāvēt bez jebkāda tuneļa. Neviens no šiem novērojumiem neiztur īstu pieprasījumu. Veselībai jānāk no tā, kas lietotājam vajadzīgs, piemēram, pieprasījuma, kas iet cauri tunelim uz zināmu iekšēju pakalpojumu.

Kas jāpārbauda pārtraukuma laikā un pēc tā

Veiciet četrus notikumus kā atsevišķus testus: pārtraukumu īsāku par logu, kļūmi garāku par to, autentifikācijas kļūmi un apzinātu apstāšanos. Katram jābeidzas citā, paredzamā stāvoklī, un robeža starp pirmajiem diviem ir viss iemesls vērtības izvēlei.

Turiet pārbaudes vērstas uz āru, jo procesu tabula pati par sevi pierāda ļoti maz. Vērojiet, vai pid paliek stabils īsā pārtraukuma laikā, pēc tam apstipriniet, ka pēc garā tas ir pazudis un vienreiz aizstāts:

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

Īsā pārtraukuma laikā apstipriniet, ka klients tiešām mēģināja vēlreiz, nevis izgāja agri, un ka maršruti un risinātāja ieraksti atgriezās bez dublikātiem. Garākai kļūmei apstipriniet tīru izeju un tieši vienu restartu pēc tam. Autentifikācijas kļūmei apstipriniet, ka klients negriežas pret vārteju, kas turpinās to noraidīt. Pievienojiet pārbaudi, ka pid atgriežas pie vienas vērtības, nevis uzkrājas.

Apzinātai apstāšanās reizei veselības URL jāpaliek nesasniedzamam, un procesam jāpaliek apstādinātam. Pēc tam aizveriet cilpu no lietojumprogrammas puses: tam pašam pieprasījumam jācieš neveiksme, kamēr tuneļa nav, un jāizdodas pēc tā atgriešanās, no avota adreses, ko sagaida jūsu politika. Zaļa tuneļa ikona nav pierādījums, bet izpildīts pieprasījums ir.