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 प्रोब को कुछ भी रिपोर्ट करने का मौका नहीं मिलता।