Identidad IKE o dirección de extremo: no las confundas

Lee un campo etiquetado como identidad FQDN como una cadena literal, no como una petición del nombre de DNS inverso de tu dirección pública. En el analizador de strongSwan es exactamente eso, una cadena, y leerlo nunca lo resuelve a un extremo. Ese hecho por sí solo elimina la distracción más habitual cuando eliges identificadores para un peer. Las comprobaciones siguientes evitan que los tres valores implicados se fundan en uno.

Una etiqueta no es una consulta

Las interfaces de los fabricantes usan palabras como FQDN y hostname con laxitud, y la etiqueta de una caja no dice nada sobre la codificación que hay detrás. Un equipo que llama a un campo Client FQDN puede enviar un FQDN, una cadena con forma de correo o una dirección desnuda. Trata el texto y el tipo como dos decisiones separadas y registra ambas.

Nada de una identidad literal requiere DNS. Es una afirmación que comprueba el otro extremo, no un nombre que la red tenga que resolver.

Tres valores separados, escritos por separado

Tres tareas se esconden tras una sola pantalla de configuración, y fusionarlas es el error caro. Un valor es la dirección del extremo, que decide adónde van los paquetes. Otro es la identidad local que presenta este peer, y el tercero es la identidad que esperas del otro extremo antes de autenticarlo. Escríbelos como tres líneas en el ticket de cambio, porque cualquier cosa menos que eso describe una VPN y no una relación.

Las identidades de ejemplo deben elegirse y autorizarse como parte del despliegue. Son afirmaciones que la autenticación verifica, no credenciales que hagan fiable a ningún peer, así que una cadena que parece plausible no autoriza nada.

El tipo forma parte del valor

La referencia de identidades de strongSwan separa FQDN, valores con forma de correo, direcciones IP y otras codificaciones, así que la codificación importa tanto como los caracteres. Dos dispositivos pueden aceptar el mismo texto con tipos distintos y aun así rechazarse. Una nota que registra el valor sin su tipo es media configuración.

Pregunta al fabricante qué tipo envía realmente el equipo y confírmalo con una decodificación, no con la etiqueta de la interfaz. Un tipo adivinado es una discrepancia esperando el próximo cambio.

Cada lado tiene que satisfacer al otro

La identidad local de cada lado tiene que pasar la política de autenticación del otro lado. Eso no es lo mismo que pegar una cadena en cada casilla de identidad de ambos dispositivos, que es el atajo que produce una configuración que nadie puede depurar.

La autenticación con certificado añade requisitos propios, porque la identidad del certificado y las condiciones de confianza están junto a la identidad IKE que escribiste. Una coincidencia de identidad IKE por sí sola no autoriza a un peer con certificado.

Dónde importa el DNS y qué impone tu versión

Un hostname de pasarela usado para el descubrimiento sí necesita DNS funcionando, y ese requisito pertenece a la búsqueda del extremo y no a ninguna consulta inversa de una identidad escrita. Mantén los dos aparte en el ticket, porque un fallo de descubrimiento y una discrepancia de identidad se leen de forma parecida en un registro de cliente y se reparan en lugares distintos.

Lee el analizador del producto y la versión que realmente ejecutas antes de copiar sintaxis que fuerza un tipo, porque las versiones antiguas de strongSwan se comportaban distinto y otros fabricantes añaden restricciones propias. Cuando compares los dos extremos, mantén cuatro cosas juntas: identidad esperada, identidad presentada, tipo y el error de autenticación. Ese conjunto convierte una discrepancia en evidencia en lugar de una opinión.