ServerAliveInterval ya SSH kupitia VPN: upande upi hutuma uchunguzi?

Mashauri mengi ya kuweka kikao cha SSH hai yanaishia kwenye «ongeza ServerAliveInterval 30» na huacha sehemu zenye manufaa. Neno kuu ni kipima muda cha upande wa mteja kinachowaka tu wakati kituo kimekaa kimya, kinahesabu uchunguzi usiojibiwa badala ya sekunde, na kinaishi katika faili ambapo thamani ya kwanza inayolingana inashinda. Ukikosea katika sifa hizo tatu, kikao chenye afya cha VPN bado kitaanguka, wakati kile kilichokufa kitabaki kinaning'inia.

Mielekeo miwili ni ya daemoni tofauti

ServerAliveInterval huisoma mteja wako wa ssh. ClientAliveInterval huisoma sshd ya upande wa mbali na huchunguza upande kinyume, kutoka seva hadi mteja. Si majina mbadala na haishirikiani, kwa hiyo kuweka kimoja hakuna athari kwa tabia ya upande mwingine. Kuwachanganya ndiyo sababu ya kawaida ya kurekebisha kuonekana kufanya kazi kwenye mwenyeji mmoja na si kwa ujao.

Zote mbili zinakubali sifuri. Kwa sifuri mteja hatumi chochote kabisa, na upande wa seva ClientAliveCountMax ya sifuri huzima kukatwa ambako kingefuata ukaguzi usiojibiwa.

Uchunguzi unathibitisha nini na hauthibitishi nini

Baada ya muda uliowekwa kupita bila data kufika kutoka seva, mteja hutuma ombi dogo kupitia kituo kilichosimbwa kilichopo na husubiri jibu. ServerAliveCountMax huamua ni ngapi kati yao zinaweza kubaki bila jibu kabla kikao kuvunjwa. Kwa muda wa 60 na hesabu ya 3 mteja hukata tamaa baada ya takriban dakika tatu za ukimya, na nambari hiyo ni sifa ya usanidi wako, si kiwango cha mtandao. Ukiacha muda kwenye thamani yake ya msingi 0 hakuna uchunguzi utakaotumwa kamwe, ndiyo sababu mteja wa kawaida anaweza kukaa kwenye muunganisho uliokufa bila kikomo.

Kwa kuwa mabadilishano hufanyika ndani ya usafirishaji wa SSH, jibu huthibitisha kwamba mchakato wa SSH wa upande mwingine bado unasoma na kuandika. Haisemi chochote kuhusu programu uliyoianzisha ndani ya kikao hicho: mteja wa hifadhidata, bandari iliyopelekwa au hati inayokaa muda mrefu inaweza kuwa imekwama wakati usafirishaji unajibu uchunguzi kwa furaha.

TCPKeepAlive ni utaratibu tofauti tabaka moja chini. Ni kernel inayousimamia, haujasimbwa, na upande mwingine ambao daemoni yake ya SSH imekwama bado unaweza kuutimiza. Ndiyo sababu uchunguzi wa ngazi ya SSH ni ishara yenye maana zaidi unapojali kikao badala ya soketi.

Mpangilio huamua thamani ipi inabaki

OpenSSH hutumia thamani ya kwanza inayopata kwa kila kigezo, kwa hiyo kitalu mahususi cha Host lazima kitangulie kitalu chochote kipana ambacho pia kingelingana. Weka thamani za msingi zenye alama za ugani chini ya faili, si juu, na kumbuka kwamba kitalu cha Match kilicho chini hakiwezi kubatilisha thamani iliyokwishawekwa. Rejea ya usanidi wa mteja wa OpenSSH inaeleza kanuni ya thamani ya kwanza moja kwa moja, na inafaa kuisoma mara moja kabla ya kupanga upya usanidi unaoshirikiwa.

Chaguo za mstari wa amri hushinda faili, jambo linalofanya jaribio la muda kuwa la bei nafuu:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

Ili kuona kile mteja alichotatua kwa hakika badala ya kile unachofikiri uliandika, mwombe atoe usanidi unaofanya kazi. Matokeo yana thamani zilizounganishwa kwa jina hilo la mwenyeji na ndiyo njia ya haraka zaidi ya kukamata kitalu cha awali kilichopotea:

ssh -G office-shell | grep -i alive

Keepalive hufanya nini kupitia handaki

Trafiki ya mara kwa mara huzuia ramani ya NAT au ukuta wa moto wenye hali kuisha muda, jambo ambalo ni faida ya kweli kwenye VPN ambayo lango lake hutupa mtiririko usio na shughuli baada ya dakika chache. Uchunguzi unaofika kila sekunde 60 huonyesha upya ramani hiyo bila kubeba data yoyote ya programu.

Hawawezi kujenga upya njia iliyotoweka. Lango la handaki linapotoweka uchunguzi unashindwa kama kila kitu kingine, na kikao huisha mara hesabu inapokwisha. Ugunduzi wa uhai na urejeshaji wa njia ni matatizo tofauti, na ni ya kwanza tu inayoweza kusanidiwa katika ssh_config. Kile muda na hesabu hukununulia kwa hakika ni jinsi mteja anavyogundua haraka, na ndiyo sehemu ambayo mtumiaji huipata kama kukwama.

Miunganisho iliyozidishwa huongeza mkunjo. ControlMaster inapohusika uchunguzi ni wa muunganisho mkuu, na kikao kipya juu ya mkuu uliopo hurithi kile ambacho mkuu huyo alijadiliana. Ikiwa mkuu wa mux umekwama, kufungua dirisha lingine hakutajaribu njia tena.

Kuthibitisha mpangilio kutoka mwanzo hadi mwisho

Kwenye seva, toa usanidi unaofanya kazi wa daemoni badala ya kusoma faili na kukisia ni include ipi ilishinda:

sshd -T | grep -i clientalive

Kisha angalia kikao halisi ukiwa umewasha matokeo ya utatuzi. Mteja huchapisha mstari wa muda kuisha hesabu inapokwisha, na mihuri ya muda pande zote huonyesha kama ukimya ulikuwa wa kuendelea au uchunguzi haukutumwa kabisa. Kikao kinachokufa bila trafiki yoyote ya uchunguzi kwa kawaida huweka neno kuu kwenye kitalu ambacho hakikuwahi kulingana.

Inafaa kuongeza ukaguzi mbili kwa mwenyeji yeyote unayemfikia kwa handaki pekee: thibitisha kwamba muda uliotatuliwa ni ule uliokusudiwa, na kwamba muda huo ukizidishwa na hesabu ni mfupi kuliko muda wa kutokuwepo kwenye lango la VPN. Nambari ya pili inapokuwa kubwa zaidi, lango hutupa mtiririko kwa utulivu kwanza na uchunguzi wa SSH haupati nafasi ya kuripoti chochote.