VPN MTU च्या अफवा: तुमचे पॅकेट का आकुंचन पावतात आणि जागा कुठे जाते

कोणीतरी तुम्हाला सांगतो की VPN "MTU मुळे पॅकेट गमावत आहे", तुम्ही टनेल 1400 वर सेट करता, आणि हस्तांतरण पुन्हा काम करते। तो निकाल निदानासारखा वाटतो। साधारणपणे हा अंकगणिताचा योगायोग असतो: तुम्ही अशी संख्या निवडली जी तुम्ही कधीही ओळखली नाही अशा मर्यादेखाली बसण्याइतकी लहान आहे, आणि पुढील नेटवर्कवर वेगळ्या बजेटसह तुम्हाला पुन्हा तीच मर्यादा भेटेल।

यापैकी बहुतेक दोन मिथकांमुळे होते। पहिले म्हणजे टनेल इंटरफेसचे MTU हे मार्गाचे MTU आहे। दुसरे म्हणजे इन्कॅप्सुलेशनची किंमत "एक हेडर" आहे आणि PPPoE ची किंमत मोजण्यासारखी काहीही नाही। दोन्ही अशा प्रकारे चुकीचे आहेत की तुमची निवडलेली संख्या अनियंत्रित वाटते, जेव्हा ती प्रत्यक्षात निश्चित असते।

पहिले मिथक: टनेलचे MTU हे मार्गाचे MTU आहे

टनेल इंटरफेसवर तुम्ही सेट करता ते मूल्य सर्वात मोठ्या आंतरिक पॅकेटबद्दल स्थानिक वचन आहे जे अंमलबजावणी खाली सोपवेल। मार्गाची खरी क्षमता तुमच्या आणि दूरच्या टोकामधील प्रत्येक दुव्याची गुणधर्म आहे, आणि मार्ग बदलल्यावर, मोबाइल कनेक्शन हस्तांतरित झाल्यावर किंवा रहदारी दुसरे पीअरिंग घेतल्यावर ती बदलू शकते। सेट केलेले 1500 तुम्हाला सांगते की तुमचा होस्ट काय बनवेल, नेटवर्क काय वाहून नेईल ते नाही।

मार्ग-MTU शोध दोन्हींचा मेळ घालण्यासाठी आहे, आणि तो अभिप्रायावर अवलंबून आहे। IPv4 मध्ये, पूर्ण आकाराचे पॅकेट पुढे पाठवू न शकणाऱ्या राउटरने ICMP "fragmentation needed" संदेश पाठवावा, आणि प्रेषक त्याचा अंदाज कमी करतो। IPv6 मध्ये समतुल्य Packet Too Big संदेश आहे, आणि राउटर ट्रान्झिटमध्ये अजिबात फ्रॅगमेंट करत नाहीत। तो अभिप्राय फिल्टर झाल्यास, प्रेषक मार्ग वाहू न शकणारी पॅकेट तयार करत राहतो, आणि काहीही त्याला कारण सांगत नाही।

दुसरे मिथक: इन्कॅप्सुलेशनची किंमत एक हेडर आहे

बाहेरील स्तर प्रामाणिकपणे मोजा। बाहेरील IP हेडर IPv4 मध्ये 20 बाइट किंवा IPv6 मध्ये 40 आहे। NAT पार करण्यासाठी UDP इन्कॅप्सुलेशन 8 जोडते। टनेल प्रोटोकॉल स्वतःचे हेडर, इनिशियलायझेशन वेक्टर किंवा नोन्स, सायफरच्या ब्लॉक किंवा संरेखन मर्यादेपर्यंत पॅडिंग, ट्रेलर आणि अखंडता तपासणी मूल्य जोडते। प्रोटोकॉल आणि सायफरनुसार, आंतरिक पॅकेट सुरू होण्यापूर्वीच एकूण आरामात डझनभर बाइटमध्ये पोहोचते।

मग आंतरिक पॅकेटच्या स्वतःच्या हेडरसाठी पुन्हा वजा करा। टनेलमधील TCP विभाग स्वतःचे 20 बाइट IP हेडर आणि 20 बाइट TCP हेडर वाहतो, आणि TCP चे MSS MTU मधून येते, टनेलच्या नाममात्र पेलोडमधून नाही। म्हणूनच ping लहान पेलोडसह यशस्वी होऊ शकते तर फाइल हस्तांतरण अडकते: साधने वेगवेगळ्या गोष्टी तपासतात, आणि त्यापैकी फक्त एक पूर्ण आकाराचा TCP विभाग वापरते।

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

पहिला आदेश सेट केलेले टनेल MTU नोंदवतो। दोन्ही प्रोब 1472 बाइटचा पेलोड पाठवतात, जो IPv4 आणि ICMP हेडरच्या 28 बाइटसह 1500 बाइटचे पॅकेट आहे, आणि नंतर लहान। मोठा प्रोब पूर्णपणे अयशस्वी होऊन लहान यशस्वी झाल्यास, तुमच्याकडे आकार-अवलंबून दोष आहे, सामान्य राउटिंग समस्या नाही।

तिसरे मिथक: PPPoE अजूनही तुम्हाला स्वच्छ 1500 देतो

पारंपरिक PPPoE प्रवेश दुवा 1500 बाइटचे IP पॅकेट वाहत नाही। PPPoE हेडर आणि PPP प्रोटोकॉल फील्ड इथरनेट फ्रेममध्ये 8 बाइट घेतात, ज्यामुळे IP पॅकेटसाठी 1492 उरतात। ही RFC 2516 मध्ये वर्णन केलेली पारंपरिक मर्यादा आहे। अशा दुव्यावर VPN चालवल्यास, टनेलचा ओव्हरहेड त्या 1492 मधून येतो, 1500 मधून नाही।

RFC 4638 मोठ्या PPP पेलोडवर वाटाघाटी करण्याची पद्धत परिभाषित करते जेव्हा प्रवेश केंद्रित्र आणि ग्राहक उपकरणे दोन्ही त्याला समर्थन देतात, म्हणूनच "हे कनेक्शन PPPoE वापरते" हे एकटे कोणतीही विशिष्ट संख्या सिद्ध करत नाही। स्थानिक सेटिंग मधल्या उपकरणाला असे पॅकेट स्वीकारण्यास भाग पाडू शकत नाही ज्यासाठी ते कधीही कॉन्फिगर केले गेले नाही, म्हणून उपयुक्त प्रश्न हा आहे की दुव्याने प्रत्यक्षात कशावर वाटाघाटी केली, लेबल काय म्हणते हे नाही।

अपयश निवडक का वाटते

लहान विनंत्या यशस्वी होणे आणि मोठे हस्तांतरण अडकणे हे मार्ग-MTU कृष्णविवराचे उत्कृष्ट लक्षण आहे। हँडशेक, DNS क्वेरी आणि API कॉल सर्व बसतात; मोठ्या प्रमाणातील हस्तांतरण एका दुव्यावर मरणारे पूर्ण आकाराचे विभाग तयार करते, आणि समस्या कळवायला हवा असलेला ICMP संदेश कधीही पोहोचत नाही। कनेक्शन ठीक दिसते आणि डाउनलोड लटकते, ज्यामुळे लोक मार्गाऐवजी सर्व्हरकडे पाहतात।

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

काय बदलावे, आणि कोणत्या क्रमाने

पुराव्याने सुरुवात करा। वरील प्रोबने दोष आकार-अवलंबून असल्याची खात्री करा, आणि नंतर पार होणारा सर्वात लहान आकार आणि अयशस्वी होणारा सर्वात मोठा आकार शोधा। टनेलला दोष देण्यापूर्वी प्रवेश दुव्याचे खरे MTU तपासा; PPPoE दुवा तुमच्या VPN ला स्पर्श करण्यापूर्वीच बजेट मर्यादित करतो। बदल परत करता येईल यासाठी मूळ मूल्ये नोंदवा।

नंतर क्लायंट दस्तऐवजीकरण करतो ते सर्वात लहान समायोजन लागू करा। अनेक क्लायंट टनेल MTU आणि MSS दुरुस्ती पर्याय देतात, आणि MSS पर्याय TCP साठी अनेकदा चांगला तोल असतो कारण तो प्रत्येक पॅकेट लहान न करता प्रेषकापर्यंत पोहोचतो। तेच गंतव्य आणि तेच हस्तांतरण पुन्हा तपासा, आणि तुम्ही स्थिरावलेल्या संख्या नोंदवा। एका प्रवेश नेटवर्कवर चालणारे टनेल मूल्य सार्वत्रिक स्थिरांक नाही, आणि पुढील साइटचे स्वतःचे बजेट असेल।