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 पद्धत आणि बॅकएंड धोरण आहे। पासवर्ड रीसेटची पुनरावृत्ती आधीच्या प्रोटोकॉल स्तरावर निवडलेले मूल्य दुरुस्त करू शकत नाही।

संबंधित लेख