tls-auth key-direction: 0 a 1 sa musia líšiť, nie zhodovať
Pri tls-auth potrebujú obe strany opačné smery, 0 a 1, alebo musia obe nastavenie vynechať. Rovnaké číslo zlyhá a tls-crypt ho nikdy nepoužíva.
Jedna strana tunela podpisuje riadiaci kanál kľúčovým slotom, ktorý druhá strana nikdy nekontroluje, a spojenie umiera s chybou autentizácie skôr, než sa vymení jediný certifikát. Takto vyzerá nesúlad smeru pri tls-auth a je deterministický: tie isté dva súbory zlyhajú pri každom pokuse, z akejkoľvek siete. Nič v logu nepomenuje voľbu, ktorú hľadáte, preto ľudia znovu vytvárajú kľúče a vydávajú certifikáty, ktoré nikdy neboli pokazené. Riešením je urobiť obe strany komplementárnymi alebo nechať obe obojsmerné, nie oslabiť overovanie.
Zlyhanie prichádza pred certifikátmi
Pri tls-auth držia obaja partneri rovnaký zdieľaný kľúč a každý používa jeden z dvoch slotov z neho odvodených: jeden slot podpisuje odchádzajúce riadiace pakety, druhý overuje prichádzajúce. Smer 0 a smer 1 priraďujú tieto úlohy v opačnom poradí, takže pár musí byť komplementárny, aby kontroly HMAC sedeli. Keď sa priradenie na jednej strane obráti, príjemca hľadá podpis v nesprávnom slote a paket odmietne. Relácia tam končí, a preto sa chyba týka autentizácie paketov, nie niečoho, čo by vytvorilo úložisko certifikátov.
Determinizmus je dôležitý pre diagnostiku, pretože problém s časom alebo cestou zanecháva inú stopu: prerušované výpadky, zlyhanie jedného smeru alebo relácia, ktorá umiera len v určitej sieti. Nesúlad smeru zlyhá pri prvom podaní ruky zakaždým a zlyhá rovnako na inom stroji s tými istými dvoma súbormi. Čítajte log pri --verb 4 a nájdite prvý odmietnutý paket namiesto posledného riadka. Ak k tomu odmietnutiu dôjde pred akoukoľvek výmenou certifikátov, zdieľaný kľúč a jeho smer sú dve veci, ktoré stoja 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
Príručka OpenVPN 2.6 dokumentuje dve miesta pre smer: druhý argument tls-auth, keď kľúč leží vo vlastnom súbore, a samostatný riadok key-direction, keď je kľúč vložený do profilu. Obe nastavujú rovnakú hodnotu, takže profil má použiť jednu formu alebo druhú, nikdy obe. Vynechanie je tiež voľba a stavia oboch partnerov do obojsmerného usporiadania, ktoré funguje, keď žiadna strana neuvedie smer. Dvaja partneri s rovnakým číslom v tomto usporiadaní nie sú: každý očakáva podpis v jednom slote a overenie v druhom, a obaja to robia rovnako.
# 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 direktíva na vlastnom riadku, nie atribút na otváracej značke kľúčového bloku, a pridanie argumentu k tejto značke je chyba, nie zmena smeru. Záleží aj na umiestnení: direktíva stojí mimo bloku, ku ktorému patrí, takže hodnota zapísaná vnútri bloku sa číta ako kľúčový materiál. Kopírujte usporiadanie, ktoré zamýšľal distribútor profilu, namiesto vymýšľania páru, pretože profil, ktorý funguje proti jednému serveru, môže už byť zrkadlený na druhej strane.
Čo voľba necháva tak
Nešifruje prevádzku aplikácií. tls-auth dáva HMAC okolo paketov riadiaceho kanála, zatiaľ čo dátový kanál chránia relácie kľúčov dohodnuté pri podaní ruky, takže otázka priepustnosti alebo šifry nemá s číslom smeru nič spoločné. Nastavenie tiež nepridáva druhú vrstvu šifrovania, a práve tento predpoklad posiela ľudí hľadať dlhší kľúč.
Nevzťahuje sa na tls-crypt, iný mechanizmus riadiaceho kanála s vlastnými voľbami a správou kľúčov, a nič nehovorí o identite certifikátu žiadnej strany. Fungujúca zhoda smeru teda dokazuje len to, že sa obe strany zhodujú, ako autentizovať riadiaci kanál, nie že bola overená reťaz dôvery.
Zosúlaďte pár a znova sa pripojte
Porovnajte obe konfigurácie predtým, než niektorú zmeníte, pretože úprava strany, ktorá už bola správna, zdvojnásobí prácu. Grep nižšie ukazuje, ktorý mechanizmus každý súbor volí; podrobný beh ukazuje, či sa riadiaci kanál vôbec autentizoval. Uložte oba výstupy, aby sa ďalšia zmena dala porovnať so známym stavom.
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ždej zmene reštartujte oboch partnerov, pretože tieto voľby sa čítajú raz pri štarte a opätovné načítanie jednej strany nechá pár nekonzistentný po celý život staré relácie. Ak nasadenie teraz funguje bez nastaveného smeru, pridanie nastavenia na jedného partnera reprodukuje zlyhanie, s ktorým ste začali; buď nechajte oboch, alebo nastavte oboch. Meňte jeden koniec naraz a uchovajte predchádzajúci súbor, aby regresia bola dvojminútovým vrátením, nie prestavbou.
Zapíšte mechanizmus, kľúčový súbor a smer pre každý koniec do poznámok k nasadeniu, pretože inak si ďalší človek prečíta dva podobné súbory a bude predpokladať, že čísla majú navzájom súhlasiť. Smer je koordinačný detail, nie bezpečnostné vylepšenie: oddeľuje dva smery riadiaceho kanála a nič iné nerobí.