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 पछ्याउनुहोस्, क्लाइन्टले कुन रिजोल्भर प्रयोग गर्यो र त्यो साइटबाट दुर्गम दृश्य देखिन्छ कि भन्ने पनि समावेश गर्दै। तीन फरक असफलता, तीन फरक समाधान, र पिंग परीक्षणले तीमध्ये एउटै छुट्याउँदैन।

समाधानपछि त्यही परीक्षण दोहोर्याउनुहोस्

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

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