IPsec गेटवे से पिंग अलग स्रोत पता इस्तेमाल करता है

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

तीन अलग सवाल जिनका जवाब पिंग दे सकती है

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

पहले सवाल चुनें। वरना असफल पिंग उसी सिद्धांत का सबूत बन जाती है जो पहले से आपके पास था।

गेटवे वह पता क्यों चुनता है जिसकी आपको उम्मीद नहीं थी

जब आप किसी गंतव्य को पिंग करते हैं, तो स्थानीय स्टैक उस मार्ग से स्रोत चुनता है जो उससे मेल खाता है। रूट-आधारित टनल पर यह टनल इंटरफ़ेस का लिंक पता हो सकता है, जो कई साइट डिज़ाइनों में पॉइंट-टू-पॉइंट हॉप के लिए चुनी गई 169.254.x.x जोड़ी होती है। ये पते लिंक के काम करने के लिए होते हैं; दूसरी ओर इन्हें एप्लिकेशन-स्रोत नेटवर्क के रूप में घोषित नहीं किया जाता।

इसलिए दूसरी ओर ऐसे पते से इको अनुरोध मिल सकता है जिसके लिए उसका कोई वापसी मार्ग नहीं है, या ऐसे से जिससे कोई सिलेक्टर मेल नहीं खाता। टनल स्वस्थ हो सकती है और पिंग फिर भी विफल हो सकती है, और यह ठीक वही झूठा नकारात्मक है जिस पर यह लेख है।

स्रोत जान-बूझकर चुनें

नियंत्रित Linux गेटवे पर वह स्रोत चुनें जो पहले से स्थानीय रूप से सौंपा गया है: ping -c 4 -I 10.30.0.1 10.40.0.20। यहाँ पते उदाहरण के लिए हैं, इसलिए गेटवे का असली भीतरी पता और असली दूर का गंतव्य डालें, और पुष्टि करें कि आपका चुना स्रोत इसी डिवाइस का है और साइट नीति उसे स्वीकार करती है।

परीक्षण के लिए किसी वर्कलोड का पता उधार न लें। ऐसे होस्ट का रूप धारण करना जो गेटवे को सौंपा नहीं गया है, ऐसा नतीजा बनाता है जिसे कोई दोहरा नहीं सकता, और कुछ स्टैक पर यह ऐसे विफल होता है जो टनल की खराबी जैसा दिखता है।

सिर्फ़ अनुरोध नहीं, वापसी पथ पढ़ें

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

यहीं पैकेट कैप्चर एक और पिंग से ज़्यादा मदद करता है: यह वह स्रोत दिखाता है जो दूसरी ओर ने देखा, और उसी पते तक उसका जवाब पहुँचना है।

फिर वर्कलोड जाँचें

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

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

सिर्फ़ एक निदान जवाब पाने के लिए 169.254.0.0/16 के लिए व्यापक मार्ग न जोड़ें। यह भ्रामक परीक्षण को स्थायी रूटिंग फ़ैसले से बदल देता है, और अगला व्यक्ति इसे संदर्भ के बिना विरासत में पाता है।