नेस्टेड 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 जवाफले वास्तविक सीमा लुकाउन सक्छ, त्यसैले प्रोब तर्कभन्दा बढी महत्त्वपूर्ण छ।
अर्को व्यक्तिले भेट्ने ठाउँमा बजेट लेख्नुहोस्
प्रत्येक तहको एक पङ्क्तिको तालिका औंलाको नियमभन्दा लामो टिक्छ। यसलाई टनेल रेखाचित्रको छेउमा राख्नुहोस् ताकि दबाबमा कसैले गणना फेरि नगरोस्।
धेरै टनेल भनेको धेरै निर्भरता, त्यसैले रोलब्याक योजनाले बजेटको छेउमा आफ्नो ठाउँ कमाउँछ। सङ्ख्याहरू अझै नमिलेमा, फेरि अनुमान गर्नुको सट्टा बाटो नाप्नुहोस्। लक्ष्य भनेको तपाईंले रक्षा गर्न सक्ने सङ्ख्या हो, सम्झनुपर्ने होइन।