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 आणि फरक सिद्ध करणारी चाचणी तिकिटात लिहा। पुढच्या व्यक्तीला दुसऱ्या दुव्यावर तीच गणिते भेटतील।

संबंधित लेख