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 घटाउनाले फिल्टर भएको सन्देश लुकाउन र लक्षण हटाउन सक्छ, तर हरेक प्याकेटमा बढी भारको मूल्यमा। यो समाधान होइन, वरिपरि जाने बाटो हो, र यसले क्याप्चरलाई प्रतिस्थापन गर्नुको सट्टा त्यसपछि आउनुपर्छ। मनपरी कम मानले पनि देखिने केही तोड्दैन, त्यसैले यो वर्षौंसम्म कन्फिगरेसनमा टिक्छ। यसलाई जानाजानी बदल्नुहोस्, मान अभिलेख गर्नुहोस्, र कुन मापनले यसलाई न्यायोचित ठहर्यायो लेख्नुहोस्।

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