iPhone VPN मा Remote ID: यो फिल्डले वास्तवमा के अर्थ राख्छ
Remote ID त्यो पहिचान हो जुन सर्भरले तपाईंको iPhone समक्ष प्रमाणित गर्नुपर्छ; Local ID क्लाइन्टले दाबी गर्ने पहिचान हो। कुन स्ट्रिङ कुन फिल्डमा जान्छ, यहाँ छ।
तपाईं सेटिङमा IKEv2 कन्फिगरेसन थप्दै हुनुहुन्छ, र दुई फिल्डले यस्तो पाठ मागिरहेका छन् जो कसैले तपाईंलाई दिएको छैन: Remote ID र Local ID। यीमध्ये कुनै पनि तपाईंको प्रयोगकर्ता नाम होइन, र कुनै पनि Server फिल्डको दोस्रो प्रतिलिपि होइन। Remote ID त्यो पहिचान हो जुन गेटवेले तपाईंको iPhone समक्ष प्रमाणित गर्नुपर्छ; Local ID त्यो पहिचान हो जुन तपाईंको iPhone ले गेटवेसमक्ष दाबी गर्छ। यीमध्ये एउटै गल्ती भयो भने सर्भरले जवाफ दिइसकेपछि टनेल मर्छ, त्यसैले यो असफलता पासवर्डको समस्या जस्तो देखिन्छ, तर होइन।
iOS मा फिल्डहरू कहाँ छन्
सेटिङ > सामान्य > VPN र यन्त्र व्यवस्थापन > VPN खोल्नुहोस् र IKEv2 कन्फिगरेसन थप्नुहोस्। प्रमाणीकरणमुनि तपाईं प्रयोगकर्ता नाम वा प्रमाणपत्र छान्नुहुन्छ, र त्यसपछि मात्र Remote ID र Local ID खुला पाठ बाकसका रूपमा देखिन्छन्। यी पहिचानकर्ता हुन्, ठेगाना होइनन्: iOS ले तिनीहरूलाई IKE_AUTH आदानप्रदानमा बोक्छ, जहाँ IKEv2 ले सुरु गर्नेको पहिचानलाई IDi र जवाफ दिनेको पहिचानलाई IDr भन्छ।
सेभ गरेपछि iOS ले कन्फिगरेसनलाई एउटै पङ्क्तिमा पट्याउँछ र मानहरू देखाउन छोड्छ। फिल्डहरू खाली छन् भन्ने निष्कर्षमा पुग्नुअघि जानकारी बटन थिच्नुहोस् वा प्रोफाइल फेरि खोल्नुहोस्। MDM बाट पठाइएको कन्फिगरेसनले तिनीहरूलाई पूरै खैरो बनाउन सक्छ, र यसले समस्या कसले सुधार्न सक्छ भन्ने बदल्छ।
Remote ID गेटवेको नाम हो
सर्भरले प्रमाणित गर्नुपर्ने भनी तपाईंको iPhone ले अपेक्षा गर्ने मान यही हो। प्रमाणपत्रद्वारा प्रमाणीकरणमा यसलाई सर्भरको प्रमाणपत्रमा भएको नामसँग तुलना गरिन्छ, सामान्यतया subject वा subjectAltName प्रविष्टिसँग। प्रमाणपत्र vpn.example.com का लागि जारी भएको भए त्यही होस्टनाम Remote ID हो, तपाईं यन्त्रसम्म खाली IP ठेगानाबाट पुग्नुभए पनि।
त्यही बेमेल नै चिरपरिचित असफलता हो: प्याकेट आउँछन्, सर्भर जवाफ दिन्छ, र पनि जडान भाँसिन्छ किनकि प्रमाणपत्रको पहिचान प्रोफाइलले मागेकोसँग मेल खाँदैन। Server फिल्डलाई कच्चा IP तिर फर्काउँदा सहयोग हुँदैन, र धेरै गेटवेमा सर्भरले मिलाउन नसक्ने पहिचानलाई जवाफ दिनै छोड्छ।
गेटवेसँग मिल्ने सेटिङ हुन्छ। strongSwan सर्भरले आफ्नो पहिचान leftid ले पठाउँछ र क्लाइन्टको पहिचान rightid ले सीमित गर्न सक्छ; दुवै पक्ष स्ट्रिङमा सहमत भएनन् भने IKE_AUTH दुवै दिशामा असफल हुन्छ। ब्राउजर बारबाट URL प्रतिलिपि गर्नुको सट्टा प्रमाणपत्र कुन पहिचानका लागि जारी भयो भनी अपरेटरलाई सोध्नुहोस्।
Apple ले आफ्नो IKEv2 सेटिङ सन्दर्भमा पेलोड कुञ्जीहरूलाई RemoteIdentifier र LocalIdentifier भनी अभिलेख गर्छ। दुवै साधारण स्ट्रिङ हुन्, त्यसैले अक्षरको आकार र अन्त्यको खाली ठाउँ महत्त्वपूर्ण हुन सक्छ।
Local ID तपाईंको iPhone ले दाबी गर्ने कुरा हो
प्रयोगकर्ता नाम प्रमाणीकरणमा EAP ले नाम र पासवर्ड जाँच्छ, र Local ID एउटा छुट्टै IKE पहिचान हो जुन केही गेटवेले पनि लागू गर्छन्। गेटवेले Local ID प्रयोगकर्ता नामसँग बराबर हुनुपर्ने, इमेल ठेगाना हुनुपर्ने, वा त्यसको जडान नीतिको प्रविष्टिसँग मिल्नुपर्ने माग गर्न सक्छ; अरूले यसलाई बेवास्ता गर्छन्। यसलाई खाली छाड्नु अपरेटरले त्यसो भनेको अवस्थामा मात्र सुरक्षित हुन्छ।
प्रमाणपत्रद्वारा प्रमाणीकरणमा Local ID त्यो पहिचानसँग मिल्नुपर्छ जुन गेटवेले त्यो क्लाइन्ट प्रमाणपत्रका लागि स्वीकार गर्छ, प्रायः प्रमाणपत्रको सामान्य नाम वा यन्त्र अभिलेखसँग जोडिएको मान। सहकर्मीको प्रोफाइल प्रतिलिपि गर्दा उनको पहिचान पनि प्रतिलिपि हुन्छ। सबैभन्दा राम्रो अवस्थामा गेटवेले गलत यन्त्र अभिलेख गर्छ; सबैभन्दा नराम्रोमा प्रति-यन्त्र नीतिले तपाईंलाई अस्वीकार गर्छ।
खाली भन्नाले कुनै पहिचान छैन भन्ने ठान्नु खतरा हो। अधुरो देखिन्छ भनेर खाली फिल्डमा आफ्नो इमेल ठेगाना नभर्नुहोस्। अभीष्ट मान पुष्टि गर्नुहोस् र दिइएको जस्तै ठ्याक्कै लेख्नुहोस्।
सेभ गर्नुअघि पाँच मिनेटको जाँच
यी क्रमैसँग पूरा गर्नुहोस्; पहिले असफल हुने चरण नै सुधार्नुपर्ने हो।
- अपरेटरबाट तीन स्ट्रिङ लिनुहोस्: सर्भरको प्रमाणपत्रमा भएको नाम, अपेक्षित Local ID र प्रमाणीकरण विधि।
- प्रमाणीकरण विधि मिलाउनुहोस्। Remote ID र Local ID ले प्रयोगकर्ता नाम र पासवर्डको विकल्प दिँदैनन्, र प्रमाणपत्र प्रोफाइलले पासवर्ड स्वीकार गर्दैन।
- मानहरू ठ्याक्कै टाइप गर्नुहोस्, अक्षरको आकारसहित, अन्त्यमा खाली ठाउँ नराखी।
- प्रमाणपत्र प्रमाणीकरण खुला राख्नुहोस्। चेतावनी शान्त पार्न असम्बन्धित रुट प्रमाणपत्र स्थापना गर्दा नामको बेमेल लुक्छ, सुधार्दैन।
- अफिसको Wi-Fi मा होइन, मोबाइल डेटामा परीक्षण गर्नुहोस्, ताकि क्याप्टिभ पोर्टल वा विभाजित DNS पहिचानको समस्या जस्तो नदेखियोस्।
| Field | What belongs there | What a wrong value looks like |
|---|---|---|
| Remote ID | The DNS name in the gateway certificate | Server answers, then the tunnel drops with a certificate or identity error |
| Local ID | The identity the gateway policy expects for you | IKE_AUTH or user authentication fails after the server responds |
| Server | A reachable hostname or IP | Timeout with no identity exchange at all |
तालिका माथिबाट पढ्नुहोस्। Server पङ्क्तिमा टाइमआउट भयो भने पहिचानका फिल्ड कहिल्यै परीक्षण भएका छैनन्, त्यसैले त्यहीँ रोक्नुहोस्। सर्भरले जवाफ दिएपछि मात्र देखिने त्रुटि लगभग सधैं Remote ID वा Local ID को बेमेल हो।
गलत फिल्डतिर देखाउने त्रुटिहरू
"User authentication failed" जस्तो सन्देश प्रमाणहरू वा EAP को बारेमा हो, Remote ID को होइन। प्रमाणपत्रको चेतावनी प्रमाणपत्रमा भएको नामको बारेमा हो, र त्यहीँ Remote ID र Server फिल्ड भेटिन्छन्। "The VPN server did not respond" को सामान्य अर्थ UDP 500 र 4500 कहिल्यै पूरा भएनन्, वा NAT पार गर्ने क्रम असफल भयो, र कुनै पहिचान तुलना भएन।
गेटवेको तर्फ पहिचानका असफलता फरक देखिन्छन्: IKE_AUTH का क्रममा पियर अस्वीकृत हुन्छ, वा लगले क्लाइन्टले पठाएको ID को नाम लिन्छ र कुनै जडानसँग मिल्दैन भन्छ। त्यो लग लाइन विवाद टुङ्गोमा पुर्याउने सबैभन्दा छिटो उपाय हो, किनकि यसले फोनले पठाएको ठ्याक्कै स्ट्रिङ देखाउँछ।
पासवर्ड रिसेट गर्दा अपेक्षित सर्भर पहिचान सुध्रिँदैन, र Remote ID बदल्दा गलत पासवर्ड सुध्रिँदैन। पहिले चरण अलग गर्नुहोस्, त्यसपछि त्यो चरणको फिल्ड सम्पादन गर्नुहोस्।
जब प्रोफाइल व्यवस्थापित हुन्छ
फिल्डहरू खैरो भए कन्फिगरेसन MDM बाट आएको हो र फोन यसलाई सुधार्ने ठाउँ होइन। VPN पेलोडले पहिचानकर्ता बोक्छ, त्यसैले सही परिवर्तन व्यवस्थापन सर्भरको प्रोफाइलमा हुन्छ, त्यसपछि त्यसलाई यन्त्रमा पुनः स्थापना गर्नुपर्छ।
सेटिङ > सामान्य > VPN र यन्त्र व्यवस्थापनमा प्रोफाइल व्यवस्थापित छ कि छैन र कसले हस्ताक्षर गर्यो जाँच्नुहोस्। तपाईंले यसलाई हटाउन सक्नुहुन्न भने पहिचानकर्ता स्थानीय रूपमा सम्पादन गर्न सक्नुहुन्न, र दोस्रो स्थानीय प्रोफाइल बनाउँदा केवल विरोधाभासी कन्फिगरेसन बन्छ।
सेटिङ बन्द गर्नुअघि तपाईंले हालेका तीन स्ट्रिङ र ती कहाँबाट आए लेख्नुहोस्। अर्को पटक टनेल असफल हुँदा गेटवे लगमा प्राप्त ID लाई त्यो टिप्पणीसँग तुलना गर्नुहोस्: फरक भए तपाईं पासवर्ड होइन, फिल्ड हेर्दै हुनुहुन्छ।