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 ને એ નોંધ સાથે સરખાવો: જો અલગ હોય તો તમે પાસવર્ડ નહીં, ફીલ્ડ તરફ જોઈ રહ્યા છો.