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 आफ्नै हेडरका लागि, र त्यो ट्रान्सपोर्ट IPv6 हुँदा 80 बाइट। 1420 बाइटको wg0 ले 1500 बाइटको मार्गले साँच्चै पुर्याउन सक्ने 1440 भन्दा तल 20 बाइट ठाउँ राख्छ, र त्यसैले विकिबाट प्रतिलिपि गरिएको अंक यहाँ पनि मिल्छ। सम्पूर्ण स्ट्याक रेखाचित्रमा लेख्नुहोस्, किनकि अर्को पटक 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 बाट अरू दस बाइट काट्नुअघि टाढाको छेउको डिक्याप्सुलेशन र मार्ग जाँच्नुहोस्।