Едната страна од тунелот го потпишува контролниот канал со клучен слот што другата страна никогаш не го проверува, и врската умира со грешка при автентикација пред да се размени ниту еден сертификат. Така изгледа несовпаѓањето на насоката кај tls-auth, и тоа е детерминистичко: истите два фајла не успеваат при секој обид, од секоја мрежа. Ништо во дневникот не ја именува опцијата што ја барате, затоа луѓето повторно градат клучеви и повторно издаваат сертификати што никогаш не биле расипани. Решението е да се направат двете страни комплементарни или да се остават двете двосмерни, наместо да се ослабне проверката.

Неуспехот настапува пред сертификатите

Со tls-auth двата партнера го држат истиот заеднички клуч и секој користи еден од двата слота изведени од него: едниот слот потпишува излезни контролни пакети, другиот ги проверува влезните. Насоката 0 и насоката 1 ги доделуваат тие улоги во обратен редослед, па парот мора да биде комплементарен за да се совпаднат HMAC-проверките. Кога доделувањето се превртува на едната страна, примачот бара потпис во погрешниот слот и го одбива пакетот. Сесијата завршува таму, затоа грешката се однесува на автентикација на пакети, а не на нешто што би го создало складиштето на сертификати.

Детерминизмот е важен за дијагноза, бидејќи проблем со време или пат остава поинаков траг: наизменични прекини, неуспех на една насока или сесија што умира само на одредена мрежа. Несовпаѓањето на насоката неуспева при првото ракување секој пат, и неуспева идентично на друга машина со истите два фајла. Читајте го дневникот при --verb 4 и најдете го првиот одбиен пакет наместо последната линија. Ако тоа одбивање се случи пред која било размена на сертификати, заедничкиот клуч и неговата насока се двете работи што вреди да се проверат.

What you seeWhat it rules outNext check
Authentication error before any certificate is sentThe data channel is irrelevant; the control channel never authenticatedCompare tls-auth and its direction on both ends
Certificate or handshake failure after the control channel authenticatesThe shared key and its direction already agreeCheck the CA, the certificate dates and the hostname
Session completes but throughput or cipher warnings appearDirection was never the problemCompare the data-channel cipher settings
Startup stops on an options errorThe number itself is not the issueRe-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'

Рестартирајте ги двата партнера по секоја промена, бидејќи овие опции се читаат еднаш при стартување и повторното вчитување на едната страна го остава парот неконзистентен за целиот животен век на старата сесија. Ако распоредувањето моментално работи без конфигурирана насока, додавањето на поставката на еден партнер ја репродуцира грешката со која почнавте; или оставете ги двата или конфигурирајте ги двата. Менувајте еден крај по еден и чувајте го претходниот фајл, за да биде регресијата две минути враќање, а не повторна изградба.

Запишете го механизмот, клучниот фајл и насоката за секој крај во белешките за распоредување, бидејќи инаку следниот човек ќе прочита два слични фајла и ќе претпостави дека броевите треба да се совпаѓаат меѓу себе. Насоката е детал за координација, а не безбедносно подобрување: таа ги одделува двете насоки на контролниот канал и не прави ништо друго.

Поврзани статии