tls-auth key-direction: 0 in 1 se morata razlikovati, ne ujemati
Pri tls-auth potrebujeta oba konca nasprotni smeri, 0 in 1, ali morata oba izpustiti nastavitev. Isto število spodleti, tls-crypt pa ga nikoli ne uporabi.
Ena stran tunela podpiše krmilni kanal z režo ključa, ki je druga stran nikoli ne preveri, in povezava umre z napako overjanja, preden se izmenja en sam certifikat. Tako izgleda neskladje smeri pri tls-auth in je deterministično: isti dve datoteki spodletita pri vsakem poskusu, iz katerega koli omrežja. Nič v dnevniku ne poimenuje možnosti, ki jo iščete, zato ljudje znova gradijo ključe in znova izdajajo certifikate, ki nikoli niso bili pokvarjeni. Rešitev je, da naredite oba konca komplementarna ali pustite oba dvosmerna, ne pa da oslabite preverjanje.
Napaka se zgodi pred certifikati
Pri tls-auth imata oba partnerja isti skupni ključ in vsak uporabi eno od dveh rež, izpeljanih iz njega: ena reža podpiše odhodne krmilne pakete, druga preveri dohodne. Smer 0 in smer 1 dodelita ti vlogi v obratnem vrstnem redu, zato mora biti par komplementaren, da se preverjanja HMAC ujemajo. Ko se dodelitev na eni strani obrne, prejemnik išče podpis v napačni reži in paket zavrne. Seja se tam konča, zato se napaka nanaša na overjanje paketov, ne na kaj, kar bi ustvarilo shrambo certifikatov.
Determinizem je pomemben za diagnostiko, ker težava s časom ali potjo pusti drugačno sled: občasne prekinitve, odpoved ene smeri ali seja, ki umre le v določenem omrežju. Neskladje smeri spodleti pri prvem rokovanju vsakič in spodleti enako na drugem stroju z istima dvema datotekama. Berite dnevnik pri --verb 4 in poiščite prvi zavrnjeni paket namesto zadnje vrstice. Če se ta zavrnitev zgodi pred kakršno koli izmenjavo certifikatov, sta skupni ključ in njegova smer tisti dve stvari, ki jih je vredno preveriti.
| 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 |
Kje živi število
Priročnik OpenVPN 2.6 dokumentira dve mesti za smer: drugi argument tls-auth, ko je ključ v svoji datoteki, in samostojno vrstico key-direction, ko je ključ vdelan v profil. Oba nastavita isto vrednost, zato naj profil uporabi eno obliko ali drugo, nikoli obeh. Izpustitev je tudi izbira in oba partnerja postavi v dvosmerno razporeditev, ki deluje, ko nobena stran ne navede smeri. Dva partnerja z isto številko nista v tej razporeditvi: vsak pričakuje podpisovanje v eni reži in preverjanje v drugi, in oba to počneta enako.
# 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
Vdelana oblika je direktiva v svoji vrstici, ne atribut na začetni oznaki bloka ključa, in dodajanje argumenta tej oznaki je napaka, ne sprememba smeri. Pomembna je tudi postavitev: direktiva stoji zunaj bloka, ki mu pripada, zato se vrednost, zapisana znotraj bloka, bere kot ključno gradivo. Kopirajte razporeditev, ki jo je predvidel distributer profila, namesto da bi si izmislili par, ker je profil, ki deluje proti enemu strežniku, morda že zrcaljen na drugi strani.
Česa se možnost ne dotakne
Ne šifrira prometa aplikacij. tls-auth postavi HMAC okoli paketov krmilnega kanala, medtem ko podatkovni kanal ščitijo sejni ključi, dogovorjeni med rokovanjem, zato vprašanje prepustnosti ali šifre nima nič skupnega s številko smeri. Nastavitev ne doda drugega sloja šifriranja, in prav ta predpostavka pošilja ljudi iskat daljši ključ.
Ne velja za tls-crypt, drug mehanizem krmilnega kanala z lastnimi možnostmi in ravnanjem s ključi, in ne pove ničesar o identiteti certifikata katerega koli partnerja. Delujoče ujemanje smeri torej dokaže le, da se oba konca strinjata, kako overiti krmilni kanal, ne pa da je bila veriga zaupanja potrjena.
Poravnajte par in se znova povežite
Primerjajte obe konfiguraciji, preden katero spremenite, ker urejanje strani, ki je bila že pravilna, podvoji delo. Spodnji grep pokaže, kateri mehanizem izbere vsaka datoteka; podroben zagon pokaže, ali je bil krmilni kanal sploh overjen. Shranite oba izhoda, da bo naslednjo spremembo mogoče primerjati z znanim stanjem.
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'
Po vsaki spremembi znova zaženite oba partnerja, ker se te možnosti preberejo enkrat ob zagonu in ponovno nalaganje ene strani pusti par nedosleden za ves čas življenja stare seje. Če nameščanje zdaj deluje brez nastavljene smeri, dodajanje nastavitve na enega partnerja poustvari napako, s katero ste začeli; bodisi pustite oba bodisi nastavite oba. Spreminjajte en konec naenkrat in shranite prejšnjo datoteko, da bo regresija dvominutna vrnitev in ne ponovna gradnja.
Zapišite mehanizem, ključno datoteko in smer za vsak konec v opombe o nameščanju, ker bo sicer naslednja oseba prebrala dve podobni datoteki in domnevala, da se morata števili ujemati. Smer je podrobnost usklajevanja, ne varnostna nadgradnja: ločuje dve smeri krmilnega kanala in ne naredi ničesar drugega.