strongSwan EAP: la identidad IKE frente al nombre AAA esperado

La autenticación EAP sobre IKEv2 puede pedir a un cliente que valide dos nombres de servidor distintos en una sola conexión. La puerta de enlace que termina IKE presenta una identidad, y el backend EAP que termina el intercambio TLS interno puede presentar otra. En strongSwan viven en bloques de configuración distintos, y poner un nombre en el bloque equivocado produce un fallo que parece un problema de certificado. Leer qué validación falló es lo que te dice qué bloque editar.

Una conexión, dos identidades de servidor

La primera identidad pertenece al intercambio IKE. El cliente marca una dirección y espera que el par demuestre una identidad concreta, normalmente el nombre del certificado de la puerta de enlace.

La segunda pertenece a EAP. Con PEAP o TTLS, el cliente construye un túnel TLS hacia el servidor de autenticación dentro de la IKE SA, y ese servidor interno presenta su propio certificado. Cuando el backend es un host aparte, su nombre difiere del de la puerta de enlace. Un cliente que solo comprueba el primer nombre acepta lo que afirme el segundo. Y un cliente configurado con un solo nombre en ambos sitios falla en cuanto los dos difieren de verdad.

Ambos nombres proceden de la configuración del operador, no del certificado que hace desaparecer el error. Preguntar al operador por los detalles del despliegue es más rápido que adivinar dos nombres de host.

Qué campo pertenece a qué capa

En swanctl, la dirección y la identidad IKE son ajustes separados, y la identidad EAP es un tercero.

La dirección remota elige adónde van los paquetes, y la identidad remota indica qué debe demostrar el par. La expectativa EAP se escribe bajo el bloque local, porque describe el intercambio EAP de este cliente y no el comportamiento IKE del par. Esa ubicación es la parte que la gente lee mal. El nombre está en la configuración del cliente mientras describe un servidor, y por eso mismo parece fuera de lugar.

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

Ese fragmento no es una conexión completa; el material de confianza, las credenciales y las políticas de las conexiones hijas todavía deben estar presentes. Copiarlo tal cual en un archivo de trabajo sustituiría ajustes que aún necesitas.

Por qué aaa_id vive bajo local

El bloque local describe qué hace este extremo durante la autenticación, incluido el método que usará y la identidad que espera que el otro extremo presente para ese método. Nada en él afirma que el servidor AAA se ejecute en la misma máquina.

El valor predeterminado agudiza la trampa. Cuando no se fija un valor explícito, la identidad AAA esperada sigue a la identidad remota, así que un despliegue con un solo nombre funciona y oculta la distinción. Un valor explícito solo importa cuando el despliegue EAP termina de verdad en otro sitio. Fijarlo a un nombre distinto sin ese motivo crea un fallo que el operador no puede reproducir. Lee el despliegue antes de inventar un segundo nombre.

Mantén el valor idéntico a lo que afirma realmente el certificado del backend, incluida la forma del nombre. Un punto final o un comodín que no cubra el host basta para que falle la comprobación.

Interfaces que no pueden expresar la separación

Un perfil de NetworkManager no es la misma interfaz de configuración que swanctl. El complemento que hay detrás expone un conjunto más estrecho de controles de identidad, y cuáles existen depende de la versión instalada.

Eso importa cuando el despliegue necesita de verdad dos nombres. Un campo etiquetado como identidad del servidor puede configurar una capa y no la otra, así que un perfil puede parecer correcto y aun así fallar la comprobación interna. Comprueba qué admite el complemento instalado antes de suponer que el perfil puede expresar esa disposición. Si no puede, la elección es del operador: una vía de aprovisionamiento distinta o un diseño corregido de la identidad del servidor. Debilitar PEAP o aceptar cualquier nombre cambia la política de autenticación en lugar de arreglarla.

La alternativa no es algo que inventar en el cliente. Pide por escrito la disposición admitida y luego guarda esa respuesta con el perfil.

Distingue una discrepancia de identidad de un certificado caducado

Una discrepancia de nombre y un certificado caducado son fallos distintos, y el registro los distingue. Lee el mensaje antes de decidir qué campo cambiar.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

Fijar la identidad AAA prevista no renueva un certificado ni establece confianza en su emisor, y renovar un certificado no corrige un nombre esperado equivocado. Lee qué validación falló antes de editar otro campo de identidad. Después recarga la configuración y confirma que la conexión cargada muestra el valor que fijaste, porque un archivo editado que nunca se cargó no cambia nada. Escribe ambos nombres y sus capas en las notas del despliegue.