IPv6 का असफलताहरूलाई तिनीहरूलाई निम्त्याउने प्याकेटको आकारभन्दा प्रोटोकलमाथि बढी दोष लगाइन्छ। दुई परिवारले साँच्चै धेरै ठूलो प्याकेटलाई फरक तरिकाले व्यवस्थापन गर्छन्, र सुरुङले नै त्यो भिन्नतालाई महत्त्वपूर्ण बनाउँछ। IPv4 राउटरहरूले नियमहरूले अनुमति दिँदा प्याकेट खण्डीकरण गर्न सक्छन्, तर IPv6 राउटरहरूले यात्रामा कत्ति पनि खण्डीकरण गर्नु हुँदैन। IPv6 ले यसको सट्टा पठाउनेलाई भन्छ, र पठाउनेले प्रतिक्रिया दिने अपेक्षा गरिन्छ। यसपछि जे गल्ती हुन्छ त्यो त्यो सन्देश पुग्छ कि पुग्दैन भन्नेमा निर्भर गर्छ।

प्रत्येक परिवारले के गर्छ

तालिका चार हरूमा संयन्त्र हो, र एउटा हरले धेरैजसो भ्रम व्याख्या गर्छ।

BehaviourIPv4IPv6
Router fragments an oversized packetAllowed while DF is clearNever
Signal returned to the senderICMP Fragmentation NeededICMPv6 Packet Too Big
Size that must always work68 bytes1280 bytes
Fragmentation possibleRouters or sourceSource only

IPv6 मा यात्रामा खण्डीकरण छैन र सफा गर्न DF झन्डा पनि छैन, त्यसैले प्याकेट धेरै ठूलो हुँदा अवलम्बन गर्न केही छैन। पठाउनेलाई भन्नुपर्छ, र पठाउनेले त्यो विश्वास गर्नुपर्छ।

सुरुङले बाटो चुपचाप साँघुरो बनाउँछ

VPN ले प्याकेट होस्ट छोड्नु अघि बाहिरी हेडरहरू थप्छ, र इन्क्रिप्टेड अवस्थामा अखण्डता डेटा पनि थप्छ। भित्री प्याकेटले देख्ने इन्टरफेस MTU मा अटाउन सक्छ, तर बाहिरी प्याकेटले अर्को लिङ्कको सीमा नाघ्छ, र त्यसैले यो पहिले सुरुङमा देखिन्छ। सुरुङ इन्टरफेसको MTU जानाजानी घटाउनुहोस्, वा बाटोमा TCP MSS कस्नुहोस्, र तपाईंले कुन संख्या रोज्नुभयो र किन लेख्नुहोस्।

ESP को ओभरहेड मोड र एल्गोरिदममा निर्भर हुन्छ, त्यसैले सही सुरुङ MTU गणना हो, परम्परा होइन। तपाईंले जे रोजे पनि, त्यसले पूरा 1280 बाइट भित्री IPv6 प्याकेटका लागि ठाउँ छोड्नुपर्छ, किनकि हरेक IPv6 लिङ्कले त्यति बोक्नुपर्छ। 1280 बाइट IPv6 बोक्न नसक्ने सुरुङ ट्युनिङको समस्या होइन; त्यो त्यो परिवारका लागि टुटेको बाटो हो। IPv4 मात्र भएको तैनाथीबाट MTU मान प्रतिलिपि गर्दा ठ्याक्कै यही सीमा हराउँछ।

लक्षण अड्किएको जस्तो किन देखिन्छ

असफलता सफा त्रुटि होइन, र त्यसैले यसको गलत निदान हुन्छ। TCP ह्यान्डशेक पूरा हुन्छ, साना प्रतिक्रियाहरू आउँछन्, र ठूलो प्रतिक्रिया वा ठूलो अपलोड सुरु हुनासाथ जडान रोकिन्छ, किनकि ती फाल्नका लागि पर्याप्त ठूला पहिलो प्याकेट हुन्। SSH जोडिन्छ र त्यसपछि पहिलो ठूलो आउटपुटमा अड्किन्छ, र पृष्ठको हेडर लोड हुन्छ जबकि मुख्य भाग कहिल्यै सकिँदैन।

ICMPv6 का प्याकेट धेरै ठूलो सन्देशहरू फिल्टर भए भने पठाउनेले कहिल्यै थाहा पाउँदैन र उही आकार दोहोर्याइरहन्छ। त्यो कालो प्वाल हो, ढिलो बाटो होइन, र यसको पहिचान अनियमित हानि होइन, दोहोरिने आकार-सीमा हो। सम्बन्धित नियन्त्रण ट्राफिकलाई अनुमति दिइराख्नु कार्यरत IPv6 तैनाथीको भाग हो, उपकार होइन।

तपाईंको आफ्नै बाटो जसका सन्देशहरूमा निर्भर छ ती बन्द गरेर त्यसपछि नतिजालाई IPv6 को खराबी भन्नु हुँदैन। त्यही तर्क IPv4 का Fragmentation Needed सन्देशहरूमा पनि लागू हुन्छ, जो फायरवाल लेखकहरूमा उत्तिकै अलोकप्रिय र उत्तिकै आवश्यक छन्।

सीमा नाप्नुहोस्, त्यसपछि तह सुधार्नुहोस्

अनुमान नगरी जाँच्नुहोस्: IPv4 मा don't-fragment झन्डा र IPv6 मा निश्चित पेलोड आकार प्रयोग गर्नुहोस्, र प्रतिक्रियाहरू कहाँ रोकिन्छन् लेख्नुहोस्। ping -M do -s 1472 र ping -6 -s 1400 समस्याको आकार निर्धारण गर्न पर्याप्त छन्, र tracepath बाटोमा फेला परेको मार्ग MTU रिपोर्ट गर्छ।

त्यसपछि त्यो संख्याको मालिक तह सुधार्नुहोस्: सुरुङ इन्टरफेसको MTU, TCP का लागि MSS कसाइ, वा बाटो आफै। IPv6 नियमका लागि RFC 8200 सन्दर्भ हो, र यो यसले रोक्ने घटनाभन्दा छोटो पढाइ हो।

एप्लिकेसनले साँच्चै प्रयोग गर्ने परिवार परीक्षण गर्नुहोस्, किनकि दोहोरो स्ट्याक नामले एउटा परिवारमा जवाफ दिन सक्छ अर्कोमा दिँदैन, र नेटवर्क परिवर्तनपछि एप्लिकेसन बदलिन सक्छ। तपाईंले परीक्षण गरेको ठेगाना लेख्नुहोस्, किनकि A रेकर्डविरुद्धको नतिजाले AAAA रेकर्डबारे केही भन्दैन।

आकार-सीमालाई प्रमाण मान्नुहोस्

दोहोरिने आकार-सीमा ती थोरै नेटवर्क खराबीमध्ये एक हो जो हरेक पटक उही बाइट संख्यामा, उही स्रोतबाट ठ्याक्कै पुनरुत्पादन हुन्छ। त्यसले यसलाई रहस्य होइन उपहार बनाउँछ, र सुधारको आशा गर्नुको सट्टा प्रमाणित गर्न सकिन्छ भन्ने पनि जनाउँछ।

फेला परेको MTU, तपाईंले कन्फिगर गरेको सुरुङ MTU र भिन्नता प्रमाणित गर्ने परीक्षण टिकटमा लेख्नुहोस्। अर्को व्यक्तिले अर्को लिङ्कमा त्यही गणित भेट्नेछ।

सम्बन्धित लेखहरू