MTU की MSS? VPN चा बदल प्रत्यक्षात काय दुरुस्त करतो

पिंग यशस्वी होतात, मोठे हस्तांतरण अडकते, आणि टनेल स्वतःला निरोगी घोषित करते। कोणी इंटरफेसचा MTU कमी करतो, दुसरा MSS मर्यादित करतो, आणि कधीकधी समस्या कोणीही नोंदवत नाही अशा कारणांमुळे नाहीशी होते। दोन संख्या वेगवेगळ्या वस्तूंचे वर्णन करतात, म्हणून चुकीची बदलल्यास नशिबासारखे वाटणारे निराकरण मिळते। ही प्रक्रिया आहे: स्तर ओळखा, जुळणारे समायोजन लागू करा, नंतर नवीन कनेक्शनवर चाचणी करा।

दोन संख्या, दोन वस्तू

MTU हा लिंक किंवा इंटरफेसचा असतो: तो न विभागता पुढे देता येणारा सर्वात मोठा पॅकेट आहे। MSS हा TCP चा असतो: एक सेगमेंट वाहू शकणारी सर्वात मोठी TCP पेलोड रक्कम, आणि तो TCP व IP दोन्ही हेडर वगळतो। IPv4 असलेल्या सामान्य इथरनेट लिंकवर 1500 बाइटचा MTU परिचित 1460 बाइटचा MSS देतो। या संख्या वेगवेगळ्या स्तरांचे वर्णन करतात आणि वेगवेगळ्या यंत्रणांद्वारे देवाणघेवाण होतात। दोन्ही बाइटमध्ये मोजल्या जातात आणि दोन्ही 1500 जवळ आहेत म्हणून त्यांचा गोंधळ करणे सोपे आहे।

एक इंटरफेस सेटिंग म्हणून येते। दुसरे SYN सेगमेंटमधील पर्याय म्हणून येते, तुमचा इंटरफेस कधीही न पाहणाऱ्या टोकांमध्ये वाटाघाटी केलेले।

बाहेरील अतिरिक्त भार कुठे उतरतो

VPN आतील पॅकेट दुसऱ्याच्या आत ठेवते, आणि बाहेरील पॅकेटला भौतिक मार्गात बसावे लागते। एनकॅप्स्युलेशन हेडर, बाहेरील IP हेडर, ट्रान्सपोर्ट हेडर आणि कोणताही प्रमाणीकरण टॅग आतील पॅकेट वापरू शकत नाही असे बाइट खर्च करतात। टनेल इंटरफेस 1500 वर ठेवल्यास बाहेरील पॅकेट मार्ग वाहू शकतो त्यापेक्षा नियमितपणे जास्त होते। 'विभाजन करू नका' बिट सेट असल्यास राउटर ते टाकून देते आणि ICMP त्रुटी परत पाठवायला हवी; ती त्रुटी गाळली गेल्यास पाठवणाऱ्याला कधीही कळत नाही।

म्हणूनच अपयश निवडक दिसते। लहान विनंत्या पूर्ण होतात आणि सेगमेंट भरणारे काहीही अडकते, कारण फक्त मोठे पॅकेट टाकले जातात। पिंग पार करणारे टनेल डेटा वाहणारे टनेल नाही।

MSS मर्यादित करणे, आणि ते कुठे लागू होते

MSS क्लॅम्पिंग निवडलेल्या बिंदूतून जाताना SYN सेगमेंटमधील मूल्य पुन्हा लिहिते, ज्यामुळे दोन्ही टोके कारण न जाणता लहान पेलोड निवडतात। Linux वर हे स्पष्ट नियमाने लागू होणारे mangle तक्त्यातील लक्ष्य आहे, आणि ते तुम्हाला हव्या त्या दिशेने SYN पॅकेटना लागले पाहिजे। ते टनेल इंटरफेस आणि पत्ता श्रेणीपर्यंत मर्यादित ठेवा, कारण रुंद नियम टनेलमध्ये कधीही न येणाऱ्या रहदारीचे वर्तन बदलतो।

परिणाम फक्त TCP वर। UDP अनुप्रयोग, QUIC सत्र आणि स्वतःचे डेटाग्राम तयार करणारा कोणताही प्रोटोकॉल यामुळे अस्पर्शित राहतो।

स्थिर मार्गाने निदान करा

एका वेळी एक चल ठेवा। तुम्हीच आकार निवडलेल्या पॅकेटने चाचणी करा, आणि कर्नेलने निकाल लपवण्याऐवजी कळवण्यासाठी 'विभाजन करू नका' ध्वज सेट करा।

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

प्रत्येक बदल काय दुरुस्त करत नाही

इंटरफेसचा MTU कमी केल्याने आधीच स्थापित सत्राचा MSS बदलत नाही। MSS मर्यादित केल्याने UDP प्रवाहाला मदत होत नाही, आणि ICMP त्रुटी फक्त एका दिशेने गाळल्या जाणाऱ्या मार्गाची दुरुस्ती होत नाही। प्रत्येक बदल समस्यांचा एक वर्ग दुरुस्त करतो आणि बाकीचे जसे होते तसेच ठेवतो।

तुम्ही कोणते समायोजन कुठे लागू केले आणि कोणत्या चाचणीने फरक दाखवला ते लिहा, अन्यथा पुढील अभियंता दोन्ही लागू करतो आणि कोणते महत्त्वाचे होते हे सांगण्याची क्षमता गमावतो। बंधन खरे आणि कायमचे असेल तर ते लपवणाऱ्या क्लॅम्पपेक्षा ते प्रतिबिंबित करणारा टनेल MTU निवडा। क्लॅम्प करावेच लागल्यास नियम मर्यादित व्याप्तीत आणि टिप्पणीसह ठेवा, कारण स्पष्टीकरण नसलेला mangle नियम डीफॉल्टनुसार कायमचा होतो।