VPN પર SSH ServerAliveInterval: પ્રોબ કઈ બાજુ મોકલે છે?

SSH સત્રને જીવંત રાખવાની મોટાભાગની સલાહ «ServerAliveInterval 30 ઉમેરો» પર અટકી જાય છે અને ઉપયોગી ભાગો બહાર રહી જાય છે. કીવર્ડ ક્લાયન્ટ બાજુનું ટાઇમર છે જે ફક્ત ત્યારે જ ચાલુ થાય છે જ્યારે ચેનલ શાંત રહી હોય, તે સેકન્ડની જગ્યાએ અનુત્તરિત પ્રોબ ગણે છે, અને તે એવી ફાઇલમાં રહે છે જ્યાં પ્રથમ મળતું મૂલ્ય જીતે છે. આ ત્રણ ગુણધર્મોમાં ભૂલ કરો તો સ્વસ્થ VPN સત્ર પણ તૂટી પડશે, જ્યારે મૃત સત્ર લટકતું રહેશે.

બે દિશાઓ જુદા જુદા ડિમનની છે

ServerAliveInterval તમારો ssh ક્લાયન્ટ વાંચે છે. ClientAliveInterval સામી બાજુનો sshd વાંચે છે અને વિરુદ્ધ દિશામાં, સર્વરથી ક્લાયન્ટ તરફ પ્રોબ કરે છે. તે અલગ નામો નથી અને સાથે કામ કરતા નથી, તેથી એક સેટ કરવાથી બીજી બાજુના વર્તન પર કોઈ અસર થતી નથી. તેમને ભેળવી દેવા એ સામાન્ય કારણ છે કે એક હોસ્ટ પર સુધારો કામ કરતો દેખાય છે અને આગલા પર નહીં.

બંને શૂન્ય સ્વીકારે છે. શૂન્ય પર ક્લાયન્ટ બિલકુલ કંઈ મોકલતો નથી, અને સર્વર બાજુએ શૂન્ય ClientAliveCountMax તે ડિસ્કનેક્ટ બંધ કરે છે જે અન્યથા અનુત્તરિત તપાસ પછી થાત.

પ્રોબ શું સાબિત કરે છે અને શું નહીં

ગોઠવેલો અંતરાલ વીતી ગયા પછી પણ સર્વરથી કોઈ ડેટા ન આવે તો ક્લાયન્ટ હાલની એન્ક્રિપ્ટેડ ચેનલ દ્વારા નાની વિનંતી મોકલે છે અને જવાબની રાહ જુએ છે. ServerAliveCountMax નક્કી કરે છે કે સત્ર તૂટે તે પહેલાં તેમાંથી કેટલા અનુત્તરિત રહી શકે. 60 અંતરાલ અને 3 ગણતરી સાથે ક્લાયન્ટ લગભગ ત્રણ મિનિટની શાંતિ પછી હાર માને છે, અને તે આંકડો તમારી ગોઠવણીનો ગુણધર્મ છે, નેટવર્ક ધોરણ નહીં. અંતરાલને તેના ડિફોલ્ટ 0 પર રાખો તો કોઈ પ્રોબ કદી મોકલાતો નથી, તેથી જ સ્ટોક ક્લાયન્ટ મૃત કનેક્શન પર અનિશ્ચિત સમય સુધી બેસી શકે છે.

આ આદાનપ્રદાન SSH ટ્રાન્સપોર્ટની અંદર ચાલે છે, તેથી જવાબ સાબિત કરે છે કે સામી બાજુની SSH પ્રક્રિયા હજી વાંચે અને લખે છે. તે તમે તે સત્રની અંદર શરૂ કરેલા પ્રોગ્રામ વિશે કંઈ કહેતું નથી: ડેટાબેઝ ક્લાયન્ટ, ફોરવર્ડ કરેલો પોર્ટ કે લાંબા સમય ચાલતી સ્ક્રિપ્ટ અટવાયેલી હોઈ શકે જ્યારે ટ્રાન્સપોર્ટ આનંદથી પ્રોબના જવાબ આપતું હોય.

TCPKeepAlive એક સ્તર નીચેની અલગ પદ્ધતિ છે. કર્નલ તેને સંભાળે છે, તે એન્ક્રિપ્ટેડ નથી, અને જેનો SSH ડિમન અટવાયેલો છે તેવો સામો પક્ષ પણ તેને સંતોષી શકે છે. તેથી જ સોકેટને બદલે સત્ર તમારા માટે મહત્વનું હોય તો SSH સ્તરનો પ્રોબ વધુ અર્થપૂર્ણ સંકેત છે.

ક્રમ નક્કી કરે છે કે કયું મૂલ્ય ટકશે

OpenSSH દરેક પરિમાણ માટે મળેલું પ્રથમ મૂલ્ય લાગુ કરે છે, તેથી ચોક્કસ Host બ્લોક કોઈપણ વિશાળ બ્લોક પહેલાં આવવો જોઈએ જે પણ મેળ ખાતો હોય. વાઇલ્ડકાર્ડ ડિફોલ્ટ ફાઇલના તળિયે મૂકો, ઉપર નહીં, અને યાદ રાખો કે નીચેનો Match બ્લોક પહેલેથી સેટ કરેલા મૂલ્યને બાજુએ ન કરી શકે. OpenSSH ક્લાયન્ટ ગોઠવણી સંદર્ભ પ્રથમ-મૂલ્યનો નિયમ સીધો જણાવે છે, જે શેર કરેલી ગોઠવણી ફરીથી ગોઠવતા પહેલાં એક વાર વાંચવા યોગ્ય છે.

કમાન્ડ-લાઇન વિકલ્પો ફાઇલ પર જીતે છે, જે કામચલાઉ પ્રયોગને સસ્તો બનાવે છે:

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

તમે શું લખ્યું છે એવું ધારો છો તેના બદલે ક્લાયન્ટે ખરેખર શું ઉકેલ્યું તે જોવા માટે તેને અસરકારક ગોઠવણી ડમ્પ કરવા કહો. આઉટપુટમાં તે હોસ્ટનામ માટે એકત્રિત મૂલ્યો હોય છે અને તે પહેલાના ભટકતા બ્લોકને પકડવાનો સૌથી ઝડપી રસ્તો છે:

ssh -G office-shell | grep -i alive

ટનલ પર કીપઅલાઇવ શું કરે છે

સામયિક ટ્રાફિક સ્ટેટફુલ NAT કે ફાયરવોલ મેપિંગને સમાપ્ત થતું અટકાવે છે, જે એવી VPN પર સાચો ફાયદો છે જેનું ગેટવે થોડી મિનિટો પછી નિષ્ક્રિય પ્રવાહો ફેંકી દે છે. દર 60 સેકન્ડે આવતા પ્રોબ કોઈ એપ્લિકેશન ડેટા વહન કર્યા વિના તે મેપિંગને તાજું કરે છે.

તેઓ ગયેલો માર્ગ ફરી બનાવી શકતા નથી. જ્યારે ટનલ ઇન્ટરફેસ અદૃશ્ય થાય ત્યારે બાકીના બધાની જેમ પ્રોબ પણ નિષ્ફળ જાય છે, અને ગણતરી ખતમ થતાં સત્ર પૂરું થાય છે. જીવંતતા શોધ અને માર્ગ પુનઃપ્રાપ્તિ જુદી સમસ્યાઓ છે, અને ફક્ત પ્રથમ જ ssh_config માં ગોઠવી શકાય છે. અંતરાલ અને ગણતરી ખરેખર તમને જે આપે છે તે એ છે કે ક્લાયન્ટ કેટલી ઝડપથી ધ્યાન આપે છે, અને તે જ ભાગ છે જે વપરાશકર્તા હેંગ તરીકે અનુભવે છે.

મલ્ટિપ્લેક્સ કનેક્શન એક ગડી ઉમેરે છે. ControlMaster રમતમાં હોય ત્યારે પ્રોબ મુખ્ય કનેક્શનના હોય છે, અને હાલના મુખ્ય પરનું નવું સત્ર તે મુખ્યએ વાટાઘાટ કરેલું બધું વારસામાં લે છે. જો mux મુખ્ય અટવાયેલું હોય તો બીજી વિન્ડો ખોલવાથી માર્ગ ફરી ચકાસાશે નહીં.

ગોઠવણીને શરૂઆતથી અંત સુધી ખાતરી કરવી

સર્વર પર ફાઇલ વાંચીને કયો include જીત્યો તે અનુમાન કરવાને બદલે અસરકારક ડિમન ગોઠવણી ડમ્પ કરો:

sshd -T | grep -i clientalive

પછી ડિબગ આઉટપુટ ચાલુ રાખીને વાસ્તવિક સત્ર જુઓ. ગણતરી પૂરી થાય ત્યારે ક્લાયન્ટ ટાઇમઆઉટ લાઇન છાપે છે, અને તેની આસપાસના ટાઇમસ્ટેમ્પ દર્શાવે છે કે શાંતિ સતત હતી કે પ્રોબ બિલકુલ મોકલાયા જ નહોતા. કોઈ પ્રોબ ટ્રાફિક વિના મરતું સત્ર સામાન્ય રીતે કીવર્ડને એવા બ્લોકમાં ધરાવે છે જે કદી મેળ ખાધો નહોતો.

ફક્ત ટનલ દ્વારા પહોંચાતા કોઈપણ હોસ્ટ માટે બે તપાસ ઉમેરવા યોગ્ય છે: ખાતરી કરો કે ઉકેલાયેલો અંતરાલ તમે ઇચ્છતા હતા તે જ છે, અને ખાતરી કરો કે તે અંતરાલ ગણતરીથી ગુણાકાર કરતાં VPN ગેટવે પરના નિષ્ક્રિય ટાઇમઆઉટ કરતાં ટૂંકો છે. જ્યારે બીજો આંકડો મોટો હોય ત્યારે ગેટવે પહેલા ચૂપચાપ પ્રવાહ ફેંકી દે છે અને SSH પ્રોબને કંઈ જાણ કરવાની તક મળતી જ નથી.