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 ची त्या नोंदीशी तुलना करा: वेगळी असेल तर तुम्ही पासवर्ड नाही, फील्ड पाहत आहात।