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 विधि और बैकएंड नीति है, पहचान नहीं। पासवर्ड रीसेट दोहराना पहले की प्रोटोकॉल परत पर चुने गए मान को ठीक नहीं कर सकता।

संबंधित लेख