OpenVPN mssfix: बड़े स्थानांतरणों में एक क्लाइंट क्यों अटक जाता है

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

विकल्प क्या फिर से लिखता है

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

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

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

सीमा टनल के भीतर TCP है

केवल TCP ट्रैफ़िक फिर से लिखा जाता है। QUIC सत्र, गेम या बड़े UDP डेटाग्राम भेजने वाला अनुप्रयोग अपने पैकेट आकार रखेगा, और यदि वही स्थानांतरण अटकते हैं, तो समाधान बल्कि टनल या पथ के MTU पर है। TCP विकल्प की ओर बढ़ने से पहले पढ़ें कि विफल स्थानांतरण कौन सा प्रोटोकॉल इस्तेमाल करता है, क्योंकि गलत परत का अपना समाधान होता है।

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

संख्या और कीवर्ड पोर्टेबल नहीं हैं

OpenVPN 2.6 का समुदाय संस्करण मान के बाद एक वैकल्पिक कीवर्ड स्वीकार करता है। mtu के साथ, संख्या IP और UDP हेडर सहित बाहरी पैकेट आकार बताती है; इसके बिना, तर्क दूसरी लेखा परंपरा का पालन करता है। इसलिए संस्करणों के बीच कॉपी की गई पंक्ति एक ही पैकेट बजट नहीं बताती। किसी दूसरे संस्करण के ट्यूटोरियल के बजाय उस बिल्ड के साथ आने वाला मैनुअल पृष्ठ देखें जिसे आप वास्तव में चलाते हैं।

सिंटैक्स ऐसा दिखता है:

mssfix 1400 mtu

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

पहले उस एक क्लाइंट पर पुष्टि करें

कुछ भी बदलने से पहले विफल मशीन से पथ मापें। जो पेलोड पथ बिना विखंडन के ले जा सकता है, वही आपकी खोजी संख्या है:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

पहला प्रोब 28 बाइट हेडर जोड़ने पर 1500 बाइट के पैकेट में फ़िट होता है। यदि यह विखंडन त्रुटि से विफल हो और छोटा सफल हो, तो उपयोगी आकार उनके बीच कहीं है, और टनल का ओवरहेड ऊपर से घटाया जाता है।

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