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