VPN को पिङ चल्छ तर वेबसाइट अड्किन्छ: आकार जाँच्नुहोस्

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

सबैभन्दा सानो प्रश्नबाट सबैभन्दा ठूलोसम्म जानुहोस्, र प्रत्येक चरणले वास्तवमा के प्रमाणित गर्यो लेख्नुहोस्।

इको जवाफ धेरै सानो प्रश्नको उत्तर दिन्छ

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

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

जडान सुरु भयो कि भएन पत्ता लगाउनुहोस्

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

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

MTU सेटिङ छुनु अघि ती तीनमध्ये कुन अवस्था देख्नुभयो लेख्नुहोस्। अस्वीकार गरिएको जडान सुधार्न टनेलको आकार बदल्नु त्यो परिवर्तन खेर फाल्छ र वास्तविक कारण केही समय लुकाउँछ।

भनिएको सङ्ख्याले आकार नाप्नुहोस्

भारमुनि अड्किने देखा पर्दा, टुक्रा नगर्ने बिट राखेर एउटा प्याकेट आकार जाँच्नुहोस् र नतिजाको अर्थ रहने गरी गणित भन्नुहोस्। iputils सहितको Linux मा, 1392 बाइटको पेलोड र 8 बाइटको ICMP हेडर तथा 20 बाइटको IPv4 हेडर मिलेर ठ्याक्कै 1420 बाइटको भित्री प्याकेट बन्छ। त्यो गणित टिकटमा लेख्नुहोस्, किनकि गेटवेसम्म पुग्ने नाङ्गो ping ले एप्लिकेसनबारे केही प्रमाणित गर्दैन।

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

दुवै जाँच मापन बिन्दु हुन्, टनेलको आकारका सिफारिस होइनन्। यदि मार्गमा कतै ICMP फिल्टर भयो भने, समय-सीमाले आकारबारे केही भन्दैन, किनकि क्लाइन्टको तर्फबाट फिल्टरिङ र धेरै ठूलो प्याकेट उस्तै देखिन्छन्। सफलताले पनि उल्टो दिशा वा फरक गन्तव्यबारे केही भन्दैन।

बाहिरी मार्गको हिसाब गर्नुहोस्

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

IPv4 मा मार्ग MTU पत्ता लगाउने कुरा विभाजनबिना अगाडि पठाउन नसकिने प्याकेटबारेको प्रतिक्रियामा निर्भर छ, र IPv6 ले Packet Too Big सन्देश प्रयोग गर्छ। IPv4 विशिष्टता ले त्यो संयन्त्र वर्णन गर्छ। प्रतिक्रिया फिल्टर गर्दा पठाउनेको सिक्ने क्षमता टुट्छ, र कहिल्यै नअटाउने प्याकेट ऊ फेरि फेरि पठाइरहन्छ। त्यसैले चल्ने सानो अनुरोध र असफल हुने ठूलो अनुरोध यति सजिलैसँग सँगै रहन्छन्।

एउटा सङ्ख्या बदल्नुहोस् र एप्लिकेसन फेरि जाँच्नुहोस्

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

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

यदि एप्लिकेसन तपाईंले प्रयास गरेको हरेक आकारमा चल्छ भने, सङ्ख्या मिलाउन छोड्नुहोस् र चल्ने सेवालाई असफल सेवाबाट अलग गर्ने नीति हेर्नुहोस्।