PPPoE पर OpenVPN: link-mtu, tun-mtu या mssfix घटाएँ?

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

तीन विकल्प इसे ठीक कर सकते हैं, और वे अलग-अलग परतों पर काम करते हैं। गलत चुनाव या तो कुछ नहीं करता या सुरंग को नए तरीके से नाज़ुक बना देता है, इसलिए चुनाव इससे शुरू होता है कि मार्ग वास्तव में क्या सहन करता है।

तीन नॉब, तीन अलग परतें

link-mtu बाहरी बजट है: एन्क्रिप्टेड पेलोड के साथ OpenVPN हेडर, UDP हेडर और बाहरी IP हेडर। यह बताता है कि मशीन से क्या निकलता है, और इसीलिए यह वह संख्या है जिसे भौतिक मार्ग सीमित करता है।

tun-mtu आंतरिक बजट है: वह इंटरफ़ेस जो आपका ट्रैफ़िक देखता है। यह मार्ग जितना ढो सकता है उससे ठीक सुरंग के ओवरहेड जितना बड़ा है, और OpenVPN सामान्यतः इसे व्युत्पन्न करता है, आपको सेट करने के लिए मजबूर करने के बजाय।

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

यदि आप link-mtu स्पष्ट रूप से सेट करते हैं, तो OpenVPN आंतरिक MTU निकालने के लिए अपना ओवरहेड घटाता है। वह ओवरहेड कोई निश्चित स्थिरांक नहीं है; यह सिफ़र और प्रमाणीकरण पर निर्भर करता है, इसीलिए किसी फ़ोरम से कॉपी किया गया मान दूसरी प्रोफ़ाइल पर गलत हो सकता है। link-mtu और tun-mtu दोनों सेट करने से क्लाइंट को दो परस्पर विरोधी निर्देश मिलते हैं।

कोई भी संख्या चुनने से पहले मार्ग मापें

भौतिक इंटरफ़ेस से मापें, सुरंग के अंदर से नहीं, और याद रखें कि पिंग पेलोड बताता है, पैकेट का आकार नहीं। पेलोड की तुलना 1500 बाइट के फ़्रेम से करने से पहले IPv4 और ICMP हेडर के लिए 28 बाइट जोड़ें, और जब कोई साथी अलग संख्या बताए तो यह सुधार ध्यान में रखें।

Linux क्लाइंट पर, ping -M do -s 1472 फ़्रैगमेंटेशन को मना करता है और पैकेट बहुत बड़ा होने पर विफल हो जाता है। पेलोड तब तक घटाएँ जब तक वह पार न हो जाए, फिर मार्ग की MTU पाने के लिए 28 जोड़ें। PPPoE का खर्च 8 बाइट है, इसलिए DSL पर 1492 सामान्य है। DS-Lite और कुछ मोबाइल मार्गों का खर्च 40 या अधिक है, और उत्तर आमतौर पर नाममात्र लिंक गति के संकेत से कम होता है।

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

पहले TCP को सीमित करें, फिर सुरंग को सिकोड़ें

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

जब प्रभावित ट्रैफ़िक TCP न हो तो आंतरिक MTU घटाएँ। UDP सेवा, सुरंग के अंदर की सुरंग, या पूरे आकार के डेटाग्राम भेजने वाला एप्लिकेशन MSS सीमा के बाद भी विफल रहेगा क्योंकि कोई भी उसका पैकेट आकार फिर से नहीं लिखता। उस स्थिति के लिए tun-mtu घटाएँ, या link-mtu सेट करें और क्लाइंट को आंतरिक मान व्युत्पन्न करने दें, लेकिन दोनों कभी नहीं।

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

छोटी जाँचें क्यों काम करती रहती हैं

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

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

जब IPv6 सुरंग पर चलता है तो आंतरिक MTU को कभी 1280 से नीचे न ले जाएँ, क्योंकि यह वह न्यूनतम है जो हर IPv6 लिंक को ढोना होता है। छोटी MTU मार्ग के बारे में तथ्य है, भावना से ट्यून करने वाली प्रदर्शन सेटिंग नहीं।