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 चा पाठलाग करा, क्लायंटने कोणता रिझॉल्व्हर वापरला आणि त्या साइटवरून दूरचे दृश्य दिसते का यासह। तीन वेगवेगळे अपयश, तीन वेगवेगळे उपाय, आणि पिंग चाचणी त्यातील एकही ओळखत नाही।

दुरुस्तीनंतर तीच चाचणी पुन्हा करा

तेच क्लायंट, गंतव्य, पोर्ट आणि पेलोड पुन्हा चालवा। नंतर पुन्हा कनेक्ट करा किंवा रचनेत असल्यास फेलओव्हर मार्ग वापरून पहा, कारण मूळ बोगदा उदाहरण जिवंत असेपर्यंतच चालणारी दुरुस्ती तपासली गेलेली नाही। चाचणी डॅशबोर्डवरील एका हिरव्या निर्देशकाऐवजी प्रत्यक्ष स्रोत, प्रत्यक्ष गंतव्य आणि प्रत्यक्ष क्रियेशी जोडून ठेवा।

चार आधार मूल्ये आणि निकाल नोंदवा। त्याच लक्षणाचा पुढील अहवाल नंतर पिंगऐवजी पुराव्यापासून सुरू होऊ शकतो।