VPN MTU का मिथकहरू: तपाईंका प्याकेट किन साना हुन्छन् र ठाउँ कहाँ जान्छ

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

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

पहिलो मिथक: टनेलको MTU मार्गको MTU हो

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

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

दोस्रो मिथक: इन्क्याप्सुलेसनको लागत एक हेडर हो

बाहिरी तहहरू इमानदारीसाथ गन्नुहोस्। बाहिरी IP हेडर IPv4 मा 20 बाइट वा IPv6 मा 40 हो। NAT पार गर्न UDP इन्क्याप्सुलेसनले 8 थप्छ। टनेल प्रोटोकलले आफ्नै हेडर, इनिसियलाइजेसन भेक्टर वा नोन्स, साइफरको ब्लक वा पङ्क्तिबद्धता सीमासम्म प्याडिङ, ट्रेलर र अखण्डता जाँच मान थप्छ। प्रोटोकल र साइफरअनुसार, आन्तरिक प्याकेट सुरु हुनुअघि नै कुल आरामसाथ दर्जनौं बाइटमा पुग्छ।

त्यसपछि आन्तरिक प्याकेटका आफ्नै हेडरहरूका लागि फेरि घटाउनुहोस्। टनेलभित्रको TCP खण्डले आफ्नै 20 बाइट IP हेडर र 20 बाइट TCP हेडर बोक्छ, र TCP को MSS MTU बाट आउँछ, टनेलको नाममात्र पेलोडबाट होइन। त्यसैले ping सानो पेलोडसँग सफल हुन सक्छ जबकि फाइल स्थानान्तरण अड्किन्छ: उपकरणहरू फरक कुरा जाँच्छन्, र तीमध्ये एउटाले मात्र पूरा आकारको TCP खण्ड प्रयोग गर्छ।

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

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

तेस्रो मिथक: PPPoE अझै तपाईंलाई सफा 1500 दिन्छ

परम्परागत PPPoE पहुँच लिङ्कले 1500 बाइटको IP प्याकेट बोक्दैन। PPPoE हेडर र PPP प्रोटोकल फिल्डले इथरनेट फ्रेमभित्र 8 बाइट लिन्छन्, जसले IP प्याकेटका लागि 1492 छोड्छ। यो RFC 2516 मा वर्णन गरिएको परम्परागत सीमा हो। यस्तो लिङ्कमा VPN चलाउनुभयो भने, टनेलको ओभरहेड ती 1492 बाट आउँछ, 1500 बाट होइन।

RFC 4638 ले पहुँच केन्द्रित्र र ग्राहक उपकरण दुवैले समर्थन गरेमा ठूलो PPP पेलोडमा वार्ता गर्ने तरिका परिभाषित गर्छ, त्यसैले "यो जडानले PPPoE प्रयोग गर्छ" भन्ने मात्रले कुनै विशेष संख्या प्रमाणित गर्दैन। स्थानीय सेटिङले बीचको उपकरणलाई कहिल्यै कन्फिगर नगरिएको प्याकेट स्वीकार गर्न बाध्य पार्न सक्दैन, त्यसैले उपयोगी प्रश्न यो हो कि लिङ्कले वास्तवमा के मा वार्ता गर्यो, लेबलले के भन्छ भन्ने होइन।

असफलता किन छनोटजस्तो देखिन्छ

साना अनुरोध सफल हुने र ठूला स्थानान्तरण अड्किने मार्ग-MTU कालो प्वालको उत्कृष्ट चिन्ह हो। ह्यान्डशेक, DNS क्वेरी र API कल सबै अट्छन्; ठूलो परिमाणको स्थानान्तरणले एक लिङ्कमा मर्ने पूरा आकारका खण्ड बनाउँछ, र समस्या जनाउनुपर्ने ICMP सन्देश कहिल्यै पुग्दैन। जडान ठीक देखिन्छ र डाउनलोड झुन्डिन्छ, जसले मानिसहरूलाई मार्गको सट्टा सर्भरतिर हेर्न लगाउँछ।

दोस्रो, सम्बन्धित गल्ती तीन संख्या मिसाउनु हो: इन्टरफेस MTU, TCP MSS र प्रोटोकलको आफ्नै फ्र्याग्मेन्टेसन वा प्याडिङ सेटिङ। राउटरमा MSS क्ल्याम्पिङले घोषित MSS पुनः लेख्छ ताकि प्रेषकले साना खण्ड बनाओस्; यसले टनेल MTU परिवर्तन गर्दैन र UDP ट्राफिकलाई मद्दत गर्दैन। सम्बन्धित देखिन्छ भनेर तीनैलाई एउटै संख्या दिनु त्यो बाटो हो जसले राम्रो नियतको परिवर्तनले काम गरिरहेको सेटअप तोड्छ।

के परिवर्तन गर्ने, र कुन क्रममा

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

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