DH ફાઇલ કે tls-auth કી? બે OpenVPN ફાઇલોને અલગ પાડવી

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

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

ફાઇલના નામ પહેલાં લેબલ વાંચો

ફાઇલની પ્રથમ લાઇન તેના નામ કરતાં વધુ માહિતી આપે છે, કારણ કે નામ માનવીય પ્રથા છે અને લેબલ સાધન દ્વારા બને છે. Diffie-Hellman પેરામીટર BEGIN DH PARAMETERS નું PEM લેબલ ધરાવે છે. OpenVPN સ્થિર કી સંપૂર્ણ ભિન્ન રચના છે, તેનું પોતાનું હેડર અને હેક્સ પેલોડ છે.

નામ બદલવાથી કંઈ રૂપાંતરિત થતું નથી. ta.key નામની પેરામીટર ફાઇલ હજી પેરામીટર છે, અને dh.pem નામની સ્થિર કી હજી સ્થિર કી છે; પાર્સર સામગ્રી વાંચે છે અને અસંગતિ નકારે છે. પ્રોફાઇલ સંપાદિત કરતાં પહેલાં તપાસો:

head -n 1 dh.pem
head -n 1 ta.key

કઈ ફાઇલ જોઈએ તે નક્કી કરતી ત્રણ શરતો

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

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

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

દરેક ભૂમિકા માટે યોગ્ય સામગ્રી બનાવો

સૂચના જે ફોર્મેટની અપેક્ષા રાખે તે ઉત્પન્ન કરતું સાધન વાપરો, તેમની વચ્ચે રૂપાંતર કરવાને બદલે. OpenVPN 2.6 પરની વહેંચાયેલ કી માટે જનરેટરનું ટાઇપ કરેલું સ્વરૂપ હેતુ સ્પષ્ટ રીતે જણાવે છે.

openvpn --genkey tls-auth ta.key

તે આદેશ નવી ગુપ્ત સામગ્રી બનાવે છે; તે હાલની કી સુધારતો નથી કે તપાસતો નથી, અને ફરી ચલાવવાથી તમને ભિન્ન કી મળે છે જે અન્ય પક્ષો પાસે નથી. પરિણામી ફાઇલને જે પક્ષોને જરૂર છે તેમને એવી ચેનલ દ્વારા કૉપિ કરો જે તમે કોઈપણ વહેંચાયેલ ગુપ્ત માહિતી માટે વાપરતા હો, અને દિશા-પ્રથા સુસંગત રાખો: tls-auth સાથે એક બાજુ key-direction 0 અને બીજી key-direction 1 વાપરે છે.

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

dh none શું કરે છે અને શું નહીં

dh none સંકુચિત અર્થની વાસ્તવિક સૂચના છે: કોઈ મર્યાદિત-ક્ષેત્ર પેરામીટર ફાઇલ લોડ થશે નહીં, કારણ કે હેન્ડશેક લંબગોળ વક્રની Diffie-Hellman વાપરે છે. તે કંઈક નબળું કરવાના અર્થમાં “DH પગલું છોડી દો” માટેનું ટૂંકું સ્વરૂપ નથી, અને તે ચોક્કસપણે OpenVPNને બીજી કોઈ ફાઇલ વિકલ્પ તરીકે સ્વીકારવા કહેતું નથી.

ખોટી રીતે વાંચવાથી બે ભૂલો થાય છે. પ્રથમ એ ધારવું કે dh none tls-auth ની જરૂર દૂર કરે છે, જ્યારે બંને ભિન્ન વસ્તુઓ નિયંત્રિત કરે છે. બીજું એ કે ફક્ત-વક્ર ગોઠવણીની બાજુમાં જૂની dh લાઇન રાખવી અને પછી વિચારવું કે સર્વર ખરેખર કઈ ફાઇલ વાપરે છે; જો સૂચના હાજર હોય તો ફાઇલ વાંચવામાં આવે છે, અને ત્યાંનો તૂટેલો પાથ વાટાઘાટ થનારા એક્સચેન્જ સાથે સંબંધ ન ધરાવતા કારણે સ્ટાર્ટઅપ નિષ્ફળ કરે છે.

જો ખોટી ફાઇલ પહેલેથી ડિપ્લોય થઈ હોય

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

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

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