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

जाल यह मानना है कि खाली का अर्थ कोई पहचान नहीं है। केवल अधूरा दिखने के कारण खाली फ़ील्ड में अपना ईमेल पता न भरें। इच्छित मान की पुष्टि करें और उसे ठीक वैसे ही दर्ज करें जैसे दिया गया था।

सहेजने से पहले पाँच मिनट की जाँच

इन्हें क्रम से पूरा करें; जो पहला चरण विफल हो वही ठीक करना है।

  1. ऑपरेटर से तीन स्ट्रिंग लें: सर्वर प्रमाणपत्र का नाम, अपेक्षित Local ID और प्रमाणीकरण विधि।
  2. प्रमाणीकरण विधि मिलाएँ। Remote ID और Local ID उपयोगकर्ता नाम और पासवर्ड का विकल्प नहीं हैं, और प्रमाणपत्र प्रोफ़ाइल पासवर्ड स्वीकार नहीं करेगी।
  3. मान ठीक-ठीक लिखें, अक्षर के आकार सहित, अंत में स्पेस के बिना।
  4. प्रमाणपत्र सत्यापन चालू रखें। चेतावनी शांत करने के लिए असंबंधित रूट प्रमाणपत्र स्थापित करना नाम की बेमेल को छिपाता है, ठीक नहीं करता।
  5. कार्यालय के Wi-Fi पर नहीं, मोबाइल डेटा पर परीक्षण करें, ताकि कैप्टिव पोर्टल या विभाजित DNS पहचान की समस्या जैसा न लगे।
FieldWhat belongs thereWhat a wrong value looks like
Remote IDThe DNS name in the gateway certificateServer answers, then the tunnel drops with a certificate or identity error
Local IDThe identity the gateway policy expects for youIKE_AUTH or user authentication fails after the server responds
ServerA reachable hostname or IPTimeout 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 की उस नोट से तुलना करें: अगर अलग है तो आप पासवर्ड नहीं, फ़ील्ड देख रहे हैं।

संबंधित लेख