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

संबंधित लेख