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 ओळख सेट केल्याने प्रमाणपत्र नूतनीकरण होत नाही किंवा त्याच्या जारीकर्त्यावर विश्वास प्रस्थापित होत नाही, आणि प्रमाणपत्र नूतनीकरण केल्याने चुकीचे अपेक्षित नाव सुधारत नाही। दुसरे ओळख फील्ड संपादित करण्यापूर्वी कोणते सत्यापन अपयशी ठरले ते वाचा। नंतर कॉन्फिगरेशन पुन्हा लोड करा आणि लोड झालेली जोडणी तुम्ही सेट केलेले मूल्य दाखवते याची खात्री करा, कारण कधीही लोड न झालेली संपादित फाइल काहीही बदलत नाही। दोन्ही नावे आणि त्यांचे स्तर तैनाती नोंदींमध्ये लिहा।

संबंधित लेख