कई सबनेट वाला IPsec वापसी ट्रैफ़िक खो रहा है? reqid गिनें

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

कुछ भी बदलने से पहले लक्षण अलग करें

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

MTU से शुरू न करें। गलत MTU रुकावटें और विखंडन के लक्षण पैदा करता है, बढ़ते बाहर जाने वाले काउंटरों के साथ साफ़ दिशा विभाजन नहीं।

नीति डेटाबेस और स्थिति डेटाबेस पढ़ें

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

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

क्लासिक असमानता: कई सबनेट के लिए एक reqid

एक आम विफलता ऐसे पीयर से आती है जो सभी तय सबनेट की नीतियाँ एक ही reqid के अंतर्गत स्थापित करता है, जो racoon के generate_policy require के साथ होता है। ट्रैफ़िक तब अंतिम में बने संबंध से बाहर जाता है, जबकि दूसरा पक्ष हर सबनेट के लिए अलग संबंध रखता है। जवाब ऐसे संबंध पर आते हैं जिसका reqid उस नीति की पहचान नहीं करता जिसे उन्हें स्वीकार करना चाहिए था, और कर्नेल डिक्रिप्शन के बाद उन्हें गिरा देता है।

सुधार एक कॉन्फ़िगरेशन बदलाव है, फ़ायरवॉल नियम नहीं: generate_policy unique; हर नीति को उसका अपना reqid देता है, ताकि पीयर के प्रति-नीति संबंधों के मेल खाते साथी हों। इसे लागू करें, फिर से बातचीत करें, और सफलता घोषित करने से पहले अपेक्षित सबनेट के अलग-अलग reqid गिनें।

अगर दो सबनेट अब भी एक reqid साझा करते हैं जबकि दूसरा पक्ष दो की अपेक्षा करता है, तो आपने असमानता पा ली। मैपिंग दर्ज करें, क्योंकि यह प्रमाण है कि अगले बदलाव ने उसे ठीक किया या बनाए रखा।

सिलेक्टर बातचीत से आते हैं, आपके कॉन्फ़िगरेशन से नहीं

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

जब लक्ष्य उलटा हो, यानी एक गंतव्य को टनल से बाहर रखना हो, तो कम प्राथमिकता संख्या वाली बायपास नीति जोड़ें ताकि वह स्वतः स्थापित प्रविष्टि पर भारी पड़े। बिना टेम्पलेट वाली नीति सादा पाठ की अनुमति देती है, जो उसे बदलाव रिकॉर्ड के लिए जानबूझकर अपवाद बनाती है, डिबगिंग कदम नहीं।

इसी क्रम में सत्यापित करें, और जानें कि कैसे पीछे हटें

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

पीयर बदलने से पहले दोनों xfrm कमांडों का मौजूदा आउटपुट सहेजें। अगर नई सेटिंग वापसी की दिशा बहाल न करे, तो उस आउटपुट को बहाल करना याद से सुरंग दोबारा बनाने से तेज़ वापसी है, और तुलना को ईमानदार रखता है।