tls-auth key-direction: 0 och 1 måste skilja sig, inte stämma överens
Med tls-auth behöver båda ändarna motsatta riktningar, 0 och 1, eller så måste båda utelämna inställningen. Samma nummer misslyckas, och tls-crypt använder det aldrig.
Den ena sidan av tunneln signerar kontrollkanalen med en nyckelslot som den andra sidan aldrig kontrollerar, och anslutningen dör med ett autentiseringsfel innan ett enda certifikat har utväxlats. Så ser en riktningskonflikt med tls-auth ut, och den är deterministisk: samma två filer misslyckas vid varje försök, från vilket nätverk som helst. Ingenting i loggen namnger inställningen du letar efter, och därför bygger folk om nycklar och utfärdar certifikat som aldrig var trasiga. Lösningen är att göra de två ändarna komplementära eller låta båda vara dubbelriktade, i stället för att försvaga verifieringen.
Felet inträffar före certifikaten
Med tls-auth har båda parterna samma delade nyckel och var och en använder en av två slots som härleds från den: den ena sloten signerar utgående kontrollpaket, den andra verifierar inkommande. Riktning 0 och riktning 1 tilldelar dessa roller i omvänd ordning, så paret måste vara komplementärt för att HMAC-kontrollerna ska stämma. När tilldelningen vänds på ena sidan letar mottagaren efter en signatur i fel slot och avvisar paketet. Sessionen slutar där, och därför handlar felet om paketautentisering och inte om något certifikatlagret skulle producera.
Determinismen är viktig för diagnostik, eftersom ett tids- eller vägproblem lämnar ett annat spår: oregelbundna avbrott, en riktning som misslyckas, eller en session som bara dör i ett visst nätverk. En riktningskonflikt misslyckas vid det första handskakningen varje gång, och den misslyckas identiskt på en annan maskin med samma två filer. Läs loggen vid --verb 4 och hitta det första avvisade paketet i stället för den sista raden. Om den avvisningen sker före något certifikatutbyte är den delade nyckeln och dess riktning de två saker som är värda att kontrollera.
| 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 |
Var numret bor
Handboken för OpenVPN 2.6 dokumenterar två ställen för riktningen: det andra argumentet till tls-auth när nyckeln ligger i en egen fil, och en fristående key-direction-rad när nyckeln är inbäddad i profilen. Båda sätter samma värde, så en profil bör använda den ena formen eller den andra, aldrig båda. Uteslutning är också ett val, och det sätter båda parterna i ett dubbelriktat arrangemang som fungerar när ingen av sidorna anger en riktning. Två parter med samma nummer är inte i det arrangemanget: var och en förväntar sig att signera i den ena sloten och verifiera i den andra, och båda gör det på samma sätt.
# 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 inbäddade formen är ett direktiv på en egen rad, inte ett attribut på öppningstaggen i nyckelblocket, och att lägga till ett argument på den taggen är ett fel, inte en riktningsändring. Placeringen spelar också roll: direktivet står utanför blocket det hör till, så ett värde som skrivs inuti blocket läses som nyckelmaterial. Kopiera arrangemanget som profilens distributör avsåg i stället för att hitta på ett par, för en profil som fungerar mot en server är kanske redan speglad på andra sidan.
Vad inställningen lämnar orörd
Den krypterar inte applikationstrafik. tls-auth lägger en HMAC runt kontrollkanalens paket, medan datakanalen skyddas av sessionsnycklar som förhandlas under handskakningen, så en fråga om genomströmning eller chiffer har ingenting med riktningsnumret att göra. Inställningen lägger inte heller till ett andra krypteringslager, och det är det antagandet som skickar folk att leta efter en längre nyckel.
Den gäller inte för tls-crypt, en annan kontrollkanalmekanism med egna inställningar och nyckelhantering, och den säger ingenting om någon parts certifikatidentitet. En fungerande riktningsmatchning bevisar därför bara att de två ändarna är överens om hur kontrollkanalen autentiseras, inte att tillitskedjan validerades.
Rikta in paret och anslut igen
Jämför de två konfigurationerna innan du ändrar någon av dem, för att redigera sidan som redan var korrekt fördubblar arbetet. Grep nedan visar vilken mekanism varje fil väljer; den detaljerade körningen visar om kontrollkanalen alls autentiserades. Spara båda utdata, så att nästa ändring kan jämföras med ett känt tillstånd.
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'
Starta om båda parterna efter varje ändring, eftersom dessa inställningar läses en gång vid start och att ladda om ena sidan lämnar paret inkonsekvent under hela den gamla sessionens livstid. Om driftsättningen just nu fungerar utan en konfigurerad riktning återskapar det att lägga till inställningen på en part felet du började med; låt båda vara eller konfigurera båda. Ändra en ände i taget och spara den föregående filen, så att en regression är en återställning på två minuter i stället för en ombyggnad.
Anteckna mekanismen, nyckelfilen och riktningen för varje ände i driftsättningsanteckningarna, för annars läser nästa person två liknande filer och antar att numren ska stämma med varandra. Riktningen är en samordningsdetalj, inte en säkerhetsuppgradering: den skiljer kontrollkanalens två riktningar och gör ingenting annat.