tls-auth key-direction: 0 અને 1 અલગ હોવા જોઈએ, મળતા નહીં
tls-auth સાથે બંને છેડાને વિરોધી દિશાઓ જોઈએ, 0 અને 1, અથવા બંનેએ સેટિંગ છોડી દેવું પડે. એ જ સંખ્યા નિષ્ફળ જાય છે, અને tls-crypt તેને ક્યારેય વાપરતું નથી.
ટનલની એક બાજુ નિયંત્રણ ચેનલને એવી કી સ્લોટથી સાઇન કરે છે જે બીજી બાજુ ક્યારેય ચકાસતી નથી, અને એક પણ પ્રમાણપત્ર બદલાય તે પહેલાં જ કનેક્શન પ્રમાણીકરણ ભૂલ સાથે મરી જાય છે. tls-auth ની દિશા-અસંગતિ આવી દેખાય છે, અને તે નિર્ધારક છે: એ જ બે ફાઇલો દરેક પ્રયાસે, દરેક નેટવર્કથી નિષ્ફળ જાય છે. લોગમાં તમે જે વિકલ્પ શોધો છો તેનું નામ નથી, તેથી લોકો કદી ન તૂટેલી કી ફરી બનાવે છે અને પ્રમાણપત્રો ફરી આપે છે. ઉકેલ એ છે કે બંને છેડાને પૂરક બનાવો, અથવા બંનેને દ્વિદિશ રાખો, ચકાસણી નબળી કરવી નહીં.
નિષ્ફળતા પ્રમાણપત્રો પહેલાં આવે છે
tls-auth સાથે બંને પીઅર એ જ શેર કરેલી કી રાખે છે અને દરેક તેમાંથી ઉત્પન્ન થતી બે સ્લોટમાંની એક વાપરે છે: એક સ્લોટ બહાર જતા નિયંત્રણ પેકેટ સાઇન કરે છે, બીજી આવતા પેકેટ ચકાસે છે. દિશા 0 અને દિશા 1 એ ભૂમિકાઓને ઊલટા ક્રમમાં સોંપે છે, તેથી HMAC ચકાસણીઓ મેળ ખાય તે માટે જોડી પૂરક હોવી જોઈએ. એક બાજુ સોંપણી ઊલટાય ત્યારે પ્રાપ્તકર્તા ખોટી સ્લોટમાં સહી શોધે છે અને પેકેટ નકારે છે. સત્ર ત્યાં જ પૂરું થાય છે, તેથી ભૂલ પેકેટ પ્રમાણીકરણની છે, પ્રમાણપત્ર સ્ટોર જે ઉત્પન્ન કરે તેની નહીં.
નિર્ધારકતા નિદાન માટે મહત્વની છે, કારણ કે સમય કે માર્ગની સમસ્યા અલગ નિશાન છોડે છે: અનિયમિત વિરામ, એક દિશાની નિષ્ફળતા, અથવા ફક્ત ચોક્કસ નેટવર્ક પર મરતું સત્ર. દિશા-અસંગતિ દર વખતે પ્રથમ હેન્ડશેકમાં નિષ્ફળ જાય છે, અને એ જ બે ફાઇલો ધરાવતા બીજા મશીન પર પણ એ જ રીતે નિષ્ફળ જાય છે. --verb 4 પર લોગ વાંચો અને છેલ્લી લાઇને બદલે પ્રથમ નકારાયેલ પેકેટ શોધો. જો એ નકાર પ્રમાણપત્રોની કોઈપણ અદલાબદલી પહેલાં થાય, તો શેર કરેલી કી અને તેની દિશા ચકાસવા લાયક બે વસ્તુઓ છે.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
સંખ્યા ક્યાં રહે છે
OpenVPN 2.6 મેન્યુઅલ દિશા માટે બે જગ્યાઓ દસ્તાવેજ કરે છે: કી અલગ ફાઇલમાં હોય ત્યારે tls-auth નો બીજો આર્ગ્યુમેન્ટ, અને કી પ્રોફાઇલમાં ઇનલાઇન હોય ત્યારે સ્વતંત્ર key-direction લાઇન. બંને એ જ મૂલ્ય સેટ કરે છે, તેથી પ્રોફાઇલે એક સ્વરૂપ કે બીજું વાપરવું જોઈએ, ક્યારેય બંને નહીં. છોડી દેવું પણ એક પસંદગી છે, અને તે બંને પીઅરને દ્વિદિશ ગોઠવણીમાં મૂકે છે જે ત્યારે કામ કરે છે જ્યારે કોઈ પણ બાજુ દિશા નામ ન આપે. એ જ સંખ્યા ધરાવતા બે પીઅર એ ગોઠવણીમાં નથી: દરેક એક સ્લોટમાં સાઇન અને બીજીમાં ચકાસણીની અપેક્ષા રાખે છે, અને બંને એ જ રીતે કરે છે.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
ઇનલાઇન સ્વરૂપ પોતાની લાઇન પરની નિર્દેશિકા છે, કી બ્લોકના ખૂલતા ટેગ પરનું એટ્રિબ્યુટ નહીં, અને એ ટેગમાં આર્ગ્યુમેન્ટ ઉમેરવો ભૂલ છે, દિશા-ફેરફાર નહીં. સ્થાન પણ મહત્વનું છે: નિર્દેશિકા જે બ્લોકની છે તેની બહાર રહે છે, તેથી બ્લોકની અંદર લખાયેલ મૂલ્ય કી સામગ્રી તરીકે વંચાય છે. પ્રોફાઇલના વિતરકે ઇચ્છેલી ગોઠવણી નકલ કરો, જોડી શોધી કાઢવાને બદલે, કારણ કે એક સર્વર સામે કામ કરતી પ્રોફાઇલ કદાચ બીજી બાજુ પહેલેથી પ્રતિબિંબિત હોય.
વિકલ્પ શું અસ્પર્શ રાખે છે
તે એપ્લિકેશન ટ્રાફિક એન્ક્રિપ્ટ કરતું નથી. tls-auth નિયંત્રણ ચેનલના પેકેટની આસપાસ HMAC મૂકે છે, જ્યારે ડેટા ચેનલ હેન્ડશેક દરમિયાન વાટાઘાટ થયેલી સત્ર કી દ્વારા સુરક્ષિત રહે છે, તેથી થ્રુપુટ કે સાઇફરનો પ્રશ્ન દિશા-સંખ્યા સાથે કોઈ સંબંધ ધરાવતો નથી. સેટિંગ બીજું એન્ક્રિપ્શન સ્તર પણ ઉમેરતું નથી, અને એ જ ધારણા લોકોને લાંબી કી શોધવા મોકલે છે.
તે tls-crypt પર લાગુ પડતું નથી, પોતાના વિકલ્પો અને કી-હેન્ડલિંગ સાથેની બીજી નિયંત્રણ ચેનલ પદ્ધતિ, અને તે કોઈ પણ પીઅરની પ્રમાણપત્ર ઓળખ વિશે કંઈ કહેતું નથી. તેથી કામ કરતી દિશા-સરખામણી ફક્ત એ સાબિત કરે છે કે બંને છેડા નિયંત્રણ ચેનલ કેવી રીતે પ્રમાણિત કરવી તે અંગે સહમત છે, વિશ્વાસ-શૃંખલા માન્ય થઈ છે તે નહીં.
જોડીને ગોઠવો, પછી ફરી જોડાઓ
કોઈ પણ બદલતા પહેલાં બંને રૂપરેખાંકનોની તુલના કરો, કારણ કે પહેલેથી સાચી બાજુને સંપાદિત કરવાથી કામ બમણું થાય છે. નીચેનું grep બતાવે છે કે દરેક ફાઇલ કઈ પદ્ધતિ પસંદ કરે છે; વિગતવાર રન બતાવે છે કે નિયંત્રણ ચેનલ પ્રમાણિત થઈ છે કે નહીં. બંને આઉટપુટ રાખો, જેથી આગળનો ફેરફાર જાણીતી સ્થિતિ સાથે સરખાવી શકાય.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
કોઈ પણ ફેરફાર પછી બંને પીઅર ફરી શરૂ કરો, કારણ કે આ વિકલ્પો શરૂઆતમાં એક વાર વંચાય છે અને એક બાજુ ફરી લોડ કરવાથી જૂના સત્રના આખા જીવનકાળ દરમિયાન જોડી અસંગત રહે છે. જો જમાવટ હાલમાં દિશા રૂપરેખાંકિત કર્યા વિના કામ કરે છે, તો એક પીઅર પર સેટિંગ ઉમેરવાથી તમે શરૂ કરેલી નિષ્ફળતા ફરી ઉત્પન્ન થાય છે; કાં તો બંનેને એમ જ રહેવા દો અથવા બંનેને રૂપરેખાંકિત કરો. એક સમયે એક છેડો બદલો અને અગાઉની ફાઇલ રાખો, જેથી રીગ્રેશન પુનઃનિર્માણ નહીં, બે મિનિટનું પુનઃસ્થાપન બને.
દરેક છેડા માટે પદ્ધતિ, કી ફાઇલ અને દિશા જમાવટની નોંધમાં લખો, નહીં તો આગળની વ્યક્તિ બે સમાન ફાઇલો વાંચશે અને ધારશે કે સંખ્યાઓ એકબીજા સાથે મેળ ખાવી જોઈએ. દિશા સંકલનની વિગત છે, સુરક્ષા સુધારો નહીં: તે નિયંત્રણ ચેનલની બે દિશાઓ અલગ કરે છે અને બીજું કંઈ કરતી નથી.