IKEv2 एउटा मात्र ह्यान्डसेक होइन: पहिले IKE SA, त्यसपछि प्रमाणीकरण र त्यसपछि CHILD SA

गेटवेको जवाफले पहुँच देखाउँछ, पहिचान होइन। IKE_SA_INIT, IKE_AUTH र पहिलो CHILD SA पछ्याउनुहोस्, त्यसपछि ट्राफिक बग्नु अघि के सत्य हुनुपर्छ जाँच्नुहोस्।

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

भ्रम: गेटवेले जवाफ दियो भने तपाईं जोडिनुभयो

पहिलो सन्देशको जवाफले अन्तिम बिन्दु पुग्न सकिने र बोल्न तयार रहेको प्रमाणित गर्छ। खाता स्वीकारियो, प्रमाणपत्र शृंखला मान्य भयो, वा कुनै डेटा नीति स्थापना भयो भनेर यसले प्रमाणित गर्दैन।

ती असफलता पछि हुन्छन्, र फरक लक्षण दिन्छन्। प्रमाणपत्र अस्वीकार वा EAP असफलता पहिलो आदानप्रदान सफल भइसकेपछि आउँछ, त्यसैले UDP 500 मा ping र क्लाइन्टको हरियो चिन्हले धेरै थोरै बताउँछ।

IKE_SA_INIT: प्यारामिटरमा सहमत हुनुहोस्, पहिचानमा होइन

पहिलो आदानप्रदानले IKE सुरक्षा संगठनका प्रस्ताव बोक्छ: इन्क्रिप्सन र अखण्डता एल्गोरिदम, स्युडो-अनियमित फंक्शन र Diffie-Hellman समूह। दुवै पक्षले nonce पनि साटासाट गर्छन्, र प्रत्येक पक्षले ती मानबाट बन्ने साझा रहस्यबाट 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 स्थापना र अन्तमा एप्लिकेसन ट्राफिक। रोकिने चरण नै सुधार्नुपर्ने चरण हो, र पछिको राउटिङ असफलता पहिले नै पास भइसकेका पहिचान जाँचहरू खुकुलो बनाउने कारण कहिल्यै होइन।

सम्बन्धित लेखहरू