એક ભૂલ, ત્રણ રહસ્યો: કઈ VPN લોગિન માહિતી નિષ્ફળ ગઈ?
ક્લાયન્ટ દરેક તબક્કા માટે એક ભૂલ બતાવે છે. જે પાસવર્ડ કોઈએ ચકાસ્યો નથી તેને ફરી સેટ કરતા પહેલા સંગઠન, વપરાશકર્તા વિનિમય અને પદ્ધતિ વાંચો.
«પ્રમાણીકરણ નિષ્ફળ ગયું» સર્વર પ્રમાણપત્ર, મશીનની પૂર્વ-શેર કરેલી ચાવી અથવા વપરાશકર્તા પાસવર્ડ તરફ ઈશારો કરી શકે છે. તેમાંથી કયું તે પ્રોટોકોલ પર આધાર રાખે છે, કારણ કે દરેક પ્રોટોકોલ અલગ રહસ્યોનો સમૂહ નક્કી કરે છે. ખોટું ફરી સેટ કરો અને ભૂલ અપરિવર્તિત રહે છે. બહાર નીકળવાનો રસ્તો એ છે કે કંઈપણ સંપાદિત કરતા પહેલા પ્રોટોકોલને કેટલા પુરાવા જોઈએ તે નક્કી કરવું.
વિરુદ્ધ દિશામાં ઈશારો કરતા બે પુરાવા
ટનલે જવાબ આપવો પડે કે તે યોગ્ય ગેટવે સુધી પહોંચી છે કે નહીં, અને અલગથી કે વપરાશકર્તા કોણ છે. ગેટવેનો પુરાવો મશીન-સ્તરનો છે: સર્વર પ્રમાણપત્ર, પૂર્વ-શેર કરેલી ચાવી અથવા સ્થિર જાહેર ચાવી. વપરાશકર્તાનો પુરાવો વ્યક્તિ-સ્તરનો છે: પાસવર્ડ, ટોકન, ક્લાયન્ટ પ્રમાણપત્ર, અથવા કંઈ જ નહીં. આ વિશ્વાસની વિરુદ્ધ દિશાઓ છે અને તેઓ અલગ સામગ્રી વાપરે છે.
IKEv2 ગેટવેનો પુરાવો IKE_AUTH અંદર કરે છે અને જ્યારે EAP વપરાય છે ત્યારે પછી વપરાશકર્તાનો પુરાવો અલગ વિનિમયમાં ચલાવે છે. IKEv2 વિશિષ્ટતા આ બંનેને અલગ વિભાગો તરીકે રાખે છે, જે એક સંદેશ બંને રાઉન્ડ આવરી લે ત્યારે ક્યાં જોવું તે અંગે મજબૂત સંકેત છે.
સંદેશ નહીં, તબક્કો વાંચો
કયો તબક્કો નિષ્ફળ ગયો તે ધ્યાનમાં લીધા વિના ક્લાયન્ટ એક જ ભૂલ શબ્દમાળા બતાવે છે, તેથી શબ્દમાળા પોતે લગભગ કોઈ માહિતી ધરાવતી નથી. માહિતી ધરાવે છે તે સ્થિતિ જે તમે દરેક તબક્કે તપાસી શકો છો: સંગઠન છે કે નહીં, વપરાશકર્તા વિનિમય શરૂ થયો કે નહીં, અને ક્લાયન્ટે ગેટવેની ઈચ્છિત પદ્ધતિ ઓફર કરી કે નહીં. કોષ્ટક તબક્કાઓને પ્રોટોકોલ નામ પ્રમાણે નહીં, પણ તે રીતે ગોઠવે છે.
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
ફક્ત બીજી હરોળ એવી માહિતી વિશે છે જે વપરાશકર્તા ફરી ટાઇપ કરી શકે. બાકીની ત્રણ રૂપરેખાંકનની હકીકતો છે, અને આ અસંગતિ એ કારણ છે કે આવા ઘણા અહેવાલો એવા પાસવર્ડ રીસેટ સાથે પૂરા થાય છે જે કંઈ બદલતું નથી. કોઈ ફીલ્ડને સ્પર્શ કરતા પહેલા તમારા પુરાવા સાથે મેળ ખાતી હરોળ વાંચો.
બે રહસ્યોવાળો પ્રોટોકોલ પોતાના પત્તા ખોલે છે
L2TP IPsec પર ગણતરી દૃશ્યમાન બનાવે છે, કારણ કે બે તપાસ અલગ પ્રક્રિયાઓમાં થાય છે. IPsec સ્તરે પહેલા પૂર્વ-શેર કરેલી ચાવી અથવા પ્રમાણપત્ર સાથે ઉપર આવવું પડે છે, અને ત્યાર પછી જ તેની અંદરનું PPP વપરાશકર્તા લોગિનનો પ્રયાસ કરે છે.
જ્યારે મશીનનું રહસ્ય ખોટું હોય ત્યારે કોઈ સંગઠન રચાતું નથી અને વપરાશકર્તાની માહિતી કદી અજમાવાતી નથી. જ્યારે મશીનનું રહસ્ય સાચું અને વપરાશકર્તાનું રહસ્ય ખોટું હોય ત્યારે સંગઠન અસ્તિત્વમાં હોય છે અને ટનલ પહેલેથી ઉપર હોય ત્યારે PPP લોગિન નકારે છે. બંને બે અલગ ઘટનાઓમાંથી સ્ક્રીન પર એક જ સંદેશ આપે છે.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerખાલી સંગઠન સૂચિ વપરાશકર્તા સ્તરને તરત જ બાકાત કરે છે, તેથી પાસવર્ડ પહેલા તેને તપાસો. વારંવાર PPP નિષ્ફળતાઓ સાથેનું સ્થાપિત સંગઠન બીજી દિશામાં, વપરાશકર્તા સ્તર અથવા તેની અંદરના પ્રમાણીકરણ પ્રોટોકોલ તરફ ઈશારો કરે છે. બંનેમાંથી કોઈ નિષ્કર્ષ ક્લાયન્ટના ભૂલ લખાણમાંથી મળતું નથી.
ફક્ત પાસવર્ડ સાથેનો પ્રવેશ ખરેખર શેના પર આધાર રાખે છે
ફક્ત પાસવર્ડ સાથેનો પ્રવેશ L2TP, PPTP, SSTP અને EAP સાથેના IKEv2 માટે સામાન્ય છે. WireGuard પાસે એવો કોઈ વિકલ્પ જ નથી, કારણ કે તેના સાથીદારો વપરાશકર્તાઓ નહીં, ચાવીઓ છે. OpenVPN માટે જવાબ સર્વરની ક્લાયન્ટ-પ્રમાણપત્ર જરૂરિયાતમાંથી આવે છે: જે ગેટવે પ્રમાણપત્ર અને પાસવર્ડ બંને માંગે છે તે ફક્ત-પાસવર્ડ ક્લાયન્ટને ફીલ્ડમાં શું લખાય તે ધ્યાનમાં લીધા વિના નકારતું રહેશે.
તમને કયો ઘટક જોઈએ તે એ જ જવાબમાંથી આવે છે. IKEv2 હેઠળ પાસવર્ડ લોગિન માટે EAP બોલતું ક્લાયન્ટ જરૂરી છે, જ્યારે પ્રમાણપત્ર લોગિન માટે ક્લાયન્ટની ખાનગી ચાવી અને સર્વરની શૃંખલા જરૂરી છે. ખોટું ઇન્સ્ટોલ કરો અને નિષ્ફળતા લોગિન માહિતીની ભૂલ જેવી વંચાય છે, જોકે ખૂટતી વસ્તુ પ્રમાણીકરણ પદ્ધતિ પોતે જ છે.
એક વસ્તુ બદલો, પછી ફરી પરીક્ષણ કરો
પહેલા ત્રણ હકીકતો નક્કી કરો: કયો પ્રોટોકોલ ચાલી રહ્યો છે, તે કેટલા રહસ્યો નક્કી કરે છે, અને તેમાંથી કયા વપરાશકર્તાને નહીં પણ મશીનને અનુસરે છે. મશીનો પહેલા તબક્કે નિષ્ફળ જાય છે અને લોકો બીજા તબક્કે નિષ્ફળ જાય છે, અને બંનેને ભેગા કરવું એ આખી સમસ્યા છે.
પછી બરાબર એક વસ્તુ બદલો અને એ જ ક્લાયન્ટમાંથી ફરી પરીક્ષણ કરો. આ શિસ્ત મૂંઝવણભરી નિષ્ફળતાને એવા સુધારામાં ફેરવે છે જે તમે આગલી વ્યક્તિને વર્ણવી શકો, અને તે કોઈ સમજાવી ન શકે એવા કામ કરતા કનેક્શન કરતાં વધુ ઉપયોગી છે.