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 आणि प्रवेश धोरण कार्यान्वित राहिले पाहिजे.