IKEv2 आदानप्रदान काम गर्छ, त्यसपछि प्रमाणीकरण असफल हुन्छ: कहाँ हेर्ने

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

जाँच 1: सन्देश होइन, चरण पढ्नुहोस्

अस्वीकार तीन ठाउँबाट आउन सक्छ: ग्राहकले सर्भरको पहिचान अस्वीकार गर्छ, गेटवेले ग्राहकको प्रमाण अस्वीकार गर्छ, र बाह्य प्रमाणीकरण सेवाले खाता अस्वीकार गर्छ।

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

जाँच 2: कुन पहिचान जाँचियो

कुनै पनि प्रयोगकर्ता प्रमाणपत्र दिनुअघि नै ग्राहकले सर्भरको प्रमाणपत्र वा अपेक्षित पहिचान अस्वीकार गर्न सक्छ, र काम गर्ने सर्भर ठेगाना त्यो जाँचको विकल्प होइन। ग्राहकले अपेक्षा गर्ने पहिचानकर्ता गेटवेले प्रस्तुत गर्नेसँग मिल्नुपर्छ, जुन नेटवर्क तथ्य होइन, कन्फिगरेसन तथ्य हो।

strongSwan को शब्दावलीमा त्यो ग्राहकमा rightid र अर्कोतर्फ गेटवेको आफ्नै पहिचान हो, र EAP चर्चा हुनुअघि नै बेमेल असफल हुन्छ।

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

जाँच 3: यदि EAP संलग्न छ

ग्राहक र सर्भरले समर्थित विधिमा सहमत हुनुपर्छ, र ब्याकएन्डले दिइएको पहिचान स्वीकार गर्नुपर्छ।

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

पहिचान जाँच बन्द गरेर पहिचानका समस्या परीक्षण नगर्नुहोस्। त्यसले निदान गर्न सकिने असफलतालाई निदान गर्न नसकिने बनाउँछ र जडानलाई पहिलेभन्दा कमजोर छोड्छ।

जाँच 4: सफल लगइनपछि के हुन्छ

IKE_AUTH पूरा भएपछि, कुन ट्राफिक चयनकर्ता स्थापना गर्ने भन्ने CHILD_SA वार्ताले निर्धारण गर्छ, र त्यहीँ जडान सफल भएर पनि केही पास नहुन सक्छ।

नयाँ काम गर्ने लगइनले प्रायः पहिले प्रमाणीकरण असफलतापछि लुकेको चयनकर्ता वा मार्ग समस्या खुलासा गर्छ। टनेल माथि आए पनि अनुप्रयोग आफ्नो गन्तव्यमा पुग्न सक्दैन भने, फेरि पहिचानतिर होइन, वार्ता भएका चयनकर्ता र मार्गतिर हेर्नुहोस्। त्यो बेला पहिचान सेटिङ बदल्नु गलत चरणलाई लक्षित गर्छ र सामान्यतया काम गर्ने लगइन तोड्छ। swanctl --list-sas ले पुष्टि गर्नुहोस्, जसले IKE SA बाट छुट्टै सन्तान र तिनका चयनकर्ता देखाउँछ।

जाँच 5: सहयोगलाई के दिने

सफा गरिएको समयरेखा र सटीक अस्वीकार पूर्ण निदान निर्यातभन्दा बढी मूल्यवान छ, र निर्यातमा साझा गर्न नहुने निजी कुञ्जी वा प्रमाणहरू हुन सक्छन्।

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