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

Un cliente autentícase coa clave compartida e outro rexéitaa, e os caracteres que pegaches parecen iguais nos dous lados. Probablemente son os mesmos caracteres; a diferenza está en que regra de descodificación lles aplica o ficheiro. Unha cadea entre comiñas tómase literalmente, un token que comeza por 0x lese como hexadecimal, e un token que comeza por 0s lese como Base64. Só unha desas tres grafías significa o que pretendías, así que a corrección adoita ser unha conversión e non un contrasinal mellor.

O síntoma apunta á codificación, non aos cifrados

Cando os dous extremos gardan bytes distintos, a negociación segue tendo éxito e a proba falla despois. O rexistro informa entón dun fallo de integridade ou de HMAC en lugar dunha discrepancia de algoritmo, porque se escolleu unha proposta e o paso de autenticación non coincidiu. Esa liña nunca menciona a forma do segredo.

A etapa é a pista. Un fallo que chega despois dunha proposta escollida significa que ambos os lados acordaron todo agás o material de clave, mentres que «ningunha proposta escollida» pertence á política ou aos conxuntos de cifrado. Unha comprobación de integridade que falla cando o contrasinal parece correcto é a cara visible dunha discrepancia de codificación.

Un segredo, tres xeitos en que o ficheiro pode lelo

Para o valor de catro bytes key1, o hexadecimal e o Base64 son dúas recodificacións dos mesmos bytes, e só os caracteres iniciais lle din ao analizador cal dos dous ten. As credenciais de swanctl seguen a mesma convención, así que un valor trasladado entre as dúas interfaces conserva o significado só se o seu prefixo viaxa con el.

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

Dous detalles dese bloque custan a maior parte do tempo. Os díxitos hexadecimais aceptan ambas as caixas, así que 0x6b657931 e 0x6B657931 son o mesmo valor, pero un número impar de caracteres lese mal en silencio en lugar de rexeitarse, o que despraza cada byte despois do corte. O recheo de Base64 forma parte do valor, así que unha cadea pegada sen os seus signos = finais descodifícase en bytes distintos en lugar de fallar ruidosamente.

Un perfil que xa descodificou o valor unha vez xa o converteu, así que volver descodificalo produce bytes distintos e un fallo de autenticación que se le como un contrasinal equivocado. As comiñas son a dirección segura para calquera cousa ambigua, porque o contido é literal mesmo cando comeza cun marcador de codificación.

De onde sae o texto Base64

As exportacións de perfís e os portais de provedores adoitan entregar a clave xa codificada, normalmente nun campo de datos que nunca se pensou para escribirse a man. Ou ben desenvuelve ese valor e garda o texto descodificado entre comiñas, ou ben déixao codificado co marcador diante. Facer a metade de cada cousa é o que o rompe. Ambas as vías funcionan só se o valor completo sobrevive á copia.

Ambas as direccións son un comando cada unha, e paga a pena gardalos no ticket como a operación exacta que produciu o valor almacenado. Execútaos nesta orde:

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

Pegar texto codificado coma se fose simple é o erro caro. O ficheiro aplica o hash aos caracteres exactamente como están escritos, a clave derivada sae aproximadamente un terzo máis longa que a que calculou o par, e cada intento falla igual sen aviso, porque o analizador seguiu a regra que se lle deu.

Confirma que bytes usa realmente cada par

Le primeiro a visión do daemon sobre a conexión e despois o resultado da autenticación, en lugar de adiviñar unha causa a partir da cadea de erro. Comparar a lonxitude almacenada é unha comprobación rápida de sensatez, porque o texto codificado é máis longo que os bytes que representa. Despois confirma que fila de identidade coincidiu, porque un segredo correcto arquivado baixo o par equivocado falla igual que un incorrecto. A orde das filas decídeo: a primeira coincidencia gaña, así que unha fila ampla %any preto de arriba substitúe en silencio a fila concreta que acabas de editar.

Recarga en lugar de reiniciar cando o ficheiro sexa correcto. ipsec rereadsecrets refresca a copia do daemon IKE, e unha instalación con swanctl carga as credenciais mediante o seu propio comando. Un reinicio descarta todas as asociacións establecidas e destrúe a comparación que intentabas facer.

Ningunha destas comprobacións esixe expor o segredo. Unha lonxitude, un selector de identidade e unha posición de fila explican a maioría dos fallos deste tipo antes de que ninguén necesite un volcado hexadecimal.

Cambia o ficheiro sen agochar o resultado

Restrinxe o ficheiro á conta do daemon e mantén os segredos vivos fóra dos tickets, do chat e das capturas de pantalla, porque unha clave pegada é unha filtración e non un diagnóstico. Ademais sobrevive ao incidente que a produciu.

Proba desde un cliente cuxa configuración controlas, confirma que a autenticación ten éxito e despois confirma que o túnel transporta tráfico. Unha recarga que arranxa o aperto de mans mentres o encamiñamento segue roto é outro problema, e faise visible en canto o segredo deixa de moverse.