संदिग्ध VPN MTU समस्या को मान अनुमान लगाए बिना जाँचना

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

संख्या बदलने से पहले पथ तय करें

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

सबसे संकीर्ण उस परीक्षण से शुरू करें जिसे चलाने की आपको अनुमति है। सर्वर पक्ष का बदलाव उस अंतिम बिंदु के हर उपयोगकर्ता तक पहुँचता है, इसलिए वह जाँच के अंत में आता है, शुरुआत में नहीं।

ऐसे आकार से जाँचें जिसे आप नियंत्रित करते हैं

Linux पर जाँच ping -M do -s 1400 host जैसी दिखती है, और Windows पर ping -f -l 1400 host जैसी। दोनों ही स्थितियों में आप पेलोड तय कर रहे हैं, पैकेट का आकार नहीं, क्योंकि IP और ICMP हेडर ऊपर जुड़ते हैं।

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

विफल जाँच MTU सीमा का प्रमाण नहीं है

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

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

एक ऐसा पैरामीटर समायोजित करें जिसे क्लाइंट पहले से समर्थन देता है

वह सेटिंग बदलें जिसे क्लाइंट इस प्रोटोकॉल के लिए दस्तावेज़ित करता है और अंतिम बिंदु तथा गंतव्य को अछूता रहने दें, वरना आपने एक साथ दो चीज़ें बदल दीं। TCP MSS क्लैंप हर UDP भार को नहीं ढकता, इसलिए काम करने लगा ब्राउज़र टनल प्रोटोकॉल को बिल्कुल वैसा ही टूटा छोड़ सकता है। IPv4 और IPv6 यहाँ अलग पथ हैं, क्योंकि हेडर किसी भी रूटिंग से पहले ही भिन्न होते हैं।

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

वापस लेना, सत्यापित करना और लिखना

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

इस अभिलेख को परिवर्तन अनुरोध के साथ रखें, इससे पहले कि कोई परिवर्तन को चौड़ा करे। पथ का MTU खोज तंत्र RFC 1191 में समझाता है कि छोटा मान एक पथ को बचा सकता है और दूसरे के लिए कुछ नहीं करता, और संख्याओं की सूची उस मॉडल का विकल्प नहीं है। जाँच तब पूरी होती है जब आप पथ, आकार, अवलोकन और वह मान बता सकें जिसे आपने बहाल किया।