tls-auth key-direction: 0 og 1 må vere ulike, ikkje like
Med tls-auth treng begge endar motsette retningar, 0 og 1, eller begge må utelate innstillinga. Same tal feilar, og tls-crypt brukar det aldri.
Den eine sida av tunnelen signerer kontrollkanalen med ein nøkkelslott som den andre sida aldri sjekkar, og sambandet døyr med ein autentiseringsfeil før eitt einaste sertifikat er bytt. Slik ser ein retningskonflikt med tls-auth ut, og han er deterministisk: dei same to filene feilar ved kvart forsøk, frå kvart nettverk. Ingenting i loggen nemner innstillinga du leitar etter, og difor byggjer folk nøklar på nytt og gjev ut sertifikat på nytt som aldri var øydelagde. Løysinga er å gjere dei to endane komplementære eller la begge vere tovegs, i staden for å svekkje verifiseringa.
Feilen skjer før sertifikata
Med tls-auth har begge partar den same delte nøkkelen, og kvar brukar ein av to slottar som er leidde ut frå han: den eine sloten signerer utgåande kontrollpakkar, den andre verifiserer innkomande. Retning 0 og retning 1 tildeler desse rollene i omvend rekkjefølgje, så paret må vere komplementært for at HMAC-kontrollane skal stemme. Når tildelinga blir snudd på den eine sida, leitar mottakaren etter ein signatur i feil slott og avviser pakken. Sesjonen sluttar der, og difor handlar feilen om pakkeautentisering og ikkje om noko sertifikatlageret ville produsere.
Determinismen er viktig for diagnostikk, fordi eit tids- eller ruteproblem etterlèt eit anna spor: uregelmessige avbrot, éin retning som feilar, eller ein sesjon som berre døyr på eit bestemt nettverk. Ein retningskonflikt feilar ved den første handtrykket kvar gong, og han feilar identisk på ein annan maskin med dei same to filene. Les loggen ved --verb 4 og finn den første avviste pakken i staden for den siste linja. Viss den avvisinga skjer før noka sertifikatutveksling, er den delte nøkkelen og retninga hans dei to tinga som er verd å sjekke.
| 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 |
Kvar talet bur
Manualen for OpenVPN 2.6 dokumenterer to stader for retninga: det andre argumentet til tls-auth når nøkkelen ligg i si eiga fil, og ei sjølvstendig key-direction-linje når nøkkelen er innebygd i profilen. Begge set same verdi, så ein profil bør bruke den eine forma eller den andre, aldri begge. Utelating er også eit val, og det set begge partar i eit tovegsoppsett som verkar når ingen av sidene oppgjev ei retning. To partar med same tal er ikkje i det oppsettet: kvar ventar å signere i den eine sloten og verifisere i den andre, og begge gjer det på same måte.
# 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
Den innebygde forma er eit direktiv på si eiga linje, ikkje eit attributt på opningstaggen i nøkkelblokka, og å leggje til eit argument på den taggen er ein feil, ikkje ei retningsendring. Plasseringa betyr også noko: direktivet står utanfor blokka det høyrer til, så ein verdi skriven inne i blokka blir lesen som nøkkelmateriale. Kopier oppsettet profilen distributøren hadde tenkt, i staden for å finne opp ein paring, for ein profil som verkar mot éin server er kanskje allereie spegla på den andre sida.
Kva innstillinga lèt vere
Ho krypterer ikkje applikasjonstrafikk. tls-auth legg ein HMAC rundt pakkane til kontrollkanalen, medan datakanalen er verna av sesjonsnøklar som blir forhandla under handtrykket, så eit spørsmål om gjennomstrøyming eller chiffer har ingenting med retningstalet å gjere. Innstillinga legg heller ikkje til eit andre krypteringslag, og det er den føresetnaden som sender folk på jakt etter ein lengre nøkkel.
Ho gjeld ikkje for tls-crypt, ein annan kontrollkanalmekanisme med eigne innstillingar og nøkkelhandtering, og ho seier ingenting om sertifikatidentiteten til nokon part. Ein fungerande retningsmatch beviser difor berre at dei to endane er samde om korleis kontrollkanalen blir autentisert, ikkje at tillitskjeda vart validert.
Rett inn paret, og kople til på nytt
Samanlikn dei to konfigurasjonane før du endrar nokon av dei, for å redigere sida som allereie var riktig doblar arbeidet. Grep nedanfor viser kva mekanisme kvar fil vel; den detaljerte køyringa viser om kontrollkanalen i det heile vart autentisert. Ta vare på begge utdata, slik at neste endring kan samanliknast med ein kjend tilstand.
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'
Start begge partar på nytt etter kvar endring, fordi desse innstillingane blir lesne éin gong ved oppstart, og å laste inn éi side på nytt gjer paret inkonsistent for heile levetida til den gamle sesjonen. Viss utrullinga for auga fungerer utan ei konfigurert retning, attskapar det å leggje innstillinga til på éin part feilen du starta med; la begge vere i fred eller konfigurer begge. Endre éin ende om gongen og ta vare på førre fil, slik at ein regresjon er ei tilbakerulling på to minutt i staden for ein gjenoppbygging.
Noter mekanismen, nøkkelfila og retninga for kvar ende i utrullingsnotata, for elles vil neste person lese to like filer og anta at tala skal stemme med kvarandre. Retninga er ein koordineringsdetalj, ikkje ei sikkerheitsoppgradering: ho skil dei to retningane til kontrollkanalen og gjer ingenting anna.