0x ou 0s? Como ler o formato PSK em ipsec.secrets

Um cliente autentica-se com a chave partilhada e outro rejeita-a, embora os caracteres que colou pareçam iguais dos dois lados. Provavelmente são os mesmos caracteres; a diferença está em qual regra de descodificação o ficheiro lhes aplica. Uma cadeia entre aspas é tomada literalmente, um token que começa por 0x é lido como hexadecimal, e um token que começa por 0s é lido como Base64. Só uma destas três grafias significa o que pretendia, por isso a correção costuma ser uma conversão e não uma palavra-passe melhor.

O sintoma aponta para a codificação, não para as cifras

Quando os dois extremos guardam bytes diferentes, a negociação continua a ter sucesso e a prova falha depois. O registo passa então a reportar uma falha de integridade ou de HMAC em vez de uma discrepância de algoritmo, porque foi escolhida uma proposta e o passo de autenticação não coincidiu. Essa linha nunca menciona a forma do segredo.

A fase é a pista. Uma falha que chega depois de uma proposta escolhida significa que ambos os lados concordaram em tudo excepto no material de chave, enquanto «nenhuma proposta escolhida» pertence à política ou aos conjuntos de cifra. Uma verificação de integridade que falha quando a palavra-passe parece correta é a face visível de uma discrepância de codificação.

Um segredo, três formas de o ficheiro o ler

Para o valor de quatro bytes key1, o hexadecimal e o Base64 são duas recodificações dos mesmos bytes, e só os caracteres iniciais dizem ao analisador qual dos dois tem em mãos. As credenciais do swanctl seguem a mesma convenção, por isso um valor movido entre as duas interfaces só conserva o significado se o seu prefixo viajar com ele.

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

Dois detalhes desse bloco custam mais tempo. Os dígitos hexadecimais aceitam as duas caixas, pelo que 0x6b657931 e 0x6B657931 são o mesmo valor, mas um número ímpar de caracteres é lido mal em silêncio em vez de ser rejeitado, o que desloca cada byte depois do corte. O enchimento Base64 faz parte do valor, por isso uma cadeia colada sem os seus sinais = finais é descodificada em bytes diferentes em vez de falhar ruidosamente.

Um perfil que já descodificou o valor uma vez converteu-o, por isso voltar a descodificar produz bytes diferentes e uma falha de autenticação que se lê como uma palavra-passe errada. As aspas são a direção segura para tudo o que é ambíguo, porque o conteúdo é literal mesmo quando começa com um marcador de codificação.

De onde vem o texto Base64

As exportações de perfil e os portais de fornecedores entregam muitas vezes a chave já codificada, normalmente num campo de dados que nunca foi pensado para ser escrito à mão. Ou desembrulha esse valor e guarda o texto descodificado entre aspas, ou deixa-o codificado com o marcador à frente. Fazer metade de cada um é o que o estraga. Ambos os caminhos só funcionam se o valor inteiro sobreviver à cópia.

Ambas as direções são um comando cada, e vale a pena guardá-las no ticket como a operação exata que produziu o valor armazenado. Execute-as nesta ordem:

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

Colar texto codificado como se fosse simples é o erro caro. O ficheiro aplica o hash aos caracteres exatamente como estão escritos, a chave derivada sai cerca de um terço mais longa do que a que o par calculou, e cada tentativa falha da mesma forma sem aviso, porque o analisador seguiu a regra que lhe foi dada.

Confirme que bytes cada par usa realmente

Leia primeiro a visão do daemon sobre a ligação e depois o resultado da autenticação, em vez de adivinhar uma causa a partir da cadeia de erro. Comparar o comprimento armazenado é uma verificação rápida de sensatez, porque o texto codificado é mais longo do que os bytes que representa. Depois confirme que linha de identidade coincidiu, porque um segredo correto arquivado sob o par errado falha exatamente como um errado. A ordem das linhas decide isso: a primeira coincidência ganha, por isso uma linha ampla %any perto do topo substitui em silêncio a linha concreta que acabou de editar.

Recarregue em vez de reiniciar quando o ficheiro estiver correto. ipsec rereadsecrets refresca a cópia do daemon IKE, e uma instalação swanctl carrega as credenciais pelo seu próprio comando. Um reinício descarta todas as associações estabelecidas e destrói a comparação que estava a tentar fazer.

Nenhuma destas verificações exige expor o segredo. Um comprimento, um seletor de identidade e uma posição de linha explicam a maioria das falhas deste tipo antes de alguém precisar de um despejo hexadecimal.

Altere o ficheiro sem esconder o resultado

Restrinja o ficheiro à conta do daemon e mantenha os segredos vivos fora de tickets, chat e capturas de ecrã, porque uma chave colada é uma fuga e não um diagnóstico. Também sobrevive ao incidente que a produziu.

Teste a partir de um cliente cuja configuração controla, confirme que a autenticação tem sucesso e depois confirme que o túnel transporta tráfego. Um recarregamento que arranja o aperto de mão enquanto o encaminhamento continua quebrado é outro problema, e torna-se visível assim que o segredo deixa de se mover.