કનેક્શન નકારવું એ સર્ટિફિકેટની સમસ્યા નથી: VPN રનબુક

તમે CRL ફરી બનાવ્યા પછી તરત જ ક્લાયન્ટ કહે છે કે કનેક્શન નકારવામાં આવ્યું, એટલે CRL દોષિત લાગે છે. એવું નથી. નકાર એ પરિવહન સ્તરનો જવાબ છે, અને સર્ટિફિકેટ માન્યતા પછી, ટનલ હેન્ડશેકની અંદર થાય છે. સમય એ સંદર્ભ છે, પુરાવો નહીં.

બે ચેક એક મિનિટથી ઓછા સમયમાં કેસોને અલગ પાડે છે, અને તેમાંનું એક પણ ટ્રસ્ટ સેટિંગ્સને સ્પર્શતું નથી.

જે સ્તરે ભૂલ થઈ તે સ્તરે વાંચો

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

ઊલટું પણ સાચું છે. રદ કરેલું સર્ટિફિકેટ પૂર્ણ TCP કનેક્શન અને નિષ્ફળ હેન્ડશેક પેદા કરે છે, જે સર્વર પર ચકાસણી ભૂલ તરીકે નોંધાય છે.

TCP નકાર: કોઈ સાંભળતું નથી

TCP માટે, ચકાસો કે ઇચ્છિત ઇન્સ્ટન્સ ચાલી રહ્યું છે અને પ્રોફાઇલના સરનામા અને પોર્ટ સાથે જોડાયેલું છે. ss -lntp શ્રોતાઓ બતાવે છે, અને તેમાંથી એકની ગેરહાજરી સામાન્ય સમજૂતી છે. જે ફાયરવોલ છોડી દેવાને બદલે નકારે છે તે ક્લાયન્ટ બાજુએ એ જ સંદેશ પેદા કરે છે, એટલે તમે બંને તપાસો છો.

સરનામા કુટુંબ પણ તપાસો. 127.0.0.1 અથવા ફક્ત IPv6 સાથે જોડાયેલી સેવા બીજા પર રિઝોલ્વ થતા ક્લાયન્ટને નકારશે.

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

UDP પાસે નકારવા જેવો હેન્ડશેક નથી

UDP પર OpenVPN TCP અર્થમાં કનેક્શન સ્થાપિત કરતું નથી, એટલે connect સમયે નકારવા જેવું કંઈ નથી. Linux માં, UDP સોકેટ દ્વારા દેખાતી ભૂલ અગાઉના ડેટાગ્રામ દ્વારા પેદા થયેલા ICMP port-unreachable માંથી આવી શકે છે. udp(7) મેન પેજ એ અસિંક્રોનસ વર્તન વર્ણવે છે.

એટલે UDP ક્લાયન્ટ નકાર છાપી શકે છે જ્યારે સર્વર પ્રક્રિયા ચાલી રહી હોય પણ અપેક્ષિત સરનામા સાથે જોડાયેલી ન હોય.

CRL ખરેખર ક્યાં તપાસાય છે

CRL ની સલાહ TLS હેન્ડશેક દરમિયાન લેવાય છે, પીઅર તેનું સર્ટિફિકેટ રજૂ કર્યા પછી, અને ફક્ત જો સર્વર ગોઠવણી તેને સક્ષમ કરે. OpenVPN નો crl-verify વિકલ્પ ફાઇલ તરફ ઇશારો કરે છે, અને નિષ્ફળતા સર્વર લોગમાં સર્ટિફિકેટનું નામ લેતી ચકાસણી ભૂલ તરીકે દેખાય છે.

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

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

આગલી વાર માટે ટૂંકી રનબુક

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

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