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