WireGuard का MTU कौन चुनता है: wg-quick, कर्नेल या आप

WireGuard में कोई MTU बातचीत नहीं होती। जो कुछ इंटरफ़ेस उसे देता है, वह उसे एन्क्रिप्ट करके परिणाम भेज देता है, और अगर एनकैप्सुलेटेड पैकेट पथ से बड़ा हो जाए, तो वह कहीं गिरा दिया जाता है या खंडित हो जाता है जहाँ आप देख नहीं सकते। किसी को इंटरफ़ेस का MTU चुनना ही होगा, और वह कोई वह टूल है जिसने इंटरफ़ेस को ऊपर उठाया।

तीन उम्मीदवार हैं, और उन्हें आपस में मिलाना आसान है।

तीन जगहें जहाँ से मान आ सकता है

मान इंटरफ़ेस कॉन्फ़िगरेशन में स्पष्ट रूप से सेट किया जा सकता है, सेटअप टूल द्वारा रूट जानकारी से निकाला जा सकता है, या जिस भी नेटवर्क मैनेजर के पास इंटरफ़ेस है वह उसे सेट कर सकता है। सामान्य wg कॉल इनमें से कुछ नहीं करता, क्योंकि wg केवल कुंजियाँ और पीयर प्रबंधित करता है। MTU नेटवर्क इंटरफ़ेस पर रहता है, इसलिए ip link show wg0 वह जगह है जहाँ आप उसे पढ़ते हैं।

अगर आपको संदेह है कि कौन-सा मामला लागू होता है, तो पहले MTU पढ़ें, फिर पता लगाएँ कि इंटरफ़ेस किसने शुरू किया।

इस आधार पर तय करें कि इंटरफ़ेस कौन चलाता है

अगर wg-quick उसे शुरू करता है, तो स्पष्ट MTU लाइन जीतती है, वरना वह एक मान निकालता है। अगर नेटवर्क मैनेजर शुरू करता है, तो उस मैनेजर की प्रोफ़ाइल तय करती है। अगर कंटेनर रनटाइम या प्रोवाइडर क्लाइंट शुरू करता है, तो wg-quick का व्यवहार मान लेने के बजाय उनका दस्तावेज़ पढ़ें।

निर्णय यह नहीं है कि अमूर्त रूप में कौन-सी संख्या सबसे अच्छी है। निर्णय यह है कि आप वास्तव में किस घटक को कॉन्फ़िगर कर सकते हैं।

डिफ़ॉल्ट गणना क्या करती है

wg-quick पीयर के एंडपॉइंट तक का रूट खोजता है, उस आउटगोइंग इंटरफ़ेस का MTU लेता है और एनकैप्सुलेशन ओवरहेड घटा देता है। IPv4 बाहरी हेडर के साथ यह लगभग 60 बाइट होता है, IPv6 के साथ लगभग 80। परिणाम को सीमित किया जाता है ताकि 1500 बाइट का पथ 1420 दे, ऐसा मान नहीं जो केवल एक पता परिवार पर काम करे। यह उचित डिफ़ॉल्ट है, आपके पथ का माप नहीं।

वह बाद की सुरंग, मोबाइल लिंक या फ़िल्टर किए गए ICMP पथ के बारे में जान नहीं सकता।

यह सीमा एक वास्तविक प्रश्न छिपाती है। अगर आपका पथ सचमुच शुरू से अंत तक 9000 बाइट है, तो 1420 प्रदर्शन को मेज़ पर छोड़ देता है, और अगर पथ 1400 है, तो 1420 पहले ही बहुत बड़ा है। डिफ़ॉल्ट एक समझौता है, और उसे वैसे ही माना जाना चाहिए।

जब पथ आपके नीचे बदलता है

Ethernet से Wi-Fi और फिर फ़ोन हॉटस्पॉट तक घूमने वाला लैपटॉप उसी इंटरफ़ेस MTU को बनाए रखता है जिसके साथ उसने शुरुआत की थी। बाहरी पथ अब छोटा हो सकता है, और कुछ भी फिर से बातचीत नहीं करता। नेस्टेड सुरंगें इसे और बिगाड़ती हैं, क्योंकि हर परत उसी बजट में से अपना ओवरहेड घटाती है। जो मान दफ़्तर में काम करता था, वह हवाई अड्डे पर काम करने वाला मान नहीं है।

हाल का हैंडशेक साबित करता है कि कुंजियाँ काम करती हैं। यह नहीं साबित करता कि बड़े पैकेट फ़िट होते हैं।

एक बार में एक संख्या जाँचें

वही एप्लिकेशन और गंतव्य रखें, एक मान बदलें और मापें। ping -M do -s 1372 DF बिट सेट के साथ 1400 बाइट का पैकेट जाँचता है, और यही वह जाँच है जो आप चाहते हैं। अगर छोटे अनुरोध काम करते हैं और बड़े अटक जाते हैं, तो आपकी समस्या आकार की है, रूटिंग की नहीं।

केवल MTU बदलें। कई पैकेट विकल्प एक साथ बदलने से आपको यह नहीं पता चलता कि कौन महत्वपूर्ण था।

और यह अपेक्षा न रखें कि MTU बदलने से गायब रिटर्न रूट, फ़ॉरवर्डिंग नियम या DNS विफलता ठीक हो जाएगी। वे भी ट्रैफ़िक न होने के लक्षण पैदा करते हैं, और उनकी अपनी जाँचें हैं। wg-quick मैनुअल स्वचालित चयन का दस्तावेज़ीकरण करता है।