IPsec सुरक्षा नीति रूट टेबल की प्रविष्टि क्यों नहीं है

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

टेबल से नहीं, लुकअप से शुरू करें

कर्नेल से पूछें कि वह वास्तव में क्या करेगा: ip route get 10.20.0.5 चुना गया रूट, बाहर जाने वाला इंटरफ़ेस और वह स्रोत पता छापता है जो वह इस्तेमाल करेगा। प्रीफ़िक्स, नीति नियम, मार्क या पसंदीदा स्रोत इन सब जवाब बदल सकते हैं, इसलिए जीवंत लुकअप आँख से टेबल पढ़ने से बेहतर है।

संरक्षित श्रेणी के अंदर की गंतव्य जाँचें, गेटवे पता नहीं। दूसरी तरफ़ के गेटवे तक पहुँचना सिर्फ़ यह साबित करता है कि कोई रूट मौजूद है; यह उस सबनेट के बारे में कुछ नहीं कहता जो आपको वास्तव में चाहिए। फिर पुष्टि करें कि लुकअप ने जो इंटरफ़ेस चुना है वही वह है जिसे टनल इस्तेमाल करेगा।

दोनों तरफ़ सिलेक्टर मिलाएँ

नीति डेटाबेस की अपनी प्रविष्टियाँ होती हैं, और हर एक दिशा, स्रोत, गंतव्य और प्रोटोकॉल बताती है, फिर कहती है कि मेल खाने वाले पैकेटों के साथ क्या होना चाहिए। उन्हें सूचीबद्ध करने के लिए ip xfrm policy इस्तेमाल करें; फ़्लैग दिखाते हैं कि क्रिया सुरक्षा है, बायपास है या ब्लॉक है। जिस नीति के सिलेक्टर आपके परीक्षण फ़्लो से चौड़े या संकीर्ण हैं वह उससे मेल नहीं खाएगी, और पैकेट असुरक्षित निकल जाता है। यही वह विफलता है जिसे आप खोज रहे हैं, कोई गुम रूट नहीं।

वास्तविक मानों की तुलना करें: स्रोत, गंतव्य, प्रोटोकॉल और पोर्ट। अगर लुकअप ने एक पता जोड़ी हल की जबकि नीति प्रविष्टि दूसरी कवर करती है, तो दोनों दृश्य अलग ट्रैफ़िक बताते हैं। निष्कर्ष निकालने से पहले दोनों को एक ही टपल के साथ फिर चलाएँ, वरना आप ऐसी नीति संपादित करेंगे जो कभी रास्ते में नहीं थी।

नीति का मेल होना इंस्टॉल की गई स्थिति नहीं है

मेल खाती नीति सिर्फ़ कहती है कि पैकेट को सुरक्षित होना चाहिए; सुरक्षा करने के लिए कर्नेल को अभी भी एक सुरक्षा एसोसिएशन चाहिए। उन्हें ip xfrm state से सूचीबद्ध करें, या जब strongSwan बातचीत करे तो swanctl --list-sas से, और हर प्रविष्टि के सिलेक्टर और काउंटर पढ़ें।

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

रूट-आधारित टनल को अभी भी क्या चाहिए

XFRM इंटरफ़ेस टनल को ऐसे उपकरण जैसा बनाता है जिसमें आप रूट कर सकते हैं, जो सचमुच उपयोगी है। यह उस नीति और स्थिति को नहीं हटाता जो तय करती हैं कि पैकेट वहाँ पहुँचने के बाद क्या होगा। रूट सिर्फ़ अगली हॉप देता है, इससे ज़्यादा नहीं।

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

कुछ भी संपादित करने से पहले स्वामित्व तय करें

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

कॉन्फ़िगरेशन का स्वामित्व तय करता है कि आपका सुधार रीस्टार्ट के बाद बचेगा या नहीं। एक घटक स्थिति इंस्टॉल कर सकता है जबकि दूसरा रूट प्रबंधित करता है, और दूसरे पर हाथ से किया संपादन अगली बार टनल आने पर अधिलेखित हो जाता है। स्वामी कॉन्फ़िगरेशन बदलें, फिर दोनों दृश्य फिर पढ़ें; RFC 4301 दोनों डेटाबेस अलग रखता है जब आपको यह विभाजन किसी और को समझाना पड़े।