Ping प्रमाण नहीं है: दो साइटों के बीच का रास्ता जाँचें

सुरंग चालू है, गेटवे एक-दूसरे को जवाब दे रहे हैं, और फिर भी एक साइट के उपयोगकर्ता दूसरी साइट की फ़ाइल साझा नहीं खोल पा रहे हैं। कोई गेटवे से पिंग करता है, जवाब पाता है और नेटवर्क को स्वस्थ घोषित कर देता है। वह जवाब उन दो उपकरणों के बीच गया जो कभी समस्या नहीं थे। उपयोगी परीक्षण उस होस्ट से शुरू होता है जिसे सेवा चाहिए, वही प्रोटोकॉल इस्तेमाल करता है जो ऐप इस्तेमाल करता है और उस स्थिति को दोहराता है जिसमें यह विफल होता है। बाकी सब ऐसे रास्ते के लिए हरी झंडी है जिस पर कोई नहीं है।

उस क्लाइंट से शुरू करें जिसे सेवा चाहिए

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

दस्तावेज़ में दिया होस्ट नाम आज़माएँ और, जहाँ सेवा अनुमति दे, उसी पोर्ट की सीधी पता जाँच करें। विफल नाम खोज और अप्राप्य हल किया गया पता आपको अलग रास्तों पर ले जाते हैं। अगर आप होस्ट नाम की जगह IP डालें, तो इसे काम कराने के लिए HTTPS पहचान जाँच बंद न करें; प्रमाणपत्र की चेतावनी जानकारी है, रुकावट नहीं।

हर किनारे पर रास्ता चलें

क्लाइंट जो मार्ग चुनता है उसे पढ़ें, फिर गेटवे उस गंतव्य के लिए जो मार्ग चुनता है, फिर हर किनारे पर काउंटर या सीमित कैप्चर। आप दो तथ्य खोज रहे हैं: क्या अनुरोध दूर के LAN तक पहुँचा, और क्या जवाब लौटा। इंटरफ़ेस काउंटर हर दूसरे प्रवाह को भी गिनते हैं, इसलिए ग्राफ़ के आकार के बजाय सटीक समय-चिह्न और पता जोड़ी से मिलान करें। गलत किनारे पर लिया कैप्चर किसी के न होने से बुरा है, क्योंकि वह सबूत जैसा दिखता है।

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

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

वही प्रोटोकॉल इस्तेमाल करें जो ऐप इस्तेमाल करता है

ICMP कमज़ोर जाँच है। इसे फ़िल्टर किया जा सकता है, दर सीमित की जा सकती है या सेवा से अलग नीति से संभाला जा सकता है, जिससे इसकी सफलता और विफलता दोनों उभयलिंगी हो जाती हैं। असली पोर्ट जाँचें और, जहाँ संभव हो, प्रोटोकॉल का असली हैंडशेक।

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

पूरा हुआ TCP हैंडशेक उस पोर्ट के लिए पहुँच और नीति साबित करता है। यह साबित नहीं करता कि ऐप काम करता है: प्रमाणीकरण, अपलोड या कोई विशेष API कॉल अब भी विफल हो सकता है। उपयोगकर्ता जो क्रिया वास्तव में करते हैं उसे जाँचें, बार-बार असली लेन-देन भेजने के बजाय किसी हानिरहित समकक्ष के साथ।

उस स्थिति को दोहराएँ जिसमें विफलता होती है

सिर्फ़ बड़े स्थानांतरणों में दिखने वाली विफलताएँ आकार की समस्या हैं, कनेक्टिविटी की नहीं। don't-fragment बिट सेट करके बड़ा पैकेट भेजें और देखें वह कहाँ रुकता है। अगर छोटा अनुरोध सफल हो और बड़ा अटक जाए, तो सुरंग का MTU और गेटवे पर MSS का संभालना अगले संदिग्ध हैं।

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

अगर सिर्फ़ एक सबनेट विफल हो, तो ट्रैफ़िक चयनकर्ता, मार्ग घोषणाएँ और उस सबनेट का रिटर्न गेटवे देखें। अगर सिर्फ़ होस्ट नाम विफल हो, तो DNS का पीछा करें, जिसमें यह भी शामिल है कि क्लाइंट ने कौन सा रिज़ॉल्वर इस्तेमाल किया और क्या दूर का दृश्य उस साइट से दिखता है। तीन अलग विफलताएँ, तीन अलग सुधार, और पिंग परीक्षण इनमें से एक भी नहीं पहचानता।

सुधार के बाद वही परीक्षण दोहराएँ

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

चार आधार मान और परिणाम लिखें। उसी लक्षण की अगली रिपोर्ट तब पिंग के बजाय सबूत से शुरू हो सकेगी।