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 प्रोबले केही रिपोर्ट गर्ने मौका पाउँदैन।