tls-auth key-direction: 0 en 1 moet verskil, nie ooreenstem nie
Met tls-auth moet die twee kante teenoorgestelde rigtings hê, 0 en 1, of albei moet die instelling weglaat. Dieselfde nommer misluk, en tls-crypt gebruik dit nooit.
Een kant van die tonnel onderteken die beheerkanaal met 'n sleutelgleuf wat die ander kant nooit nagaan nie, en die verbinding sterf met 'n verifikasiefout voordat 'n enkele sertifikaat uitgeruil is. Dit is hoe 'n rigtingbotsing by tls-auth lyk, en dit is deterministies: dieselfde twee lêers misluk by elke poging, vanaf elke netwerk. Niks in die log noem die opsie waarna jy soek nie, en daarom bou mense sleutels oor en heruitreik sertifikate wat nooit stukkend was nie. Die oplossing is om die twee kante aanvullend te maak, of om albei tweerigting te laat, eerder as om verifikasie te verswak.
Die fout kom voor die sertifikate
Met tls-auth hou albei eweknieë dieselfde gedeelde sleutel, en elkeen gebruik een van twee gleuwe wat daaruit afgelei word: een gleuf onderteken uitgaande beheerpakette, die ander verifieer inkomende. Rigting 0 en rigting 1 wys daardie rolle in teenoorgestelde volgorde toe, so die paar moet aanvullend wees sodat die HMAC-kontroles ooreenstem. Wanneer die toewysing aan een kant omgekeer is, soek die ontvanger 'n handtekening in die verkeerde gleuf en verwerp die pakket. Die sessie eindig daar, en daarom gaan die fout oor pakketverifikasie eerder as oor iets wat die sertifikaatstoor sou produseer.
Die determinisme is belangrik vir diagnose, want 'n tyds- of padprobleem laat 'n ander prentjie: ongereelde onderbrekings, een rigting wat misluk, of 'n sessie wat net op 'n bepaalde netwerk sterf. 'n Rigtingbotsing misluk elke keer by die eerste handdruk, en dit misluk identies op 'n ander masjien met dieselfde twee lêers. Lees die log met --verb 4 en vind die eerste verwerpte pakket eerder as die laaste reël. As daardie verwerping voor enige sertifikaatuitruiling gebeur, is die gedeelde sleutel en sy rigting die twee dinge wat die moeite werd is om na te gaan.
| 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 |
Waar die nommer sit
Die OpenVPN 2.6-handleiding dokumenteer twee plekke vir die rigting: die tweede argument van tls-auth wanneer die sleutel in 'n eie lêer sit, en 'n losstaande key-direction-reël wanneer die sleutel in die profiel ingebed is. Albei stel dieselfde waarde, so 'n profiel moet een vorm of die ander gebruik, nooit albei nie. Weglating is ook 'n keuse, en dit plaas albei eweknieë in 'n tweerigtingreëling wat werk wanneer geen kant 'n rigting noem nie. Twee eweknieë met dieselfde nommer is nie in daardie reëling nie: elkeen verwag om in een gleuf te onderteken en in die ander te verifieer, en albei doen dit op dieselfde manier.
# 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
Die ingebedde vorm is 'n riglyn op sy eie reël, nie 'n eienskap op die openingstag van die sleutelblok nie, en om 'n argument by daardie tag te voeg is 'n fout eerder as 'n rigtingsverandering. Plasing maak ook saak: die riglyn sit buite die blok waaraan dit behoort, so 'n waarde wat binne die blok geskryf is, word as sleutelmateriaal gelees. Kopieer die reëling wat die profiel se verspreider bedoel het in plaas daarvan om 'n paring te bedink, want 'n profiel wat teen een bediener werk, is dalk al aan die ander kant gespieël.
Wat die opsie ongemoeid laat
Dit versleutel nie toepassingsverkeer nie. tls-auth plaas 'n HMAC om beheerkanaalpakette, terwyl die datakanaal beskerm word deur sessiesleutels wat tydens die handdruk onderhandel word, so 'n vraag oor deurset of syfer het niks met die rigtingsnommer te doen nie. Die instelling voeg ook geen tweede versleutelingslaag by nie, en dit is die aanname wat mense 'n langer sleutel laat soek.
Dit is nie van toepassing op tls-crypt nie, 'n ander beheerkanaalmeganisme met sy eie opsies en sleutelhantering, en dit sê niks oor enige eweknie se sertifikaatidentiteit nie. 'n Werkende rigtingooreenstemming bewys dus net dat albei kante saamstem oor hoe om die beheerkanaal te verifieer, nie dat die vertroueketting gevalideer is nie.
Belyn die paar en herverbind
Vergelyk die twee konfigurasies voordat jy enigeen verander, want om die kant te wysig wat al korrek was, verdubbel die werk. Die grep hieronder wys watter meganisme elke lêer kies; die uitvoerige lopie wys of die beheerkanaal hoegenaamd verifieer het. Hou albei uitsette, sodat die volgende verandering teen 'n bekende toestand vergelyk kan word.
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'
Herbegin albei eweknieë ná enige verandering, want hierdie opsies word een keer by die opstart gelees, en om een kant te herlaai laat die paar inkonsekwent vir die lewe van die ou sessie. As die ontplooiing tans werk sonder 'n gekonfigureerde rigting, reproduseer die toevoeging van die instelling aan een eweknie die fout waarmee jy begin het; laat albei alleen of konfigureer albei. Verander een kant op 'n slag en hou die vorige lêer, sodat 'n regressie 'n terugdraai van twee minute is eerder as 'n herbou.
Teken die meganisme, die sleutellêer en die rigting vir elke kant in die ontplooiingsnotas aan, want anders sal die volgende persoon twee soortgelyke lêers lees en aanneem die nommers moet met mekaar ooreenstem. Die rigting is 'n koördineringsdetail, nie 'n sekuriteitsopgradering nie: dit skei die twee rigtings van die beheerkanaal en doen niks anders nie.