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 मधून आणखी दहा बाइट कापण्यापूर्वी दूरच्या टोकाचे डीकॅप्सुलेशन आणि मार्ग तपासा।