IKEv2 સર્વર સરનામું વિ ઓળખ: ક્લાયંટ ખરેખર શું તપાસે છે

એક ગેટવે જે સરનામું બદલે છે તે કામ કરવાનું ચાલુ રાખી શકે છે જ્યારે નવા પ્રમાણપત્રની પાછળનો એ જ ગેટવે બંધ થઈ જાય છે, અને વિપરીત પણ થાય છે. સરનામું ક્લાયન્ટને કહે છે કે પેકેટો ક્યાં મોકલવા; અધિકૃત ઓળખ ક્લાયન્ટને જણાવે છે કે શું પીઅર જવાબ આપનાર પર વિશ્વાસ કરવો જોઈએ. IKEv2 તેને બે અલગ-અલગ ફીલ્ડ તરીકે રાખે છે, જે ઉપયોગી છે એકવાર તમે તેને એક સ્ટ્રીંગ તરીકે ગણવાનું બંધ કરો. તેઓ અલગ-અલગ સ્થળોએ પણ ગોઠવેલા છે, જેથી એક સાચો હોઈ શકે જ્યારે બીજો ખોટો હોય.

તેમને આ ક્રમમાં તપાસો અને પ્રથમ મેળ ખાતી વખતે રોકો, કારણ કે પછીની તપાસ ધારે છે કે પહેલાની ચકાસણીઓ પાસ થઈ ગઈ છે.

પ્રથમ, કયું મૂલ્ય સરનામું છે

કનેક્શન સરનામું ક્લાયંટ જે પણ ડાયલ કરે છે તે છે: એક IP, DNS નામ કે જે એકને ઉકેલે છે, અથવા લોડ-બેલેન્સ્ડ ફ્રન્ટ એન્ડ. તે પરિવહન માહિતી છે અને વધુ કંઈ નથી. ઓળખ IKEv2 ID પેલોડમાં આવે છે અને પછી તે પીઅરના પ્રમાણપત્ર સાથે મેળ ખાય છે. એડ્રેસ બોક્સમાંનું DNS નામ અપેક્ષિત ઓળખ બની શકતું નથી, અને કાચો IP ઓળખ બની શકતો નથી કારણ કે તેની સાથે જોડાયેલ સોકેટ છે.

strongSwanની શરતોમાં, સરનામું right અથવા left છે, અને અપેક્ષિત ઓળખ rightid અથવા leftid છે, અને તે જ IKEv2 રૂપરેખાંકન દસ્તાવેજીકરણ વર્ણવે છે. જો તમે ફક્ત સરનામું સંપાદિત કર્યું હોય, તો તમે અડધી જોડી ગોઠવી દીધી છે.

બીજું, પ્રમાણપત્ર શું સાબિત કરી શકે છે

ઓળખનો એક પ્રકાર છે, અને પ્રમાણપત્રમાં મેળ ખાતું નામ હોવું જરૂરી છે. વિષય વૈકલ્પિક નામ એક્સ્ટેંશનમાં dNSName એન્ટ્રી દ્વારા DNS ઓળખ સંતુષ્ટ થાય છે; IP ઓળખ માટે iPAddress એન્ટ્રીની જરૂર છે. vpn.example.com માટે જારી કરાયેલ પ્રમાણપત્ર શાબ્દિક સરનામા 203.0.113.10 વિશે કંઈ જ સાબિત કરતું નથી, અને તે સરનામા માટે જારી કરાયેલ પ્રમાણપત્ર નામ વિશે કંઈ સાબિત કરતું નથી. એક જ કી અને CA નો પુનઃઉપયોગ થાય ત્યારે પણ અલગ નામ માટે ફરીથી જારી કરવું એ ડ્રોપ-ઇન રિપ્લેસમેન્ટ નથી.

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

ત્રીજું, દરેક ગ્રાહક કેવી રીતે અપેક્ષા જણાવે છે

Windows તમે ટાઇપ કરેલ સર્વર નામ અથવા સરનામું લે છે અને તેને મેચ કરવા માટે પ્રમાણપત્રની જરૂર છે, તેથી IP ટાઇપ કરવાથી IP અપેક્ષાઓ ઊભી થાય છે. Androidનો IKEv2 ક્લાયંટ એ જ રીતે વર્તે છે, અને બંને એક માન્ય, સાર્વજનિક રીતે વિશ્વસનીય પ્રમાણપત્રને નકારે છે જે એક અલગ હોસ્ટનું નામ આપે છે. પ્રોફાઇલ નિષ્ફળ થવાનું શરૂ કરી શકે છે કારણ કે સ્થળાંતર દરમિયાન કોઈએ હોસ્ટનામને તેના સરનામા સાથે બદલ્યું છે. પ્રમાણપત્રમાં શું છે તે જુઓ તે પહેલાં ક્લાયન્ટે શું માંગ્યું તે જુઓ.

strongSwan પર અપેક્ષા સ્પષ્ટ છે: સર્વર વાસ્તવમાં રજૂ કરે છે તે ઓળખ માટે rightid સેટ કરો, જે જમણેથી અલગ હોઈ શકે છે. તેને %any પર સેટ કરવાથી પીઅર જે પણ ઓફર કરે છે તે સ્વીકારે છે અને તમે જે ચેક રાખવાનો પ્રયાસ કરી રહ્યાં છો તે બરાબર દૂર કરે છે.

ચોથું, પીઅર ઓળખથી અલગ વપરાશકર્તા લોગિન

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

સેનિટાઈઝ્ડ રિપોર્ટમાં બંનેના નામ હોવા જોઈએ: ક્લાયન્ટને અપેક્ષિત ઓળખ, સર્વરે રજૂ કરેલી ઓળખ અને પ્રમાણપત્રની SAN એન્ટ્રીઓ.

પાંચમું, ચકાસાયેલ ચેનલ દ્વારા તેને બદલો

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

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