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'
Поново покрените обе стране после сваке промене, јер се ове опције читају једном при покретању и поновно учитавање једне стране оставља пар недоследан за цео животни век старе сесије. Ако распоређивање тренутно ради без конфигурисаног смера, додавање подешавања на једну страну репродукује неуспех са којим сте почели; или оставите обе или конфигуришите обе. Мењајте један крај по један и чувајте претходни фајл, да регресија буде двоминутни повратак, а не поновна изградња.
Запишите механизам, кључни фајл и смер за сваки крај у белешке о распоређивању, јер ће иначе следећа особа прочитати два слична фајла и претпоставити да бројеви треба да се поклапају. Смер је детаљ координације, а не безбедносно побољшање: он раздваја два смера контролног канала и не чини ништа друго.