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 र पहुँच नीति काम गर्नुपर्छ।