SECLEVEL=0 લક્ષણ મટાડે છે, પ્રમાણપત્ર નહીં

OpenVPN કનેક્શન નિષ્ફળ જાય છે, કોઈને એક લીટીનો ઉપાય મળે છે જે SECLEVEL=0 ઉમેરે છે, અને ટનલ ઊપર આવે છે. બદલાયું તે પ્રમાણપત્ર નહોતું અને સાઇફર સ્યૂટ પણ નહોતું; લાઇબ્રેરી-વ્યાપી સ્વીકૃતિ મર્યાદા ખસી ગઈ, અને પ્રક્રિયા પછી જે કંઈ કરે છે તે બધું નવી સીમા વારસામાં લે છે. એ જ લીટી આખા પર્યાવરણની દરેક પ્રોફાઇલમાં નકલ થાય તે પહેલાં આ સમજવા જેવું છે.

કઈ લાઇબ્રેરી અને કઈ નીતિ અમલમાં છે તે નક્કી કરો

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

openvpn --version | head -3
openssl version -a

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

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

નકારી શકાય તેવી ત્રણ વસ્તુઓ અલગ કરો

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

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

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

ઇનપુટ બદલો, મર્યાદા નહીં

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

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

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

જો ઘટાડવું જ પડે, તો મર્યાદિત કરો અને નોંધો

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

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

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

પછી ઓળખ અને સુરક્ષા ચકાસો

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

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

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

ઓડિટમાંથી પસાર થતું હસ્તાંતરણ કહે છે કે કઈ નીતિએ કયું ઇનપુટ નકાર્યું, શું બદલાયું, અને પરિણામે શું સ્વીકાર્ય રહે છે. “તે SECLEVEL=0 સાથે કામ કરે છે” એ એક કનેક્શન વિશેનું અવલોકન છે, તૈનાતીનું સુરક્ષા મૂલ્યાંકન નહીં.