લોગમાં P_CONTROL_HARD_RESET_CLIENT_V2: તે ભૂલ છે?

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

ઓપકોડ પ્રોટોકોલમાં સ્થાન દર્શાવે છે

OpenVPN એક સોકેટ પર કેટલાક પ્રકારના પેકેટ મલ્ટિપ્લેક્સ કરે છે, અને ઓપકોડ ગ્રાહકને કહે છે કે તે કયો પ્રકાર પકડી રહ્યો છે. હાર્ડ-રીસેટ પેકેટ સત્ર ખોલે છે, નિયંત્રણ પેકેટ હેન્ડશેક સામગ્રી વહન કરે છે, સ્વીકૃતિઓ પ્રાપ્તિની પુષ્ટિ કરે છે અને ડેટા પેકેટ ટનલનો ભાર વહન કરે છે. પહેલું બાઇટ વાંચવાથી ખબર પડે છે કે તે આદાનપ્રદાનમાં પેકેટ ક્યાં આવે છે, અને સ્રોત કોડમાં પેકેટ વ્યાખ્યાઓ દરેક કુટુંબને સ્પષ્ટ નામ આપે છે.

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

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

તે ક્ષણે ક્લાયન્ટ ખરેખર શું કરે છે

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

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

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

રીસેટ પછી સાચી ખામી ક્યાં છુપાય છે

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

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

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

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

એ શોધ પોતે નિદાન નથી, પણ તે એક પગલામાં તમને પ્રોટોકોલના શબ્દભંડોળથી વાસ્તવિક ખામી-વર્ગ સુધી લઈ જાય છે.

ચકાસણી બંધ કરવી શા માટે ખોટો પ્રતિભાવ છે

જ્યારે રીસેટ દેખાતું રહે છે, ત્યારે સૌથી ઝડપી લાગતો ઉપાય પ્રમાણપત્ર ચકાસણી બંધ કરવી અથવા કંઈક જોડાય તે માટે નિયંત્રણ-ચેનલ સુરક્ષા છોડી દેવી છે. તે નિદાન કરી શકાય તેવી ખામીને નિદાન ન કરી શકાય તેવી સાથે બદલે છે, અને જમાવટને એવા પક્ષો સ્વીકારતી રાખે છે જેમને નકારવા માટે તે બનાવાઈ હતી.

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

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