OpenVPN પેકેટ HMAC પ્રમાણીકરણ નિષ્ફળ: કયો સ્તર?

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

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

એક શબ્દ વહેંચતી બે નિષ્ફળતાઓ

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

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

ચાલતી પ્રક્રિયાએ ખરેખર શું લોડ કર્યું તે સરખાવો

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

એક જ સ્રોતમાંથી સમર્થિત પ્રોફાઇલ ફરી નિકાસ કરવી સસ્તી સરખામણી છે, કારણ કે તે તમે જે ગોઠવેલું માનો છો અને ક્લાઇન્ટ ખરેખર જે મોકલે છે તે વચ્ચેનું વિચલન દૂર કરે છે. નવી કી સામગ્રી પેદા કરવી ઘણું મોટું પગલું છે, અને તે ત્યારે જ મદદ કરે છે જ્યારે બંને છેડા તેને સાથે અપનાવે. એક બાજુ સ્થાનિક રીતે બદલવાથી તમે દૂર કરવા માંગતી અસંગતિ ફરી ઊભી થાય છે.

નિયંત્રણ ચેનલની ડેટા ચેનલ સાથે સરખામણી કરો

બે મિકેનિઝમ કનેક્શનના જુદા જુદા ભાગોનું પ્રમાણીકરણ કરે છે અને અલગથી ગોઠવાય છે, જેમ 2.6 વિકલ્પ સંદર્ભ વર્ણવે છે. tls-auth નિયંત્રણ-ચેનલ પેકેટોમાં HMAC ઉમેરે છે અને એવો દિશા-દલીલ લે છે જે બે પીઅર પર વિરુદ્ધ હોવી જોઈએ, જ્યારે tls-crypt તેના બદલે નિયંત્રણ ચેનલને વહેંચાયેલ કી વડે સુરક્ષિત કરે છે. બંનેમાંથી કોઈ ડેટા ચેનલની પોતાની અખંડિતતા ચકાસણી નથી. AEAD ડેટા સાઇફર સાથે એ ચકાસણી સાઇફરમાં જ ગોઠવાયેલી હોય છે, તેથી auth અલગ ડાયજેસ્ટ એ રીતે વપરાતું નથી જે રીતે નોન-AEAD સાઇફર સાથે વપરાય છે.

એટલે કે auth લીટી, જે કાર્યરત નોન-AEAD જમાવટમાંથી નકલ કરાઈ છે, તે AEAD જમાવટમાં અપ્રસ્તુત હોઈ શકે છે, અને AEAD જમાવટ હજુ પણ નિયંત્રણ ચેનલ પર નિષ્ફળ જઈ શકે છે જો tls-auth કી કે તેની દિશા ખોટી હોય. દરેક સેટિંગની સરખામણી પીઅર સાથે કરો, યાદ રાખેલી ગોઠવણ સાથે નહીં.

સુધારાની સરખામણી તમે છોડી દેતી મિલકત સાથે કરો

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

કંઈ પણ બદલતા પહેલાં બંને છેડે પ્રથમ સંબંધિત ઘટના વાંચો, પછી ફક્ત તે અસંગતિ બદલો જેનું તે નામ લે છે.

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