OpenVPN पर SSH अटक रहा है? पहले पथ MTU मापें

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

प्रोफ़ाइल छूने से पहले विफलता का आकार पढ़ें

छोटे पैकेट पार होते हैं और भरे हुए नहीं। प्रॉम्प्ट, बैनर या एक कुंजी-दबाव आसानी से बैठते हैं; निर्देशिका सूची, डाउनलोड या चिपकाया गया ब्लॉक नहीं। जिस आकार पर व्यवहार बदलता है वही सुराग है, यह नहीं कि SSH ही संबंधित प्रोग्राम है।

तंत्र यह है: पथ MTU की खोज, जो प्रतिक्रिया पर निर्भर है. TCP एक खंड आकार चुनता है, और जब रास्ते का कोई राउटर परिणामी पैकेट आगे नहीं भेज सकता, तो उसे ICMP संदेश से यह बताना चाहिए। एनकैप्सुलेशन बाहरी पैकेट को भीतरी से बड़ा बनाता है, इसलिए टनल के भीतर उपयोगी आकार हमेशा भौतिक लिंक से नीचे रहता है। उन ICMP संदेशों को कहीं भी फ़िल्टर कर दें और प्रेषक को कभी सुधार नहीं मिलेगा, वह भरे खंड भेजता रहेगा, और बाहरी पैकेट बिना सूचना के गिरा दिया जाएगा।

दोनों ओर से सीमा मापें

किसी एक को बदलने से पहले टनल के MTU की भौतिक लिंक से तुलना करें। जिस टनल ने भौतिक मान की नकल की है, वह पहले ही बता चुका है कि असंगति कहाँ है।

टनल के भीतर से विखंडन मना करने वाले अनुरोध से जाँचें, उत्तर आने तक पेलोड घटाते जाएँ। आकार का तर्क केवल पेलोड गिनता है, इसलिए काम करने वाला अंक हमेशा इंटरफ़ेस MTU से नीचे रहता है। इंटरफ़ेस का अंक चाहिए तो हेडर के आकार फिर जोड़ें।

ip link show tun0
ping -M do -s 1380 10.9.0.1

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

mssfix और fragment अलग काम करते हैं

mssfix उस खंड आकार को सीमित करता है जिसकी घोषणा टनल के भीतर के TCP कनेक्शन अपने हैंडशेक में करते हैं। SSH, HTTPS और फ़ाइल प्रतियों के लिए यही सही लीवर है, इसीलिए सेट होते ही रुकावट अक्सर गायब हो जाती है। यह UDP पेलोड को बिल्कुल नहीं छूता।

जो टनल UDP सेवा भी ढोती है, वह SSH ठीक होने के बाद भी विफल रह सकती है, और यह परिणाम हर उसे उलझाता है जो मानता है कि एक विकल्प सब कुछ ढक लेता है।

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

इंटरफ़ेस MTU घटाना मोटा विकल्प है

दोनों सिरों पर इंटरफ़ेस MTU घटाना मोटा औज़ार है। यह हर भीतरी प्रेषक को छोटा अंक बताता है, जो काम करता है, और वह लागत उन TCP प्रवाहों पर डालने के बजाय सारे ट्रैफ़िक पर डाल देता है जिन्हें उसकी ज़रूरत है।

इसे तब चुनें जब टनल ऐसा ट्रैफ़िक ढोती हो जिसे आप सीमित नहीं कर सकते, या जब क्लाइंट ऐसा उपकरण हो जिसकी प्रोफ़ाइल आपके नियंत्रण में न हो। इसे सममित रूप से लागू करें और मान प्रोफ़ाइल के पास दर्ज करें। आधा लागू किया गया बदलाव न होने से भी बुरा है, क्योंकि वह समाधान जैसा दिखता है।

जिस स्थानांतरण ने रोका उसी से फिर परखें

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

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