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 से बँधी सेवा तक नहीं पहुँच सकती, और सुरंग में जाने वाले रूट को अब भी गंतव्य सहित सिलेक्टर चाहिए। तीनों को उसी परीक्षण अनुरोध पर जाँचें, और असंगति अपना नाम ख़ुद बता देगी।