आपका IKEv2 SA चालू है पर कोई चाइल्ड SA नहीं: विनिमय पढ़ें

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

दो एसोसिएशन, दो काम

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

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

किस परत ने मना किया

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

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

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

फिर डेटा पथ के बारे में पूछें

चाइल्ड SA होने पर काउंटर अगले प्रश्न का उत्तर देते हैं। ip -s xfrm state प्रति एसोसिएशन पैकेट और बाइट गणना बताता है, और ट्रैफिक उत्पन्न करते समय कुछ न ले जाने वाला चाइल्ड SA मिलान या रूटिंग की ओर संकेत करता है अनुपस्थित एसोसिएशन की ओर नहीं। swanctl --list-sas उन काउंटरों के बगल में चाइल्ड SA के चयनकर्ता छापता है, और यही पुष्टि करता है कि पैकेट स्वीकृत समुच्चय के भीतर है।

सफल प्रमाणीकरण और विफल चाइल्ड SA विनिमय को रिपोर्ट में अलग रखें। प्रमाणीकरण विफल होने वाली रिपोर्ट अगले इंजीनियर को प्रमाणपत्र भंडार तक भेजती है, और सटीक वाक्य बहुत छोटा है: IKE SA ऊपर आया, और इस प्रवाह के लिए चाइल्ड SA कभी स्वीकृत नहीं हुआ।

दोनों सिरों को जोड़ें

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

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