iPhone IKEv2 से RouterOS तक: कौन-सा पहचानकर्ता कहाँ जाता है
चार अलग-अलग दावे iOS पर IKEv2 सुरंग तय करते हैं: डायल किया गया पता, अपेक्षित सर्वर पहचान, दावा की गई क्लाइंट पहचान और प्रमाणपत्र सामग्री।
MikroTik गेटवे तक पहुँचना IKEv2 परिनियोजन का केवल परिवहन आधा हिस्सा तय करता है और कुछ नहीं। इसके बाद चार अलग-अलग दावे तय करते हैं कि सुरंग बनेगी या नहीं: वह पता जो फ़ोन डायल करता है, वह सर्वर पहचान जिसकी वह अपेक्षा करता है, वह पहचान जो वह अपने लिए दावा करता है, और वह प्रमाणपत्र सामग्री जो उस दावे का समर्थन करती है। इन्हें उसी क्रम में जाँचें, और पहले ऐसे दावे पर रुकें जो गेटवे जो प्रस्तुत करता है उससे मेल नहीं खाता। हर एक अलग जगह संपादित होता है, इसलिए गलत संपादन आमतौर पर विफलता को ठीक करने के बजाय स्थानांतरित कर देता है।
| Setting | What it decides | What it has to agree with |
|---|---|---|
| Remote address | where IKE packets are sent | a reachable name or address for the gateway |
| Remote Identifier | which server identity is expected | the gateway certificate name and the peer identity RouterOS presents |
| Local Identifier | who the phone claims to be | the client certificate name and the RouterOS identity entry |
| Certificate payload | trust plus proof of key possession | the issuing chain and a usable client private key |
प्रोफ़ाइल फ़ील्ड को उसी क्रम में जाँचें जिसमें विनिमय उनका उपयोग करता है
दूरस्थ पता पहले IKE पैकेट का गंतव्य है और इससे अधिक कुछ नहीं। दूरस्थ पहचानकर्ता वह है जो फ़ोन अपेक्षा करता है कि गेटवे स्वयं को सिद्ध करे, और वह एक नाम है, मार्ग नहीं। दोनों को एक ही होस्टनाम से भरना तब काम करता है जब गेटवे का प्रमाणपत्र वह नाम रखता है, और जब नहीं रखता तो ऐसे विफल होता है जो रूटिंग समस्या जैसा दिखता है। प्रोफ़ाइल को भरने योग्य फ़ील्ड की सूची नहीं, दावों के क्रम के रूप में पढ़ें।
स्थानीय पहचानकर्ता फ़ोन का अपना दावा है, और यह ऐसा नाम होना चाहिए जिसे RouterOS की पहचान प्रविष्टि उस क्लाइंट प्रमाणपत्र के लिए स्वीकार करे जो फ़ोन प्रस्तुत करता है। यदि दोनों मेल नहीं खाते, तो प्रमाणपत्र के स्वयं सत्यापित होने के बाद गेटवे कनेक्शन अस्वीकार कर देता है, और लॉग नामकरण की नहीं, प्राधिकरण की समस्या जैसा दिखता है।
पहचानकर्ताओं को गेटवे जो प्रस्तुत करता है उसके विरुद्ध जाँचें
प्रमाणपत्र प्रमाणीकरण के लिए कॉन्फ़िगर की गई RouterOS पीयर प्रविष्टि अपना प्रमाणपत्र प्रस्तुत करती है, और उसकी पहचान उसी प्रमाणपत्र से ली जाती है जब तक आपने अन्यथा कॉन्फ़िगर न किया हो। यदि फ़ोन का दूरस्थ पहचानकर्ता गेटवे का DNS नाम बताता है, तो गेटवे के प्रमाणपत्र में वह नाम ऐसी जगह चाहिए जिसे फ़ोन स्वीकार करे, आमतौर पर विषय के वैकल्पिक नाम में। किसी दूसरे सामान्य नाम के लिए जारी प्रमाणपत्र कुंजी और श्रृंखला सही होने पर भी सत्यापित नहीं होगा।
प्रबंधित Apple प्रोफ़ाइल में पहचानकर्ता फ़ील्ड के अतिरिक्त मूल्यांकित होने वाला प्रमाणपत्र-नाम प्रतिबंध भी हो सकता है। सेटिंग्स स्क्रीन जो दिखाती है उससे सत्यापन नाम का अनुमान लगाने के बजाय पेलोड की जाँच करें, क्योंकि दोनों एक ही सेटिंग नहीं हैं।
जाँचें कि क्लाइंट प्रमाणपत्र एक कुंजी है, केवल विश्वास एंकर नहीं
CA प्रमाणपत्र आयात करने से फ़ोन को गेटवे को सत्यापित करने का कुछ मिलता है। इससे फ़ोन को क्लाइंट पहचान नहीं मिलती, और प्रमाणपत्र प्रमाणीकरण के लिए क्लाइंट लीफ प्रमाणपत्र और उसकी निजी कुंजी दोनों को स्वीकृत नामांकन मार्ग से साथ में पहुँचाना पड़ता है। निजी कुंजी के बिना बनाया गया PKCS#12 ऐसा प्रोफ़ाइल बनाता है जो साफ़ स्थापित होता है और कुछ भी प्रमाणित नहीं करता।
क्लाइंट लीफ को RouterOS पक्ष द्वारा अपेक्षित पहचान भी चाहिए, यानी विषय या विषय का वैकल्पिक नाम संबंधित पहचान कॉन्फ़िगरेशन से मेल खाना चाहिए। एक ही CA से क्लाइंट और सर्वर प्रमाणपत्र जारी करना श्रृंखला को सुविधाजनक बनाता है और दोनों लीफ को परस्पर विनिमेय नहीं बनाता।
जाँचें कि RouterOS नीति उस नाम को स्वीकार करती है
गेटवे पर पीयर प्रविष्टि विनिमय मोड और प्रमाणीकरण विधि तय करती है, और पहचान प्रविष्टि स्वीकृत दूरस्थ पहचान को प्रमाणपत्र और उसके बाद की नीति से जोड़ती है। RouterOS v7 में यह जोड़ी IPsec पीयर और पहचान प्रविष्टियों के माध्यम से व्यक्त होती है, उदाहरण के लिए auth-method=digital-signature वाली IKEv2 पीयर। पुराने संस्करण के लिए लिखी गाइड नहीं, अपने स्थापित संस्करण की वास्तविक मेनू सामग्री जाँचें।
यहीं असंगति सुधारना सबसे सस्ता है, क्योंकि गेटवे आपको वह पहचान भी बता सकता है जो उसे मिली और वह भी जो उसे चाहिए थी। त्रुटि शांत करने के लिए स्वीकृत पहचान को चौड़ा करना उस बंधन को हटा देता है जिसने परिनियोजन को अर्थ दिया था।
कुछ भी संपादित करने से पहले जाँचें कि कौन-सा चरण विफल हुआ
दोनों सिरों पर प्रयास पढ़ें और प्रस्ताव बदलने से पहले उसका वर्गीकरण करें। प्रस्ताव की असंगति, गुम हस्ताक्षर कुंजी, अविश्वसनीय जारीकर्ता, गलत पीयर पहचानकर्ता और अस्वीकृत क्लाइंट प्राधिकरण — सभी फ़ोन से मृत सुरंग जैसे दिखते हैं, और हर एक का अलग स्वामी है। पाँचों सेटिंग एक साथ बदलने से यह निश्चित है कि परिणाम से आप कुछ नहीं सीखेंगे।
प्रस्तुत पहचान, अपेक्षित पहचान, प्रमाणपत्र का जारीकर्ता और क्रम संख्या तथा संबंधित नीति का नाम दर्ज करें, और निजी कुंजियाँ तथा प्रोफ़ाइल रहस्य उस रिकॉर्ड से बाहर रखें। प्रमाणीकरण सफल होने पर, किसी निजी सेवा और उसके उत्तर का परीक्षण करें, क्योंकि IKE विनिमय समाप्त होने के बाद भी पता आवंटन, सिलेक्टर, DNS और पहुँच नीति को काम करना है।