tls-auth key-direction: 0 a 1 se musí lišit, ne shodovat
U tls-auth potřebují obě strany opačné směry, 0 a 1, nebo musí obě nastavení vynechat. Stejné číslo selže a tls-crypt ho nikdy nepoužívá.
Jedna strana tunelu podepisuje řídicí kanál klíčovým slotem, který druhá strana nikdy nekontroluje, a spojení umírá s chybou autentizace dřív, než se vymění jediný certifikát. Tak vypadá nesoulad směru u tls-auth a je deterministický: stejné dva soubory selžou při každém pokusu, z jakékoli sítě. Nic v logu nepojmenuje volbu, kterou hledáte, a proto lidé znovu vytvářejí klíče a vydávají certifikáty, které nikdy nebyly rozbité. Řešením je udělat obě strany komplementární, nebo nechat obě obousměrné, místo oslabení ověřování.
Selhání přichází dřív než certifikáty
U tls-auth drží oba partneři stejný sdílený klíč a každý používá jeden ze dvou slotů z něj odvozených: jeden slot podepisuje odchozí řídicí pakety, druhý ověřuje příchozí. Směr 0 a směr 1 přiřazují tyto role v opačném pořadí, takže pár musí být komplementární, aby kontroly HMAC seděly. Když se přiřazení na jedné straně obrátí, příjemce hledá podpis ve špatném slotu a paket odmítne. Relace tam končí, a proto se chyba týká autentizace paketů, ne něčeho, co by vytvořilo úložiště certifikátů.
Determinismus je důležitý pro diagnostiku, protože problém s časem nebo cestou zanechává jiný otisk: přerušované výpadky, selhání jednoho směru nebo relace, která umírá jen v určité síti. Nesoulad směru selže při prvním handshake pokaždé a selže stejně na jiném stroji se stejnými dvěma soubory. Čtěte log při --verb 4 a najděte první odmítnutý paket místo posledního řádku. Pokud k tomu odmítnutí dojde před jakoukoli výměnou certifikátů, sdílený klíč a jeho směr jsou dvě věci, které stojí za kontrolu.
| 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 |
Kde číslo žije
Příručka OpenVPN 2.6 dokumentuje dvě místa pro směr: druhý argument tls-auth, když klíč leží ve vlastním souboru, a samostatný řádek key-direction, když je klíč vložen do profilu. Obě nastavují stejnou hodnotu, takže profil má použít jednu formu nebo druhou, nikdy obě. Vynechání je také volba a staví oba partnery do obousměrného uspořádání, které funguje, když žádná strana směr neuvede. Dva partneři se stejným číslem v tomto uspořádání nejsou: každý očekává podpis v jednom slotu a ověření v druhém, a oba to dělají stejně.
# 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
Vložená forma je direktiva na vlastním řádku, ne atribut na otevírací značce klíčového bloku, a přidání argumentu k této značce je chyba, ne změna směru. Záleží i na umístění: direktiva stojí mimo blok, ke kterému patří, takže hodnota zapsaná uvnitř bloku se čte jako klíčový materiál. Kopírujte uspořádání, které zamýšlel distributor profilu, místo vymýšlení páru, protože profil, který funguje proti jednomu serveru, může už být zrcadlený na druhé straně.
Co volba nechává být
Nešifruje provoz aplikací. tls-auth dává HMAC kolem paketů řídicího kanálu, zatímco datový kanál chrání relace klíčů dohodnuté při handshake, takže otázka propustnosti nebo šifry nemá s číslem směru nic společného. Nastavení také nepřidává druhou vrstvu šifrování, a to je předpoklad, který lidi posílá hledat delší klíč.
Nevztahuje se na tls-crypt, jiný mechanismus řídicího kanálu s vlastními volbami a správou klíčů, a nic neříká o identitě certifikátu žádného partnera. Fungující shoda směru tedy dokazuje jen to, že se obě strany shodují, jak autentizovat řídicí kanál, ne že byl ověřen řetězec důvěry.
Srovnejte pár a znovu se připojte
Porovnejte obě konfigurace, než některou změníte, protože úprava strany, která už byla správná, zdvojnásobí práci. Grep níže ukazuje, který mechanismus každý soubor volí; podrobný běh ukazuje, zda se řídicí kanál vůbec autentizoval. Uložte oba výstupy, aby se další změna dala porovnat se známým stavem.
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 každé změně restartujte oba partnery, protože tyto volby se čtou jednou při startu a znovunačtení jedné strany nechá pár nekonzistentní po celý život staré relace. Pokud nasazení nyní funguje bez nastaveného směru, přidání nastavení na jednoho partnera reprodukuje selhání, se kterým jste začali; buď nechte oba, nebo nastavte oba. Měňte jeden konec po druhém a uchovejte předchozí soubor, aby regrese byla dvouminutovým návratem, ne přestavbou.
Zapište mechanismus, klíčový soubor a směr pro každý konec do poznámek k nasazení, protože jinak si příští člověk přečte dva podobné soubory a bude předpokládat, že čísla mají navzájem souhlasit. Směr je koordinační detail, ne bezpečnostní vylepšení: odděluje dva směry řídicího kanálu a nic jiného nedělá.