WireGuard के अंदर IPIP: वे अतिरिक्त 20 बाइट जिन्हें किसी ने बजट में नहीं रखा
IPIP WireGuard के अंदर 20 अतिरिक्त बाइट खर्च करता है। जीवंत टनल पर अटके ट्रांसफ़र के लिए फ़्रैगमेंटेशन को दोष देने से पहले सही परत पर बजट बनाएँ।
छोटे ping पूरे दिन टनल पार करते हैं, SSH बैनर आता है, और फिर फ़ाइल ट्रांसफ़र शुरू होते ही सत्र जम जाता है। यह पैटर्न गलत परत पर गिने गए बाइट-बजट की ओर संकेत करता है, जहाँ बाहरी टनल को उसके अपने ओवरहेड के लिए मापा गया और किसी ने भीतरी को घटाया नहीं। WireGuard के लिए नेस्टेड IPIP पैकेट बस एक और IP पैकेट है, और इसीलिए यह उन बाइट का उपभोग करता है जो आपने कभी आरक्षित नहीं किए। सुधार अंकगणित है, और वह तीन कमांड और एक तालिका में समा जाता है।
वह लक्षण जो इसे पकड़ लेता है
फ़्रैगमेंटेशन की समस्या अपनी घोषणा आकार से करती है, कभी पतों से नहीं। आपका पीयर एक घंटे तक 56 बाइट के ping का जवाब देता है और फिर 1400 बाइट पर चुप हो जाता है, जबकि टनल चालू रहती है और कोई रूट नहीं बदला। हैंडशेक समा जाता है, पहली पूरी TCP विंडो नहीं, और ट्रांसफ़र स्वस्थ दिखने के कुछ सेकंड बाद अटक जाता है।
कुछ भी संपादित करने से पहले छत नापें, क्योंकि बिना नापी छत वही है जिसका आप दो बार पीछा करेंगे। संदिग्ध आकार से नीचे do-not-fragment बिट सेट करके एक प्रोब भेजें, ping -M do -s 1000 10.9.0.2, और फिर उसे उस आकार पर दोहराएँ जिसे आप पहले से बहुत बड़ा जानते हैं। जब उलटाव पेलोड के आकार का अनुसरण करता है जबकि गंतव्य अपरिवर्तित रहता है, तो रूटिंग अपना काम कर रही है और बजट से एक हेडर गायब है।
हर हेडर को एक बार गिनें, सही परत पर
टनल इंटरफ़ेस से नहीं, बल्कि पथ के सबसे छोटे MTU से शुरू करें, क्योंकि दीवार दोनों सिरों से ऊपर है। WireGuard IPv4 बाहरी परिवहन पर 60 बाइट खर्च करता है: 20 IP के लिए, 8 UDP के लिए और 32 अपने हेडर के लिए, और 80 बाइट जब वह परिवहन IPv6 हो। 1420 बाइट का wg0 1440 के नीचे 20 बाइट की छूट रखता है, जो 1500 बाइट का पथ वास्तव में पहुँचा सकता है, और इसीलिए विकी से कॉपी किया गया आंकड़ा यहाँ भी फ़िट बैठता है। पूरा स्टैक आरेख पर लिखें, क्योंकि अगली बार MTU बदलने वाला अन्यथा नया गोल अंक चुनेगा और आपका बग विरासत में पाएगा।
| Layer | Bytes | Remaining |
|---|---|---|
| Path MTU on the wired link | none yet | 1500 |
| WireGuard outer: IP, UDP, WG header | 60 | 1440 |
| Slack kept for safety | 20 | 1420 (wg0) |
| IPIP header inside the tunnel | 20 | 1400 (ipip0) |
| Original IPv4 and TCP headers | 40 | 1360 payload |
पाँचवीं पंक्ति वह जगह है जहाँ बजट बिगड़ते हैं, क्योंकि नेस्टेड इंटरफ़ेस जो 1400 बाइट ढोता है उनमें मूल पैकेट के अपने 40 बाइट हेडर पहले से शामिल हैं। उन बाइट में से केवल 1360 फ़ाइल पढ़ने वाली प्रक्रिया तक पहुँचते हैं। 1400 को एप्लिकेशन पेलोड मानें, जैसा उस कॉलम के बिना कोई भी आरेख आपको आमंत्रित करता है, और भीतरी उपकरण ऐसी दीवार के सामने 40 बाइट अधिक उदार निकलता है जो हिली नहीं है।
दोनों MTU अलग-अलग सेट करें
वाहक और नेस्टेड उपकरण अलग वस्तुएँ हैं, इसलिए हर एक को अपना मान चाहिए। इन्हें इस क्रम में लागू करें, क्योंकि नेस्टेड उपकरण वाहक से कुछ भी नहीं पाता:
ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400याद रखने योग्य नियम: भीतरी MTU = बाहरी MTU - 20 जब IPIP टनल जो पैकेट ढोती है वह IPv4 हो, और - 40 जैसे ही भीतरी पैकेट का कोई भी पक्ष IPv6 हो, क्योंकि नेस्टेड हेडर 20 बाइट से बढ़कर 40 हो जाता है। उस घटाव में और कुछ नहीं आता। 1420 चुनते समय WireGuard का ओवरहेड पहले ही खर्च हो चुका था, और उसे दो बार लगाने से ऐसी टनल बनती है जो बिल्कुल ठीक काम करती है और जब तक कोई उसे नापता नहीं, धीमी बनी रहती है। जिस परिनियोजन में दोनों उपकरण गोल 1400 ढोते हैं, वह ठीक उसी गलती की उँगली की छाप है।
नेस्टेड पैकेट के किसी भी पक्ष पर IPv6 ऊपर के हर आंकड़े को अमान्य कर देता है, इसलिए किसी मिलती-जुलती साइट से अंक कॉपी करने के बजाय फिर से गणना करें। जैसे ही IPv6 बाहरी पथ में या मूल डेटाग्राम में दिखता है, घटाए गए हेडर प्रत्येक 40 बाइट के होते हैं, और पेलोड का आंकड़ा ठीक उतना ही गिरता है।
वह फ़ायरवॉल नियम जिसकी आपको शायद ज़रूरत नहीं है
दो WireGuard पीयर के बीच तार पर एकमात्र चीज़ UDP है, इसलिए प्रोटोकॉल 4 के लिए एक इनबाउंड नियम, जो नंबर RFC 2003 IPv4-में-IPv4 एनकैप्सुलेशन को देता है, न नेस्टेड पथ बनाता है और न ही उसे जीवित रखता है। IPIP हेडर एन्क्रिप्टेड पेलोड के भीतर रहता है, जहाँ कोई एज फ़ायरवॉल उसे नहीं देखता। प्रोटोकॉल 4 खोलने से होस्ट तक एक और अनुमत रास्ते के सिवा कुछ नहीं मिलता।
मूल पैकेट के स्रोतों और गंतव्यों का उल्लेख करने वाली नीति डीकैप्सुलेशन के बाद, टनल इंटरफ़ेस पर और रूटिंग तालिका में आती है। उसे वहीं रखें और एज नियम बंद रह सकता है।
WireGuard वास्तव में क्या सत्यापित करता है
AllowedIPs WireGuard जो पैकेट ढोता है उसके स्रोत का निर्णय करता है, और वह जो ढोता है वह IPIP-एनकैप्सुलेटेड पैकेट है। अनुमत IPIP स्रोत तब भी स्वीकार किया जाता है जब भीतर का हेडर ऐसे होस्ट का नाम लेता है जिसे आप रूट नहीं करना पसंद करेंगे। इसलिए मूल स्रोत वह नहीं है जो पीयर ने आपके लिए जाँचा, और उस भीतरी जोड़ी पतों को डीकैप्सुलेशन के बाद अपना प्रवर्तन चाहिए।
आवरण रूटिंग संरचना देता है, क्रिप्टोग्राफ़ी की दूसरी परत नहीं। WireGuard के भीतर IPIP को अतिरिक्त सुरक्षा कहना किसी अलग डिज़ाइन का वर्णन है।
एक ping नहीं, सीढ़ी से सत्यापित करें
आपके गणना किए गए घेरे के दोनों ओर के आकार जाँचें, फिर पुष्टि करें कि कर्नेल दोनों उपकरणों के बारे में क्या मानता है। 1360 बाइट पेलोड और 40 बाइट हेडर मिलकर 1400 बनाते हैं, नीचे की पहली गूँज फ़िट बैठती है और दूसरी छत से एक बाइट आगे बैठती है:
ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0छत के नीचे साफ़ निकलना और उससे ऊपर के पहले आकार पर विफल होना इसका मतलब है कि अंकगणित शुरू से अंत तक टिकता है। फिर उस ट्रांसफ़र को दोबारा चलाएँ जो मूल रूप से अटका था, क्योंकि कृत्रिम प्रोब बजट साबित करता है और प्रेषक के अपने लेखन-आकारों के बारे में कुछ नहीं कहता। अगर नेस्टेड पथ उस आकार पर भी टूटता है जिसे आपने फ़िट साबित किया, तो MTU से और दस बाइट काटने से पहले दूर के सिरे का डीकैप्सुलेशन और रूट जाँचें।