शंकास्पद VPN MTU समस्या मान अनुमान नगरी परीक्षण गर्ने

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

संख्या बदल्नुअघि मार्ग निश्चित गर्नुहोस्

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

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

तपाईंले नियन्त्रण गर्ने आकारले परीक्षण गर्नुहोस्

Linux मा परीक्षण ping -M do -s 1400 host जस्तो देखिन्छ, र Windows मा ping -f -l 1400 host जस्तो। दुवै अवस्थामा तपाईं पेलोड तोक्दै हुनुहुन्छ, प्याकेटको आकार होइन, किनकि IP र ICMP हेडर माथि थपिन्छन्।

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

असफल परीक्षण MTU सीमाको प्रमाण होइन

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

परीक्षण सफल हुँदा अनुप्रयोग असफल भयो भने, त्यो मार्गमा यो साधारण आकार-सीमा होइन भन्ने प्रमाण तपाईंसँग छ। यो लेख्नुहोस्, किनकि यसले सम्भावित परिवर्तनको पूरै शाखा हटाउँछ।

क्लाइन्टले पहिले नै समर्थन गर्ने एउटा मात्र प्यारामिटर समायोजन गर्नुहोस्

क्लाइन्टले यो प्रोटोकलका लागि कागजात गर्ने सेटिङ बदल्नुहोस् र अन्तिम बिन्दु तथा गन्तव्य अछुत राख्नुहोस्, नत्र तपाईंले एकैचोटि दुई कुरा बदल्नुभयो। TCP MSS क्ल्याम्पले हरेक UDP भार ढाक्दैन, त्यसैले काम थाल्ने ब्राउजरले टनेल प्रोटोकल ठ्याक्कै त्यस्तै बिग्रेको छोड्न सक्छ। IPv4 र IPv6 यहाँ छुट्टाछुट्टै मार्ग हुन्, किनकि कुनै पनि राउटिङले केही गर्नुअघि नै हेडर फरक पर्छन्।

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

फिर्ता लिने, प्रमाणित गर्ने र लेख्ने

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

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