tls-auth key-direction: 0 og 1 må være forskjellige, ikke like
Med tls-auth trenger begge ender motsatte retninger, 0 og 1, eller begge må utelate innstillingen. Samme tall feiler, og tls-crypt bruker det aldri.
Den ene siden av tunnelen signerer kontrollkanalen med en nøkkelslot som den andre siden aldri sjekker, og forbindelsen dør med en autentiseringsfeil før et eneste sertifikat er utvekslet. Slik ser en retningskonflikt med tls-auth ut, og den er deterministisk: de samme to filene feiler ved hvert forsøk, fra hvert nettverk. Ingenting i loggen navngir innstillingen du leter etter, og derfor bygger folk nøkler på nytt og utsteder sertifikater på nytt som aldri var ødelagt. Løsningen er å gjøre de to endene komplementære eller la begge være toveis, i stedet for å svekke verifiseringen.
Feilen skjer før sertifikatene
Med tls-auth har begge parter den samme delte nøkkelen, og hver bruker en av to slots som utledes fra den: den ene sloten signerer utgående kontrollpakker, den andre verifiserer innkommende. Retning 0 og retning 1 tildeler disse rollene i omvendt rekkefølge, så paret må være komplementært for at HMAC-kontrollene skal stemme. Når tildelingen snus på den ene siden, leter mottakeren etter en signatur i feil slot og avviser pakken. Sesjonen slutter der, og derfor handler feilen om pakkeautentisering og ikke om noe sertifikatlageret ville produsere.
Determinismen er viktig for diagnostikk, fordi et tids- eller ruteproblem etterlater et annet spor: uregelmessige avbrudd, én retning som feiler, eller en sesjon som bare dør på et bestemt nettverk. En retningskonflikt feiler ved den første håndtrykket hver gang, og den feiler identisk på en annen maskin med de samme to filene. Les loggen ved --verb 4 og finn den første avviste pakken i stedet for den siste linjen. Hvis den avvisningen skjer før noen sertifikatutveksling, er den delte nøkkelen og retningen dens de to tingene som er verdt å 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 |
Hvor tallet bor
Manualen for OpenVPN 2.6 dokumenterer to steder for retningen: det andre argumentet til tls-auth når nøkkelen ligger i sin egen fil, og en selvstendig key-direction-linje når nøkkelen er innebygd i profilen. Begge setter samme verdi, så en profil bør bruke den ene formen eller den andre, aldri begge. Utelatelse er også et valg, og det setter begge parter i et toveisoppsett som virker når ingen av sidene angir en retning. To parter med samme tall er ikke i det oppsettet: hver forventer å signere i den ene sloten og verifisere i den andre, og begge gjør det på samme 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 formen er en direktiv på sin egen linje, ikke et attributt på åpningstaggen i nøkkelblokken, og å legge til et argument på den taggen er en feil, ikke en retningsendring. Plasseringen betyr også noe: direktivet står utenfor blokken det hører til, så en verdi skrevet inne i blokken leses som nøkkelmateriale. Kopier oppsettet profilen distributøren hadde tenkt, i stedet for å finne opp en paring, for en profil som virker mot én server er kanskje allerede speilet på den andre siden.
Hva innstillingen lar være
Den krypterer ikke applikasjonstrafikk. tls-auth legger en HMAC rundt pakkene til kontrollkanalen, mens datakanalen beskyttes av sesjonsnøkler som forhandles under håndtrykket, så et spørsmål om gjennomstrømning eller chiffer har ingenting med retningstallet å gjøre. Innstillingen legger heller ikke til et andre krypteringslag, og det er den antakelsen som sender folk på jakt etter en lengre nøkkel.
Den gjelder ikke for tls-crypt, en annen kontrollkanalmekanisme med egne innstillinger og nøkkelhåndtering, og den sier ingenting om sertifikatidentiteten til noen part. En fungerende retningsmatch beviser derfor bare at de to endene er enige om hvordan kontrollkanalen autentiseres, ikke at tillitskjeden ble validert.
Rett inn paret, og koble til på nytt
Sammenlign de to konfigurasjonene før du endrer noen av dem, for å redigere siden som allerede var riktig dobler arbeidet. Grep nedenfor viser hvilken mekanisme hver fil velger; den detaljerte kjøringen viser om kontrollkanalen i det hele tatt ble autentisert. Ta vare på begge utdataene, slik at neste endring kan sammenlignes med en kjent 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 parter på nytt etter enhver endring, fordi disse innstillingene leses én gang ved oppstart, og å laste inn én side på nytt gjør paret inkonsistent for hele levetiden til den gamle sesjonen. Hvis utrullingen for øyeblikket virker uten en konfigurert retning, gjenskaper det å legge innstillingen til på én part feilen du startet med; la begge være i fred eller konfigurer begge. Endre én ende om gangen og ta vare på forrige fil, slik at en regresjon er en tilbakerulling på to minutter i stedet for en gjenoppbygging.
Noter mekanismen, nøkkelfilen og retningen for hver ende i utrullingsnotatene, for ellers vil neste person lese to like filer og anta at tallene skal stemme med hverandre. Retningen er en koordineringsdetalj, ikke en sikkerhetsoppgradering: den skiller de to retningene til kontrollkanalen og gjør ingenting annet.