रूट-आधारित IPsec XFRM इंटरफ़ेस के साथ कैसे काम करता है

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

डिवाइस क्या है और क्या नहीं

XFRM इंटरफ़ेस एक रूटिंग हैंडल है। इसमें रूट किए गए पैकेट उन XFRM नीतियों से मिलाए जाते हैं जो उसी इंटरफ़ेस पहचानकर्ता का संदर्भ देती हैं, और यदि नीति और स्थिति दोनों मौजूद हों तो उन्हें एनकैप्सुलेट किया जाता है। उनके बिना इंटरफ़ेस मौजूद रहता है, काउंटर स्थिर रहते हैं, और ट्रैफ़िक किसी काम की जगह नहीं जाता।

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

एक और सीमा: इंटरफ़ेस पहचानकर्ता कोई नाम नहीं है। समान नाम और भिन्न पहचानकर्ता वाले दो डिवाइस स्थिति साझा नहीं करते, और गलत पहचानकर्ता के साथ कॉन्फ़िगर किया गया कनेक्शन ऐसी स्थिति स्थापित करता है जिसका कोई रूट कभी उपयोग नहीं करेगा।

सही क्रम में एक बनाएँ

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

डिवाइस को ऊपर लाएँ, फिर VPN कॉन्फ़िगरेशन छूने से पहले कर्नेल द्वारा दर्ज पहचानकर्ता की पुष्टि करें:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

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

IKE और ESP को सुरंग रूट से बाहर रखें

XFRM डिवाइस में इंगित डिफ़ॉल्ट रूट एनकैप्सुलेटेड पैकेट और उनके द्वारा ढोए जाने वाले ट्रैफ़िक दोनों को पकड़ लेता है। परिणाम एक लूप है: गेटवे अपना ESP उस सुरंग से भेजने की कोशिश करता है जिसे ESP को बनाना है।

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

आप जो भी चुनें, सत्यापित करें कि बाहरी पैकेट बिना एनकैप्सुलेशन के निकलता है। तेज़ जाँच यह है कि सुरंग ऊपर आने के बाद साथी के बाहरी पते पर पिंग करें; यदि इंटरफ़ेस ऊपर रहते हुए यह विफल हो, तो पहुँच के बजाय पकड़े जाने का संदेह करें। यही तर्क IKE पोर्ट पर लागू होता है, क्योंकि डेमन का अपना UDP ट्रैफ़िक उस डिवाइस में रूट नहीं होना चाहिए जिसे वह स्थापित करने की कोशिश कर रहा है।

एन्क्रिप्शन को दोष देने से पहले दो जगहों पर काउंटर जाँचें

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

दोनों पढ़ें, फिर चाइल्ड एसोसिएशन पर डेमन का दृष्टिकोण पढ़ें:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

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

तय करें कि रूट कौन स्थापित करेगा

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

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

फ़ॉरवर्डिंग और फ़ायरवॉल नियम इसके ऊपर एक अलग निर्णय हैं, क्योंकि दूसरे होस्टों का ट्रैफ़िक पार कराने वाले गेटवे को दोनों चाहिए। रूट-आधारित IPsec उस ट्रैफ़िक को सामान्य रूटिंग उपकरणों से व्यक्त करना आसान बनाता है; यह नीति परत को वैकल्पिक नहीं बनाता।