VPN मार्फत स्थिर 1,500 बाइट आन्तरिक प्याकेट बोक्ने

तपाईंसँग नझुक्ने आवश्यकता छ: पठाउनेले निकाल्ने त्यही 1,500 बाइटको IP प्याकेट, हेडरसहित, विपक्षी पक्षले प्राप्त गर्नुपर्छ। टनेलले त्यो प्याकेट र आफ्नै फ्रेमिङलाई दोस्रो 1,500 बाइट IP प्याकेटभित्र बेर्न सक्दैन, त्यसैले डिजाइनमा केही तत्वले छोड्नुपर्छ। तलको क्रम मैले परिवर्तन विन्डोमा प्रयोग गर्ने क्रम हो: बाइट बजेट लेख्नुहोस्, underlay ले वास्तवमा के बोक्न सक्छ भनी प्रमाणित गर्नुहोस्, त्यसपछि ठ्याक्कै एउटा वहन संयन्त्र छान्नुहोस् र विपक्षी पक्षमा आन्तरिक प्याकेट पुष्टि गर्नुहोस्।

प्रोफाइल सम्पादन गर्नुअघि बाइट बजेट लेख्नुहोस्

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

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

do-not-fragment ping प्रयोग गरेर underlay जाँच्नुहोस्

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

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 र आफ्नो नभएको लिङ्कबारे प्रदायकसँग झगडा गर्नुको सट्टा फ्र्याग्मेन्टेसनतर्फ जानुहोस्।

underlay बढ्न नसक्दा टनेल फ्र्याग्मेन्टेसन प्रयोग गर्नुहोस्

आन्तरिक प्याकेटमुनि समर्थित फ्र्याग्मेन्टेसन संयन्त्रले धेरै बाह्य प्याकेटलाई एउटा आन्तरिक प्याकेट बोक्न दिन्छ, र विपक्षी टनेल endpoint ले मूल प्याकेट स्ट्याकमा दिनुअघि तिनीहरूलाई पुनः जोड्छ। Community OpenVPN को UDP fragment विकल्प त्यो विचारको एउटा कार्यान्वयन हो, र बाह्य प्याकेटको साधारण IP फ्र्याग्मेन्टेसन जस्तै होइन। दुवै peer ले त्यो ढाँचा समर्थन गर्ने संस्करण चलाउनुपर्छ, र डेटा मार्ग तपाईंले सोचेको जस्तै हुनुपर्छ: OpenVPN 3 क्लाइन्ट र कर्नेल-त्वरित डेटा च्यानलका सीमा फरक छन्, त्यसैले एउटा क्लाइन्टमा चल्ने प्रोफाइल अर्कोमा असफल हुन सक्छ।

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

साधारण बाह्य फ्र्याग्मेन्टेसन अर्को विकल्प हो, र त्यो कमजोर हो। IPv6 राउटरले अगाडि पठाइएको प्याकेटलाई कत्ति पनि फ्र्याग्मेन्ट गर्दैन, त्यसैले अति ठूलो बाह्य प्याकेट यत्तिकै मर्छ, र सम्बन्धित ICMPv6 सन्देश मार्गमा बाँचेमा मात्र पठाउनेले थाहा पाउँछ। फ्र्याग्मेन्टले फिल्टरिङ र हानिको वृद्धि पनि निम्त्याउँछ, त्यसैले म यसलाई योजना होइन, वैकल्पिक उपाय मान्छु।

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

आन्तरिक प्याकेट अपरिवर्तित आउँछ भनी पुष्टि गर्नुहोस्

प्रमाणीकरण सफल handshake होइन। दुवै छेउमा टनेल इन्टरफेसमा क्याप्चर गर्नुहोस् र अनुप्रयोगले वास्तवमा पठाएको प्याकेटको आकार र सामग्रीलाई विपक्षी पक्षले प्राप्त गरेकोसँग तुलना गर्नुहोस्।

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 भनी रिपोर्ट गर्दा केही नदेखाए बाह्य प्याकेट endpoint बीच कतै फालिँदै छ, जसले तपाईंलाई सिफर सेटिङमा होइन, जाँचमा फर्काउँछ।

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