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 कमी केल्याने फिल्टर झालेला संदेश लपू शकतो आणि लक्षण नाहीसे होऊ शकते, पण प्रत्येक पॅकेटवर अधिक भाराच्या किंमतीवर। हा उपाय नाही, टाळाटाळ आहे, आणि त्याने कॅप्चरच्या जागी न येता त्यानंतर यायला हवे। अनियंत्रित कमी मूल्य दिसण्यात काहीही मोडत नाही, म्हणूनच ते वर्षानुवर्षे कॉन्फिगरेशनमध्ये टिकते। ते जाणीवपूर्वक बदला, मूल्य नोंदवा, आणि कोणत्या मोजमापाने ते न्याय्य ठरवले ते लिहा।

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