ગેટવે પ્રમાણપત્ર ઠીક છે: IKEv2 PEAP લોગિન હજુ કેમ નિષ્ફળ જાય છે
PEAP વિનિમય IKE પ્રમાણીકરણની અંદર પોતાનું TLS સર્વર પ્રમાણપત્ર માન્ય કરે છે. ગેટવે પ્રમાણપત્ર બદલતા પહેલાં બંને ઓળખની તુલના કરો.
તમારા VPN ગેટવેનું પ્રમાણપત્ર માન્ય છે, શૃંખલા ચકાસાય છે, અને IKEv2 ક્લાયન્ટ પ્રમાણપત્રની માન્યતા-અવધિ વિશેના સંદેશ સાથે લોગિન નકારી કાઢે છે. પ્રથમ વૃત્તિ ગેટવે પ્રમાણપત્ર ફરી બહાર પાડવાની કે EAP પદ્ધતિ બદલવાની હોય છે, અને બંને સામાન્ય રીતે ખોટા છે. લોગિનનો પ્રયાસ બે અલગ સર્વર ઓળખ વહન કરે છે: IKE વાપરે છે તે ગેટવે પ્રમાણપત્ર, અને PEAP ને સમાપ્ત કરનાર જે રજૂ કરે છે તે પ્રમાણપત્ર. તેમાંથી એક ઠીક છે, અને બીજું જ ક્લાયન્ટ અટક્યાનું કારણ છે.
બે ઓળખ, એક લોગિન પ્રયાસ
VPN પ્રોફાઇલનું પ્રમાણપત્ર IKE વિનિમયનું છે: તે સાબિત કરે છે કે ગોઠવાયેલી IKE નીતિ હેઠળ ગેટવે એ જ પક્ષ છે જેનું નામ પ્રોફાઇલ આપે છે. અહીં નિષ્ફળ જતું પ્રમાણપત્ર બીજી વાતચીતનું છે, એટલે કે PEAP જે TLS સત્ર વપરાશકર્તાને પ્રમાણિત કરનાર સાથે ખોલે છે, જે ઘણી વાર NPS જેવું RADIUS સર્વર હોય છે, ગેટવે પોતે નહીં. ત્રીજી ચકાસણી, વપરાશકર્તાના ઓળખપત્ર, તે સત્રની અંદર થાય છે. માન્ય પાસવર્ડ સમાપ્ત થયેલું સર્વર પ્રમાણપત્ર સુધારી શકતો નથી, અને માન્ય ગેટવે પ્રમાણપત્ર PEAP અંતિમ બિંદુ માટે જામીન બની શકતું નથી.
આ સ્તરીકરણ સમજાવે છે કે પ્રમાણપત્રની ભૂલ એવી જગ્યાએ કેમ દેખાય છે જ્યાં કોઈએ ગોઠવેલું એકમાત્ર પ્રમાણપત્ર ગેટવેનું જ હતું. તે એ પણ સમજાવે છે કે તે પ્રમાણપત્ર ફરી બહાર પાડવાથી કંઈ કેમ બદલાતું નથી.
લોગની લાઇનને તબક્કા સામે વાંચો
કારણ અને તારીખોનું નામ આપતો સંદેશ શોધો. વિષય-ભૂલની બાજુમાં માન્યતા-અવધિની ફરિયાદનો અર્થ એ છે કે સર્વરે તેને આપેલું પ્રમાણપત્ર નકાર્યું, એવું નહીં કે વપરાશકર્તાએ લોગિન નકાર્યું. પછી તબક્કો શોધો: strongSwanનો charon લોગ EAP વિનિમય શરૂ થાય તે પહેલાં IKE_SA .* established દર્શાવે છે, તેથી તે લાઇન પછીની પ્રમાણપત્ર ભૂલ EAP ઓળખની છે, જ્યારે તે પહેલાંની ભૂલ ગેટવે તરફ ઇશારો કરે છે. Windows ક્લાયન્ટના કનેક્શન પેનલમાંનું તબક્કા-લખાણ પણ એ જ કહે છે.
કોઈપણ પ્રમાણપત્રને અડકતા પહેલાં ક્લાયન્ટની ઘડિયાળ તપાસો. કલાકો જેટલી ખોટી હોય તેવું ઉપકરણ ખરેખર સમાપ્ત થયેલા પ્રમાણપત્ર જેવી જ માન્યતા-ભૂલ ઉત્પન્ન કરે છે. ઘડિયાળ સુધારવી પાંચ સેકન્ડની કામગીરી છે, અને જે પ્રમાણપત્ર કદી સમસ્યા જ નહોતું તેને બદલવું એ આઉટેજ છે.
PEAP કયું અંતિમ બિંદુ સમાપ્ત કરે છે તે શોધો
ગેટવે-વત્તા-RADIUS રચનામાં ગેટવે EAP આગળ મોકલે છે અને તેને સમાપ્ત કરતું નથી. strongSwanનું eap-radius પ્લગઇન વિનિમય RADIUS સર્વરને સોંપે છે, જેની પાસે PEAP TLS સત્ર અને તેનું પ્રમાણપત્ર હોય છે. બંને લોગમાં એક નિષ્ફળ પ્રયાસને સહસંબંધિત કરો અને ખાતરી કરો કે કઈ પ્રક્રિયાએ ખરેખર તે સત્ર માટે પ્રમાણપત્ર પસંદ કર્યું.
NPS માટે પ્રમાણપત્ર સ્થાનિક કમ્પ્યુટર સ્ટોરમાં હોવું જોઈએ, સર્વર પ્રમાણીકરણનો હેતુ ધરાવવો જોઈએ, ક્લાયન્ટ જે નામની અપેક્ષા રાખે તેની સાથે મેળ ખાવો જોઈએ, અને સેવા ખાતા માટે વાંચનક્ષમ હોવું જોઈએ. NPS માટે Microsoftની પ્રમાણપત્ર જરૂરિયાતો તે શરતોની સૂચિ આપે છે. અન્ય EAP સર્વરોની પોતાની પસંદગી-નિયમો હોય છે, તેથી NPSની વિશિષ્ટતાઓ FreeRADIUS ઇન્સ્ટોલેશનમાં કે ઊલટું કૉપિ કરશો નહીં. બંને સંજોગોમાં ટકતો નિયમ એ છે કે PEAP સમાપ્ત કરતું અંતિમ બિંદુ તે પ્રમાણપત્રનું માલિક છે જે તમે બદલવા જઈ રહ્યા છો.
EAP સમાપ્ત થાય છે ત્યાં પ્રમાણપત્ર બદલો
PEAP સમાપ્ત કરતા અંતિમ બિંદુ પર સમર્થિત પ્રક્રિયા દ્વારા પ્રમાણપત્ર નવીકરણ કે બદલો, સર્વર-પ્રમાણીકરણનો હેતુ અને અપેક્ષિત નામ જાળવી રાખીને. સેવા જ્યાં શોધે છે ત્યાં સંપૂર્ણ શૃંખલા સ્થાપિત કરો અને સેવાને ખાનગી કીનો ઍક્સેસ આપો. સેવાને ફરી શરૂ કરો કે ફરી બાઈન્ડ કરો, કારણ કે ઘણી સેવાઓ જૂનું પ્રમાણપત્ર મેમરીમાં રાખે છે અને તેને રજૂ કરતી રહે છે. મશીન પર કૉપિ કરેલી ફાઇલ સેવા ખરેખર કયું પ્રમાણપત્ર રજૂ કરે છે તે વિશે કંઈ સાબિત કરતી નથી.
આગલા પ્રયાસને સેવાના પોતાના લોગ સાથે સહસંબંધિત કરીને, અથવા સત્રે રજૂ કરેલું પ્રમાણપત્ર તપાસીને ફેરફારની પુષ્ટિ કરો. જો તે લોગ હજુ જૂની થંબપ્રિન્ટ દર્શાવે, તો ફરી શરૂ કરવું કામ ન લાગ્યું.
ડિરેક્ટરીમાંની સૌથી નવી ફાઇલ જ વપરાય છે એવું ધારી ન લો. સાચા નામ અને ખોટી પરવાનગીઓવાળી નકલ કંઈ બદલતી નથી. ફેરફારને ફાઇલના ટાઇમસ્ટેમ્પથી નહીં, રજૂ થયેલી ઓળખથી આંકો.
શું ન કરવું
ભૂલ ટાળવા PEAP ચકાસણી બંધ કરશો નહીં કે નબળી આંતરિક પદ્ધતિ ફરજિયાત લાદશો નહીં. તે નીતિ બદલે છે અને સર્વર-પ્રમાણીકરણનો ગુણ દૂર કરે છે જેણે શરૂઆતમાં સમાપ્ત પ્રમાણપત્ર પકડ્યું હતું. તમે કામ કરતી ચકાસણીને કામ કરતા કનેક્શન સાથે બદલી નાખો છો, અને આગલું સમાપ્ત પ્રમાણપત્ર કંઈ જાહેર કર્યા વિના આવશે.
બીજી ઓપરેટિંગ સિસ્ટમના સફળ કનેક્શનને પ્રમાણપત્ર સ્વીકાર્ય હોવાનો પુરાવો ન ગણો. તે ક્લાયન્ટ બીજી EAP પદ્ધતિ, બીજો ટ્રસ્ટ સ્ટોર કે સર્વર ચકાસણી વગર પણ ચાલી શકે, તેથી તેની સફળતા અહીં નિષ્ફળ ગયેલી ચકાસણી વિશે કંઈ કહેતી નથી. એક જાણી જોઈને કરેલી નકારાત્મક કસોટી—જેમ કે ખોટા નામનું પ્રમાણપત્ર કે અવિશ્વસનીય શૃંખલા—અપેક્ષા મુજબ નિષ્ફળ રાખો. જો તે કસોટી હવે પાસ થાય, તો તમે પ્રમાણપત્ર સુધારવાને બદલે ચકાસણી દૂર કરી છે. કઈ ઓળખ નિષ્ફળ ગઈ તે લખી રાખો, જેથી આગલી વ્યક્તિ ફરી ગેટવે પ્રમાણપત્રથી શરૂ ન કરે.