VPN पर SSH हर मिनट टूटता है? वजह keepalive नहीं है

SSH जुड़ता है, लगभग एक मिनट काम करता है, और फिर हर बार लगभग उसी अंतराल पर जम जाता है। आम व्याख्या निष्क्रिय टाइमआउट है, इसलिए लोग MTU घटाते हैं और क्लाइंट keepalives सेट करते हैं। जिस WireGuard लिंक पर मैंने काम किया था, वह यह सब पहले ही झेल चुका था: छोटा टनल MTU, client-alive सेटिंग्स, कॉन्फ़िगर किया गया टनल keepalive। ब्रेक बिना बदलाव के जारी रहे। वजह एक असममित LAN रूट निकली, और यह पैटर्न पहचानने लायक है क्योंकि यह टाइमर-आधारित हर ठीक को हरा देता है।

keepalive साबित करता है कि आपका होस्ट अभी भी भेजने को तैयार है। यह स्थिति रखने वाले डिवाइस को ऐसा जवाब नहीं दिखा सकता जो कभी उससे नहीं गुज़रता।

मिथक: keepalives चुपचाप टूटना ठीक करते हैं

SSH keepalives एक ही काम के लिए हैं: किसी ऐसी चीज़ को, जो खामोशी गिनती है, निष्क्रिय सत्र हटाने से रोकना। वे यह अच्छी तरह करते हैं। वे स्थिति रखने वाले डिवाइस की समस्या नहीं सुलझाते जिसने एक दिशा में पहला पैकेट देखा और फिर कभी जवाब नहीं देखा, क्योंकि क्लाइंट जो भेजता है उससे यह नहीं बदलता कि जवाब कौन-सा इंटरफ़ेस इस्तेमाल करता है।

MTU बदलना दूसरा लोकप्रिय उपाय है, और उसका भी वही विफलता ढंग है। MTU घटाना फ़्रैगमेंटेशन और पाथ-MTU समस्याओं में मदद करता है, और रूट के लिए कुछ नहीं करता। अगर आपके टाइमर और MTU पहले से उचित हैं और ब्रेक अब भी दोहराए जाने वाले अंतराल पर है, तो अंतराल आपको कहीं टाइमआउट के बारे में बता रहा है, पैकेट के आकार के बारे में नहीं। अंतराल लिख लें और पाथ के हर डिवाइस पर स्थिति टाइमआउट से तुलना करें।

संकेत नियमितता है, साथ में ऐसा सत्र जो उस अंतराल के भीतर इस्तेमाल योग्य रहता है। निष्क्रिय टाइमआउट तब मारते हैं जब कुछ नहीं होता; यह तब मारता है जब आप टाइप कर रहे होते हैं।

अतिरिक्त गेटवे असल में क्या करता है

लैपटॉप और VPN गेटवे को एक ही LAN पर रखें, अलग LAN फ़ायरवॉल को डिफ़ॉल्ट गेटवे बनाएँ। लैपटॉप VPN की ओर जाने वाला ट्रैफ़िक फ़ायरवॉल को भेजता है, फ़ायरवॉल उसे गेटवे तक भेजता है, और गेटवे के जवाब सीधे LAN के पार लैपटॉप तक लौटते हैं। वह दूसरा पैर कभी फ़ायरवॉल से नहीं गुज़रता, इसलिए उसकी स्थिति तालिका आधा कनेक्शन रखती है।

नीचे दिए पते उसी व्यवस्था को दर्शाते हैं:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

रीडायरेक्ट और स्थिति-प्रबंधन फिर एक काम करते हैंडशेक को ऐसे कनेक्शन में बदल देते हैं जो तुरंत नहीं, बाद में मरता है। देरी स्थिति प्रविष्टि के पुराने होने या कड़ी जाँच विफल होने से है, इसीलिए अंतराल इतना यांत्रिक दिखता है।

इनमें से कुछ भी क्लाइंट कॉन्फ़िगरेशन में नहीं दिखता, इसीलिए इसकी खोज आमतौर पर गलत फ़ाइल में शुरू होती है।

एक सोचा-समझा रास्ता चुनें

ऊपर की व्यवस्था के लिए, दूरस्थ सबनेट को सीधे VPN गेटवे पर रूट करना आधा कनेक्शन हटा देता है:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

ये उदाहरण पते हैं। अगला हॉप आपके LAN पर पहुँचने योग्य होना चाहिए, प्रीफ़िक्स इच्छित दूरस्थ नेटवर्क होना चाहिए, और दूसरा कमांड उस पर भरोसा करने से पहले परिणाम दिखाता है। अगर गेटवे आपके सबनेट पर नहीं है, तो यह रूट वह ठीक नहीं है जो आप चाहते हैं।

अगर फ़ायरवॉल का काम उन सिस्टमों के बीच ट्रैफ़िक की निगरानी करना है, तो उसके चारों ओर से रूट करना गलत डिज़ाइन है। इसके बजाय दोनों दिशाओं को सीमा पार करने दें और हर तरफ़ के रूट इस तरह कॉन्फ़िगर करें कि वापसी का रास्ता मेल खाए। लक्ष्य एक सोचा-समझा रास्ता है, कम स्थिति-जाँच नहीं।

Netgate के असममित रूटिंग पर नोट्स उसी इंटरफ़ेस-स्तरीय असममिति और उससे बनने वाली स्थिति समस्याओं का वर्णन करते हैं, इसलिए स्थिति-प्रबंधन को वैश्विक रूप से ढीला करने से पहले उन्हें पढ़ें। इस मामले जैसे समयबद्ध डिस्कनेक्ट अपने आप में सबूत नहीं हैं। लेख को एक विफलता ढंग का वर्णन मानें, फिर वैश्विक स्थिति नीति बदलने से पहले साबित करें कि आपका अपना नेटवर्क उससे मेल खाता है।

दोनों सिरों से परखें

लैपटॉप का गंतव्य की ओर रूट और गंतव्य का लैपटॉप की ओर वापसी रूट पढ़ें; ये दो अलग फ़ैसले हैं और संभवतः उनमें से सिर्फ़ एक गलत है। गेटवे से ही सफल ping समस्या को पूरी तरह छिपा सकता है, क्योंकि वह उस मशीन से शुरू होता है जिसका रास्ता पहले से सही है। आपको असली सत्र के दोनों सिरों की नज़र से दोनों दिशाएँ चाहिए।

ठीक करने के बाद SSH फिर खोलें और सत्र को उस अंतराल से काफ़ी आगे तक खुला रखें जो पहले विफल होता था। फिर मंज़ूर नेटवर्क कॉन्फ़िगरेशन में रूट को स्थायी बनाएँ, क्योंकि एकबारगी कमांड रीबूट योजना नहीं है और अगली बार रीबूट पर समस्या नई पहेली के साथ लौटेगी।

असममिति कब ठीक है

असममित रूटिंग कई नेटवर्क में सामान्य है और परिभाषा से टूटी नहीं है। यह समस्या तब बनती है जब स्थिति-ट्रैकिंग, अनुवाद या नीति ऐसे रास्ते को देखने पर निर्भर हों जिसे वे नहीं देखते, और इनमें से हर एक का इलाज अलग है। उसके इर्द-गिर्द नया डिज़ाइन करने से पहले जाँचें कि बीच का डिवाइस असल में क्या माँगता है।

टिकाऊ जवाब दोनों रास्तों के नाम बताता है, उस डिवाइस का नाम बताता है जिसे दोनों देखने हैं, और उस रूट का नाम बताता है जो यह संभव बनाता है। अगर आप डिवाइस का नाम नहीं बता सकते, तो आपने अभी तक कारण नहीं खोजा।