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 प्रोबला काहीही कळवण्याची संधीच मिळत नाही।