VPN मार्फत पाथ MTU पत्ता लगाउने: आकार र ICMP अन्तर

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

पाथ MTU ले वास्तवमा के नाप्छ

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

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

टनेलले उपयोगी प्याकेट किन सानो बनाउँछ

यदि टनेल इन्टरफेसले भौतिक कडाको MTU राख्छ भने, प्रत्येक ठूलो प्याकेट तल कोही यसलाई फ्र्याग्मेण्ट गर्न तयार हुनेमा निर्भर हुन्छ। IPv4 सिद्धान्ततः यसलाई अनुमति दिन्छ, तर फ्र्याग्मेण्ट नगर्न भनिएको राउटरले यसको सट्टा त्रुटि फर्काउँछ। IPv6 राउटरहरू ट्रान्जिटमा कहिल्यै फ्र्याग्मेण्ट गर्दैनन्, त्यसैले उही सेटिङ ठेगाना परिवारअनुसार फरक व्यवहार गर्छ। जसरी भए पनि केही फर्केर रिपोर्ट नगरेसम्म पठाउनेले केही सिक्दैन।

व्यावहारिक परिणाम ह्यान्डशेकमा अटाउने तर पेलोडमा नअटाउने आकार हो। TLS ClientHello वा DNS क्वेरी साँघुरिएको मार्ग नछोइकन पार गर्न पर्याप्त सानो हुन्छ, जबकि ठूलो स्थानान्तरण त्यस्तो हुँदैन। त्यसैले लक्षणहरू विशिष्ट होस्टको वरिपरि होइन, विशिष्ट क्रियाकलापको वरिपरि जम्मा हुन्छन्।

फिडब्याक आएपछि मात्र पत्ता लगाउने काम गर्छ

IPv4 पत्ता लगाउने काम don't-fragment बिटमा निर्भर छ: प्याकेट अगाडि पठाउन नसक्ने राउटरले अर्को हपको MTU सहित ICMP fragmentation-needed फर्काउँछ, र पठाउनेले आफ्नो अनुमान घटाउँछ। IPv6 ले यसको सट्टा Packet Too Big सन्देशहरू प्रयोग गर्छ, किनभने राउटरहरू ट्रान्जिटमा फ्र्याग्मेण्ट गर्दैनन्। दुवै संयन्त्रले सन्देशले पठाउनेकहाँ फर्कने बाटो भेट्टाउँछ भनी मान्छन्, टनेलबाट र फर्कने मार्गमा कुनै पनि फायरवालको पछाडिबाट। त्यो मान्यता असफल भएपछि, पठाउनेले मार्गले बोक्न नसक्ने आकार फेरि फेरि प्रयास गरिरहन्छ।

echo request र echo reply लाई अनुमति दिने फायरवालले ती त्रुटि प्रकारहरूलाई अनुमति दिएको हुनैपर्ने होइन। ICMP एउटा परिवार हो, र यहाँ महत्त्वपूर्ण सदस्यहरू त्रुटिहरू हुन्, इको जोडी होइन। टनेलका दुवै छेउमा र तिनीहरूबीचको मार्गमा नियन्त्रण-ट्राफिक नीति जाँच्नुहोस्, र सबैतिर सबै ICMP प्रकारलाई अनुमति दिनुको सट्टा प्लेटफर्मको समर्थित मार्गदर्शन पालना गर्नुहोस्।

त्यही फिल्टरिङ टनेलभित्र पनि हुन सक्छ। भित्री मार्गले त्रुटि छोड्छ तर बाह्य मार्गले त्यो बोक्छ भने, पठाउनेले इन्क्याप्सुलेटेड ट्राफिकले कहिल्यै वास्तवमा नदेख्ने सीमासँग मेल खान सक्छ।

संख्या अनुमान गर्नुको सट्टा मार्ग परीक्षण गर्नुहोस्

गन्तव्य, पहुँच नेटवर्क र टनेल स्थिर राख्नुहोस्, त्यसपछि प्याकेटको आकार मात्र बदल्नुहोस्। MTU संकेतसहित असफल हुने don't-fragment परीक्षणले तपाईंलाई अर्को हपको सीमा दिन्छ; कुनै आकार पास नहुँदासम्म दोहोर्याउनुहोस्, र आकार तथा ठेगाना परिवार दुवै अभिलेख गर्नुहोस्।

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

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

RFC 4821 मा वर्णन गरिएको PLPMTUD माथितिर परीक्षण गर्छ र पुर्याइएका त्रुटिहरूमा भरोसा गर्नुको सट्टा ट्रान्सपोर्ट स्वीकृतिहरू प्रयोग गर्छ। ICMP फिल्टर गर्ने मार्गहरूमा यसले मद्दत गर्छ, तर समर्थन स्ट्याक र अनुप्रयोगअनुसार फरक पर्छ। TCP प्रवाह आफैं सुधार्न सक्छ जबकि निश्चित डेटाग्राम आकारको UDP अनुप्रयोग असफल हुँदै रहन्छ।

मान छान्नुहोस् र कारण अभिलेख गर्नुहोस्

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

IPv4 संयन्त्रको वर्णन RFC 1191 मा र IPv6 प्याकेटाइजेसन मार्गदर्शन RFC 8201 मा छ; दुवैको नाम लिँदा अर्को इन्जिनियरले मान्यता फेरि निकाल्नु पर्दैन। तपाईंले छानेको आकारमा स्थानान्तरण अझै अड्किन्छ भने, संख्या घटाउन छोड्नुहोस् र अर्को तह हेर्नुहोस्। हरेक आकारमा असफल हुने मार्ग MTU समस्या होइन।