tls-auth key-direction: 0 e 1 devem diferir, não coincidir

Um lado do túnel assina o canal de controlo com um slot de chave que o outro lado nunca verifica, e a ligação morre com um erro de autenticação antes de qualquer certificado ser trocado. É assim que um desalinhamento de direção no tls-auth se parece, e é determinístico: os mesmos dois ficheiros falham em todas as tentativas, a partir de qualquer rede. Nada no registo nomeia a opção que procura, por isso as pessoas reconstroem chaves e reemitem certificados que nunca estiveram avariados. A solução é tornar as duas pontas complementares, ou deixar ambas bidirecionais, em vez de enfraquecer a verificação.

A falha ocorre antes dos certificados

Com tls-auth, ambos os pares têm a mesma chave partilhada e cada um usa um de dois slots derivados dela: um slot assina os pacotes de controlo de saída, o outro verifica os de entrada. A direção 0 e a direção 1 atribuem esses papéis na ordem inversa, por isso o par tem de ser complementar para que as verificações HMAC coincidam. Quando a atribuição é invertida num lado, o recetor procura uma assinatura no slot errado e rejeita o pacote. A sessão termina aí, e é por isso que o erro diz respeito à autenticação de pacotes e não a algo que o armazém de certificados produziria.

O determinismo importa para o diagnóstico, porque um problema de tempo ou de caminho deixa uma marca diferente: cortes intermitentes, uma direção a falhar ou uma sessão que só morre numa rede concreta. Um desalinhamento de direção falha no primeiro aperto de mão todas as vezes, e falha de forma idêntica noutra máquina com os mesmos dois ficheiros. Leia o registo em --verb 4 e encontre o primeiro pacote rejeitado em vez da última linha. Se essa rejeição acontecer antes de qualquer troca de certificados, a chave partilhada e a sua direção são as duas coisas que vale a pena verificar.

Onde vive o número

O manual do OpenVPN 2.6 documenta dois locais para a direção: o segundo argumento do tls-auth quando a chave está num ficheiro próprio, e uma linha key-direction autónoma quando a chave está integrada no perfil. Ambos definem o mesmo valor, por isso um perfil deve usar uma forma ou a outra, nunca as duas. A omissão também é uma escolha, e coloca ambos os pares numa disposição bidirecional que funciona quando nenhum lado nomeia uma direção. Dois pares com o mesmo número não estão nessa disposição: cada um espera assinar num slot e verificar no outro, e ambos o fazem da mesma maneira.

# 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

A forma integrada é uma diretiva numa linha própria, não um atributo na etiqueta de abertura do bloco de chave, e acrescentar um argumento a essa etiqueta é um erro, não uma mudança de direção. A colocação também importa: a diretiva fica fora do bloco a que pertence, por isso um valor escrito dentro do bloco é lido como material de chave. Copie a disposição que o distribuidor do perfil pretendia em vez de inventar um par, porque um perfil que funciona contra um servidor pode já estar espelhado do outro lado.

O que a opção deixa intacto

Não cifra o tráfego das aplicações. O tls-auth coloca um HMAC à volta dos pacotes do canal de controlo, enquanto o canal de dados é protegido por chaves de sessão negociadas durante o aperto de mão, por isso uma pergunta de débito ou de cifra não tem nada a ver com o número de direção. A definição também não acrescenta uma segunda camada de cifra, e é essa suposição que manda as pessoas à procura de uma chave mais longa.

Não se aplica ao tls-crypt, outro mecanismo de canal de controlo com opções e gestão de chaves próprias, e não diz nada sobre a identidade do certificado de qualquer par. Por isso uma correspondência de direção que funciona só prova que as duas pontas concordam em como autenticar o canal de controlo, não que a cadeia de confiança foi validada.

Alinhe o par e volte a ligar

Compare as duas configurações antes de alterar qualquer uma, porque editar o lado que já estava correto duplica o trabalho. O grep abaixo mostra que mecanismo cada ficheiro escolhe; a execução detalhada mostra se o canal de controlo chegou a ser autenticado. Guarde as duas saídas, para que a próxima alteração possa ser comparada com um estado conhecido.

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'

Reinicie ambos os pares depois de qualquer alteração, porque estas opções são lidas uma vez no arranque e recarregar um lado deixa o par inconsistente durante toda a vida da sessão antiga. Se a implementação funciona agora sem direção configurada, acrescentar a definição num par reproduz a falha com que começou; ou deixa ambos em paz ou configura ambos. Altere uma ponta de cada vez e guarde o ficheiro anterior, para que uma regressão seja um retrocesso de dois minutos e não uma reconstrução.

Registe o mecanismo, o ficheiro de chave e a direção de cada ponta nas notas de implementação, porque caso contrário a pessoa seguinte lerá dois ficheiros semelhantes e assumirá que os números devem coincidir entre si. A direção é um detalhe de coordenação, não uma melhoria de segurança: separa as duas direções do canal de controlo e não faz mais nada.