VPN मधून स्थिर 1,500 बाइटचा आंतरिक पॅकेट पाठवणे

तुमच्याकडे न वाकणारी गरज आहे: पाठवणारा जो 1,500 बाइटचा IP पॅकेट तयार करतो तोच, हेडरसह, समोरच्या बाजूने मिळणे आवश्यक आहे. टनेल तो पॅकेट आणि स्वतःचे फ्रेमिंग दुसऱ्या 1,500 बाइटच्या IP पॅकेटमध्ये मढवू शकत नाही, म्हणून डिझाइनमधील काहीतरी सोडावे लागेल. खालील क्रम मी बदल विंडोमध्ये वापरतो: बाइट बजेट लिहा, अंडरले प्रत्यक्षात काय वाहू शकते हे सिद्ध करा, नंतर नेमका एक वाहतूक यंत्रणा निवडा आणि समोरच्या बाजूला आंतरिक पॅकेटची पुष्टी करा.

प्रोफाइल संपादित करण्यापूर्वी बाइट बजेट लिहा

एनकॅप्स्युलेशन अनेक स्तरांवर बाइट जोडते, आणि एकूण ही तुमच्या प्रोफाइलची गुणधर्म आहे, शोधून काढता येणारा स्थिरांक नाही. पत्ता कुटुंब, सिफरची निवड, वाहतूक प्रोटोकॉल आणि कोणताही कॉम्प्रेशन किंवा फ्रेमिंग पर्याय संख्या बदलतो, म्हणून दुसऱ्या तैनातीतून कॉपी केलेली वजाबाकी बजेट म्हणून निरुपयोगी आहे. आंतरिक गरजेपासून सुरुवात करा, तुमच्या कॉन्फिगरेशनचा मोजलेला प्रति-पॅकेट ओव्हरहेड जोडा आणि कोणीही फाइल संपादित करण्यापूर्वी परिणामी बाह्य आकार बदल तिकिटावर लिहा.

दोन संख्या डिझाइन ठरवतात: मार्ग फ्रॅगमेंटेशनशिवाय वाहतो तो सर्वात मोठा बाह्य पॅकेट, आणि तुमच्या एनकॅप्स्युलेशनला लागणारे अतिरिक्त बाइट. पहिला दुसऱ्यापेक्षा 1,500 ने जास्त असलेल्या पेक्षा कमी असेल तेव्हा त्यातील एक बदलावे लागेल. मग निवड सर्जनशील नसून अरुंद होते, म्हणून पर्याय चर्चा करण्यापूर्वी मी दोन्ही संख्या लिहून ठेवतो. टनेल स्तरावर ते बाइट कॉम्प्रेस करून गायब करणारे काहीही नाही, आणि कोणताही एक MTU पूर्णांक तुम्हाला दिलेली गरज काढून टाकत नाही.

do-not-fragment ping ने अंडरले तपासा

इंटरफेस MTU वर विश्वास न ठेवता मार्ग मोजा, कारण बाह्य मार्गातील सर्वात लहान दुवा महत्त्वाचा असतो. Linux वर, -M do do-not-fragment बिट सेट करते आणि -s ICMP पेलोड घेते, म्हणून 20 बाइट IP हेडर आणि 8 बाइट ICMP हेडर वजा केल्यावर 1,500 बाइट फ्रेम 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 कॉन्फिगरेशन उघडण्यापूर्वी तुम्हाला हवे होते ते उत्तर हेच आहे. पुढील दोन विभागांपैकी कोणता तुम्हाला लागू होतो हेही हे ठरवते, म्हणून दोन्ही तपासणी निकाल तिकिटाजवळ ठेवा. इथे अंदाज लावणे एक देखभाल विंडो खर्च करते, कारण स्वतःला up असे नोंदवणारे टनेल मार्ग स्वीकारणाऱ्या सर्वात मोठ्या पॅकेटबद्दल काहीही सांगत नाही.

प्रत्येक हॉप सहमत असेल तिथेच मार्ग MTU वाढवा

जंबो फ्रेम्स ही end-to-end गुणधर्म आहे, तुम्ही योगायोगाने नियंत्रित करता त्या दोन एंडपॉइंटवर सुरू करायची सेटिंग नाही. बाह्य मार्गावरील प्रत्येक स्विच, राउटर आणि पुरवठादाराचे हस्तांतरण मोठ्या आकारावर सहमत असले पाहिजे, आणि एकच 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 fragment पर्याय त्या कल्पनेची एक अंमलबजावणी आहे आणि बाह्य पॅकेटच्या सामान्य 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'

कॅप्चरने समोरच्या टोकावर पूर्ण आकाराचा आंतरिक पॅकेट दाखवला तर वाहतूक निवड कार्य करते आणि उर्वरित काम ते नोंदवणे आहे. टनेल स्वतःला up असे नोंदवत असताना काहीही दाखवत नसेल तर बाह्य पॅकेट एंडपॉइंटमध्ये कुठेतरी टाकला जात आहे, जे तुम्हाला सिफर सेटिंग्जकडे नाही तर तपासणीकडे परत पाठवते.

तिकीट बंद करण्यापूर्वी तीन गोष्टी नोंदवा: मोजलेले बाह्य बजेट, निवडलेली यंत्रणा आणि आंतरिक पॅकेट टिकले हे सिद्ध करणारी आज्ञा. हे टनेल पुढे हाताळणाऱ्या व्यक्तीला तिन्ही लागतील, आणि त्यातील एकही केवळ कॉन्फिगरेशन फाइलमधून पुन्हा तयार करता येणार नाही.