PSK de L2TP/IPsec rejeitada: passe pela janela de diálogo e depois pelos ficheiros

Cola a chave pré-partilhada da mensagem do administrador na janela de diálogo do NetworkManager, assinala a caixa para a mostrar, e ela coincide carácter a carácter. A ligação termina mesmo assim num erro de autenticação antes de o túnel subir. A primeira vez que vi isto, pensei que a chave estivesse errada; não estava. Duas outras coisas decidem o que o daemon lê de facto: o ficheiro de segredos que o plugin escreve para essa ligação e se o valor passou pela janela sem alterações.

O percurso abaixo segue a chave do campo até ao ficheiro, e é essa ordem que lhe diz onde se perdeu. Faça-o na máquina que falha, não na que funciona, porque a diferença entre as duas é normalmente a disposição dos ficheiros e não a chave.

Comece pela janela de diálogo, mas não confie no campo

Abra o separador IPsec da ligação e volte a escrever a chave em vez de a colar. Uma chave copiada de uma mensagem de chat, de um PDF ou de um gestor de palavras-passe pode chegar com uma quebra de linha final que o campo não mostra, e os caracteres visíveis continuam a parecer corretos.

Clique no controlo de mostrar palavra-passe e olhe para o fim da cadeia, não para o meio. Se o cursor deixar uma linha vazia por baixo do texto, apague-a e volte a escrever o último carácter. Essa única correção resolve uma parte surpreendente destes relatos e custa menos do que ler qualquer registo.

Se a chave vem de um sistema de tickets que quebra linhas longas, peça-a por um canal que não quebre. Compare os comprimentos com o administrador em vez de olhar para duas cadeias lado a lado; um carácter perdido num ponto de quebra é invisível numa fonte proporcional.

Siga a chave para dentro de /etc/ipsec.d

O plugin nunca entrega a PSK ao daemon do IPsec como argumento numa linha de comandos. Em vez disso guarda o valor num ficheiro de segredos e trata de que o daemon inclua esse ficheiro, acrescentando uma linha include a /etc/ipsec.secrets se não houver nenhuma. O que a janela guarda é uma entrada para o ficheiro gerado, não o valor em uso.

Liste o que existe antes de mudar alguma coisa:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

As versões antigas do plugin escreviam um ficheiro por ligação, com o nome do UUID da ligação, por exemplo /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Apagar um perfil na applet não apaga esse ficheiro de forma fiável. Se um ficheiro antigo de um servidor anterior ainda estiver no disco e ainda for incluído, o daemon pode escolher um segredo que pertence a um perfil que já não usa, e a ligação falha enquanto o campo visível está correto.

Compreenda o que a alteração 1.2.12 fez às atualizações

A versão 1.2.12 do plugin substituiu os ficheiros de segredos por ligação por um único ficheiro partilhado, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Uma atualização não limpa os ficheiros antigos por UUID, e uma linha include /etc/ipsec.d/*.secrets existente continua a incluí-los. A versão 1.2.16 alterou o tratamento das propostas predefinidas, não a disposição dos segredos.

Essa história explica por que duas máquinas com o que parece o mesmo perfil se comportam de forma diferente. A chave é idêntica; o conjunto de ficheiros que o daemon inclui não é. Quando retirar um ficheiro órfão, ponha-o de lado em vez de o apagar, confirme a ligação e só depois o apague, quando o estado funcional estiver registado. Renomeá-lo mantém o valor antigo recuperável se se verificar que a falha está noutro sítio.

Separe os caracteres que o formato de armazenamento não consegue conter

A documentação do strongSwan para a cadeia de segredo partilhado indica que o valor não pode conter uma quebra de linha nem um carácter de aspas duplas. Uma chave colada de um documento pode trazer qualquer dos dois sem qualquer diferença visual numa janela normal.

Desde 1.2.12 o valor guardado não é texto simples. O plugin codifica a PSK em base64 antes de chegar ao ficheiro, e as notas de versão apresentam essa codificação como a razão pela qual uma aspa dupla é agora aceitável numa chave. Uma aspa escrita no campo é, por isso, representável; o mesmo não se aplica a todos os caracteres de controlo.

O comprimento é outra restrição. Não existe um mínimo universal no software L2TP/IPsec: alguns clientes aceitam chaves mais curtas de vinte caracteres e alguns gateways impõem um mínimo. Se uma chave curta for recusada, a regra pertence à política do servidor ou à validação desse cliente, e elevar algo localmente não a mudará.

Leia que camada de autenticação falhou

Execute primeiro ipsec --version, porque o strongSwan e o Libreswan usam nomes de ficheiro e sintaxe diferentes, e um conselho para um pode danificar o outro. Depois leia a etapa da falha na mensagem do cliente ou no registo do daemon: uma queixa sobre a chave pré-partilhada é um evento diferente de um nome de utilizador e uma palavra-passe recusados.

A PSK autentica os extremos do túnel. O nome de utilizador e a palavra-passe autenticam a pessoa dentro de L2TP, e o PPP trata deles depois de a associação IPsec estar no ar. Uma PSK correta com uma conta errada continua a falhar, e mudar de conta não reparará uma chave que o daemon nunca leu corretamente.

Quando fechar o ticket, anote as quatro coisas: versão do plugin, ficheiro de segredos em uso, se a chave foi reescrita ou colada e a camada indicada no erro. Assim, quem repetir este percurso mais tarde poderá saltar diretamente para a diferença entre a máquina que funciona e a que falha.