સાચો VPN પાસવર્ડ ખૂટતા પ્રમાણપત્રની જગ્યા લઈ શકતો નથી

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

પાસવર્ડ રહસ્યના જ્ઞાનનો પુરાવો આપે છે; પ્રમાણપત્ર કીના કબજાનો પુરાવો આપે છે, અને એક બીજાનો વિકલ્પ નથી.

પાસવર્ડ ક્યારેય સમસ્યા ન હતો

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

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

ક્લાયન્ટ સ્ટોરમાં શું હોવું જોઈએ

બે વસ્તુઓ સંકળાયેલી છે. ક્લાયન્ટ પ્રમાણપત્ર VPN ક્લાયન્ટ ચલાવતા વપરાશકર્તા માટે તેની ખાનગી કી સાથે સ્થાપિત હોવું જોઈએ, અને જારી કરતું રૂટ વિશ્વસનીય હોવું જોઈએ. .cer ફાઇલમાં ફક્ત જાહેર પ્રમાણપત્ર હોય છે, તેથી તે એકલું કંઈ પ્રમાણીકરણ કરી શકતું નથી. Windows પ્રમાણપત્ર વ્યવસ્થાપકમાં, ક્લાયન્ટ ઓળખ વર્તમાન વપરાશકર્તાના અંગત સ્ટોરમાં હોય છે, અને રૂટ વિશ્વસનીય રૂટ સ્ટોરમાં હોય છે.

ઓળખને મશીન સ્ટોરમાં, અથવા ફક્ત રૂટ સ્ટોરમાં સ્થાપિત કરવાથી વપરાશકર્તાના અંગત સ્ટોરને લક્ષ્ય બનાવેલી શોધ સંતોષાતી નથી. સ્ટોર, ખાનગી-કી ફ્લેગ અને માન્યતાના તારીખો એકસાથે તપાસો, પછી ક્લાયન્ટ ફરી શરૂ કરો જેથી તે સ્ટોર ફરી વાંચે.

બે ઉત્પાદનો, એક જ ખૂટતું ઓળખપત્ર

OpenVPN સર્વર ડિફોલ્ટ રીતે ક્લાયન્ટ પ્રમાણપત્ર માંગે છે. ક્લાયન્ટમાં auth-user-pass ઉમેરવાથી વપરાશકર્તાનામ અને પાસવર્ડ મોકલાય છે, અને TLS હેન્ડશેક હજી પણ પ્રમાણપત્ર માંગે છે, તેથી ફક્ત પાસવર્ડ verify-client-cert require હેઠળ કનેક્શન પૂર્ણ કરી શકતો નથી. સર્વરને કંઈ ન માંગવા સેટ કરી શકાય છે, જે પાસવર્ડને એકમાત્ર ક્લાયન્ટ ઓળખપત્ર બનાવે છે અને તે શક્તિમાં વાસ્તવિક ઘટાડો છે. auth-user-pass-verify પાછળની shell સ્ક્રિપ્ટ ઓળખપત્રોને માન્ય કરી શકે છે, અને તેને સ્ક્રિપ્ટ ચલાવવાનું સક્ષમ હોવું જરૂરી છે, જે તેને યોગ્ય પ્રમાણીકરણ બેકએન્ડ કરતાં વધુ જોખમી ડિઝાઇન બનાવે છે.

ફક્ત પાસવર્ડ આધારિત પ્રોફાઇલ પણ ધકેલાયેલા વિકલ્પો પર આધાર રાખે છે, જે બદલામાં ખેંચવાની પદ્ધતિ સક્ષમ હોવા પર આધાર રાખે છે.

ચકાસણી બંધ કરીને ખૂટતું પ્રમાણપત્ર સુધારશો નહીં

લોભ એ છે કે સંદેશ અદૃશ્ય થાય તે માટે ચકાસણી ઢીલી કરવી. તે પોતાનું કામ કરતું નિયંત્રણ દૂર કરે છે અને એવું કનેક્શન છોડે છે જે હવે પોતાનો દાવો સાબિત કરતું નથી. જો ગેટવેએ તાજેતરમાં તેનું રૂટ બદલ્યું હોય, તો પ્રોફાઇલ સંપાદિત કરવાને બદલે ક્લાયન્ટ પેકેજ ફરી ડાઉનલોડ કરો, કારણ કે જૂના પેકેજમાં હજી પણ અગાઉનું રૂટ હોઈ શકે છે. જો પ્રોફાઇલ એડિટરમાં પ્રમાણપત્ર પ્રમાણીકરણનો વિકલ્પ ન હોય, તો સ્થાપિત Windows આવૃત્તિ તે પદ્ધતિ બતાવતી ન હોઈ શકે; XML હાથે સંપાદિત કરવાને બદલે સિસ્ટમ અપડેટ કરો.

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

પાસવર્ડ ઠીક હતો. પદ્ધતિને ખરેખર જે ઓળખપત્રની જરૂર હતી તે બીજે ક્યાંક હતું.