VPN के ज़रिए पाथ MTU का पता लगाना: आकार और ICMP की खाई

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

पाथ MTU वास्तव में क्या मापता है

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

टनल के लिए, मायने रखने वाली संख्या भीतरी MTU है, जो बाहरी पाथ का भत्ता है घटाकर वह जो एन्कैप्सुलेशन खर्च करता है। WireGuard बाहरी IP हेडर और UDP हेडर जोड़ता है; अन्य ट्रांसपोर्ट अपने जोड़ते हैं। भीतरी आकार बहुत ऊँचा रखें तो हर पूर्ण-आकार पैकेट को फ़्रैगमेंटेशन चाहिए जो शायद कभी न हो।

टनल उपयोगी पैकेट को क्यों छोटा करती है

अगर टनल इंटरफ़ेस भौतिक कड़ी का MTU रखता है, तो हर बड़ा पैकेट नीचे की ओर किसी के उसे फ़्रैगमेंट करने के लिए तैयार होने पर निर्भर है। IPv4 सिद्धांत रूप में इसे अनुमति देता है, लेकिन जिस राउटर को फ़्रैगमेंट न करने को कहा गया हो वह इसके बजाय त्रुटि लौटाता है। IPv6 राउटर ट्रांज़िट में कभी फ़्रैगमेंट नहीं करते, इसलिए वही सेटिंग पता परिवार के अनुसार अलग व्यवहार करती है। दोनों तरह से प्रेषक तब तक कुछ नहीं सीखता जब तक कोई वापस रिपोर्ट न करे।

व्यावहारिक परिणाम वह आकार है जो हैंडशेक में फिट होता है और पेलोड में नहीं। TLS ClientHello या DNS क्वेरी इतनी छोटी है कि सिकुड़े पाथ को बिना छुए पार कर जाए, जबकि बड़ा ट्रांसफ़र नहीं। इसलिए लक्षण विशिष्ट होस्ट के बजाय विशिष्ट क्रियाओं के आसपास जमा होते हैं।

पता लगाना तभी काम करता है जब फ़ीडबैक पहुँचता है

IPv4 में पता लगाना don't-fragment बिट पर निर्भर है: जो राउटर पैकेट आगे नहीं भेज सकता वह अगली हॉप के MTU के साथ ICMP fragmentation-needed लौटाता है, और प्रेषक अपना अनुमान घटा देता है। IPv6 इसके बजाय Packet Too Big संदेश इस्तेमाल करता है, क्योंकि राउटर ट्रांज़िट में फ़्रैगमेंट नहीं करते। दोनों तंत्र मानते हैं कि संदेश प्रेषक तक वापस रास्ता खोज लेगा, टनल से होकर और वापसी मार्ग पर किसी भी फ़ायरवॉल से आगे। जब यह मान्यता विफल होती है, प्रेषक ऐसा आकार बार-बार आज़माता रहता है जो पाथ उठा नहीं सकता।

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

वही फ़िल्टरिंग टनल के अंदर भी हो सकती है। अगर भीतरी पाथ त्रुटि को गिरा देता है लेकिन बाहरी पाथ उसे ले जाता है, तो प्रेषक ऐसी सीमा के साथ तालमेल बिठा सकता है जिसे एन्कैप्सुलेटेड ट्रैफ़िक कभी वास्तव में देखता ही नहीं।

संख्या का अनुमान लगाने के बजाय पाथ की जाँच करें

गंतव्य, एक्सेस नेटवर्क और टनल स्थिर रखें, फिर केवल पैकेट का आकार बदलें। MTU संकेत के साथ विफल होने वाली don't-fragment जाँच आपको अगली हॉप की सीमा देती है; किसी आकार के पास होने तक दोहराएँ, और आकार तथा पता परिवार दोनों दर्ज करें।

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

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

PLPMTUD, जिसका वर्णन RFC 4821 में है, ऊपर की ओर जाँच करता है और पहुँचाई गई त्रुटियों पर भरोसा करने के बजाय ट्रांसपोर्ट स्वीकृतियाँ इस्तेमाल करता है। यह ICMP फ़िल्टर करने वाले पाथ पर मदद करता है, लेकिन समर्थन स्टैक और एप्लिकेशन के अनुसार बदलता है। TCP फ़्लो अपने आप सुधर सकता है जबकि निश्चित डेटाग्राम आकार वाला UDP एप्लिकेशन विफल होता रहता है।

मान चुनें और तर्क दर्ज करें

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

IPv4 तंत्र का वर्णन RFC 1191 में और IPv6 पैकेटाइज़ेशन मार्गदर्शन RFC 8201 में है; दोनों का नाम लेने से अगला इंजीनियर उस मान्यता को फिर से नहीं निकालता। अगर आपके चुने आकार पर ट्रांसफ़र अब भी अटकता है, तो संख्या घटाना बंद करें और अगली परत देखें। हर आकार पर विफल होने वाला पाथ MTU की समस्या नहीं है।