OpenConnect inapaswa kuendelea kujaribu VPN iliyokatika kwa muda gani?

--reconnect-timeout hujibu swali moja jembamba: baada ya handaki kuanguka, mchakato huu wa mteja unaendelea kujaribu kwa muda gani kabla ya kukata tamaa na kutoka. Ukurasa wa mwongozo wa OpenConnect hurekodi chaguo hilo kwa thamani ya msingi iliyoandikwa ya sekunde 300 kwa majaribio mapya yanayofuata kiungo kilichopotea au mshirika aliyeacha kujibu, na nambari hiyo ni tarehe ya mwisho kwa mteja mmoja anayeendesha, si uthibitisho kwamba VPN inabaki kufikiwa. Pia si sera ya kuweka mchakato hai, na hapo ndipo sehemu kubwa ya mkanganyiko huanzia.

Mkanganyiko huongezeka wakati utaratibu wa pili unakaa juu. Msimamizi anayeanzisha mteja upya, kipimaji kinachopinga lango, na dirisha la majaribio mapya lililojengwa ndani vyote vinaweza kuitikia hitilafu moja, na tukio hilo hutoa mistari mitatu ya muda ambayo hakuna anayeweza kuipatanisha.

Dirisha la kuunganisha upya huzuia nini kwa kweli

Fikiria mtandao wa ufikiaji unatoweka kwa sekunde chache. Mteja anaona kiungo kikianguka, au anaacha kusikia majibu kutoka kwa mshirika aliyekufa, na huanza kuunda upya kikao huku akishikilia hali anayoweza. Majaribio yanaendelea hadi lango likubali tena au dirisha liishe, na dirisha lililoisha huishia kwa kutoka kwa thamani isiyo sifuri. Kutoka huko, si thamani ya kikomo cha muda, ndiko umiliki wa mzunguko wa maisha unapopita kwa yeyote anayesimamia mchakato.

Dirisha halisemi chochote kuhusu ni mara ngapi kipimaji kinaendeshwa, na haliwezi kuongeza uthibitishaji. Ikiwa lango lilitengua kikao, au akaunti sasa inadai kipengele cha pili kipya, kusubiri zaidi hakutafanya kikao cha zamani kuwa halali tena. Jaribio jipya hufaulu tu wakati njia inarudi, lango bado linatambua kikao, na vitambulisho vinavyoombwa vinabaki vinatumika, kwa hivyo soma nambari kama tarehe ya mwisho na si kama muda wa uhai.

Dirisha pia halidhibiti kile programu zinafanya wakati linaendelea. Kutegemea jukwaa na umbali ambao hitilafu ilifika, mteja anaweza kuunganisha upya huku njia bado zimewekwa, au baada ya kuondolewa. Ndiyo sababu ombi lililotolewa katikati ya usumbufu huwa hutegemea hadi kikomo cha muda badala ya kushindwa haraka.

Uanzishaji upya wa msimamizi na majaribio mapya ya mteja ni tabaka mbili

Acha mteja anayeendesha atumie dirisha lake mwenyewe, na msimamizi wa huduma aitikie kutoka. Mteja wa mbele chini ya systemd na sera ya kuanzisha upya hutoa mgawanyo huo hasa: majaribio kwa kipindi kilichowekewa kikomo, kisha uamuzi mmoja wa kuanzisha upya. Matokeo ni mstari mmoja wa muda ambao bado unaweza kuujenga upya baadaye.

Mteja wa chinichini pamoja na kipimaji huru kinachoanzisha nakala nyingine kinaposhindwa kuona kiolesura ni mtindo unaokwenda vibaya. Wakati huo michakato yote miwili inashindania nodi ya kifaa, njia na mipangilio ya kitatuzi sawa. Ikiwa kwa kweli unataka daemon, weka chaguo kwenye mstari wa amri ambao mteja huanza nao kwa kweli:

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

Maelezo mawili kwenye mstari huo yana uzito. --background hutenganisha mchakato, kwa hivyo faili ya pid inakuwa kishikilio pekee cha kuaminika juu yake, na kikomo cha muda hutumika tu wakati mchakato huo huo ukiwa hai; msimamizi anayeuita hana bajeti ya kuendelea.

Kukatisha kwa makusudi kunahitaji ishara yake yenyewe. Pumziko lililopangwa na usumbufu halisi huonekana sawa kwa mwangalizi asiye na ujuzi, na yote mawili husomwa kama «haijaunganishwa». Ongeza pumziko kupitia operesheni ya kusimamisha ya msimamizi, au alama inayoeleweka na kifuniko, ili kusimamisha kwa makusudi kusisababishe kuanzisha upya ambako hakuna aliyekuomba.

Kuzuia uhamishaji kushindana na mzunguko wa majaribio mapya

Urejeshaji bila uangalizi hutegemea vitambulisho vinavyohuishwa bila mtu kuwepo. Kifungo cha funguo kinachofunguka tu ndani ya kikao cha desktop shirikishi, au tokeni inayodai kila mara msimbo uliobandikwa, kitamwacha mteja amekwama katika hatua ya uthibitishaji mara njia inaporudi. Rekebisha mtiririko huo wa kazi kabla ya kurefusha dirisha, kwa sababu dirisha refu hulipa tu ombi lile lile lililozuiwa muda zaidi wa kushindwa.

Uthibitishaji wa seva haupaswi kulegezwa ili kupunguza maombi. Ni pini au nanga ya uaminifu inayothibitisha lango ndiyo inayofanya kuunganisha upya kiotomatiki kuwa salama, na kuizima ili kuepuka swali la cheti hubadilisha usumbufu unaoonekana na usioonekana. Weka utambulisho uliothibitishwa na urekebishe ombi badala yake; mteja aliye tayari kuunganisha na lango lolote ni mbaya kuliko yule anayesimama na kusubiri.

Uwepo wa kiolesura pia si ishara ya afya. Kifaa cha handaki kinaweza kuwepo na kikao kilichokufa nyuma yake, na mchakato wa kuzindua unaweza kuwepo bila handaki hata moja. Hakuna moja ya uchunguzi huo unaostahimili ombi halisi. Afya lazima itokee kutokana na kile mtumiaji anahitaji, kama ombi linalopita handakini kuelekea huduma ya ndani inayojulikana.

Nini cha kuthibitisha wakati wa usumbufu na baada yake

Endesha matukio manne kama majaribio tofauti: usumbufu mfupi kuliko dirisha, usumbufu mrefu kuliko hilo, kushindwa kwa uthibitishaji, na kusimamisha kwa makusudi. Kila moja inapaswa kuishia katika hali tofauti inayotabirika, na mpaka kati ya mawili ya kwanza ndiyo sababu yote ya kuchagua thamani.

Weka ukaguzi ukielekea nje, kwa sababu jedwali la michakato yenyewe huthibitisha kidogo sana. Tazama kama pid inabaki imara wakati wa mkato mfupi, kisha thibitisha kwamba baada ya ule mrefu imeondoka na kubadilishwa mara moja:

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

Wakati wa usumbufu mfupi, thibitisha kwamba mteja alijaribu tena kweli badala ya kutoka mapema, na kwamba njia na maingizo ya kitatuzi yalirudi bila nakala. Kwa usumbufu mrefu, thibitisha kutoka safi na kuanzisha upya moja hasa baada yake. Kwa kushindwa kwa uthibitishaji, thibitisha kwamba mteja haizunguki dhidi ya lango litakaloendelea kumkataa. Ongeza ukaguzi kwamba pid inarudi kwa thamani moja badala ya kujilimbikiza.

Kwa kusimamisha kwa makusudi, URL ya afya inapaswa kubaki isifikika na mchakato ubaki chini. Kisha funga mzunguko kutoka upande wa programu: ombi lile lile lazima lishindwe wakati handaki haipo na lazima lifaulu baada ya kurudi, kutoka anwani ya chanzo ambayo sera yako inatarajia. Aikoni ya kijani ya handaki si uthibitisho, lakini ombi lililokamilika ni uthibitisho.