एक OpenVPN रूट strongSwan XFRM नीति से क्यों हार जाता है

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

दो निर्णय, एक नहीं

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

चौड़ा IPsec सिलेक्टर ही सामान्य कारण है। 172.16.0.0/12 की सुरक्षा करने वाली नीति 172.20.8.0/24 को भी ढकती है, जहाँ व्यवस्थापक शायद OpenVPN टनल से पहुँचना चाहता है। इरादा केवल रूटिंग तालिका में मौजूद है, और नीति डेटाबेस को उसकी कभी जानकारी नहीं हुई।

इसे दो कॉन्फ़िगर किए गए सुरक्षा रास्तों के बीच टकराव मानें, दो मीट्रिक के बीच मुकाबला नहीं। सुधार उसी घटक में होना चाहिए जो गलत दायरे के साथ कॉन्फ़िगर हुआ था।

वह रूट पढ़ें जो कर्नेल वास्तव में चुनता है

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

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

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

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

वह नीति भी पढ़ें जो लागू होती है

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

ip -s xfrm policy
swanctl --list-sas

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

अगर सूची में आपकी अपेक्षित प्रीफ़िक्स के लिए कोई नीति नहीं है, तो समस्या कहीं और है और रूटिंग तालिका संभवतः सच कह रही है। अगर इसमें प्रीफ़िक्स को ढकने वाली अधिक चौड़ी नीति है, तो आपको वह कैप्चर मिल गया है।

जब दोनों रास्ते वैध हों तब तीन विकल्प

IPsec सिलेक्टर को सीमित करना सबसे स्वच्छ विकल्प है जब चौड़ा प्रीफ़िक्स आवश्यकता नहीं बल्कि सुविधा था। दूरस्थ ट्रैफ़िक सिलेक्टर को उन सबनेट तक घटाना जो सचमुच IPsec के पीछे हैं, एक साथ हर होस्ट के लिए टकराव हटा देता है, और इसकी कीमत कुंजी का पुनः वार्तालाप है, नया घटक नहीं।

पासथ्रू अपवाद तब सर्जिकल विकल्प है जब चौड़ा सिलेक्टर रहना ही चाहिए। strongSwan ऐसा अलग कनेक्शन समर्थित करता है जिसका child pass मोड उपयोग करता है, जो कर्नेल को बताता है कि मेल खाते ट्रैफ़िक को IPsec द्वारा संसाधित नहीं किया जाना चाहिए। लूपबैक दूरस्थ पता उस कनेक्शन को आने वाले साथियों के लिए चुने जाने से रोकता है, और सिलेक्टरों को सब कुछ नहीं, बल्कि वास्तविक अधिकृत जोड़ी का वर्णन करना चाहिए।

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

strongSwan कॉन्फ़िगरेशन उदाहरण इस नीति प्रकार और लूपबैक साथी परंपरा का दस्तावेज़ीकरण करते हैं। तीसरा विकल्प XFRM इंटरफ़ेस के साथ रूट-आधारित डिज़ाइन है, जो नीति को वैश्विक सिलेक्टर के बजाय किसी नामित इंटरफ़ेस से रूट होने वाले ट्रैफ़िक से जोड़ता है। यह ट्वीक नहीं, माइग्रेशन है, और ट्रैफ़िक को अब भी तय किए गए सिलेक्टरों को पूरा करना है।

बाकी को कमज़ोर किए बिना अपवाद सिद्ध करें

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

लिखें कि कौन-सा प्रीफ़िक्स कौन-सा रास्ता उपयोग करता है और क्यों। वरना चौड़ा सिलेक्टर देखने वाला अगला इंजीनियर वही जाँच फिर खोलेगा, और उत्तर किसी ऐसे commit संदेश में पड़ा रहेगा जिसे कोई नहीं पढ़ता।