IKEv2 વિનિમય કામ કરે છે, પછી પ્રમાણીકરણ નિષ્ફળ જાય છે: ક્યાં શોધવું

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

તપાસ 1: સંદેશ નહીં, તબક્કો વાંચો

અસ્વીકાર ત્રણ જગ્યાએથી આવી શકે છે: ક્લાયન્ટ સર્વરની ઓળખ નકારે છે, ગેટવે ક્લાયન્ટનો પુરાવો નકારે છે, અને બાહ્ય પ્રમાણીકરણ સેવા ખાતું નકારે છે.

દરેક જુદી મશીન પર જુદી લોગ લાઇન ઉત્પન્ન કરે છે, અને દરેકનો જુદો ઉપાય છે. ક્લાયન્ટ તરફથી સર્વર પ્રમાણપત્રનો અસ્વીકાર એ ક્લાયન્ટ પરની વિશ્વાસ કે નામકરણ સમસ્યા છે; ગેટવે તરફથી ક્લાયન્ટ પ્રમાણપત્રનો અસ્વીકાર એ ગેટવે પરની વિશ્વાસ સમસ્યા છે; EAP નિષ્ફળતા એ ખાતા કે બેકએન્ડની સમસ્યા છે. તમે જે સંદેશ જુઓ છો તે સામાન્ય રીતે તેમાંથી એકનો ક્લાયન્ટનો સારાંશ છે, તેથી જ ગેટવેનો લોગ ક્લાયન્ટના લોગ જેટલો જ મહત્ત્વનો છે.

તપાસ 2: કઈ ઓળખ તપાસવામાં આવી

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

strongSwanની દૃષ્ટિએ તે ક્લાયન્ટ પર rightid છે અને બીજી બાજુ ગેટવેની પોતાની ઓળખ છે, અને EAP ચર્ચાય તે પહેલાં જ મેળ ન ખાવો નિષ્ફળ જાય છે.

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

તપાસ 3: જો EAP સંડોવાયેલું હોય

ક્લાયન્ટ અને સર્વરે સમર્થિત પદ્ધતિ પર સંમત થવું પડે છે, અને બેકએન્ડે આપેલી ઓળખ સ્વીકારવી પડે છે.

વપરાશકર્તાનામને ડોમેન સફિક્સ અથવા ડિપ્લોયમેન્ટ જે ચોક્કસ ખાતા ફોર્મેટની જરૂર હોઈ શકે છે, અને ફોર્મેટ અનુમાન કરવા યોગ્ય નહીં પરંતુ દસ્તાવેજીકૃત છે. ઓપરેટરના દસ્તાવેજીકૃત ફીલ્ડ આપવા એ વિવિધતાઓ અજમાવવા કરતાં ઝડપી છે, અને તે બીજી સમસ્યા ટાળે છે: વારંવારના પ્રયાસો ખાતા લૉકઆઉટ કરી શકે છે, જે પછી મૂળ તબક્કાને નવી નિષ્ફળતા પાછળ છુપાવે છે. જો પદ્ધતિ ડિરેક્ટરી સામે EAP-MSCHAPv2 હોય, તો નિષ્ફળતા VPNની નહીં પરંતુ ડિરેક્ટરીની હોઈ શકે છે.

ઓળખ તપાસ બંધ કરીને ઓળખ સમસ્યાઓનું પરીક્ષણ ન કરો. તે નિદાન કરી શકાય તેવી નિષ્ફળતાને નિદાન ન કરી શકાય તેવી બનાવે છે અને કનેક્શનને પહેલા કરતાં નબળું છોડે છે.

તપાસ 4: સફળ લોગિન પછી શું થાય છે

IKE_AUTH પૂર્ણ થાય પછી, CHILD_SA વાટાઘાટ નક્કી કરે છે કે કયા ટ્રાફિક સિલેક્ટર સ્થાપિત થાય છે, અને ત્યાં જ કનેક્શન સફળ થઈને પણ કંઈ પસાર ન કરી શકે.

નવેસરથી કાર્યરત લોગિન ઘણી વાર સિલેક્ટર કે રૂટ સમસ્યા ઉજાગર કરે છે જે પહેલા પ્રમાણીકરણ નિષ્ફળતા પાછળ છુપાયેલી હતી. જો ટનલ ઉપર આવે અને એપ્લિકેશન હજી તેના લક્ષ્ય સુધી પહોંચી ન શકે, તો ફરીથી ઓળખને બદલે વાટાઘાટ કરેલા સિલેક્ટર અને રૂટ જુઓ. તે સમયે ઓળખ સેટિંગ્સ બદલવી ખોટા તબક્કાને લક્ષ્ય બનાવે છે અને સામાન્ય રીતે કાર્યરત લોગિન તોડે છે. swanctl --list-sas થી ખાતરી કરો, જે IKE SAથી અલગ ચિલ્ડ્રન અને તેમના સિલેક્ટર બતાવે છે.

તપાસ 5: સપોર્ટને શું આપવું

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

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