strongSwan EAP: IKE पहिचान र अपेक्षित AAA नाम

strongSwan EAP क्लाइन्टले दुई सर्भर नाम प्रमाणित गर्न सक्छ। remote.id ले IKE गेटवे र local.aaa_id ले EAP सर्भर समेट्छ; यी एउटै फिल्ड होइनन्।

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

एउटै जडान, दुई सर्भर पहिचान

पहिलो पहिचान IKE आदानप्रदानको हो। क्लाइन्टले ठेगाना डायल गर्छ र विपक्षीले निश्चित पहिचान, सामान्यतया गेटवे प्रमाणपत्रको नाम, प्रमाणित गर्ने अपेक्षा गर्छ।

दोस्रो EAP को हो। PEAP वा TTLS सँग, क्लाइन्टले IKE SA भित्र प्रमाणीकरण सर्भरसम्म TLS सुरुङ बनाउँछ, र त्यो भित्री सर्भरले आफ्नै प्रमाणपत्र प्रस्तुत गर्छ। ब्याकएन्ड छुट्टै होस्ट भएमा त्यसको नाम गेटवेको नामभन्दा फरक हुन्छ। पहिलो नाम मात्र जाँच्ने क्लाइन्टले दोस्रोले दाबी गरेको सबै स्वीकार्छ। र दुवै ठाउँमा एउटै नाम राखिएको क्लाइन्ट ती दुई साँच्चै फरक हुने बित्तिकै असफल हुन्छ।

दुवै नाम अपरेटरको कन्फिगरेसनबाट आउँछन्, त्रुटि हटाउने प्रमाणपत्रबाट होइन। अपरेटरलाई तैनाथीको विस्तृत विवरण सोध्नु दुई होस्ट नाम अनुमान गर्नुभन्दा छिटो हुन्छ।

कुन फिल्ड कुन तहको हो

swanctl मा ठेगाना र IKE पहिचान छुट्टै सेटिङ हुन्, र EAP पहिचान तेस्रो हो।

टाढाको ठेगानाले प्याकेट कहाँ जाने छनोट गर्छ, र टाढाको पहिचानले विपक्षीले के प्रमाणित गर्नुपर्ने बताउँछ। EAP अपेक्षा local ब्लकमुनि लेखिन्छ, किनभने यसले विपक्षीको IKE व्यवहार होइन, यो क्लाइन्टको EAP आदानप्रदान वर्णन गर्छ। यही स्थान मानिसहरूले गलत पढ्छन्। नाम क्लाइन्टको कन्फिगरेसनमा रहेर पनि सर्भर वर्णन गर्छ, र त्यसैले यो गलत ठाउँमा देखिन्छ।

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

यो अंश पूरा जडान होइन; विश्वास सामग्री, प्रमाणहरू र सन्तान जडानका नीतिहरू अझै हुनुपर्छ। यसलाई शब्दशः काम गर्ने फाइलमा प्रतिलिपि गर्दा अझै चाहिएका सेटिङ बदलिनेछन्।

aaa_id local मुनि किन बस्छ

local ब्लकले प्रमाणीकरणका बेला यो पक्षले के गर्छ भन्ने वर्णन गर्छ, जसमा यसले प्रयोग गर्ने विधि र त्यो विधिका लागि अर्को पक्षबाट अपेक्षित पहिचान पर्छ। यसमा AAA सर्भर एउटै मेसिनमा चल्छ भन्ने कुरा कतै छैन।

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

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

विभाजन व्यक्त गर्न नसक्ने फ्रन्टएन्ड

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

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

विकल्प क्लाइन्टमा आविष्कार गर्ने कुरा होइन। समर्थित व्यवस्था लिखित रूपमा माग्नुहोस्, त्यसपछि त्यो उत्तर प्रोफाइलसँगै राख्नुहोस्।

पहिचानको असङ्गति र म्याद सकिएको प्रमाणपत्र छुट्याउनुहोस्

नामको असङ्गति र म्याद सकिएको प्रमाणपत्र फरक असफलता हुन्, र लगले ती छुट्याउँछ। कुन फिल्ड बदल्ने निर्णय गर्नुअघि सन्देश पढ्नुहोस्।

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

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

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