tls-auth key-direction: 0 at 1 ay dapat magkaiba, hindi magtugma
Sa tls-auth kailangan ng magkabilang dulo ng magkasalungat na direksyon, 0 at 1, o dapat parehong alisin ang setting. Nabigo ang parehong numero, at hindi ito ginagamit ng tls-crypt.
Ang isang gilid ng tunnel ay pumipirma sa control channel gamit ang isang key slot na hindi kailanman sinusuri ng kabilang gilid, at namamatay ang koneksyon sa isang authentication error bago pa man mapalitan ang kahit isang certificate. Ganyan ang hitsura ng hindi pagkakatugma ng direksyon sa tls-auth, at ito ay deterministiko: ang parehong dalawang file ay nabigo sa bawat pagtatangka, mula sa anumang network. Walang anumang bagay sa log ang nagngangalan sa opsyon na hinahanap mo, kaya muling binubuo ng mga tao ang mga key at muling naglalabas ng mga certificate na hindi naman nasira. Ang solusyon ay gawing komplementaryo ang dalawang dulo, o hayaang parehong bidirectional, hindi ang pagpapahina ng verification.
Nangyayari ang pagkabigo bago ang mga certificate
Sa tls-auth, hawak ng dalawang peer ang parehong shared key at gumagamit ang bawat isa ng isa sa dalawang slot na hinango mula rito: ang isang slot ay pumipirma sa mga papalabas na control packet, ang isa ay nagbe-verify ng mga papasok. Itinatakda ng direksyon 0 at direksyon 1 ang mga tungkuling iyon sa kabaligtarang pagkakasunod-sunod, kaya dapat komplementaryo ang pares upang magtugma ang mga HMAC check. Kapag binaligtad ang pagtatalaga sa isang gilid, naghahanap ang receiver ng pirma sa maling slot at tinatanggihan ang packet. Nagtatapos doon ang session, kaya tungkol sa authentication ng packet ang error at hindi sa anumang gagawin ng certificate store.
Mahalaga ang determinismo sa diagnosis, dahil ang problema sa oras o ruta ay nag-iiwan ng ibang bakas: pabagu-bagong pagkaputol, isang direksyong nabigo, o session na namamatay lamang sa isang partikular na network. Nabigo ang hindi pagkakatugma ng direksyon sa unang handshake tuwing ginagawa, at nabigo ito nang pareho sa ibang makina na may parehong dalawang file. Basahin ang log sa --verb 4 at hanapin ang unang tinanggihang packet sa halip na ang huling linya. Kung nangyari ang pagtanggi na iyon bago ang anumang pagpapalitan ng certificate, ang shared key at ang direksyon nito ang dalawang bagay na sulit suriin.
| 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 |
Saan nakatira ang numero
Itinatala ng manual ng OpenVPN 2.6 ang dalawang lugar para sa direksyon: ang ikalawang argumento ng tls-auth kapag nasa sariling file ang key, at isang hiwalay na linyang key-direction kapag naka-inline ang key sa profile. Pareho nilang itinatakda ang parehong halaga, kaya dapat gumamit ang profile ng isang anyo o ng isa pa, hindi kailanman pareho. Ang pag-alis ay isa ring pagpipilian, at inilalagay nito ang dalawang peer sa isang bidirectional na kaayusan na gumagana kapag walang panig na nagngangalan ng direksyon. Ang dalawang peer na may parehong numero ay wala sa kaayusang iyon: inaasahan ng bawat isa na pumirma sa isang slot at mag-verify sa isa pa, at pareho silang gumagawa nito sa parehong paraan.
# 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
Ang naka-inline na anyo ay isang direktiba sa sarili nitong linya, hindi isang attribute sa pambungad na tag ng key block, at ang pagdaragdag ng argumento sa tag na iyon ay isang error, hindi pagbabago ng direksyon. Mahalaga rin ang pagkakalagay: nasa labas ng block na kinabibilangan nito ang direktiba, kaya ang halagang nakasulat sa loob ng block ay binabasa bilang key material. Kopyahin ang kaayusang inilaan ng distributor ng profile sa halip na mag-imbento ng pares, dahil ang profile na gumagana laban sa isang server ay maaaring nakasalamin na sa kabilang panig.
Ano ang hindi ginagalaw ng opsyon
Hindi nito ini-encrypt ang trapiko ng application. Naglalagay ang tls-auth ng HMAC sa paligid ng mga packet ng control channel, habang ang data channel ay pinoprotektahan ng mga session key na napagkasunduan sa handshake, kaya walang kinalaman ang tanong tungkol sa throughput o cipher sa numero ng direksyon. Hindi rin nagdaragdag ng pangalawang layer ng encryption ang setting, at iyon ang palagay na nagpapadala sa mga tao upang maghanap ng mas mahabang key.
Hindi ito nalalapat sa tls-crypt, isang ibang mekanismo ng control channel na may sariling mga opsyon at paghawak ng key, at wala itong sinasabi tungkol sa pagkakakilanlan ng certificate ng alinmang peer. Kaya ang gumaganang pagkakatugma ng direksyon ay nagpapatunay lamang na nagkasundo ang dalawang dulo kung paano i-authenticate ang control channel, hindi na na-validate ang chain of trust.
Ihanay ang pares, pagkatapos ay kumonekta muli
Ihambing ang dalawang configuration bago baguhin ang alinman, dahil ang pag-edit sa panig na tama na ay nagdodoble ng trabaho. Ipinapakita ng grep sa ibaba kung aling mekanismo ang pinipili ng bawat file; ipinapakita ng detalyadong pagpapatakbo kung na-authenticate man ang control channel. Itago ang parehong output, upang maihambing ang susunod na pagbabago sa isang kilalang estado.
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'
I-restart ang dalawang peer pagkatapos ng anumang pagbabago, dahil ang mga opsyong ito ay binabasa nang isang beses sa pag-start at ang muling pag-load ng isang panig ay nag-iiwan sa pares na hindi konsistente sa buong buhay ng lumang session. Kung gumagana ngayon ang deployment nang walang naka-configure na direksyon, ang pagdaragdag ng setting sa isang peer ay muling gumagawa ng pagkabigong sinimulan mo; hayaan ang pareho o i-configure ang pareho. Baguhin ang isang dulo sa isang pagkakataon at itago ang nakaraang file, upang ang regression ay dalawang minutong pag-urong at hindi muling pagbuo.
Itala ang mekanismo, ang key file at ang direksyon para sa bawat dulo sa mga tala ng deployment, dahil kung hindi ay babasahin ng susunod na tao ang dalawang magkatulad na file at ipagpapalagay na dapat magtugma ang mga numero. Ang direksyon ay isang detalye ng koordinasyon, hindi isang pagpapabuti ng seguridad: hinihiwalay nito ang dalawang direksyon ng control channel at wala nang iba pang ginagawa.