Clave precompartida IPsec: los bytes detrás de la cadena que escribió
Dos extremos pueden tener cadenas que parecen idénticas y derivar claves distintas. Compruebe el tipo de campo, cualquier codificación y los bytes finales antes de debilitar nada.
Dos administradores comparan el secreto en la pantalla, coinciden en que son iguales, y el túnel sigue fallando la autenticación. La cadena que compararon no es el valor que ninguno de los dos extremos introduce en la derivación de claves. Entre los caracteres que ve y los bytes que el protocolo aplica al hash hay un tipo de campo, una codificación de texto, un editor y un portapapeles, y cualquiera de los cuatro puede cambiar la entrada sin cambiar su aspecto. Compare los bytes y el desacuerdo suele aparecer en segundos.
Qué hace la puerta de enlace con la cadena
Una clave precompartida no se envía por el cable y se compara. Cada extremo introduce su copia local en la derivación de claves para el intercambio IKE, y las cargas útiles de autenticación resultantes se verifican o no. Ese diseño implica que las dos copias deben ser idénticas byte a byte en lugar de visualmente similares, y también implica que el fallo se informa en la etapa de autenticación en lugar de como un mensaje de contraseña incorrecta.
Así que la pregunta útil nunca es si estas se ven iguales, sino qué secuencia exacta de bytes aplica al hash cada implementación.
De dónde vienen los bytes adicionales
Un salto de línea final es el culpable clásico, y se esconde a plena vista porque la mayoría de los editores añaden uno de forma invisible al guardar un archivo. Un espacio inicial o final pegado desde una ventana de chat hace lo mismo, y también lo hace una comilla tipográfica sustituida por una recta por un procesador de textos. Nada de eso cambia la comparación visual que hace una persona.
Compare con una herramienta que muestre bytes en lugar de glifos. printf '%s' "$PSK" | xxd | tail -2 imprime la cola del valor en hexadecimal, donde un 0a o un 20 extraviado es evidente. Hágalo en ambos extremos y compare los dos volcados lado a lado. Hágalo con material de prueba generado, no con un secreto de producción que luego deje en el historial del intérprete de órdenes.
Codificado no es cifrado
Las exportaciones de configuración suelen llevar el secreto en una codificación base, a veces con saltos de línea cada sesenta o setenta y seis caracteres y a veces con relleno. Si un extremo espera los bytes decodificados y usted pega el texto codificado, no ha enviado una contraseña distinta, ha enviado una mucho más larga formada por caracteres imprimibles. Base64 no ofrece ninguna confidencialidad, y por eso un secreto codificado nunca debe pegarse en un foro para pedir una segunda opinión.
El diccionario IPSec de Apple es un buen ejemplo de que el tipo importa: documenta SharedSecret como dato para el método de autenticación con secreto compartido en las cargas útiles L2TP y Cisco IPsec. Es una propiedad concreta en una carga útil concreta, no un campo de texto general que pueda reutilizar para otro protocolo que casualmente pida un secreto.
Un límite supuesto pertenece a una combinación
Los informes antiguos de un techo de treinta y dos caracteres en un cliente de Apple son informes reales sobre una versión de cliente, un protocolo y una forma de perfil. No son un límite universal para cada plataforma de Apple, cada proveedor y cada protocolo. Verifique la versión, el tipo de carga útil y el requisito de la puerta de enlace juntos, y luego pruebe con una configuración aprobada en lugar de inferir de un hilo. Escriba la combinación probada en el registro de cambios, porque de lo contrario la siguiente persona citará el mismo hilo con más confianza de la que merece.
Si un límite se aplica de verdad, la respuesta es un diseño de credenciales compatible que encaje en él, no una versión acortada de un secreto fuerte. Truncar una clave de producción para satisfacer un límite supuesto reduce su fuerza de forma permanente y produce un sistema cuya documentación ya no coincide con su seguridad.
Corrija la representación, no la fuerza
Cuando la autenticación falla después de confirmar la representación, lea la política efectiva en la etapa de autenticación: qué método se negocia, qué identidad de par se espera y si la puerta de enlace coincide con la conexión que usted cree. Las conjeturas cada vez más débiles no son diagnóstico, son una degradación lenta con un tique de soporte adjunto.
Si la credencial requerida no puede cumplir el estándar de la organización, cambie el diseño por uno que sí pueda. Un secreto compartido con suficiente entropía, generado una vez, guardado en un campo gestionado y nunca publicado, es una respuesta perfectamente buena; una versión más corta no lo es.