IKEv1 નું હાઇબ્રિડ પ્રમાણીકરણ IKEv2 ના વપરાશકર્તા પ્રમાણીકરણમાં કેવી રીતે પસાર થાય છે
હાઇબ્રિડ મોડ ગેટવેના પુરાવાને વપરાશકર્તાના પુરાવાથી અલગ રાખતો હતો. IKEv2 તરફ જવાથી આ અલગીકરણ ટકે છે, પણ આદાનપ્રદાન, EAP પદ્ધતિ અને પ્રમાણપત્રની ચકાસણી બદલાય છે.
સર્વર પ્રમાણપત્ર અને પછી વપરાશકર્તાનામ માંગતી દરેક જૂની VPN પ્રોફાઇલ એક જ આદાનપ્રદાનમાં પ્રમાણીકરણની બે ઘટનાઓ ધરાવે છે, અને આ આકાર તેને લાવનાર પ્રોટોકોલ કરતાં વધુ જીવે છે. IKEv1 નો હાઇબ્રિડ મોડ બરાબર આ માટે બન્યો હતો: ગેટવે પોતાને જાહેર કી દ્વારા સાબિત કરે છે અને વપરાશકર્તા પછી XAuth મારફતે પોતાને સાબિત કરે છે. IKEv2 એ જ બે-પગલાંનો વિચાર બીજી યંત્રણા દ્વારા વ્યક્ત કરે છે, અને આ ફરકોમાં જ સ્થળાંતર નિષ્ફળ જાય છે. કોઈ સંસ્કરણ સંખ્યા એકને બીજામાં બદલતી નથી, અને જૂની વિકલ્પોનાં નામ નવી પ્રોફાઇલમાં નકલ કરવાથી એવો ક્લાયન્ટ મળે છે જે વાટાઘાટ કરે છે અને પછી કંઈ પણ પ્રમાણિત કરતો નથી.
હાઇબ્રિડ મોડે IKEv1 ની અંદર શું કર્યું
હાઇબ્રિડ પ્રોફાઇલમાં જવાબ આપનાર પક્ષ પ્રથમ તબક્કાના આદાનપ્રદાન પર પોતાના પ્રમાણપત્રથી સહી કરે છે જ્યારે શરૂ કરનાર જાણી જોઈને કોઈ પ્રમાણપત્ર દર્શાવતો નથી. તેથી ઓળખનો પુરાવો અસમમિત છે, અને તેનાથી જ ગેટવેને પોતાનું હાલનું PKI રાખવા અને વપરાશકર્તાઓને પોતાના ડિરેક્ટરી પાસવર્ડ રાખવા મળ્યા. પ્રથમ તબક્કો પૂરો થતાં XAuth વિનંતી અને જવાબ તરીકે ચાલે છે જે હવે એન્ક્રિપ્ટ થયેલા ISAKMP ચેનલની અંદર વપરાશકર્તાનામ અને પાસવર્ડના ગુણ લઈ જાય છે.
ધ્યાન આપો ભરોસો ક્યાં પહોંચે છે. પ્રમાણપત્ર કહે છે કે ક્લાયન્ટ કયા ગેટવે સુધી પહોંચ્યો; XAuth કહે છે કે કયો વપરાશકર્તા પ્રવેશ ઈચ્છે છે. કોઈ કોઈની જગ્યા લેતું નથી, અને કોઈપણ સર્વર પ્રમાણપત્ર સ્વીકારવા સેટ કરેલો ક્લાયન્ટ શાંતિથી પહેલો જવાબ ફેંકી ચૂક્યો છે. હાઇબ્રિડ લેબલ પહેલેથી વહેંચાયેલી કી સાથે આક્રમક મોડ અને XAuth માટે પણ વપરાય છે, જે એ જ વપરાશકર્તા અનુભવ ધરાવતી અલગ ગોઠવણ છે, તેથી નામ નહીં પ્રોફાઇલ વાંચો. બંને રૂપ એવા મુસદ્દાઓમાંથી આવે છે જે કદી ધોરણ ન બન્યા, અને તેથી જ બે ઉત્પાદક હાઇબ્રિડ મોડ લાગુ કરી શકે છે અને કોઈ સાથે આંતરક્રિયા કરી શકતા નથી.
IKEv2 એ જ બે પુરાવા સુધી કેવી રીતે પહોંચે છે
IKEv2 કામને IKE_SA_INIT અને IKE_AUTH વચ્ચે વિભાજે છે. પ્રથમ આદાનપ્રદાન કોઈપણ ઓળખ વગર દરખાસ્તો અને કીઓ પર સંમત થાય છે; બીજું IDi, IDr અને AUTH પેલોડ લઈ જાય છે. EAP હેઠળ શરૂ કરનારનો પહેલો AUTH પેલોડ ખાલી જાય છે, જવાબ આપનાર પહેલા પોતાના પ્રમાણપત્ર અને સહી સાથે પ્રમાણિત થાય છે, અને પછી EAP વાતચીત IKE_AUTH સંદેશાઓની અંદર ચાલે છે.
આને સુરક્ષિત બનાવતી યંત્રણા કી સામગ્રી છે. સફળ EAP પદ્ધતિ સત્ર કી નિકાસ કરે છે, અને શરૂ કરનારનો અંતિમ AUTH પેલોડ તેમાંથી ગણાય છે, તેથી વપરાશકર્તાનો પુરાવો અને સુરંગની કીઓ એકબીજા સાથે બંધાય છે. XAuth પાસે આવું સમતુલ્ય નથી: તેના ગુણ પ્રથમ તબક્કા પછી આવે છે અને કીઓમાં કંઈ ઉમેરતા નથી. આ જ ખાલી જગ્યા ભરવા IKEv2 ઢાંચો બનાવાયો હતો, અને તેથી જ ચાલતું IKEv2 લોગિન કંઈ માંગતા પહેલા સર્વર પ્રમાણપત્ર ચકાસે છે.
આ ક્રમ ઉપયોગી નિદાન પણ છે. જ્યારે ક્લાયન્ટ તમને પ્રમાણપત્ર દેખાડ્યા પહેલા જ ઓળખપત્રોની ફરિયાદ કરે છે, ત્યારે તે IKEv2 EAP આદાનપ્રદાન જ કરતું નથી.
ત્રણ ઓળખ અલગ રાખો
સ્થળાંતર ત્યારે બગડે છે જ્યારે ત્રણ ઓળખ એક જ ક્ષેત્રમાં ભળી જાય છે. ગેટવેની ઓળખ છે જે ક્લાયન્ટ ચકાસે છે, સામાન્ય રીતે પ્રમાણપત્રના subject અથવા SAN માં DNS નામ. EAP માં રજૂ થતી વપરાશકર્તાની ઓળખ છે, કદાચ ડોમેન લોગિન, સરનામું અથવા સ્પષ્ટ EAP ઓળખ સ્ટ્રિંગ. અને તે અધિકાર સ્રોત છે જે તે વપરાશકર્તાને નેટવર્ક અને માર્ગો પર મેપ કરે છે.
strongSwan નું swanctl સિન્ટેક્સ અલગીકરણ દૃશ્યમાન કરે છે: કનેક્શન ગેટવે માટે remote { auth = pubkey } અને વપરાશકર્તા માટે local { auth = eap-mschapv2 } સેટ કરે છે, અને EAP ઓળખ અલગ વહેવાય છે.
જ્યારે નવી પ્રોફાઇલમાં વપરાશકર્તાની ઓળખ જૂનાં XAuth ગુણોથી અલગ હોય, જેમ કે ટૂંકા નામની જગ્યાએ UPN, પ્રમાણીકરણ સર્વર અજાણ્યો વપરાશકર્તા જુએ છે અને નિષ્ફળતા ખોટા પાસવર્ડ જેવી લાગે છે. ઓળખપત્રો ચકાસતા પહેલા ઓળખ સ્ટ્રિંગ ચકાસો.
વિકલ્પોનો નકશો બનાવો અને પછી જાળની અપેક્ષા રાખો
નકશો ટૂંકો છે અને દરેક પંક્તિમાં એક જાળ છે જે ફક્ત પ્રમાણીકરણ વખતે દેખાય છે.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
તે પંક્તિઓમાંથી કોઈ પણ ફક્ત નામ બદલવું નથી. રૂપરેખા પેલોડ સરનામાં અને રિઝોલ્વર ટાઇપ કરેલી ગુણ સૂચિ દ્વારા પહોંચાડે છે, જ્યારે XAuth નું ગુણ ક્ષેત્ર તેની પોતાની શોધ હતું; તેમને બદલી શકાય તેવા ગણવા એ જ માર્ગ છે જેનાથી પ્રોફાઇલ એવી સેટિંગ માંગે છે જે ગેટવે કદી મોકલશે નહીં.
ટ્રાફિક પસંદકર્તાઓ પોતાની અલગ ચેતવણીને લાયક છે. IKEv1 રસપ્રદ ટ્રાફિકને quick mode આદાનપ્રદાન સાથે બંધાયેલા પ્રોક્સી આઈડી દ્વારા વ્યક્ત કરતું હતું, જ્યારે IKEv2 IKE_AUTH દરમિયાન પસંદકર્તાઓ પર વાટાઘાટ કરે છે અને જવાબ આપનાર તેમને સાંકડા કરી શકે છે. બેમેળ થતાં child SA વગરનું સ્થાપિત IKE SA બને છે, જે કેટલાક ક્લાયન્ટ આનંદથી જોડાયેલું દર્શાવે છે.
જૂના કનેક્શનને સીમા ગણો
RFC 9395 IKEv1 ને અપ્રચલિત જાહેર કરે છે, તેથી જૂનું હાઇબ્રિડ કનેક્શન તારીખવાળી સુસંગતતાની સીમા છે, પાયો નહીં. બદલાવ દરમિયાન બંને પ્રોફાઇલ સાથોસાથ ચલાવો, કારણ કે મહત્ત્વની કસોટી એ નથી કે નવી પ્રોફાઇલ ઉપર આવે છે કે નહીં, પણ એ કે એ જ વપરાશકર્તા એ જ ઉપકરણ પર એ જ સંસાધનો સુધી પહોંચે છે.
પ્રમાણપત્ર ચકાસણી શરૂઆતથી અંત સુધી કડક રાખો. ક્લાયન્ટ પોતાનું પ્રમાણપત્ર દર્શાવવાનું બંધ કરે કે તરત, હાથમિલાવની પૂરી થાય ત્યાં સુધી સર્વર ચકાસણી ઢીલી કરવાનું લલચાવન આવે છે, અને તે બાકી રહેલો એકમાત્ર પુરાવો લીલા ચિહ્ન સાથે બદલી નાખે છે.
જૂની પ્રોફાઇલ નિવૃત્ત કરતા પહેલા ચાર વાતો લખો: EAP પદ્ધતિ, ઓળખ સ્ટ્રિંગ, અધિકાર સ્રોત અને સમર્થન પૂરું થતી તારીખ.