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

तीन शर्तें उत्तर तय करती हैं: पीयर क्या तुलना करते हैं, मान पुराना है या नहीं, और चेतावनी से परे कौन-सा लक्षण मौजूद है।

चेतावनी पैकेट नहीं, विकल्पों की तुलना करती है

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

पूरी चेतावनी को उसके स्थानीय और दूरस्थ मान के साथ रखें। जोड़ी ही प्रमाण है; आपको याद रहने वाली अकेली संख्या नहीं।

link-mtu पुराना क्यों है

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

संगति जाँच में tun-mtu से जुड़ा एक वैकल्पिक OCC मान भी है, जो नेटवर्क क्या ले जाता है उसे बदले बिना तुलना का विषय बदल देता है। उसे सेट करने से बड़े पैकेट भीतर नहीं आ जाते।

पथ का परीक्षण करने से पहले प्रोफ़ाइल ठीक करें

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

साझा सर्वर में वैश्विक मान हिलाने से पहले उसकी क्लाइंट सूची जाँची जानी चाहिए, क्योंकि एक साइट के लिए उपयुक्त मान दूसरी साइट को तोड़ सकता है।

फिर उस लक्षण का परीक्षण करें जो वास्तव में आपके पास है

यदि बड़े स्थानांतरण अटक जाते हैं जबकि छोटे अनुरोध सफल होते हैं, तो नियंत्रित गंतव्य के विरुद्ध पैकेट का आकार मापें। ‘विखंडन न करें’ बिट सेट करके पेलोड का आकार बढ़ाने वाला प्रोब पथ का उपयोगी MTU केवल सफल होने वाले ping की तुलना में कहीं अधिक भरोसेमंद ढंग से खोजता है। परीक्षण में विफल एप्लिकेशन को भी शामिल करें: ICMP समय-समाप्ति फ़िल्टरिंग दर्शा सकती है, और छोटा सफल ping पूर्ण आकार के एप्लिकेशन पैकेट के बारे में कुछ नहीं कहता।

mssfix टनल के भीतर TCP सत्रों के लिए घोषित MSS को सीमित करता है, जो TCP की मदद करता है और आंतरिक UDP भार के लिए कुछ नहीं करता। विखंडन और ऑफ़लोड सेटिंग्स की अपनी संगतता शर्तें हैं। लॉग की एक पंक्ति शांत करने के लिए कई चीजें एक साथ बदलने के बजाय सिद्ध समस्या के लिए एक तंत्र चुनें।

प्रभावी मान परिणाम के साथ रखें

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

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

संबंधित लेख