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 के बारे में फ़ैसला नहीं, निदान के बारे में खुला सवाल मानें।