OpenVPN tls-ciphersuites વિરુદ્ધ tls-version-min: દરેક શું લાગુ કરે છે

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

કોઈપણ યાદી વાંચતા પહેલાં બિલ્ડ તપાસો

કન્ફિગરેશન સૂચના એવા બાઇનરીમાં પ્રોટોકોલ સપોર્ટ ઉમેરી શકતી નથી જેની પાસે તે નથી. આવૃત્તિ બેનરથી શરૂ કરો, જે કમ્પાઇલ થયેલી ક્રિપ્ટો લાઇબ્રેરીનું નામ આપે છે:

openvpn --version

OpenSSL સાથે લિંક થયેલું 2.6 બિલ્ડ tls-cipher અને tls-ciphersuites બંને સ્વીકારે છે. mbed TLS સાથેનું બિલ્ડ TLS 1.3 સ્યૂટ પસંદગી બિલકુલ ધરાવતું નથી, અને 2.6 મેન્યુઅલ tls-ciphersuites ને OpenSSL વિકલ્પ તરીકે ચિહ્નિત કરે છે. જો સર્વર બીજા બેકએન્ડ સાથે ફરી બનાવવામાં આવે, તો એ જ પ્રોફાઇલ કન્ફિગરેશનની એક પણ લીટી બદલ્યા વિના વર્તન બદલી શકે છે.

તમે અહીં હો ત્યારે openvpn --show-tls ચલાવો અને આઉટપુટ સાચવો. તે એ જ ઇન્વેન્ટરી છે જેની સાથે પછી સરખામણી કરશો, અને કોઈ પ્રોફાઇલ સંપાદિત કરવાનું શરૂ કરે તે પહેલાં તેને કેપ્ચર કરવું સસ્તું છે.

બેનર અને યાદી ચેટ વિન્ડોમાં નહીં, ફેરફાર ટિકિટમાં લખો. છ અઠવાડિયા પછી ક્લાયન્ટ સ્યૂટ આપી શકશે કે નહીં તે અંગે બે વ્યક્તિ દલીલ કરે ત્યારે, કેપ્ચર કરેલું આઉટપુટ એક લીટીમાં તે નક્કી કરે છે.

આવૃત્તિની મર્યાદાઓ સાઇફર યાદીઓથી અલગ રાખો

2.6 મેન્યુઅલમાં આ એક નહીં, ત્રણ નિયંત્રણો છે:

• tls-cipher TLS 1.2 અને પહેલાના માટે સાઇફર નીતિ નક્કી કરે છે અને OpenSSLની સાઇફર યાદીમાં મોકલાય છે;
• tls-ciphersuites TLS 1.3 સ્યૂટ પસંદ કરે છે;
• tls-version-min અને tls-version-max કનેક્શન વાપરી શકે તે પ્રોટોકોલ આવૃત્તિઓની મર્યાદા નક્કી કરે છે.

તેથી કાળજીપૂર્વક કાપેલી TLS 1.3 સ્યૂટ યાદી જૂની આવૃત્તિ હજી મંજૂર છે તે વિશે કંઈ સાબિત કરતી નથી. જો જરૂરિયાત «ફક્ત TLS 1.3» હોય, તો તેને આવૃત્તિની નીચી મર્યાદા ટકાવે છે, અને સ્યૂટ યાદી ફક્ત તે મર્યાદાની અંદર વિકલ્પો સાંકડા કરે છે:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

આ જોડી બે કામ કરે છે. એક લીટી કાઢી નાખવાથી બીજી તમે ધારો છો તેના કરતાં ઓછું લાગુ કરે છે, અને આખી તપાસ એ જ ભૂલ પકડવા માટે છે.

ડેટા ચેનલ ચોથું નિયંત્રણ છે. data-ciphers ટનલની અંદર સિમેટ્રિક સાઇફરની વાટાઘાટ કરે છે, અને તેનું પરિણામ કંટ્રોલ ચેનલની TLS આવૃત્તિ વિશે કંઈ કહેતું નથી. સેશન સારાંશમાં AES-256-GCM જોવું કોઈપણ દિશામાં TLS 1.3નો પુરાવો નથી.

show-tls ને સ્થાનિક ઇન્વેન્ટરી તરીકે વાંચો

--show-tls આ બાઇનરી સાથે લિંક થયેલી ક્રિપ્ટો લાઇબ્રેરી સપોર્ટ કરે તે સ્યૂટને પ્રાધાન્ય ક્રમમાં યાદી બનાવે છે. તે ગેટવેથી આવેલો અહેવાલ નથી. મેન્યુઅલ સ્પષ્ટ કહે છે કે યાદી સ્થાનિક લાઇબ્રેરીમાંથી આવે છે, એટલે કે OpenSSL 3.x ધરાવતું લેપટોપ અને જૂના બિલ્ડવાળું રાઉટર એક જ સર્વર સાથે વાત કરતાં અલગ યાદીઓ છાપશે.

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

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

ગેટવેને એવું પૂછો જેનો તે જવાબ આપી શકે

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

જો તમે તેને સંભાળતા નથી, તો ઓપરેટરને સપોર્ટેડ ક્લાયન્ટ આવશ્યકતાઓ અથવા મર્યાદિત સ્વીકૃતિ પરીક્ષણ માટે પૂછો. નકારાયેલ પ્રયાસ આપોઆપ નકારાયેલ સ્યૂટ નથી: આવૃત્તિની નીચી મર્યાદા, remote-cert-tls જેવી સર્ટિફિકેટ ઓળખ તપાસ, અથવા tls-auth અને tls-crypt વચ્ચેની અસંગતિ સ્યૂટ પસંદગી મહત્વની થાય તે પહેલાં આદાનપ્રદાન સમાપ્ત કરી શકે છે. ક્લાયન્ટની યાદી બદલતા પહેલાં સર્વરની ભૂલ વાંચો, કારણ કે «handshake failed» ચાર અલગ કારણોને આવરી લે છે અને તેમાંથી ફક્ત એક જ સાઇફર અસંગતિ છે.

VPN પોર્ટ પર openssl s_client તાકવાથી પણ પ્રશ્નનું પુનરુત્પાદન થતું નથી. કંટ્રોલ ચેનલ OpenVPNની પોતાની ફ્રેમિંગની અંદર ચાલે છે, તેથી કાચી TLS પ્રોબ બીજું કંઈક અપેક્ષા રાખતા પોર્ટ પર અલગ પ્રોટોકોલ ચકાસે છે. તેમાંથી કાઢેલો કોઈપણ નિષ્કર્ષ પ્રોબ વિશે છે, ટનલ વિશે નહીં.

બે પરિણામો નોંધો અને તેમને અલગ રાખો

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

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

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

આ ક્રમમાં તપાસો કરો. --version વડે બિલ્ડ અને બેકએન્ડની પુષ્ટિ કરો. કંઈપણ બદલતા પહેલાં --show-tls કેપ્ચર કરો. જરૂરી આવૃત્તિ નીચી મર્યાદા સ્યૂટ યાદીથી અલગ જણાવો. ચાલુ ઇન્સ્ટન્સની અસરકારક નીતિ તેના માલિક સાથે પુષ્ટિ કરો. એક મંજૂર સેશન અને, યોજના પરવાનગી આપે તો, જૂની આવૃત્તિ સાથેનો એક નકારાયેલ પ્રયાસ નિરીક્ષણ કરો. કંટ્રોલ ચેનલ અને ડેટા ચેનલના પરિણામો અલગ તારણો તરીકે નોંધો.

જો જરૂરી ક્લાયન્ટ નવી ન્યૂનતમ પૂરી કરી શકતું નથી, તો રોલઆઉટ પૂર્ણ દેખાય તે માટે અસંબંધિત સ્વીકૃતિ નિયમ ચૂપચાપ નીચો કરવાને બદલે તે સ્થળાંતર અથવા અપવાદનો નિર્ણય સ્પષ્ટ રીતે લો.