tls-auth key-direction: 0 kaj 1 devas malsami, ne sami
Ĉe tls-auth la du flankoj bezonas kontraŭajn direktojn, 0 kaj 1, aŭ ambaŭ devas forlasi la agordon. La sama nombro malsukcesas, kaj tls-crypt neniam uzas ĝin.
Unu flanko de la tunelo subskribas la kontrolkanalon per ŝlosilfendo, kiun la alia flanko neniam kontrolas, kaj la konekto mortas per aŭtentiga eraro antaŭ ol eĉ unu atestilo estas interŝanĝita. Tiel aspektas direkta miskongruo ĉe tls-auth, kaj ĝi estas determinisma: la samaj du dosieroj malsukcesas ĉe ĉiu provo, el ĉiu reto. Nenio en la protokolo nomas la opcion, kiun vi serĉas, tial homoj rekonstruas ŝlosilojn kaj reeldonas atestilojn, kiuj neniam estis difektitaj. La solvo estas igi la du flankojn komplementaj aŭ lasi ambaŭ dudirektaj, anstataŭ malfortigi la kontrolon.
La fiasko okazas antaŭ la atestiloj
Ĉe tls-auth ambaŭ partneroj tenas la saman komunan ŝlosilon kaj ĉiu uzas unu el du fendoj derivitaj el ĝi: unu fendo subskribas elirantajn kontrolpakaĵojn, la alia kontrolas enirantajn. Direkto 0 kaj direkto 1 atribuas tiujn rolojn en kontraŭa ordo, do la paro devas esti komplementa por ke la HMAC-kontroloj kongruu. Kiam la atribuo inversiĝas ĉe unu flanko, la ricevanto serĉas subskribon en la malĝusta fendo kaj rifuzas la pakaĵon. La sesio finiĝas tie, tial la eraro koncernas pakaĵan aŭtentigon kaj ne ion, kion produktus la atestila konservejo.
La determinismo gravas por diagnozo, ĉar tempo- aŭ vojproblemo lasas alian spuron: intermitaj interrompoj, unu direkto malsukcesanta, aŭ sesio mortanta nur en aparta reto. Direkta miskongruo malsukcesas ĉe la unua manpremo ĉiufoje, kaj ĝi malsukcesas idente sur alia maŝino kun la samaj du dosieroj. Legu la protokolon ĉe --verb 4 kaj trovu la unuan rifuzitan pakaĵon anstataŭ la lastan linion. Se tiu rifuzo okazas antaŭ iu ajn atestila interŝanĝo, la komuna ŝlosilo kaj ĝia direkto estas la du aferoj indaj je kontrolo.
| 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 |
Kie loĝas la nombro
La manlibro de OpenVPN 2.6 dokumentas du lokojn por la direkto: la dua argumento de tls-auth, kiam la ŝlosilo estas en propra dosiero, kaj memstara linio key-direction, kiam la ŝlosilo estas enmetita en la profilon. Ambaŭ starigas la saman valoron, do profilo uzu unu formon aŭ la alian, neniam ambaŭ. Forlaso ankaŭ estas elekto, kaj ĝi metas ambaŭ partnerojn en dudirektan aranĝon, kiu funkcias kiam neniu flanko nomas direkton. Du partneroj kun la sama nombro ne estas en tiu aranĝo: ĉiu atendas subskribi en unu fendo kaj kontroli en la alia, kaj ambaŭ faras tion same.
# 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
La enmetita formo estas direktivo sur propra linio, ne atributo sur la malferma etikedo de la ŝlosilbloko, kaj aldoni argumenton al tiu etikedo estas eraro, ne direkta ŝanĝo. Ankaŭ la loko gravas: la direktivo staras ekster la bloko, al kiu ĝi apartenas, do valoro skribita ene de la bloko estas legata kiel ŝlosilmaterialo. Kopiu la aranĝon, kiun la distribuanto de la profilo intencis, anstataŭ elpensi paron, ĉar profilo, kiu funkcias kontraŭ unu servilo, eble jam estas spegulita aliflanke.
Kion la opcio lasas netuŝita
Ĝi ne ĉifras aplikaĵtrafikon. tls-auth metas HMAC ĉirkaŭ la pakaĵojn de la kontrolkanalo, dum la datenkanalo estas protektata per sesiaj ŝlosiloj intertraktitaj dum la manpremo, do demando pri trairo aŭ ĉifro neniel rilatas al la direkta nombro. La agordo ankaŭ ne aldonas duan ĉifrotavolon, kaj ĝuste tiu supozo sendas homojn serĉi pli longan ŝlosilon.
Ĝi ne aplikiĝas al tls-crypt, alia kontrolkanala mekanismo kun propraj opcioj kaj ŝlosiltraktado, kaj ĝi diras nenion pri la atestila identeco de iu partnero. Do funkcianta direkta kongruo pruvas nur, ke la du flankoj konsentas pri kiel aŭtentigi la kontrolkanalon, ne ke la fidoĉeno estis validigita.
Ĝustigu la paron, poste rekonektu
Komparu la du agordojn antaŭ ol ŝanĝi iun ajn, ĉar redakti la flankon, kiu jam estis ĝusta, duobligas la laboron. La suba grep montras, kiun mekanismon ĉiu dosiero elektas; la detala rulo montras, ĉu la kontrolkanalo entute aŭtentiĝis. Konservu ambaŭ eligojn, por ke la sekva ŝanĝo kompareblu kun konata stato.
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'
Restartigu ambaŭ partnerojn post iu ajn ŝanĝo, ĉar ĉi tiuj opcioj estas legataj unufoje ĉe starto, kaj reŝargi unu flankon lasas la paron nekonsekvenca por la tuta vivo de la malnova sesio. Se la deplojo nun funkcias sen agordita direkto, aldoni la agordon al unu partnero reproduktas la fiaskon, kun kiu vi komencis; aŭ lasu ambaŭ aŭ agordu ambaŭ. Ŝanĝu unu finaĵon samtempe kaj konservu la antaŭan dosieron, por ke regreso estu du-minuta restarigo anstataŭ rekonstruo.
Notu la mekanismon, la ŝlosildosieron kaj la direkton por ĉiu finaĵo en la deplojnotoj, ĉar alie la sekva persono legos du similajn dosierojn kaj supozos, ke la nombroj devas kongrui unu kun la alia. La direkto estas kunordiga detalo, ne sekureca plibonigo: ĝi apartigas la du direktojn de la kontrolkanalo kaj faras nenion alian.