Mac IKEv2 ECDSA: ક્લાયન્ટને કયો પ્રમાણપત્ર પ્રકાર અનુલક્ષે છે?
Mac પર, IKEv2 સેટિંગ્સમાં ECDSA256 સ્થાનિક ઓળખ પ્રમાણપત્રનું વર્ણન કરે છે, ગેટવે કે ઇશ્યુઅરની સહી નહીં. પસંદ કરતા પહેલા દરેક ભૂમિકા વાંચો.
macOS પર, IKEv2 ક્લાયન્ટ સેટિંગમાં ECDSA ની પસંદગી એક સાંકડા પ્રશ્નનો જવાબ આપે છે: કયું પ્રમાણપત્ર Mac ની ઓળખ સાબિત કરે છે. તે ગેટવે પ્રમાણપત્ર, ક્લાયન્ટ પ્રમાણપત્ર જારી કરનાર સહી, કે ટનલ માટેની એન્ક્રિપ્શન દરખાસ્તનું વર્ણન કરતું નથી. આ ચાર ભૂમિકાઓને એક જ સુસંગતતા પ્રશ્ન તરીકે ગણવો એ જ રીતે છે જેમાં સાચી સ્થાનિક ગોઠવણને સર્વર બાજુની અસંગતિ માટે દોષિત ઠેરવવામાં આવે છે. નિર્ણય નાનો છે, પણ તે લેવા માટે વપરાતા પુરાવા ચોક્કસ હોવા જોઈએ.
આ ફીલ્ડ એક પ્રમાણપત્રનું નામ આપે છે: સ્થાનિક ઓળખ
Apple નું Network Extension API ક્લાયન્ટ ક્રેડેન્શિયલ માટે પ્રમાણપત્ર પ્રકાર આપે છે, જેમાં NEVPNIKEv2CertificateType.ECDSA256 પણ છે, જે ECDSA p-256 પ્રમાણપત્ર પ્રકાર તરીકે દસ્તાવેજીકૃત છે. આ પ્રોપર્ટી identityReference કે identityData દ્વારા પૂરા પાડવામાં આવેલા પ્રમાણપત્રને લાગુ પડે છે.
એટલે કે નિર્ણય Mac જે પ્રમાણપત્ર રજૂ કરે છે તેના તથા તેની સાથે જતી ખાનગી કીના વિશે છે. એ લીફ પ્રમાણપત્રની જાહેર કી સાથે મળતો પ્રકાર પસંદ કરો અને સમર્થિત મિકેનિઝમ દ્વારા ઓળખ પૂરી પાડો. જો Mac પાસે ઓળખ માટે વાપરી શકાય એવી ખાનગી કી ન હોય, તો પ્રકારની પસંદગી જોડાણ બચાવી શકતી નથી.
મેનેજ કરેલા પ્રોફાઇલ સમાન નિર્ણય IKEv2 પેલોડના CertificateType દ્વારા લે છે, સાથે PayloadCertificateUUID જેવા પ્રમાણપત્ર સંદર્ભ સાથે. એ ફીલ્ડમાં લક્ષ્ય OS આવૃત્તિ માટે પૂર્વશરતો અને સ્કીમા છે; પ્રોફાઇલમાં નકલ કરેલું નક્કોર પ્રકાર-મૂલ્ય સ્થાપિત થઈ શકતું નથી, અને સેટિંગ્સ વિન્ડો દરેક API વિકલ્પ બતાવે ન પણ શકે. તૈનાતી પહેલા એ આવૃત્તિ માટે પેલોડની પૂર્વશરતો તપાસો.
પ્રમાણપત્રના લેબલ પ્રમાણે નહીં, ભૂમિકા પ્રમાણે નિર્ણય કરો
તમે બદલવા જઈ રહ્યા છો એ ફીલ્ડ વાંચો અને પૂછો કે તે કયા પ્રમાણપત્ર તરફ ઇશારો કરે છે. પ્રમાણપત્ર દર્શકમાંના લેબલ વિષય, ઇશ્યુઅર અને સહી અલ્ગોરિધમને ભેગા કરે છે, અને તેમાંથી ફક્ત એક જ ક્લાયન્ટ ઓળખની પસંદગી સાથે સંબંધિત છે.
| What you inspected | What it controls | Does it choose the Mac certificate type? |
|---|---|---|
| Client leaf public key | The identity the Mac presents | Yes, this is the field's subject |
| Issuer signature algorithm | How the client certificate was signed | No |
| Gateway certificate | What the Mac validates as the peer | No, check it separately |
| IKE and ESP proposals | Algorithms for the tunnel | No, separate proposal settings |
જો પ્રમાણપત્ર દર્શક CA તરફથી ECDSA સહી બતાવે, તો તે ઇશ્યુઅરની સાઇનિંગ કીનું વર્ણન કરે છે. ક્લાયન્ટની પોતાની કી હજી પણ RSA હોઈ શકે છે, અને પ્રકાર-ફીલ્ડે સહીની લાઇન નહીં, ક્લાયન્ટની કીને અનુસરવું જોઈએ. આ એક જ ગૂંચવણ "ECDSA ગોઠવેલું છે પણ જોડાણ નિષ્ફળ જાય છે" એવા ઘણા અહેવાલો સમજાવે છે. કંઈપણ બદલતા પહેલા લીફમાંની કી-પ્રકારને પ્રોફાઇલમાં પસંદ કરેલા પ્રકાર સાથે સરખાવો.
લીફ ઓળખાઈ જાય પછી નિર્ણય સરળ બને છે: p-256 ક્લાયન્ટ કી માટે ECDSA256, અલગ કી માટે બીજો સમર્થિત પ્રકાર. જો ક્લાયન્ટ પ્રમાણપત્ર અને તેની કી મળતાં ન હોય, તો VPN પ્રોફાઇલ બદલતા પહેલા એ જોડી સુધારો.
ગેટવે પ્રમાણપત્ર અલગ નિર્ણય છે
ગેટવે પોતાનું પ્રમાણપત્ર રજૂ કરે છે અને Mac તેને ટ્રસ્ટ એન્કર તથા અપેક્ષિત નામ સામે ચકાસે છે. એ પ્રમાણપત્ર ECDSA, RSA કે બીજો કી-પ્રકાર વાપરે છે કે નહીં એ સર્વરની લાક્ષણિકતા છે, ક્લાયન્ટ ઓળખ સેટિંગની નહીં.
ECDSA ક્લાયન્ટ પ્રમાણપત્ર માટેનું સ્થાનિક સમર્થન એ સાબિત કરતું નથી કે દરેક ગેટવે પ્રમાણપત્ર, વક્ર કે સર્વર પ્રમાણીકરણ ગોઠવણી આંતરસંચાલન કરશે. સર્વરની ઓળખ, તેની શૃંખલા અને IKE પ્રમાણીકરણ પદ્ધતિને અલગ ઇનપુટ તરીકે તપાસો, અને જે પ્રોફાઇલ ખરેખર તૈનાત થશે તેની સાથે પરીક્ષણ કરો.
જો ગેટવે પ્રમાણપત્ર સમસ્યા હોય, તો લક્ષણ સામાન્ય રીતે ઓળખ પસંદગીમાં નહીં, પીઅર ચકાસણી દરમિયાન દેખાય છે. ક્લાયન્ટ પ્રકાર બદલતા પહેલા નિષ્ફળતાનો તબક્કો વાંચો, કારણ કે ટ્રસ્ટ નિષ્ફળતા અને ક્લાયન્ટ-કી અસંગતિનો ઉકેલ એક નથી.
ઇશ્યુઅરની સહી અને કી-સંમતિ જૂથ ક્લાયન્ટનો પ્રકાર નથી
X.509 વિષયની જાહેર કી અને ઇશ્યુઅરની સહીને અલગ ફીલ્ડમાં રાખે છે. વિષય જાહેર કી માહિતી પ્રમાણપત્રમાંની કીનું વર્ણન કરે છે; સહી અલ્ગોરિધમ CA ની કી અને સહી ક્રિયાનું વર્ણન કરે છે. ફક્ત પહેલું જ પ્રમાણપત્ર-પ્રકાર સેટિંગ સાથે મળે છે.
IKE અને Child SA દરખાસ્તો બીજો અક્ષ છે. ECDSA પ્રમાણપત્ર પ્રકાર એ ESP એન્ક્રિપ્શન પસંદગી નથી, અને કી-સંમતિ જૂથ બદલવાથી પ્રમાણપત્ર પ્રકાર પસંદ થતો નથી. પ્રોફાઇલમાં માન્ય દરખાસ્તો અને ખોટો ઓળખ-પ્રકાર હોઈ શકે, અથવા સાચો ઓળખ-પ્રકાર અને પીઅર જે દરખાસ્ત નકારે છે તે હોઈ શકે.
ફેરફાર રેકોર્ડમાં ત્રણ લીટીઓ અલગ રાખો: ઓળખ પ્રમાણપત્ર અને કી, ગેટવે ટ્રસ્ટ ઇનપુટ, અને દરખાસ્તોના અલ્ગોરિધમ. તેમને એક જ "ક્રિપ્ટો સેટિંગ્સ" નોંધમાં ભેગા કરવાથી આગળની નિષ્ફળતા કોને આભારી છે તે નક્કી કરવું અશક્ય બને છે.
તમે ગોઠવેલા ફીલ્ડ સાથે નિર્ણય ચકાસો
પ્રોફાઇલ ખરેખર જે ઓળખનો સંદર્ભ આપે છે તે તપાસો, પછી ખાતરી કરો કે એ સંદર્ભના પ્રમાણપત્રમાં અપેક્ષિત જાહેર કી અને વાપરી શકાય એવી ખાનગી કી છે. UI માં દેખાતો પ્રકાર, સંદર્ભિત પ્રમાણપત્ર અને ઉપકરણ પરની કી—ત્રણેય મળવા જોઈએ.
પછી ગેટવે ઇનપુટની ખાતરી કરો: અપેક્ષિત સર્વર નામ, ટ્રસ્ટ એન્કર અને IKE પ્રમાણીકરણ પદ્ધતિ. અંતે જોડાઓ અને જુઓ હેન્ડશેક ક્યાં અટકે છે. ઓળખની આપલે પહેલાંની નિષ્ફળતા આ સેટિંગથી દૂર ઇશારો કરે છે; પીઅર ચકાસણીમાં નિષ્ફળતા ગેટવે બાજુ તરફ ઇશારો કરે છે.
પસંદ કરેલો પ્રકાર, ઓળખ સંદર્ભ અને ગેટવે પ્રમાણપત્રનો વિષય તૈનાતી નોંધમાં લખો. આગળનું પ્રોફાઇલ અપડેટ તેમાંથી કોઈપણ બદલી શકે છે, અને ત્રણ નામિત મૂલ્યો સેટિંગ્સ પેનલની સ્ક્રીનશોટ કરતાં ઝડપથી સરખાવી શકાય છે.