IKE SA स्थापित, CHILD SA छैन: डेटा कहाँ रोकिन्छ

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

दुई SA ले के गर्छन्

IKE SA नियन्त्रण सम्बन्ध हो: यसले पक्षहरूलाई प्रमाणीकरण गर्छ र सुरक्षाको वार्ता गर्ने, प्रतिस्थापन गर्ने र हटाउने आदानप्रदान बोक्छ। यसले तपाईंको अनुप्रयोग प्याकेट कहिल्यै बोक्दैन। त्यसैले स्वस्थ अभिभावकले दुई छेउ सुरक्षा नीतिमा सहमत हुन सक्ने मात्र प्रमाणित गर्छ, त्यसभन्दा बढी केही होइन।

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

जडान लेबल होइन, चाइल्ड प्रविष्टि पढ्नुहोस्

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

अभिभावकले तपाईं परीक्षण गरिरहेकोभन्दा फरक ट्राफिक समूह देखाएमा तपाईं गलत चाइल्ड पढिरहनुभएको छ। त्यो सिलेक्टरको समस्या हो, बिग्रिएको सुरुङ होइन।

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

चाइल्ड नै नभएको अवस्थामा

डेटा प्रस्ताव वा सिलेक्टर असफल हुँदा पनि प्रमाणीकरण सफल हुन सक्छ, र अभिभावक चाइल्डविहीन रहन्छ। सामान्य कारण एल्गोरिदमको नमिल्नु वा ट्राफिक सिलेक्टरको नमिल्नु हो, र दुवै पक्षले अस्वीकृत प्रस्ताव लगमा लेख्छन्। दुवै छेउ पढ्नुहोस्, किनकि तपाईं पुग्ने पक्षले अस्वीकृति मात्र देखाउन सक्छ। अभिभावक पुनः सुरु गर्नुको सट्टा नमिलेको कुरा सुधार्नुहोस्, किनकि त्यसले त्यही असफल वार्ता दोहोर्याउँछ र प्रमाणमा अर्को अवरोध थप्छ।

पटक-पटक पुनः स्थापित हुने अभिभावक चाइल्डबिना टिक्ने अभिभावकभन्दा फरक खराबी हो। दोस्रो अवस्थामा लगहरूले अस्वीकृत प्रस्तावको नाम दिन्छन्, त्यसैले नीति सम्पादन गर्नु अघि त्यो प्रस्ताव दुवै छेउबाट संकलन गर्नुहोस्।

चाइल्ड छ तर काउन्टर शून्यमै रहँदा

चाइल्डका सिलेक्टरसँग मिल्ने नयाँ अनुरोध पठाउनुहोस्। त्यो नीतिबाहिरको गन्तव्यमा जाने अनुरोध जतिसुकै सफल देखिए पनि त्यसका काउन्टर सार्दैन।

प्रवाहलाई सुरुङमा धकेल्नुपर्ने मार्ग जाँच्नुहोस्, किनकि ट्राफिक नभएको चाइल्ड प्रायः त्यस्तो चाइल्ड हुन्छ जहाँ केही पनि मार्गनिर्देशित हुँदैन। एउटै दिशामा मात्र सर्ने काउन्टरले फर्किने बाटोमा सिलेक्टर वा नीतिको नमिलेको संकेत गर्छ। स्थानीय पक्ष छुनु अघि टाढाको पक्षको फर्किने सिलेक्टर हेर्नुहोस्। नयाँ अनुरोधले दुवै छेउको स्थिति आउटपुटसँग भिडाउन समय छाप पनि दिन्छ।

प्रतिवेदनमा तहको नाम दिनुहोस्

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

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