नेस्टेड VPN टनेल: मोठ्या पॅकेटवर आतील टनेल का अडकते
प्रत्येक टनेल पुढील सुरू होण्यापूर्वी मार्गाच्या पॅकेट बजेटचा भाग खर्च करते। हेडर जोडा आणि मोठ्या पॅकेटवर आतील सत्र अयशस्वी होते।
DNS सुटतो, SSH सत्र टिकून राहते, आणि नंतर मोठा अपलोड गोठतो, तर त्याच होस्टला ping अजूनही उत्तर देतो। हे विभाजन तुटलेल्या टनेलकडे नाही, तर पॅकेटच्या आकाराकडे बोट दाखवते। नेस्टेड टनेल अशा आकारांवर तिथे पोहोचतात जिथे कोणतेही एक टनेल एकटे पोहोचत नाही। आतील सत्र ठीक आहे; त्याला आता न बसणारे पॅकेट दिले जात आहेत।
मार्गाचा MTU प्रत्यक्षात कुठे जातो
प्रत्येक एन्कॅप्स्युलेशन पुढील स्तराची पाळी येण्यापूर्वी बाइट खर्च करते। Ethernet मार्ग बाहेरील पॅकेटला 1500 बाइट देतो, आणि बाहेरील टनेल त्याच्या आत काहीही पत्ता मिळण्यापूर्वी आपला वाटा घेते। एक अंदाजित ओव्हरहेड मूल्य तितकेच चुकीचे असेल जितके महत्त्वाचे आहे।
स्तर क्रमाने सूचीबद्ध करा: प्रवेश मार्ग, बाहेरील वाहतूक, बाहेरील टनेल, आतील वाहतूक, आतील टनेल, अनुप्रयोग। प्रत्येक हेडर एकदा मोजा, आणि UDP टनेलच्या स्वतःच्या हेडर आणि टॅगपासून वेगळे ठेवा।
दोन WireGuard स्तर, एकदा मोजलेले
IPv4 प्रवेश मार्ग घ्या, त्याच्या आत आणखी एक WireGuard टनेल। बाहेरील स्तर 20 बाइट IPv4, 8 बाइट UDP आणि WireGuard डेटा हेडर व त्याच्या प्रमाणीकरण टॅगसाठी 32 बाइट खर्च करतो। त्याच्या आत आतील टनेलला स्वतःचे 20 बाइटचे IPv4 हेडर आणि 8 बाइटचे UDP हेडर हवे, त्याच्या दुसऱ्या 32 बाइट WireGuard ओव्हरहेडपूर्वी। उरलेल्या भागात IPv4 हेडर, TCP हेडर आणि डेटा बसतो। बाहेरील IPv6 मार्ग 20 ऐवजी 40 खर्च करतो आणि 1320 ठेवतो।
| Layer | Bytes |
|---|---|
| Path MTU | 1500 |
| Outer IPv4 header | 20 |
| Outer UDP header | 8 |
| Outer WireGuard header and tag | 32 |
| Inner transport IPv4 header | 20 |
| Inner UDP header | 8 |
| Inner WireGuard header and tag | 32 |
| Innermost IPv4 header | 20 |
| TCP header | 20 |
| Payload that fits | 1340 |
गणना 1340 बाइटवर येते। त्याच नियमांनी एक स्तर TCP पेलोडसाठी 1400 ठेवतो, म्हणजे 1500 वजा 20, 8, 32, 20 आणि 20, आणि 60 बाइटचा फरक म्हणजे दुसरे टनेल जोडणारे तेच आतील एन्कॅप्स्युलेशन।
1400 नेस्टेड मार्गावर लागू करा आणि आतील टनेल 60 बाइटने कमी पडते, जोपर्यंत पॅकेट ते आवश्यक होईल इतके मोठे होत नाही तोपर्यंत अदृश्य। पॅडिंग आणि प्रोटोकॉलचा स्वतःचा फ्रॅगमेंटेशन पर्याय संख्या पुन्हा हलवतो, म्हणून तक्त्यावर विश्वास ठेवा।
MTU, MSS आणि फ्रॅगमेंटेशन वेगवेगळ्या ठिकाणी काम करतात
इंटरफेस MTU इंटरफेस काय बाहेर पाठवेल हे मर्यादित करतो, तर TCP MSS क्लॅम्पिंग TCP सहकारी काय पाठवायला तयार आहे ते बदलते। क्लॅम्पिंग TCP सत्रे दुरुस्त करते आणि मोठ्या UDP डेटाग्रामसाठी काहीही करत नाही, अशा प्रकारे एक दुरुस्ती एका अनुप्रयोगासाठी यशस्वी दिसते आणि पुढचा गुपचूप चुकवते। प्रोटोकॉलचा स्वतःचा फ्रॅगमेंटेशन पर्याय स्वतःच्या अपयशांसह तिसरा लीव्हर आहे। इंटरफेस MTU हा नेहमीचा पहिला उपाय आणि सर्वात ढोबळ आहे।
ब्रिज केलेले आणि राउटेड टनेल वेगळे फ्रेम वाहतात, म्हणून दुसऱ्या तैनातीतील संख्या क्वचितच लागू होतात। मार्ग MTU शोध, ज्याचे वर्णन RFC 8201 मध्ये आहे, फक्त तेव्हाच मदत करते जेव्हा त्यावर अवलंबून असलेले ICMP संदेश जाऊ दिले जातात।
कमी पडणारा स्तर शोधणे
आवश्यकता तुलना परवानगी देत असल्यास, नेस्ट करण्यापूर्वी प्रत्येक टनेल स्वतंत्रपणे तपासा। ठराविक आकाराची प्रोब हे ठरवते: ping -M do -s 1472 -c 3 10.8.0.1 त्या स्तराच्या आत पूर्ण 1500 बाइटचे IPv4 पॅकेट पाठवते। दुसरा स्तर जोडा आणि तीच प्रोब पुन्हा करा, जेणेकरून कोणतेही अपयश ज्ञात बदलाचे असेल।
हस्तांतरण अडकले की, एका वेळी एक दस्तऐवजीकृत पॅरामीटर बदला आणि अयशस्वी होणारा आकार नोंदवा। परतीचा मार्गही तपासा, कारण नेस्टेड मार्ग रिकर्सन पॅकेट-आकाराची समस्या दुपारचा वेळ वाया घालवण्याइतकी जवळून अनुकरण करू शकते। फिल्टर केलेले ICMP उत्तर खरी मर्यादा लपवू शकते, म्हणून प्रोब तर्कापेक्षा महत्त्वाची आहे।
पुढील व्यक्तीला ते सापडेल तिथे बजेट लिहा
प्रत्येक स्तरासाठी एका ओळीचा तक्ता अंगठ्याच्या नियमापेक्षा जास्त टिकतो। तो टनेल आकृतीजवळ ठेवा जेणेकरून दबावाखाली कोणीही गणना पुन्हा करणार नाही।
अधिक टनेल म्हणजे अधिक अवलंबित्व, म्हणून रोलबॅक योजना बजेटजवळ स्थान मिळवते। संख्या तरीही जुळत नसतील, तर पुन्हा अंदाज न लावता मार्ग मोजा। उद्दिष्ट अशी संख्या आहे जी तुम्ही समर्थ करू शकता, लक्षात ठेवण्यासारखी नाही।