openssl rand શા માટે tls-crypt ને જોઈતી કી બનાવી શકતું નથી
OpenSSL રેન્ડમ બાઇટ ઉત્પન્ન કરે છે; tls-crypt ને રચનાબદ્ધ સ્ટેટિક કી ફાઇલની જરૂર છે, અને tls-crypt-v2 ને એવી કીની જરૂર છે જે ફક્ત સર્વર જ લપેટી શકે. openvpn --genkey વાપરો.
OpenSSL પહેલેથી ઇન્સ્ટોલ છે, હોસ્ટ પાસે એન્ટ્રોપી છે, અને તેની સાથે કી બનાવવી સ્પષ્ટ શોર્ટકટ લાગે છે. આઉટપુટ રેન્ડમ અને ગુપ્ત અને સંપૂર્ણ નકામું હશે, અને નિષ્ફળતા કી ફોર્મેટનો ઉલ્લેખ કરતી કોઈ વસ્તુને બદલે કંટ્રોલ-ચેનલ ભૂલ તરીકે આવશે. આ ભ્રમ ખર્ચાળ ભાગ છે, કારણ કે તે લોકોને તેમના સાઇફર તપાસવા મોકલે છે. VPN જે વાંચે છે તે ચોક્કસ ફાઇલ રચના છે, મનસ્વી બાઇટ બ્લોક નહીં, અને સુવિધાનો એક પ્રકાર સર્વરની બહાર બિલકુલ બનાવી શકાતો નથી.
ડિસ્ક પરની ફાઇલ ખરેખર શું હોવી જોઈએ
OpenVPN ની સ્ટેટિક કી ફાઇલ ટેક્સ્ટ છે. તે એક ટિપ્પણી લાઇનથી શરૂ થાય છે જે જણાવે છે કે તે શું છે, નિશ્ચિત પહોળાઈની હરોળમાં હેક્સ ડેટા ધરાવે છે, અને કુલ 256 બાઇટ કી સામગ્રી ધરાવે છે. OpenVPN તેને કંટ્રોલ ચેનલના શેર્ડ સિક્રેટ તરીકે વાંચે છે, પ્રમાણપત્ર તરીકે નહીં, પાસફ્રેઝ તરીકે નહીં અને TLS લાઇબ્રેરી ઓળખે એવી કોઈ વસ્તુ તરીકે નહીં.
એ જ પ્રકારની ઑબ્જેક્ટ કંટ્રોલ ચેનલની બંને સુવિધાઓ માટે કામ કરે છે. tls-auth સાથે, દરેક પીઅરને દિશા પણ જોઈએ જેથી એક બાજુના પેકેટ તેની તરફ પાછા પ્રતિબિંબિત ન થાય. tls-crypt સાથે, એક જ શેર્ડ સિક્રેટ બંને દિશામાં કંટ્રોલ ચેનલને એન્ક્રિપ્ટ અને પ્રમાણિત કરે છે, જે હેન્ડશેકને છુપાવે છે અને સાથે સાથે રક્ષણ આપે છે.
એમાંથી કંઈ ગુપ્ત જ્ઞાન નથી, અને ફોર્મેટ મુખ્ય મુદ્દો નથી. મુખ્ય મુદ્દો એ છે કે ફાઇલ વાચક જે ધારે છે તેની સાથે બરાબર મેળ ખાવી જોઈએ: હેડર, હરોળની પહોળાઈ, અંતિમ નવી લાઇન અને કુલ લંબાઈ. એક હરોળ જેટલી ખોટી ફાઇલ કચરા તરીકે લોડ થાય છે અથવા સંપૂર્ણ નિષ્ફળ જાય છે. તેથી બે પીઅરને બાઇટ-બાઇટ સરખાવવું કાયદેસર પ્રથમ કસોટી છે, અને તે બેમાંથી કોઈપણ કન્ફિગરેશન ફાઇલ વાંચવા કરતાં ઝડપી છે.
એક બનાવવાની સમર્થિત રીત
સાદી સ્ટેટિક કી તે સાધન વડે બનાવો જે તેનો ઉપયોગ કરશે, પછી બંને છેડેથી તેનો સંદર્ભ આપો:
openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key
વિકલ્પની જોડણી સમય સાથે બદલાઈ: 2.4 યુગની જૂની ઇન્સ્ટોલેશન ફાઇલનામ પહેલાં અલગ ફ્લેગવાળી રચના વાપરતી, જ્યારે વર્તમાન બિલ્ડ ટૂંકી રચના સ્વીકારે છે. કોઈપણ રીતે પરિણામી ફાઇલ એ જ પ્રકારની ઑબ્જેક્ટ છે, તેથી ચકાસણી એ છે કે બંને પીઅર પાસે સમાન બાઇટ છે કે નહીં.
બીજી પેઢી એવી રચના ઉમેરે છે જે કોઈ બાહ્ય જનરેટર શોધી શકતું નથી. સર્વર કી એક વાર બનાવાય છે, અને દરેક ક્લાયન્ટ તેમાંથી વ્યુત્પન્ન થયેલી લપેટાયેલી કી મેળવે છે:
openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key
ક્લાયન્ટ જે મેળવે છે તે સર્વરની પોતાની કીની નકલ નથી. તે એક લપેટાયેલી ઑબ્જેક્ટ છે જે એવા મેટાડેટા ધરાવે છે જે ફક્ત સર્વર જ ખોલી શકે, અને આ લપેટવાને કારણે જ એક ઉપકરણની ફાઇલ બીજા કોઈપણ ઉપકરણને સ્પર્શ કર્યા વિના રદ કરી શકાય છે. સર્વર કી સર્વર પર જ રાખો અને તેને તે ઉપકરણ-આધારિત વિશ્વાસના મૂળ તરીકે ગણો.
હાથે બનાવેલા બાઇટ ક્યાં તૂટી પડે છે
સાચા હેડર નીચે 256 રેન્ડમ બાઇટને હેક્સ તરીકે છાપવાથી સૈદ્ધાંતિક રીતે લોડ થતી સ્ટેટિક કી ફાઇલ મળે. તેમ છતાં તે ખરાબ વિચાર છે. દરેક ફોર્મેટિંગ વિગત એવી સામગ્રી બનાવવાની તક બને છે જે લોડ વખતે નિષ્ફળ જાય અથવા, ખરાબ રીતે, બે પીઅરને અલગ મૂલ્યો સાથે છોડી દે જે ફક્ત પ્રમાણીકરણ નિષ્ફળતા તરીકે જ પ્રગટ થાય.
v2 પ્રકાર સાથે સમકક્ષ કંઈ શક્ય નથી. લપેટાયેલી ક્લાયન્ટ કી ફક્ત સર્વર કી પ્રક્રિયાના આઉટપુટ તરીકે જ અસ્તિત્વમાં છે, અને સર્વર તેને ખોલવા માટે જરૂરી સામગ્રી રાખે છે. રેન્ડમ બ્લોક નકારાશે અથવા સરળ રીતે ડિક્રિપ્ટ કરવામાં નિષ્ફળ જશે, અને બંને સંદેશાઓમાંથી કોઈ રેન્ડમનેસનો ઉલ્લેખ કરશે નહીં.
આવૃત્તિ સુસંગતતા આ બધાની ઉપર બેસે છે. પ્રથમ પેઢીને બંને છેડે તેને સમર્થન આપતું પ્રકાશન જોઈએ, અને બીજીને ફરી નવું પ્રકાશન જોઈએ. સુવિધા અસ્તિત્વમાં આવે તે પહેલાં બનેલો ક્લાયન્ટ ફક્ત લપેટાયેલી સામગ્રી સ્વીકારતા સર્વર સાથે હેન્ડશેક પૂર્ણ કરી શકતો નથી, અને તે જે નિષ્ફળતા જણાવે છે તે આવૃત્તિ તરફ નહીં, કંટ્રોલ ચેનલ તરફ નિર્દેશ કરે છે.
બધાને બહાર લોક કર્યા વિના ફેરવવું
એક શેર્ડ સિક્રેટ ફેરવવું એ સંકલનની કસરત છે, તકનીકી નહીં. સર્વર અગાઉની પાછી ખેંચે તે પહેલાં દરેક ક્લાયન્ટ પાસે બદલીની ફાઇલ હાથમાં હોવી જોઈએ, અને જૂનું મૂલ્ય હજી ધરાવતું કોઈપણ મશીન તે ક્ષણે જ નિષ્ફળ જાય છે. કામકાજના દિવસની વચ્ચે આ ફેરવવાનું શરૂ કરશો નહીં.
v2 ગોઠવણી સાથે, ફેરવવું ઉપકરણ પ્રમાણે છે: એક મશીન માટે નવી લપેટાયેલી કી આપો અને જૂની ફક્ત તે મશીન માટે નિવૃત્ત કરો. દરેક ક્લાયન્ટ તેને સમર્થન આપતા પ્રકાશન પર હોય ત્યારે સ્થળાંતર માટેની મુખ્ય દલીલ એ છે.
ફાઇલ પરવાનગીઓ એ જ વાતચીતનો ભાગ છે. કી ફક્ત તે ખાતા માટે વાંચી શકાય તેવી હોવી જોઈએ જે સેવા ચલાવે છે, અને તે જે પ્રોફાઇલને સુરક્ષિત કરે છે તેમની સાથે એ જ રિપોઝિટરીમાં રહેવી જોઈએ નહીં. OpenVPN 2.6 સંદર્ભ બનાવવાના સ્વરૂપો અને કી-સામગ્રી વિભાગોનું દસ્તાવેજીકરણ કરે છે, જે ફોરમ પોસ્ટમાંથી કોપી કરેલી આદેશ કરતાં વધુ સારો સ્રોત છે.