VPN का ping काम करता है पर वेबसाइट अटक जाती है: आकार जाँचें

पिंग उत्तर आते हैं, रिमोट डेस्कटॉप काम करता है, और ब्राउज़र खाली पृष्ठ पर बैठा रहता है जब तक हार न मान ले। इस पैटर्न पर दो व्याख्याएँ बैठती हैं, और वे एक ही समस्या के रूपांतर नहीं हैं: ऐसी नीति जिसने सेवा को कभी अनुमति नहीं दी, या ऐसे पैकेट जो स्थानांतरण बड़ा होते ही फिट होना बंद कर देते हैं। इको उत्तर इनमें से किसी को भी नहीं नकारता।

सबसे छोटे प्रश्न से सबसे बड़े तक जाएँ, और लिखें कि हर चरण ने वास्तव में क्या सिद्ध किया।

इको उत्तर बहुत छोटे प्रश्न का उत्तर देता है

इको उत्तर कहता है कि गंतव्य का 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 के स्क्रीनशॉट से उसे फिर से निकालने के बजाय।

अगर एप्लिकेशन हर उस आकार पर काम करता है जिसे आपने आज़माया, तो संख्याएँ समायोजित करना छोड़ें और उस नीति को देखें जो काम करती सेवा को विफल होती सेवा से अलग करती है।