¿0x o 0s? Cómo leer el formato PSK en ipsec.secrets

Un cliente se autentica con la clave compartida y otro la rechaza, y los caracteres que pegó parecen iguales en ambos lados. Probablemente sean los mismos caracteres; la diferencia está en qué regla de decodificación les aplica el archivo. Una cadena entre comillas se toma literalmente, un token que empieza por 0x se lee como hexadecimal y un token que empieza por 0s se lee como Base64. Solo una de esas tres grafías significa lo que usted pretendía, así que la corrección suele ser una conversión y no una contraseña mejor.

El síntoma apunta a la codificación, no a los cifrados

Cuando los dos extremos guardan bytes distintos, la negociación sigue teniendo éxito y la prueba falla después. El registro informa entonces de un fallo de integridad o de HMAC en lugar de una discrepancia de algoritmo, porque se eligió una propuesta y el paso de autenticación no coincidió. Esa línea nunca menciona la forma del secreto.

La etapa es la pista. Un fallo que llega después de una propuesta elegida significa que ambos lados acordaron todo salvo el material de clave, mientras que «ninguna propuesta elegida» pertenece a la política o a los conjuntos de cifrado. Una comprobación de integridad que falla cuando la contraseña parece correcta es la cara visible de una discrepancia de codificación.

Un secreto, tres formas en que el archivo puede leerlo

Para el valor de cuatro bytes key1, el hexadecimal y el Base64 son dos recodificaciones de los mismos bytes, y solo los caracteres iniciales le dicen al analizador cuál de las dos tiene entre manos. Las credenciales de swanctl siguen la misma convención, así que un valor trasladado entre las dos interfaces conserva su significado solo si su prefijo viaja con él.

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

Dos detalles de ese bloque cuestan la mayor parte del tiempo. Los dígitos hexadecimales aceptan ambas cajas, así que 0x6b657931 y 0x6B657931 son el mismo valor, pero un número impar de caracteres se lee mal en silencio en lugar de rechazarse, lo que desplaza cada byte después del corte. El relleno de Base64 forma parte del valor, así que una cadena pegada sin sus signos = finales se decodifica en bytes distintos en lugar de fallar ruidosamente.

Un perfil que ya decodificó el valor una vez lo ha convertido, así que volver a decodificarlo produce bytes distintos y un fallo de autenticación que se lee como una contraseña equivocada. Las comillas son la dirección segura para cualquier cosa ambigua, porque el contenido es literal incluso cuando empieza con un marcador de codificación.

De dónde sale el texto Base64

Las exportaciones de perfiles y los portales de proveedores suelen entregar la clave ya codificada, normalmente en un campo de datos que nunca se pensó para escribirse a mano. O bien desenvuelva ese valor y guarde el texto decodificado entre comillas, o bien déjelo codificado con el marcador delante. Hacer la mitad de cada cosa es lo que lo rompe. Ambas vías funcionan solo si el valor completo sobrevive a la copia.

Ambas direcciones son un comando cada una, y merece la pena guardarlos en el ticket como la operación exacta que produjo el valor almacenado. Ejecútelos en este orden:

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

Pegar texto codificado como si fuera plano es el error caro. El archivo aplica el hash a los caracteres exactamente como están escritos, la clave derivada sale aproximadamente un tercio más larga que la que calculó el par, y cada intento falla igual sin aviso, porque el analizador siguió la regla que se le dio.

Confirme qué bytes usa realmente cada par

Lea primero la visión del demonio sobre la conexión y después el resultado de la autenticación, en lugar de adivinar una causa a partir de la cadena de error. Comparar la longitud almacenada es una comprobación rápida de sensatez, porque el texto codificado es más largo que los bytes que representa. Después confirme qué fila de identidad coincidió, porque un secreto correcto archivado bajo el par equivocado falla igual que uno incorrecto. El orden de las filas lo decide: la primera coincidencia gana, así que una fila amplia %any cerca de arriba sustituye en silencio la fila concreta que acaba de editar.

Recargue en lugar de reiniciar cuando el archivo sea correcto. ipsec rereadsecrets refresca la copia del demonio IKE, y una instalación con swanctl carga las credenciales mediante su propio comando. Un reinicio descarta todas las asociaciones establecidas y destruye la comparación que intentaba hacer.

Ninguna de estas comprobaciones exige exponer el secreto. Una longitud, un selector de identidad y una posición de fila explican la mayoría de los fallos de este tipo antes de que nadie necesite un volcado hexadecimal.

Cambie el archivo sin ocultar el resultado

Restrinja el archivo a la cuenta del demonio y mantenga los secretos vivos fuera de los tickets, del chat y de las capturas de pantalla, porque una clave pegada es una filtración y no un diagnóstico. Además sobrevive al incidente que la produjo.

Pruebe desde un cliente cuya configuración controle, confirme que la autenticación tiene éxito y luego confirme que el túnel transporta tráfico. Una recarga que arregla el apretón de manos mientras el enrutamiento sigue roto es otro problema, y se hace visible en cuanto el secreto deja de moverse.