VPN के पार 1,500 बाइट का निश्चित भीतरी पैकेट ले जाएँ

आपके पास एक ऐसी आवश्यकता है जो झुकती नहीं: दूर का पक्ष वही 1,500 बाइट का IP पैकेट प्राप्त करे जो प्रेषक भेजता है, हेडर सहित। एक टनल उस पैकेट को अपने फ़्रेमिंग के साथ दूसरे 1,500 बाइट के IP पैकेट के अंदर नहीं लपेट सकती, इसलिए डिज़ाइन में कुछ न कुछ झुकना ही होगा। नीचे दिया क्रम वही है जो मैं परिवर्तन विंडो में उपयोग करता हूँ: बाइट बजट लिखें, सिद्ध करें कि अंडरले वास्तव में क्या ढो सकता है, फिर ठीक एक वहन तंत्र चुनें और दूर के छोर पर भीतरी पैकेट की पुष्टि करें।

प्रोफ़ाइल संपादित करने से पहले बाइट बजट लिखें

एनकैप्सुलेशन कई परतों पर बाइट जोड़ता है, और कुल योग आपकी प्रोफ़ाइल का गुण है, कोई ऐसा स्थिरांक नहीं जिसे आप खोज सकें। एड्रेस फ़ैमिली, सिफ़र का चयन, ट्रांसपोर्ट प्रोटोकॉल और कोई भी कम्प्रेशन या फ़्रेमिंग विकल्प इस संख्या को बदलते हैं, इसलिए किसी दूसरे परिनियोजन से कॉपी किया गया घटाव बजट के रूप में बेकार है। भीतरी आवश्यकता से शुरू करें, अपने स्वयं के कॉन्फ़िगरेशन का मापा गया प्रति-पैकेट ओवरहेड जोड़ें, और परिणामी बाहरी आकार किसी के द्वारा फ़ाइल संपादित करने से पहले परिवर्तन टिकट पर लिखें।

दो संख्याएँ डिज़ाइन तय करती हैं: वह सबसे बड़ा बाहरी पैकेट जो पथ बिना फ़्रैगमेंटेशन के ढोता है, और वे अतिरिक्त बाइट जो आपके एनकैप्सुलेशन को चाहिए। जब पहला दूसरे से 1,500 अधिक से छोटा हो, तो उनमें से एक को बदलना होगा। तब चयन रचनात्मक नहीं बल्कि संकुचित होता है, इसलिए विकल्पों पर चर्चा से पहले मैं दोनों संख्याएँ लिख लेता हूँ। टनल परत पर कुछ भी उन बाइट को संपीड़ित नहीं करता, और कोई भी एकल MTU पूर्णांक आपको दी गई आवश्यकता को नहीं हटाता।

नो-फ़्रैगमेंट पिंग से अंडरले जाँचें

इंटरफ़ेस MTU पर भरोसा करने के बजाय पथ को मापें, क्योंकि बाहरी पथ में सबसे छोटी कड़ी ही मायने रखती है। Linux में -M do नो-फ़्रैगमेंट बिट सेट करता है और -s ICMP पेलोड लेता है, इसलिए 1,500 बाइट का फ़्रेम 20 बाइट के IP हेडर और 8 बाइट के ICMP हेडर घटाने के बाद 1,472 बाइट पेलोड पर उत्तर देता है। पेलोड बढ़ाते जाएँ जब तक जाँच विफल न हो, फिर जंबो आकार पर कूदें यह देखने के लिए कि पथ उसे बिलकुल ढोता है या नहीं।

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

जो पथ 1,472 पार करता है और 8,972 पर विफल होता है, वह 1,500 बाइट का भीतरी पैकेट और ओवरहेड एक बाहरी पैकेट में नहीं ढो सकता। VPN कॉन्फ़िगरेशन खोलने से पहले आपको यही उत्तर चाहिए था। यह यह भी तय करता है कि अगले दो में से कौन सा खंड आप पर लागू होता है, इसलिए दोनों जाँच परिणाम टिकट के पास रखें। यहाँ अनुमान लगाने पर एक रख-रखाव विंडो की कीमत चुकानी पड़ती है, क्योंकि स्वयं को चालू बताने वाली टनल इस बारे में कुछ नहीं कहती कि पथ कौन सा सबसे बड़ा पैकेट स्वीकार करेगा।

पथ MTU केवल वहीं बढ़ाएँ जहाँ हर हॉप सहमत हो

जंबो फ़्रेम एक एंड-टू-एंड गुण है, वह सेटिंग नहीं जिसे आप अपने नियंत्रण वाले दो एंडपॉइंट पर चालू करते हैं। बाहरी पथ पर हर स्विच, राउटर और प्रदाता हैंडऑफ़ को बड़े आकार पर सहमत होना होगा, और एक भी 1,500 बाइट का हॉप उस पैकेट को चुपचाप गिरा देगा जिसे आपने अभी बड़ा किया है। केवल स्थानीय इंटरफ़ेस बढ़ाना वही पुराना आधा परिवर्तन है जिससे टनल टूटी दिखती है जबकि अंडरले चुपचाप गिराता रहता है।

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

इंटरफ़ेस बदलें, फिर कुछ और बदलने से पहले उसी पथ को दोबारा जाँचें। यदि जाँच अभी भी विफल हो, तो ip link set dev eth1 mtu 1500 से वापस लौटें और ऐसी कड़ी के लिए प्रदाता से बहस करने के बजाय फ़्रैगमेंटेशन पर जाएँ जो आपकी नहीं है।

जब अंडरले बढ़ न सके तो टनल फ़्रैगमेंटेशन का उपयोग करें

भीतरी पैकेट के नीचे समर्थित फ़्रैगमेंटेशन तंत्र कई बाहरी पैकेट को एक भीतरी पैकेट ढोने देता है, और दूर का टनल एंडपॉइंट मूल को स्टैक को सौंपने से पहले उन्हें फिर से जोड़ता है। Community OpenVPN का UDP फ़्रैगमेंट विकल्प उस विचार का एक कार्यान्वयन है, और यह बाहरी पैकेट के सामान्य IP फ़्रैगमेंटेशन जैसा नहीं है। दोनों पक्षों को ऐसा संस्करण चलाना होगा जो प्रारूप का समर्थन करे, और डेटा पथ वही होना चाहिए जो आप सोचते हैं: OpenVPN 3 क्लाइंट और कर्नेल-त्वरित डेटा चैनल की सीमाएँ अलग हैं, इसलिए एक क्लाइंट पर चलने वाली प्रोफ़ाइल दूसरे पर विफल हो सकती है।

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

सामान्य बाहरी फ़्रैगमेंटेशन दूसरा विकल्प है, और वह कमज़ोर है। IPv6 राउटर अग्रेषित पैकेट को बिलकुल फ़्रैगमेंट नहीं करते, इसलिए बहुत बड़ा बाहरी पैकेट सीधे मर जाता है और प्रेषक को इसका पता तभी चलता है जब संबंधित ICMPv6 संदेश पथ पार कर ले। फ़्रैगमेंट फ़िल्टरिंग और हानि प्रवर्धन को भी आमंत्रित करते हैं, इसलिए मैं इसे योजना नहीं बल्कि फ़ॉलबैक मानता हूँ।

स्ट्रीम-आधारित बाहरी वाहक अपनी बाइट स्ट्रीम को खंडित करके आकार का प्रश्न टाल देता है, और पुनर्निर्मित भीतरी पैकेट अभी भी 1,500 बाइट का हो सकता है। यह अपनी लागत वाला परिवहन निर्णय है, जिसमें TCP के भीतर TCP का सुविचारित व्यवहार भी शामिल है, इसलिए इसे MTU बहस का दुष्प्रभाव नहीं बल्कि जानबूझकर लें।

पुष्टि करें कि भीतरी पैकेट बिना बदलाव के पहुँचता है

सत्यापन सफल हैंडशेक नहीं है। दोनों छोरों पर टनल इंटरफ़ेस पर कैप्चर करें और एप्लिकेशन द्वारा वास्तव में भेजे गए पैकेट का आकार और सामग्री दूर के पक्ष द्वारा प्राप्त पैकेट से तुलना करें।

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

यदि कैप्चर दूर के छोर पर पूर्ण आकार का भीतरी पैकेट दिखाता है, तो वहन का चयन काम करता है और बाकी काम उसे दर्ज करना है। यदि टनल के स्वयं को चालू बताने पर भी कुछ न दिखे, तो बाहरी पैकेट छोरों के बीच कहीं गिराया जा रहा है, जो आपको सिफ़र सेटिंग्स नहीं बल्कि जाँच की ओर लौटाता है।

टिकट बंद करने से पहले तीन बातें दर्ज करें: मापा गया बाहरी बजट, आपके द्वारा चुना गया तंत्र और वह कमांड जिसने सिद्ध किया कि भीतरी पैकेट बचा रहा। इस टनल को छूने वाले अगले व्यक्ति को तीनों चाहिए होंगे, और इनमें से कोई भी केवल कॉन्फ़िगरेशन फ़ाइल से फिर से नहीं बनाया जा सकता।