VPN MTU के मिथक: आपके पैकेट क्यों सिकुड़ते हैं और जगह कहाँ जाती है

कोई आपसे कहता है कि VPN "MTU की वजह से पैकेट खो रहा है", आप टनल को 1400 पर सेट करते हैं, और ट्रांसफ़र फिर काम करने लगता है। वह नतीजा निदान जैसा लगता है। आमतौर पर यह अंकगणित का संयोग है: आपने ऐसी संख्या चुनी जो उस सीमा के नीचे फ़िट होने के लिए काफ़ी छोटी है जिसे आपने कभी पहचाना ही नहीं, और अगले नेटवर्क पर अलग बजट के साथ आप फिर उसी सीमा से मिलेंगे।

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

पहला मिथक: टनल का MTU ही पथ का MTU है

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

पथ-MTU खोज दोनों में तालमेल बैठाने के लिए है, और यह प्रतिक्रिया पर निर्भर करती है। IPv4 में, जो राउटर पूरे आकार का पैकेट आगे नहीं भेज सकता उसे ICMP "fragmentation needed" संदेश भेजना चाहिए, और प्रेषक अपना अनुमान घटा देता है। IPv6 में इसका समकक्ष Packet Too Big संदेश है, और राउटर ट्रांज़िट में बिल्कुल फ़्रैगमेंट नहीं करते। जब वह प्रतिक्रिया फ़िल्टर हो जाती है, तो प्रेषक ऐसे पैकेट बनाता रहता है जिन्हें पथ ढो नहीं सकता, और कोई उसे कारण नहीं बताता।

दूसरा मिथक: एनकैप्सुलेशन की कीमत एक हेडर है

बाहरी परतों को ईमानदारी से गिनें। बाहरी IP हेडर IPv4 में 20 बाइट या IPv6 में 40 है। NAT पार करने के लिए UDP एनकैप्सुलेशन 8 जोड़ता है। टनल प्रोटोकॉल अपना हेडर जोड़ता है, एक इनिशियलाइज़ेशन वेक्टर या nonce, सिफ़र के ब्लॉक या संरेखण सीमा तक पैडिंग, एक ट्रेलर और एक इंटीग्रिटी जाँच मान। प्रोटोकॉल और सिफ़र के अनुसार, भीतरी पैकेट शुरू होने से पहले ही कुल आराम से दर्जनों बाइट में पहुँच जाता है।

फिर भीतरी पैकेट के अपने हेडरों के लिए दोबारा घटाएँ। टनल के भीतर TCP खंड अपना 20 बाइट का IP हेडर और 20 बाइट का TCP हेडर ढोता है, और TCP का MSS MTU से निकलता है, टनल के नाममात्र पेलोड से नहीं। इसलिए ping छोटे पेलोड के साथ सफल हो सकता है जबकि फ़ाइल ट्रांसफ़र अटक जाता है: उपकरण अलग-अलग चीज़ें जाँचते हैं, और उनमें से सिर्फ़ एक पूरे आकार का TCP खंड आज़माता है।

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

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

तीसरा मिथक: PPPoE अब भी आपको साफ़ 1500 देता है

पारंपरिक PPPoE एक्सेस लिंक 1500 बाइट का IP पैकेट नहीं ढोता। PPPoE हेडर और PPP प्रोटोकॉल फ़ील्ड Ethernet फ़्रेम के भीतर 8 बाइट लेते हैं, जिससे IP पैकेट के लिए 1492 बचते हैं। यह RFC 2516 में वर्णित पारंपरिक सीमा है। अगर आप ऐसे लिंक पर VPN चलाते हैं, तो टनल का ओवरहेड उन्हीं 1492 में से आता है, 1500 में से नहीं।

RFC 4638 बड़े PPP पेलोड पर बातचीत का तरीक़ा परिभाषित करता है जब एक्सेस कॉन्संट्रेटर और ग्राहक उपकरण दोनों इसका समर्थन करते हैं, इसलिए "यह कनेक्शन PPPoE इस्तेमाल करता है" अकेला कोई ख़ास संख्या साबित नहीं करता। स्थानीय सेटिंग बीच के उपकरण को ऐसा पैकेट स्वीकार करने पर मजबूर नहीं कर सकती जिसके लिए उसे कभी कॉन्फ़िगर ही नहीं किया गया, इसलिए उपयोगी सवाल यह है कि लिंक ने असल में किस पर बातचीत की, यह नहीं कि लेबल क्या कहता है।

विफलता चुनिंदा क्यों दिखती है

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

दूसरी, संबंधित ग़लती तीन संख्याओं को मिला देना है: इंटरफ़ेस MTU, TCP MSS और प्रोटोकॉल की अपनी फ़्रैगमेंटेशन या पैडिंग सेटिंग। राउटर पर MSS क्लैंपिंग घोषित MSS को फिर से लिखती है ताकि प्रेषक छोटे खंड बनाए; यह टनल MTU नहीं बदलती और UDP ट्रैफ़िक की मदद नहीं करती। संबंधित दिखने की वजह से तीनों को एक ही संख्या देना वह तरीक़ा है जिससे अच्छे इरादे का बदलाव काम करता सेटअप तोड़ देता है।

क्या बदलें, और किस क्रम में

सबूत से शुरू करें। ऊपर के प्रोब से पुष्टि करें कि ख़राबी आकार-निर्भर है, फिर सबसे छोटा आकार ढूँढें जो पार होता है और सबसे बड़ा जो विफल होता है। टनल को दोष देने से पहले एक्सेस लिंक का असली MTU जाँचें; PPPoE लिंक आपके VPN के उसे छूने से पहले ही बजट सीमित कर देता है। मूल मान नोट करें ताकि बदलाव वापस लिया जा सके।

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