IKEv2 एक ही हैंडशेक नहीं है: पहले IKE SA, फिर प्रमाणीकरण और फिर CHILD SA

गेटवे का उत्तर पहुँच सिद्ध करता है, पहचान नहीं। IKE_SA_INIT, IKE_AUTH और पहले CHILD SA का अनुसरण करें, फिर देखें कि ट्रैफ़िक बहने से पहले क्या सच होना चाहिए।

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

भ्रम: अगर गेटवे उत्तर देता है, तो आप जुड़े हुए हैं

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

वे विफलताएँ बाद में होती हैं, और वे अलग लक्षण पैदा करती हैं। प्रमाणपत्र का अस्वीकार या EAP विफलता पहले आदान-प्रदान के सफल होने के बाद आती है, इसलिए UDP 500 पर पिंग और क्लाइंट का हरा आइकन आपको बहुत कम बताते हैं।

IKE_SA_INIT: पैरामीटर पर सहमति, पहचान पर नहीं

पहला आदान-प्रदान IKE सुरक्षा संगठन के लिए प्रस्ताव ले जाता है: एन्क्रिप्शन और अखंडता एल्गोरिदम, एक छद्म-यादृच्छिक फ़ंक्शन और एक Diffie-Hellman समूह। दोनों पक्ष nonces का भी आदान-प्रदान करते हैं, और हर पक्ष उन मानों से बनने वाले साझा रहस्य से IKE SA के लिए कुंजी सामग्री प्राप्त करता है। इस आदान-प्रदान में कुछ भी यह स्थापित नहीं करता कि दूसरा पक्ष कौन है। यह स्थापित करता है कि दोनों पक्ष समान कुंजियाँ गणना कर सकते हैं और वे एक प्रस्ताव पर सहमत हैं। जिसे कोई प्रस्ताव पसंद न हो, वह उत्तरदाता यहाँ आदान-प्रदान को अस्वीकार कर देता है, इसलिए संस्करण या एल्गोरिदम की असंगति सर्वर के बंद होने जैसी दिखती है।

इस बिंदु पर बनाया गया IKE SA बाद के सभी प्रबंधन आदान-प्रदानों की रक्षा करता है। यही उसका काम है, और यह आपके पैकेट की रक्षा से अलग काम है।

IKE_AUTH: पहचान सिद्ध करें और फिर पहला CHILD SA बनाएँ

दूसरा आदान-प्रदान पहचान ले जाता है। प्रमाणपत्रों के साथ, हर पक्ष अपनी निजी कुंजी से हस्ताक्षर करता है और ऐसी शृंखला प्रस्तुत करता है जिसे दूसरे पक्ष को मान्य करना होता है; EAP के साथ, उत्तरदाता चुनी गई विधि से आरंभकर्ता को चुनौती देता है। यहीं गलत सर्वर नाम, समाप्त प्रमाणपत्र या अस्वीकृत पासवर्ड अंततः सामने आते हैं।

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

दो SA, दो काम

संगठनरक्षा करता हैजीवनकाल का व्यवहार
IKE SAप्रबंधन आदान-प्रदान: कुंजी नवीनीकरण, विलोपन, कॉन्फ़िगरेशन पेलोडअपनी समय-सारिणी के अनुसार कुंजी नवीनीकृत होती है; डेटा पथ परिवर्तन को सह सकता है
CHILD SAट्रैफ़िक चयनकर्ताओं से मेल खाता एप्लिकेशन ट्रैफ़िकस्वतंत्र रूप से नवीनीकृत होता है, अक्सर अधिक बार

इन्हें अलग रखना दो ऐसे व्यवहारों को समझाता है जो बग जैसे लगते हैं। सुरंग स्थापित दिख सकती है जबकि पृष्ठभूमि में कुंजी नवीनीकरण विफल हो रहा हो, और क्लाइंट का कनेक्शन खोए बिना CHILD SA बदला जा सकता है।

strongSwan पर, IKEv2 कॉन्फ़िगरेशन संदर्भ और swanctl --list-sas दोनों स्तर दिखाते हैं, और ip xfrm state के साथ ip xfrm policy दिखाते हैं कि कर्नेल ने वास्तव में क्या स्थापित किया। इन दो दृश्यों की तुलना देखने का सबसे तेज़ तरीका है कि बातचीत पूरी हुई या केवल पूरी लगी। अगर डेमॉन ऐसा CHILD SA सूचीबद्ध करता है जिसके लिए कर्नेल के पास कोई स्थिति नहीं है, तो स्थापन चुपचाप विफल हुआ। अगर कर्नेल के पास ऐसी स्थिति है जिसे डेमॉन नहीं जानता, तो आप पिछले प्रयास का अवशेष देख रहे हैं।

सुरंग बनने के बाद भी क्या सच रहना चाहिए

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

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

संबंधित लेख