VPN टनेलमा traceroute एकै दिशामा किन मर्छ
एक दिशामा पूरा भएर अर्को दिशामा ताराहरू छाप्ने ट्रेस सामान्यतया निदानको समस्या हो। प्रोब विधिहरू, फर्कने मार्गहरू र वास्तविक अनुरोध तुलना गर्नुहोस्।
एक दिशामा पूरा भएर अर्को दिशामा ताराहरूका पङ्क्तिहरू छाप्ने traceroute को आउटपुट असममित फर्वार्डिङजस्तो देखिन्छ, र सामान्यतया त्यस्तो हुँदैन। देखाइएको प्रत्येक हपका लागि प्रोब पुग्नु, राउटरले जवाफ दिने निर्णय गर्नु र जवाफ फर्केर प्रोबसँग मिल्नु आवश्यक छ। यीमध्ये कुनै पनि कडी तोड्नुभयो भने पङ्क्ति तारा बन्छ, जबकि टनेलले डाटा बोक्न जारी राख्छ।
ट्रेस यातायातको प्रमाण बन्नुअघि निदानको प्रमाण हो। सोध्न लायक प्रश्न यो हो कि तीनमध्ये कुन कडी असफल भयो, र जवाफ आउटपुटको आकारबाट होइन, प्याकेटबाट आउँछ।
तारा भनेको हराएको जवाफ हो, हराएको हप होइन
traceroute प्रत्येक राउन्डमा TTL एक राउटर टाढा सकिने प्रोबहरू पठाएर बाहिरतिर अघि बढ्छ। म्याद सकिएको प्रोब फाल्ने राउटरले आफूलाई नाम दिने ICMP Time Exceeded सन्देश फर्काउनुपर्छ, र उपकरणले त्यो नाम छाप्छ। उपकरणले वास्तवमा त्यो सन्देश समयसीमाभित्र आउने पर्खाइ गर्छ। राउटरले अर्को स्रोत ठेगानाबाट जवाफ दिए, त्रुटि बनाउने आवृत्ति सीमित गरे वा प्रोबलाई शब्द नभनी फाले भने त्यो राउन्डले छाप्न लायक केही दिँदैन।
यीमध्ये कुनै पनि नतिजाले अगाडिको मार्ग बिग्रिएको छ भन्दैन। तारा भनेको जवाफ नपाएको हुलाकको रिपोर्ट हो, खाली बाटोको होइन।
प्रोब विधिले तपाईंले कुन फिल्टर भेट्नुहुनेछ भन्ने निर्धारण गर्छ
Linux मा पूर्वनिर्धारित विधि सामान्यतया उच्च नम्बरको UDP गन्तव्य पोर्ट हो, Windows को tracert ले ICMP प्रतिध्वनि पठाउँछ, र Linux लाई यसको सट्टा ICMP वा TCP प्रयोग गर्न भन्न सकिन्छ। यीमध्ये प्रत्येक स्टेटफुल फायरवाल वा क्लाउड सुरक्षा समूहका लागि फरक प्रकारको ट्राफिकजस्तो देखिन्छ। एक तर्फको UDP ट्रेसलाई अर्को तर्फको ICMP ट्रेससँग तुलना गर्नु दुई फरक प्रयोगको तुलना हो। नतिजालाई फरक भन्नुअघि विधि, ठेगाना परिवार, स्रोत ठेगाना र समयसीमा निश्चित गर्नुहोस्।
निष्पक्ष तुलनाका लागि ट्रेसलाई ट्राफिक साँच्चै बोक्ने होस्टहरूबाट चलाउनुहोस्, तिनीहरूको तर्फबाट फर्वार्ड गर्ने गेटवेबाट होइन। राउटरले बनाएको ट्रेसले राउटरको आफ्नै स्रोत ठेगाना र आउटपुट नीति प्रयोग गर्छ, जो क्लाइन्टले देख्ने जुनसुकै कुराभन्दा कडा हुन सक्छ। ठ्याक्कै आदेश नोट गर्नुहोस् ताकि अर्को व्यक्तिले दोहोर्याउन सकोस्।
समयसीमाको मान प्रयोगको अर्को आधा हो, र नोटबाट छुट्न सजिलो छ। भीडभाड भएको मार्गमा दुई सेकेन्डको प्रतीक्षाले ताराहरू रिपोर्ट गर्छ जहाँ पाँच सेकेन्डको प्रतीक्षाले हपहरू रिपोर्ट गर्छ। सबै चलाइहरूमा मान एउटै राख्नुहोस् ताकि तुलना सञ्जालकै बारेमा रहोस्।
फर्कने मार्ग आफ्नै एउटा मार्ग हो
ICMP त्रुटि आफ्नै स्रोत र गन्तव्य भएको साधारण प्याकेट हो, र यसलाई ट्रेसरसम्म फर्कने मार्ग चाहिन्छ। यदि टनेल नीतिले LAN प्रिफिक्सहरू बोक्छ तर त्रुटि बनाउने राउटरको ठेगाना बोक्दैन भने सन्देश तपाईंसम्म पुग्न नसक्ने मार्गबाट बाहिरिन्छ। मार्ग भए पनि जवाफ फिल्टरिङले यसलाई फाल्न सक्छ, किनकि प्याकेट अप्रत्याशित इन्टरफेसमा अप्रत्याशित ठेगानाबाट आउँछ। यो अनुप्रयोगको असफलता होइन, निदान तहको असंगति हो।
ट्रेस पूरा नहुँदासम्म प्रत्येक चयनकर्ता फराकिलो बनाउनु तस्बिर सुन्दर र नीति खराब बनाउँछ। विशिष्ट निदान ठेगाना मर्मत गर्नुहोस्, वा तारा स्वीकार गरेर अनुप्रयोग अर्को तरिकाले परीक्षण गर्नुहोस्।
वास्तविक अनुरोधले टनेल पुष्टि गर्नुहोस्
सेवाको आफ्नै पोर्टमा TCP ह्यान्डशेकले महत्त्वपूर्ण दिशामा फर्वार्डिङ, फर्कने राउटिङ र फिल्टरिङ परीक्षण गर्छ। तलका आदेशहरू दुवै छेउमा चल्छन् र प्रत्येक पक्षले के खोल्न सक्छ भन्ने तुलना गर्छन्। आफ्नै सेटअपबाट सेवा पोर्ट र टनेल इन्टरफेसको नाम बदल्नुहोस्।
traceroute -I -n -w 2 203.0.113.40
traceroute -T -p 443 -n -w 2 203.0.113.40
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 5 http://203.0.113.40:8080/health
ss -tan state established
पहिले दुवै traceroute चलाइ पढ्नुहोस्: यदि ICMP चलाइले हप देखाउँछ र TCP चलाइले देखाउँदैन भने फरक विधिमा छ, मार्गमा होइन। त्यसपछि curl को नतिजालाई अनुप्रयोग-स्तरको जवाफ मान्नुहोस्, किनकि उचित स्थिति कोडसहित पूरा भएको आदानप्रदानको अर्थ अगाडि र फर्कने दुवै मार्ग वास्तविक ट्राफिकका लागि काम गर्छन्। सकेट सूचीले जडान कतै स्थापित भएको छ कि छैन देखाउँछ, जो कुनै ट्रेसले बताउन सक्दैन।
दुवै दिशामा अन्तरक्रियात्मक सत्र बोकेर एक traceroute ले ताराहरू छापिरहेको टनेल स्वस्थ छ र केवल फोटोजेनिक छैन। प्रत्येक पक्षको आदेश आउटपुट अभिलेखका रूपमा राख्नुहोस्, र हराएका हपहरूलाई VPN बारेको फैसला होइन, निदानबारेको खुला प्रश्न मान्नुहोस्।