IPv6 पैकेट बहुत बड़ा: बड़े VPN ट्रांसफ़र क्यों अटकते हैं

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

छोटी माँगें, बड़े अटकाव

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

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

Packet Too Big फ़ीडबैक है, ट्रैफ़िक नहीं

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

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

दोनों एड्रेस परिवारों को अलग-अलग जाँचें

IPv6 को अलग से जाँचें, क्योंकि सफल IPv4 ट्रांसफ़र IPv6 पथ के बारे में कुछ भी साबित नहीं करता। फिर बड़ा ट्रांसफ़र अटकने के दौरान नियंत्रण संदेश कैप्चर करें। दोनों रिकॉर्ड मिलकर या तो दिखाते हैं कि फ़ीडबैक बाहर जा रहा है, या साबित करते हैं कि वह कभी पहुँचा ही नहीं।

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

प्रोब do-not-fragment बिट सेट करके पैकेट भेजता है और वह आकार बताता है जिस पर वह विफल होता है, यही वह संख्या है जिसे टनल को समेटना है। रूट क्वेरी उस इंटरफ़ेस का नाम बताती है जो गंतव्य ले जाएगा, इसलिए आप जानते हैं कि किस लिंक का MTU लागू होता है। कैप्चर ICMPv6 प्रकार 2, यानी Packet Too Big संदेश, फ़िल्टर करता है और दिखाता है कि वह इस होस्ट तक पहुँचता है या नहीं। अगर संदेश कैप्चर में दिखे और ट्रांसफ़र फिर भी अटके, तो भेजने वाला उसे नज़रअंदाज़ कर रहा है, जो जाँच को नेटवर्क के बजाय स्टैक में ले जाता है।

टनल का आकार सबूत के बाद ही बदलें

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

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