ServerAliveInterval i SSH përmes VPN: cili skaj e dërgon provën?

Shumica e këshillave për ta mbajtur një sesion SSH gjallë ndalen te «shto ServerAliveInterval 30» dhe lënë jashtë pjesët e dobishme. Fjala kyçe është një kohëmatës në anën e klientit që aktivizohet vetëm kur kanali ka qenë i qetë, numëron provat pa përgjigje në vend të sekondave, dhe jeton në një skedar ku fiton vlera e parë që përputhet. Gaboni në këto tri veti dhe një sesion i shëndoshë VPN do të bjerë gjithsesi, ndërsa një i vdekur do të mbetet i varur.

Dy drejtimet u përkasin demonëve të ndryshëm

ServerAliveInterval lexohet nga klienti juaj ssh. ClientAliveInterval lexohet nga sshd në anën tjetër dhe provon në drejtimin e kundërt, nga serveri te klienti. Nuk janë pseudonime dhe nuk bashkëpunojnë, pra vendosja e njërit nuk ka efekt në sjelljen e skajit tjetër. Ngatërrimi i tyre është arsyeja e zakonshme që një rregullim duket se funksionon në një host dhe jo në tjetrin.

Të dyja pranojnë zero. Në zero klienti nuk dërgon asgjë fare, dhe në anën e serverit një ClientAliveCountMax zero çaktivizon shkëputjen që përndryshe do të pasonte kontrollet pa përgjigje.

Çfarë provon një provë dhe çfarë jo

Pasi kalon intervali i konfiguruar pa ardhur të dhëna nga serveri, klienti dërgon një kërkesë të vogël përmes kanalit ekzistues të kriptuar dhe pret një përgjigje. ServerAliveCountMax përcakton sa prej tyre mund të mbeten pa përgjigje para se sesioni të rrëzohet. Me interval 60 dhe numër 3 klienti dorëzohet pas rreth tre minutash heshtjeje, dhe ky numër është veti e konfigurimit tuaj, jo standard rrjeti. Lëreni intervalin në vlerën e paracaktuar 0 dhe asnjë provë nuk dërgohet kurrë, prandaj një klient standard mund të rrijë pafundësisht mbi një lidhje të vdekur.

Meqenëse shkëmbimi zhvillohet brenda transportit SSH, një përgjigje provon që procesi SSH i palës tjetër ende lexon dhe shkruan. Nuk thotë asgjë për programin që nisët brenda atij sesioni: një klient baze të dhënash, një port i ridrejtuar ose një skript i gjatë mund të jenë bllokuar ndërsa transporti u përgjigjet provave me gëzim.

TCPKeepAlive është një mekanizëm i veçantë një shtresë më poshtë. E trajton kerneli, nuk është i kriptuar, dhe një palë tjetër, demoni SSH i së cilës është bllokuar, mund ta përmbushë ende. Prandaj prova në nivelin SSH është sinjali më kuptimplotë kur ju intereson sesioni dhe jo soketi.

Renditja vendos cila vlerë mbijeton

OpenSSH zbaton vlerën e parë që merr për çdo parametër, prandaj një bllok Host i veçantë duhet të shfaqet para çdo blloku më të gjerë që do të përputhej gjithashtu. Vendosni vlerat e paracaktuara me karaktere të gjera në fund të skedarit, jo në krye, dhe mbani mend se një bllok Match më poshtë nuk mund të anulojë një vlerë të vendosur tashmë. Referenca e konfigurimit të klientit OpenSSH e shpreh drejtpërdrejt rregullin e vlerës së parë, dhe ia vlen ta lexoni një herë përpara se të riorganizoni një konfigurim të përbashkët.

Opsionet e rreshtit të komandës fitojnë mbi skedarin, gjë që e bën të lirë një eksperiment të përkohshëm:

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

Për të parë çfarë ka zgjidhur vërtet klienti dhe jo çfarë mendoni se keni shkruar, kërkoni që ai të nxjerrë konfigurimin efektiv. Dalja përmban vlerat e bashkuara për atë emër hosti dhe është mënyra më e shpejtë për të kapur një bllok të mëparshëm të humbur:

ssh -G office-shell | grep -i alive

Çfarë bëjnë keepalive përmes një tuneli

Trafiku periodik nuk lejon që të skadojë një hartëzim NAT ose muri zjarri me gjendje, gjë që është një përfitim i vërtetë në një VPN, portiku i së cilës i hedh poshtë rrjedhat joaktive pas disa minutash. Provat që vijnë çdo 60 sekonda e rifreskojnë atë hartëzim pa mbajtur asnjë të dhënë aplikacioni.

Nuk mund të rindërtojnë një rrugë që ka humbur. Kur ndërfaqja e tunelit zhduket, provat dështojnë si gjithçka tjetër, dhe sesioni mbaron sapo numri shteron. Zbulimi i gjallërisë dhe rikuperimi i rrugës janë probleme të ndryshme, dhe vetëm i pari konfigurohet në ssh_config. Ajo që intervali dhe numri ju blejnë vërtet është sa shpejt e vë re klienti, dhe pikërisht këtë përdoruesi e përjeton si ngecje.

Lidhjet e shumëfishta shtojnë një palosje. Kur ControlMaster është në lojë, provat i përkasin lidhjes kryesore, dhe një sesion i ri mbi një kryesore ekzistuese trashëgon atë që ajo kryesorja negocioi. Nëse kryesorja e mux është bllokuar, hapja e një dritareje tjetër nuk do ta testojë përsëri rrugën.

Konfirmimi i konfigurimit nga fillimi në fund

Në server, nxirrni konfigurimin efektiv të demonit në vend që të lexoni skedarin dhe të hamendësoni cili include fitoi:

sshd -T | grep -i clientalive

Pastaj vëzhgoni një sesion të vërtetë me daljen e korrigjimit të aktivizuar. Klienti printon një rresht të skadimit të kohës kur numri shteron, dhe vulat kohore përreth tregojnë nëse heshtja ishte e vazhdueshme ose provat nuk u dërguan fare. Një sesion që vdes pa trafik provash zakonisht e mban fjalën kyçe në një bllok që nuk përputhej kurrë.

Vlen të shtohen dy kontrolle për çdo host që e arrini vetëm përmes një tuneli: konfirmoni që intervali i zgjidhur është ai që synonit, dhe që ai interval i shumëzuar me numrin është më i shkurtër sesa koha e papunësisë në portikun e VPN. Kur numri i dytë është më i madh, portiku e hedh poshtë rrjedhën në heshtje i pari dhe prova SSH nuk ka kurrë rast të raportojë ndonjë gjë.