RADIUS ले VPN प्रयोगकर्तानामको सट्टा IP ठेगाना किन देख्छ

strongSwan ले कुनै पनि EAP आदानप्रदान अघि IKE पहिचान RADIUS User-Name मा राख्न सक्छ। खाताको पहिचान कसले माग्छ भन्ने तय गर्नुहोस्, त्यसपछि एउटा प्रयास मिलाउनुहोस्।

Windows IKEv2 क्लाइन्ट जोडिन्छ, र RADIUS अनुरोध खाताको नाम हुनुपर्ने ठाउँमा ठेगानासहित आउँछ। अझै केही असफल भएको छैन, र अन्योलको भाग त्यही हो: गेटवेले क्लाइन्टले IKE तहमा प्रस्तुत गरेको पहिचान रिपोर्ट गर्दै छ। तपाईंको ब्याकएन्डले चाहेको प्रयोगकर्तानाम अझै नभएको छुट्टै EAP आदानप्रदानबाट आउन सक्छ। खाता बदल्नु अघि यो कसले माग्छ भन्ने तय गर्नुहोस्।

एउटै जडानमा दुई पहिचान यात्रा गर्छन्

एउटै जडानमा दुई नाम देखिन सक्छन्। IKE पहिचानले सुरुङ सेटअपका क्रममा साथीलाई चिन्छ, र eap-radius प्लगइनले सुरुमा यसलाई RADIUS User-Name मा प्रतिलिपि गर्छ। EAP पहिचान प्रयोगकर्ता प्रमाणीकरणका लागि प्रयोग हुने फरक मान हो, र कसैले नमागे यो कहिल्यै नपठाइन सक्छ।

त्यसैले खाता अवस्थित र पासवर्ड सही हुँदा पनि RADIUS लगले ठेगाना देखाउन सक्छ। ब्याकएन्डलाई गलत तहबारे सोधिँदै छ। RADIUS विशेषता छानिएको नामका लागि वाहक मात्र हो।

गेटवेलाई EAP पहिचान माग्न भन्नुहोस्

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

remote {
    auth = eap-radius
    eap_id = %any
}

त्यसपछि ब्याकएन्डले IKE ठेगानाको सट्टा क्लाइन्टले EAP आदानप्रदानमा दिने पहिचान पाउँछ। जडानमा अरू केही बदलिँदैन।

वा RADIUS लाई EAP आदानप्रदान सुरु गर्न दिनुहोस्

अर्को व्यवस्थाले पहिलो कदम RADIUS पक्षमा राख्छ। प्लगइनले सुरुवाती पहिचान प्रतिक्रियाको प्रतीक्षा गर्नुको सट्टा EAP-Start संकेत पठाउन सक्छ, जसले सर्भरलाई आदानप्रदान चलाउन दिन्छ। यो प्लगइन-स्तरको कन्फिगरेसन हो, त्यसैले प्लगइन प्रयोग गर्ने हरेक जडानमा असर पर्छ।

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

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

एउटा प्रयास दुवै लगमा पछ्याउनुहोस्

एउटै प्रयास दुवै लगमा मिलाउनुहोस्। IKE पहिचान हेर्नुहोस्, त्यसपछि EAP-Identity आदानप्रदान हुन्छ कि भनेर, त्यसपछि प्रमाणीकरण चरणले कुन नाम पाउँछ भनेर। EAP आदानप्रदान अघि ठेगाना अस्वीकार गर्ने ब्याकएन्डले तपाईंको इच्छित पहिचान कहिल्यै देखिनु अघि प्रक्रिया रोक्न सक्छ।

journalctl -u strongswan -f

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

यदि सुधारिएको प्रवाह सही खातामा पुग्छ र अझै अस्वीकृत हुन्छ भने, अर्को प्रमाण पहिचान होइन, EAP विधि र ब्याकएन्ड नीति हो। पासवर्ड रिसेट दोहोर्याउँदा अघिल्लो प्रोटोकल तहमा छानिएको मान सुधार्न सकिँदैन।

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