Linux पर प्रति-रूट MTU: तीन आकार नियंत्रण, एक रूट
इंटरफ़ेस MTU, रूट MTU और MSS क्लैंप अलग-अलग परतों पर काम करते हैं। जो रूट लुकअप जीतता है उससे बजट जोड़ें और बदलाव को उलटने योग्य रखें।
Linux क्लाइंट पर तीन सेटिंग्स सभी «पैकेट छोटे करो» जैसी लगती हैं और वे अलग-अलग परतों पर काम करती हैं। इंटरफ़ेस MTU डिवाइस द्वारा भेजे गए हर पैकेट को सीमित करता है। रूट MTU उस रूट का उपयोग करने वाले पैकेट सीमित करता है, जो एक VPN गंतव्य के लिए अक्सर वही होता है जो आप वास्तव में चाहते हैं। TCP MSS क्लैंप बदलता है कि दोनों सिरे क्या बातचीत करते हैं, और UDP के लिए कुछ नहीं करता।
तीन नियंत्रण जो एक ही नॉब जैसे दिखते हैं
चुनने से पहले उन्हें साथ रखें, क्योंकि गलत पंक्ति चुनना ही उन ज़्यादातर सलाहों को समझाता है जो काम नहीं करतीं:
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
पूरी मशीन के लिए Ethernet MTU घटाना इस सुधार का मोटा संस्करण है। यह काम करता है, और मेज़बान पर हर दूसरे ऐप को भी दंडित करता है, उन सहित जिनके रास्ते ठीक थे। प्रति-रूट मान वही इरादा बिना सहवर्ती लागत के व्यक्त करता है।
तुलना केवल उसी ट्रैफ़िक के लिए मान्य है जो मेज़बान स्वयं उत्पन्न करता है। किसी दूसरे क्लाइंट के लिए पैकेट फ़ॉर्वर्ड करने में उस क्लाइंट का अपना रास्ता और टनल का बाहरी बजट शामिल होता है, और इस मेज़बान पर रूट मीट्रिक उस सीमा को पार नहीं करता।
बजट को उस रूट से जोड़ें जो लुकअप जीतता है
एक उदाहरण IPv4 रूट रिकॉर्ड ऐसा दिखता है:
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380रिकॉर्ड को चिपकाने के मान के रूप में नहीं, इरादे के वर्णन के रूप में पढ़ें। प्रीफ़िक्स, डिवाइस और पसंदीदा स्रोत वास्तविक कॉन्फ़िगरेशन से मेल खाने चाहिए, और संख्या ब्लॉग पोस्ट से नहीं, एनकैप्सुलेटेड रास्ते के सबूत से आनी चाहिए। रूट MTU भीतरी IP पैकेट सीमित करता है, जो 1380 बाइट का TCP पेलोड या 1380 बाइट का एन्क्रिप्टेड बाहरी पैकेट नहीं है।
कुछ जोड़ने से पहले देखें कि लुकअप वास्तव में कहाँ हल होता है। नीति नियमों वाला मेज़बान किसी गंतव्य को main के अलावा किसी और तालिका से रूट कर सकता है, और केवल main में मौजूद मीट्रिक उस अनुरोध के लिए अदृश्य है। ip -4 route show table all की तुलना ip route get के उत्तर से करें, जब नियम उनका उपयोग करें तब मार्क या नेमस्पेस संदर्भ सहित। अगर दोनों सहमत न हों, तो जिस तालिका ने उत्तर दिया वही मीट्रिक चाहती है, ज़्यादा सुव्यवस्थित दिखने वाली नहीं।
mtu, mtu lock नहीं है
डिफ़ॉल्ट रूप से कर्नेल अभी भी ICMP फ़ीडबैक से पथ MTU अपडेट कर सकता है, पथ MTU खोज इसी के लिए है। lock जोड़ना इसे रोकता है। यह अलग निर्णय है, वही संख्या बचाने का ज़्यादा मज़बूत तरीका नहीं, और IPv4 के लिए यह «खंडित न करें» बिट के प्रलेखित व्यवहार को बदलता है।
लॉक करना तब उचित है जब आपने पथ मापा हो और चाहें कि मान जो भी आए स्थिर रहे। यह खराब डिफ़ॉल्ट है जब नेटवर्क वैध आकार-फ़ीडबैक भेजता है, क्योंकि कर्नेल अब समायोजित नहीं कर सकता और विफलता दूसरे लक्षण में चली जाती है।
अगर पथ में कहीं ICMP फ़िल्टर होता है, तो कोई रूट सेटिंग उसे ठीक नहीं करती। सुधार फ़िल्टर का है, और छोटा MTU एक उपाय है जो अगले पथ परिवर्तन तक असली खराबी छिपाता है।
टनल सॉफ़्टवेयर अपने आकार-नॉब जोड़ता है
OpenVPN- mssfix अपने प्रलेखित UDP टनल मामले के लिए TCP सेगमेंट आकार समायोजित करता है। यह TCP बातचीत पर काम करता है, इसलिए यह ऑपरेटिंग सिस्टम के रूट MTU की दूसरी वर्तनी नहीं है, और बातचीत अनदेखा करने वाली UDP सेवा की मदद नहीं कर सकता।
एक ही परिवर्तन-विंडो में रूट MTU, इंटरफ़ेस MTU बदलाव और MSS क्लैंप न ढेरें। अगर समस्या गायब हो गई तो आपको पता नहीं चलेगा कि कौन महत्वपूर्ण था, और जो रखेंगे वे वर्षों तक ट्रैफ़िक सीमित करेंगे ऐसे कारण से जो किसी को याद नहीं रहता।
इसे उलटने योग्य बनाएँ, फिर सिद्ध करें
रूट का असली मालिक तय करता है कि बदलाव पुनःकनेक्ट के बाद बचता है या नहीं। रूट को गतिशील रूप से स्थापित करने वाला VPN क्लाइंट सामान्यतः इसे आपके मीट्रिक के बिना फिर बनाएगा, और हाथ से किया गया ip route add फिर एक दिन बाद विफल हुए सुधार जैसा दिखता है। मान प्रबंधक के कॉन्फ़िगरेशन में रखें, और अगर अस्थायी प्रयोग चाहिए तो पहले मूल रूट दर्ज करें।
उस ऑपरेशन को करने वाले नए कनेक्शन से परीक्षण करें जो अटक गया था, फिर पुष्टि करें कि इच्छित निजी रूट अब भी जीतता है और असंबंधित गंतव्य अपरिवर्तित हैं। टनल फिर से कनेक्ट करें और रूट फिर पढ़ें, क्योंकि पुनःकनेक्ट में गायब होने वाला मान सुधार नहीं है।
अगर सबूत बदलाव का समर्थन नहीं करते, तो ओवरराइड को उसके प्रबंधक से हटाएँ और रूट हटाने के बजाय मूल रूट विशेषताएँ बहाल करें। फिर नोट करें कि आपने क्या मापा, किस पथ पर, ताकि अगला व्यक्ति असली सुधार को चालू छोड़े गए प्रयोग से अलग पहचान सके।