IPsec ट्राफिक सेलेक्टरहरू: तिनीहरूले के समेट्छन् र के समेट्दैनन्

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

तिनीहरूलाई दुवै छेउबाट पढ्नुहोस्

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

मानहरू सधैं एकल सबनेट हुँदैनन्। IKEv2 सेलेक्टरहरूले ठेगाना-दायरा, प्रोटोकल नम्बर र पोर्ट-दायरा बोक्न सक्छन्, र यसरी नीतिले पूरै सञ्जालको सट्टा एउटा सेवाको रक्षा गर्छ। इच्छित ट्राफिकभन्दा साँघुरो सेलेक्टरले केही गन्तव्य बोक्ने र अरूलाई चुपचाप बाहिर राख्ने सुरुङ बनाउँछ।

केही बदल्नुअघि दुवै पक्षलाई एउटै तालिकामा लेख्नुहोस्। यो अभ्यासले प्रायः कन्फिगरेसन फाइल छुनु नपरी प्रश्न टुङ्गो लगाउँछ।

साँघुरो बनाउनु प्रतिक्रियाकर्ताको निर्णय हो

सुरु गर्नेले प्रस्ताव राख्छ, र प्रतिक्रियाकर्ताले उपसमूह मात्र स्वीकार गर्न सक्छ। IKEv2 ले प्रतिक्रियाकर्तालाई प्रस्तावित ट्राफिक सेलेक्टर साँघुरो बनाउन अनुमति दिन्छ, र साँघुरिएको परिणाम नै वास्तवमा स्थापना हुन्छ। त्यसैले सुरु गर्नेको कन्फिगरेसन पढ्नु प्रस्ताव वर्णन गर्छ, सम्झौता होइन।

त्यसैले ग्राहकमा थपिएको सबनेटले चलिरहेको सुरुङ बनाए पनि नयाँ गन्तव्य अस्वीकार गर्न सक्छ। सर्भरले आफ्नो नीतिले अनुमति दिएसम्म प्रस्ताव साँघुरो बनायो, तर ग्राहकको फाइलले अझै फराकिलो दायरा सूचीबद्ध गर्छ। वार्ताद्वारा तय भएको अवस्थाले मात्र सत्य देखाउँछ: Linux मा ip xfrm policy र strongSwan को IKEv2 कागजातमा child SA सूचीले मागिएको होइन, स्थापना गरिएको रिपोर्ट गर्छ। दुई फरक परेमा प्रतिक्रियाकर्ताको नीति नै बदल्नुपर्ने हुन्छ।

अस्वीकृत प्रस्ताव साँघुरिएको भन्दा फरक लक्षण हो। अस्वीकृति वार्ता लगमा देखिन्छ र कुनै child सम्बन्ध छोड्दैन।

एउटा गन्तव्यलाई सुरुदेखि अन्त्यसम्म पछ्याउनुहोस्

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

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

मार्ग प्रश्नले प्याकेट बोक्ने इन्टरफेस र स्रोत ठेगाना बताउँछ। नीति सूचीले त्यो जोडीका लागि मिल्ने सुरुङ नीति छ कि छैन देखाउँछ, त्यसको दिशा र स्तरसहित। SA सूचीले वार्ताद्वारा तय भएका child सेलेक्टरहरू गणकसहित देखाउँछ, त्यसैले ट्राफिक प्रयास गरेपछि शून्य प्याकेट भएको child सम्बन्ध पठाइँदै गरेको कुरा बाहिर राख्ने सेलेक्टरहरूको हस्ताक्षर हो। तीन आदेश, तीन फरक उत्तर, र तिनमध्ये एउटाले मात्र चुपचाप खस्किने व्याख्या गर्छ।

यदि अनुप्रयोग अझै असफल हुँदै गर्दा child गणक सर्छन् भने समस्या सुरुङपारि छ। त्यसले अनुसन्धानलाई सेलेक्टरतिर होइन, टाढाको होस्टको श्रोता वा फायरवालतिर सार्छ।

दुई लक्ष्य अलग राख्नुहोस्

कार्यालय सबनेटको रक्षा गर्नु र सबै ब्राउजिङ टाढाको निकासबाट पठाउनु फरक सेलेक्टर भएका फरक आवश्यकता हुन्। एउटाका लागि बनाइएको प्रोफाइल अर्कोका लागि विरलै मिल्छ, र दुवै मिसाउँदा या त चुहावट या टुटेको विभाजन हुन्छ। सुरक्षित दायरा फराकिलो बनाउनु भनेको दुवै छेउ र तिनका अगाडि पठाउने नीति बदल्नु हो, किनकि एकतर्फी परिवर्तन अस्वीकृत प्रस्ताव बन्छ। सानो सम्पादनपछि चलिरहेको सुरुङ चल्न छाड्ने सबैभन्दा सामान्य बाटो यही हो।

सेलेक्टरहरूले क्रिप्टोग्राफिक समेट्ने क्षेत्र वर्णन गर्छन्, मार्गहरूले बाटो छान्छन्, र अनुप्रयोगहरूले आफ्नै अनुमति लागू गर्छन्। सबै समेट्ने सुरुङले पनि loopback मा बाँधिएको सेवासम्म पुग्न सक्दैन, र सुरुङभित्र जाने मार्गलाई अझै गन्तव्य समेट्ने सेलेक्टर चाहिन्छ। तीनवटैलाई एउटै परीक्षण अनुरोधमा जाँच्नुहोस्, र असङ्गतिले आफ्नै नाम भन्नेछ।