tls-auth key-direction: 0 і 1 мусіць адрознівацца, а не супадаць
З tls-auth двум бакам патрэбныя супрацьлеглыя кірункі, 0 і 1, або абодва павінны апусціць наладу. Адзін і той жа нумар не працуе, а tls-crypt яго ніколі не выкарыстоўвае.
Адзін бок тунеля падпісвае кантрольны канал ключавым слотам, які іншы бок ніколі не правярае, і злучэнне памірае з памылкай аўтэнтыфікацыі яшчэ да абмену хоць адным сертыфікатам. Менавіта так выглядае неадпаведнасць кірунку tls-auth, і яна дэтэрмінаваная: тыя ж два файлы не працуюць пры кожнай спробе, з любой сеткі. Нішто ў журнале не называе опцыю, якую вы шукаеце, таму людзі перабудоўваюць ключы і перавыдаюць сертыфікаты, якія ніколі не былі зламаныя. Рашэнне — зрабіць два бакі ўзаемадапаўняльнымі або пакінуць абодва двухбаковымі, а не паслабляць праверку.
Збой адбываецца раней за сертыфікаты
З tls-auth абодва бакі трымаюць адзін агульны ключ, і кожны выкарыстоўвае адзін з двух слотаў, вытворных ад яго: адзін слот падпісвае зыходныя кантрольныя пакеты, другі правярае ўваходныя. Кірунак 0 і кірунак 1 прызначаюць гэтыя ролі ў адваротным парадку, таму пара павінна быць узаемадапаўняльнай, каб праверкі HMAC супалі. Калі прызначэнне адменена на адным баку, атрымальнік шукае подпіс у няправільным слоце і адхіляе пакет. Сесія сканчаецца там, таму памылка датычыцца аўтэнтыфікацыі пакетаў, а не чаго-небудзь, што стварыў бы сховішча сертыфікатаў.
Дэтэрмінаванасць важная для дыягностыкі, бо праблема часу або шляху пакідае іншую прыкмету: перарывістыя абрывы, збой аднаго кірунку або сесія, якая памірае толькі ў пэўнай сетцы. Неадпаведнасць кірунку зрываецца на першым рукапацісканні кожны раз, і гэтак жа сама зрываецца на іншай машыне з тымі ж двума файламі. Чытайце журнал пры --verb 4 і знайдзіце першы адхілены пакет, а не апошні радок. Калі гэтае адхіленне адбываецца да абмену сертыфікатамі, агульны ключ і яго кірунак — гэта дзве рэчы, якія варта праверыць.
| 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 |
Дзе жыве нумар
Кіраўніцтва OpenVPN 2.6 апісвае два месцы для кірунку: другі аргумент tls-auth, калі ключ ляжыць у асобным файле, і асобны радок key-direction, калі ключ убудаваны ў профіль. Абодва задаюць адно і тое ж значэнне, таму профіль павінен выкарыстоўваць адну форму або другую, ніколі абедзве. Апусканне таксама з'яўляецца выбарам, і яно ставіць абодва бакі ў двухбаковае размяшчэнне, якое працуе, калі ні адзін бок не называе кірунак. Два бакі з адным і тым жа нумарам не знаходзяцца ў такім размяшчэнні: кожны чакае падпісваць у адным слоце і правяраць у другім, і абодва робяць гэта аднолькава.
# 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
Убудаваная форма — гэта дырэктыва на асобным радку, а не атрыбут у адкрывальным тэгу ключавога блока, і даданне аргумента да гэтага тэга — памылка, а не змена кірунку. Размяшчэнне таксама мае значэнне: дырэктыва стаіць па-за блокам, да якога належыць, таму значэнне, запісанае ўнутры блока, чытаецца як ключавы матэрыял. Капіруйце размяшчэнне, якое меў на ўвазе распаўсюднік профілю, замест таго каб выдумляць пару, бо профіль, які працуе супраць аднаго сервера, магчыма, ужо адлюстраваны на іншым баку.
Што опцыя пакідае без змен
Яна не шыфруе трафік прыкладанняў. tls-auth ставіць HMAC вакол пакетаў кантрольнага канала, а канал даных абаронены сесійнымі ключамі, узгодненымі падчас рукапаціскання, таму пытанне пра прапускную здольнасць або шыфр не мае нічога агульнага з нумарам кірунку. Налада таксама не дадае другога слоя шыфравання, і менавіта гэта дапушчэнне прымушае людзей шукаць даўжэйшы ключ.
Яна не датычыцца tls-crypt, іншага механізму кантрольнага канала з уласнымі опцыямі і апрацоўкай ключоў, і нічога не кажа пра ідэнтычнасць сертыфіката любога боку. Таму працоўнае супадзенне кірунку даказвае толькі, што абодва бакі згодныя, як аўтэнтыфікаваць кантрольны канал, а не што ланцуг даверу быў правераны.
Выраўнайце пару, затым перападключыцеся
Параўнайце дзве канфігурацыі, перш чым змяняць якую-небудзь, бо рэдагаванне боку, які ўжо быў правільным, падвойвае працу. Grep ніжэй паказвае, які механізм выбірае кожны файл; падрабязны запуск паказвае, ці аўтэнтыфікаваўся кантрольны канал наогул. Захавайце абодва выхады, каб наступную змену можна было параўнаць з вядомым станам.
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'
Перазапусціце абодва бакі пасля любой змены, бо гэтыя опцыі чытаюцца адзін раз пры запуску, і перазагрузка аднаго боку пакідае пару непаслядоўнай на ўвесь час жыцця старой сесіі. Калі разгортванне зараз працуе без наладжанага кірунку, даданне налады на адным баку ўзнаўляе збой, з якога вы пачалі; альбо пакіньце абодва, альбо наладзьце абодва. Змяняйце адзін канец за раз і захоўвайце папярэдні файл, каб рэгрэс быў адкатам за дзве хвіліны, а не перабудовай.
Запішыце механізм, ключавы файл і кірунак для кожнага канца ў нататках пра разгортванне, бо інакш наступны чалавек прачытае два падобныя файлы і выкажа здагадку, што нумары павінны супадаць адзін з адным. Кірунак — гэта дэталь каардынацыі, а не паляпшэнне бяспекі: ён раздзяляе два кірункі кантрольнага канала і не робіць больш нічога.