iPhone પર IKEv2 પ્રમાણપત્ર સેટઅપ: મેન્યુઅલ અને મેનેજ્ડ નોંધણી

ગેટવેના પ્રમાણપત્ર સાધન ડિફોલ્ટમાં RSA વાપરે છે તેથી તેને પસંદ કરવું એ મહત્ત્વના પ્રશ્ન પહેલાં લેવાયેલો નિર્ણય છે: આ iPhone કેવી રીતે નોંધાશે? વપરાશકર્તા જાતે લખેલું કનેક્શન અને મેનેજમેન્ટ દ્વારા પહોંચાડાયેલી રૂપરેખા જુદા જુદા સેટિંગ્સ દર્શાવે છે, અને કેટલાક પ્રમાણપત્ર વિકલ્પો આ બેમાંથી માત્ર એક જ માર્ગ પર હોય છે. ક્રમ સાચો રાખો તો પ્રમાણપત્રની યોજના ટૂંકી થાય છે; ખોટું કરો તો તમે એવું પ્રમાણપત્ર આપો છો જે ફોન વાપરશે નહીં. નીચેનાં પગલાંને ક્રમ તરીકે ગણો, કારણ કે દરેક પગલું આગલા માટે ઉપલબ્ધ વિકલ્પો સાંકડા કરે છે.

પહેલું પગલું: નોંધણીનો માર્ગ પસંદ કરો

મેન્યુઅલ સેટઅપ એટલે વપરાશકર્તા સર્વરનું સરનામું દાખલ કરે, પ્રમાણીકરણ પદ્ધતિ પસંદ કરે અને ઇન્ટરફેસ જે પણ પ્રમાણપત્ર આપવા દે તે આપે. મેનેજ્ડ નોંધણી એટલે રૂપરેખા સરનામું, ઓળખકર્તાઓ અને પ્રમાણપત્ર પેલોડનો સંદર્ભ વહન કરે. મેનેજ્ડ માર્ગ એવા સંયોજનો વ્યક્ત કરી શકે છે જે મેન્યુઅલ સ્ક્રીન કરી શકતી નથી, તેથી પ્રમાણપત્રનો નિર્ણય આ પસંદગી પછી આવવો જોઈએ, પહેલાં નહીં.

બંને માર્ગો ફોનનું પ્રમાણીકરણ કરી શકે છે. તમે શું ગોઠવી શકો છો અને ઓળખ કોની માલિકીની છે તેમાં તેઓ અલગ પડે છે, તેથી મેનેજ્ડ રૂપરેખાને મેન્યુઅલ પ્રમાણપત્ર દાખલ સાથે ભેળવવાને બદલે જાણી જોઈને એક પસંદ કરો.

બીજું પગલું: તમે પસંદ કરેલા માર્ગ માટે એલ્ગોરિધમ પસંદ કરો

મેન્યુઅલ રીતે ગોઠવેલા iPhone માટે, strongSwanની iOS આંતરકાર્યક્ષમતા નોંધો RSA સર્વર પ્રમાણપત્ર સૂચવે છે, કારણ કે મેન્યુઅલ ક્લાયન્ટ ECDSA સર્વર પ્રમાણપત્ર સ્વીકારે નહીં હોય; એ જ નોંધો macOSને અલગથી લે છે. આને સમર્થિત ક્લાયન્ટ સમૂહ માટે માર્ગદર્શન તરીકે વાંચો, Apple ઉપકરણો વિશે કાયમી કાયદા તરીકે નહીં. મેનેજ્ડ રૂપરેખા પાસે વધુ જગ્યા છે: જ્યારે પેલોડ અને ગેટવે બંને ટેકો આપે ત્યારે તે પ્રમાણપત્રના પ્રકારને સ્પષ્ટપણે પસંદ કરી શકે છે, જેમાં ECDSA ક્લાયન્ટ ઓળખનો સમાવેશ થાય છે.

કંઈપણ તૈનાત કરતા પહેલા તમે ખરેખર જે iOS આવૃત્તિઓને ટેકો આપો છો તેની ચકાસણી કરો. સૌથી નવી આવૃત્તિ પરનો લેબ ફોન જૂનાં ઉપકરણો ધરાવતા ફ્લીટનું વર્ણન કરતો નથી, અને લેબમાં કામ કરતું એલ્ગોરિધમ ક્ષેત્રના સૌથી જૂના ફોન પર હજી પણ નિષ્ફળ જઈ શકે છે. આવૃત્તિની શ્રેણી યાદશક્તિમાંથી નહીં, ઉપકરણ મેનેજમેન્ટમાંથી લો. જો ફ્લીટ ઘણી આવૃત્તિઓમાં ફેલાયેલી હોય, તો પહેલા સૌથી જૂની ચકાસો, કારણ કે મેન્યુઅલ ઇન્ટરફેસ ત્યાં જ સૌથી મર્યાદિત છે.

ત્રીજું પગલું: રૂપરેખાના ક્ષેત્રોને અલગ વસ્તુઓ તરીકે વાંચો

સમાન નામની ઘણી કી અલગ અલગ ઑબ્જેક્ટનું વર્ણન કરે છે. દૂરનું સરનામું એ હોસ્ટ છે જેને ફોન ડાયલ કરે છે. દૂરનું ઓળખકર્તા એ IKE ઓળખ છે જે ગેટવે રજૂ કરશે તેવી તે અપેક્ષા રાખે છે. પેલોડનો પ્રમાણપત્ર સંદર્ભ ક્લાયન્ટ પ્રમાણપત્ર તરફ નિર્દેશ કરે છે, અને પ્રમાણપત્ર પ્રકારનું ક્ષેત્ર IKEv2 મશીન પ્રમાણીકરણ માટે વપરાતો પ્રકાર પસંદ કરે છે. આમાંથી કોઈ પણ CAનું સહી એલ્ગોરિધમ નથી, છતાં શબ્દો એકબીજામાં ભળે છે.

Appleનો IKEv2 પેલોડ સંદર્ભ સ્પષ્ટ ECDSA પ્રકારો સાથે RSAને ડિફોલ્ટ પ્રમાણપત્ર પ્રકાર તરીકે સૂચિબદ્ધ કરે છે, અને તે ઇશ્યુઅર-નામ કીને ચોક્કસ પ્રમાણીકરણ સેટિંગ્સ સાથે જોડે છે. કાર્યરત તૈનાતીમાંથી એક કી નકલ કરવાને બદલે તમે પસંદ કરેલી પદ્ધતિના સંદર્ભમાં તે સંબંધો વાંચો.

ચોથું પગલું: ગેટવેની ઓળખ તેના પ્રમાણપત્ર સાથે મેળવો

સ્પષ્ટ ગેટવે નામ વાપરો, જેમ કે vpn.example.com અને સર્વર પ્રમાણપત્રમાં મેળ ખાતું વૈકલ્પિક વિષય નામ મૂકો. strongSwanનું Apple માર્ગદર્શન સર્વર પ્રમાણીકરણ માટે વિસ્તૃત કી વપરાશની પણ અપેક્ષા રાખે છે. RSA કે ECDSA પસંદ કરવાથી તેમાં કંઈ બદલાતું નથી: એલ્ગોરિધમ નામની અસંગતિ, ખૂટતું EKU કે અધૂરી શૃંખલા સુધારી શકતું નથી.

વિશ્વાસ એન્કરનું વિતરણ ઓળખ દાવા કરવાથી અલગ કાર્ય છે. ફોનને એવી પ્રમાણપત્ર શૃંખલા જોઈએ જે તે ચકાસી શકે, અને પ્રમાણપત્રમાં તમે ખરેખર મૂકેલા નામની અપેક્ષા રાખવા માટે તેને ગોઠવવો પડે.

બીજું પ્લેટફોર્મ સફળતાપૂર્વક જોડાય તે તે પ્લેટફોર્મના ચકાસણી નિયમોનો પુરાવો છે, ફોનના નિયમો ઢીલા કરવાની પરવાનગી નથી. અલગ પડવાનું દસ્તાવેજી કારણ ન હોય તો ક્લાયન્ટ વચ્ચે ચકાસણીઓ સમાન રાખો.

પાંચમું પગલું: ક્લાયન્ટ ઓળખને CA વિશ્વાસથી અલગ કરો

ક્લાયન્ટ પ્રમાણપત્ર અને તેની ખાનગી કી એ ફોન જે CA પ્રમાણપત્ર પર વિશ્વાસ કરે છે તેની સમાન વસ્તુ નથી. PKCS#12 ઓળખની અંદર CA પ્રમાણપત્રને બંડલ કરવાથી તે દરેક સમર્થિત ઉપકરણ પર આપોઆપ વિશ્વાસ એન્કર તરીકે સ્થાપિત થતું નથી, તેથી વિશ્વાસ વિતરણને પોતાની ચકાસણી સાથે અલગ પગલું ગણો.

જો ડિઝાઇન તેના બદલે પાસવર્ડ-આધારિત EAP વાપરે છે, તો ફોનને ઇચ્છિત ખાતા પ્રમાણીકરણ ઉપરાંત સર્વર ચકાસણીની જરૂર છે. આ માર્ગ આખા ફ્લીટને એક શેર કરેલી ખાનગી ક્લાયન્ટ કી મોકલવાનું વાજબી ઠેરવતું નથી, જે વધુ ખરાબ નિષ્ફળતા સ્થિતિવાળી અલગ ડિઝાઇન છે.

નવીકરણ અને રદ કરવાને ધ્યાનમાં રાખીને યોજના પૂરી કરો: ક્લાયન્ટ પ્રમાણપત્ર કોણ ફરી આપે છે, રૂપરેખા કેવી રીતે અપડેટ થાય છે અને ખોવાયેલો ફોન કેવી રીતે કાપવામાં આવે છે. રૂપરેખાની આવૃત્તિ અને તમે જે ઉપકરણ આવૃત્તિઓ સામે ચકાસણી કરી તે નોંધો, કારણ કે તે નોંધ જ આગલા પ્રમાણપત્ર ફેરફારને નિયમિત કામ બનાવે છે.