¿El par IPsec entrante no coincide con ningún perfil? Revise cuatro campos

Su par informa de que el túnel está levantado, su lado no muestra ninguna asociación de seguridad y el archivo de configuración contiene claramente un nombre de conexión coincidente. Las tres afirmaciones pueden ser ciertas a la vez. Una negociación entrante se compara con la configuración en ejecución, usando la dirección del par, la identidad que presenta y el tráfico que propone. Un archivo en disco que nunca se cargó, una identidad que no coincide con el valor esperado o un par de selectores desviado en un prefijo producirán silencio cada uno. Recorra los cuatro grupos de campos en el orden en que lo hace el respondedor.

Empiece por el paquete, no por el archivo

El respondedor recibe una solicitud IKE, busca una definición que pueda aceptar a este par y después continúa con la autenticación y la selección de tráfico. Si ninguna definición cargada coincide en el primer paso, la negociación termina antes de que llegue al usuario algún error útil.

Por eso «la configuración parece correcta» no es una prueba. La pregunta es qué ha cargado el servicio en ejecución y qué entrada seleccionó para este intento. Un listado de estado responde a eso con un solo comando, mientras que el búfer del editor responde a otra pregunta. Revise el listado antes de volver a cambiar el archivo.

Primer grupo de campos: la definición que realmente está cargada

Revise el estado en ejecución con la herramienta que es propietaria del demonio: un comando de estado que liste las conexiones cargadas, no el búfer del editor. Confirme que la entrada que espera está presente, que está habilitada para el comportamiento de arranque que desea y que se cargó después de su última edición. Un archivo guardado que no se ha recargado es la causa más habitual de «lo arreglé y no cambió nada».

Confirme también qué archivo lee el servicio. Las distribuciones difieren, y una conexión escrita en la inclusión equivocada se ignora en silencio en lugar de rechazarse. Si el listado de estado no muestra su entrada en absoluto, sospeche de la ruta de inclusión antes que de la sintaxis.

Segundo grupo de campos: los extremos no son identidades

La dirección desde la que se conecta el par y la identidad con la que se autentica son campos separados. Un nombre de host, un nombre distinguido, un identificador de clave y una dirección pueden servir todos como identidad IKE según la configuración, y no tienen por qué parecerse en absoluto a la dirección pública.

La coincidencia de extremos también puede implicar una vista NAT: la dirección vista en la red puede diferir de la dirección que el par cree tener. En el modelo de conexiones de libreswan, left y right son etiquetas de los dos participantes y no un orden fijo de local y remoto, y por eso copiar una configuración que funciona de otro sitio e intercambiar las direcciones no es una traducción fiable.

Anote la identidad esperada de cada lado y la credencial que la valida. Si esas dos líneas no coinciden, ninguna cantidad de ajuste de direcciones producirá una coincidencia.

Tercer grupo de campos: el tráfico que se protege

Los selectores describen los rangos internos de origen y destino, su familia de direcciones y cualquier restricción de protocolo o puerto. Una propuesta para la dirección de un solo host no es la misma solicitud que para una subred entera, y un respondedor configurado para la subred puede rechazarla o estrecharla.

Cuando los dos extremos no coinciden, compare el flujo previsto desde ambos puntos de vista en lugar de ampliar cada selector para que algo conecte. Pregunte a cada administrador qué flujo cree que protege y luego compare las dos respuestas. La discrepancia suele ser un prefijo de host en un lado y una subred en el otro. Un túnel que coincide porque ahora lo protege todo es una decisión de seguridad distinta, y que nadie ha aprobado.

Cuarto grupo de campos: está leyendo una implementación

Libreswan, el antiguo Openswan y strongSwan tienen herramientas de gestión distintas, sintaxis de configuración distinta y orden de coincidencia distinto. Un ejemplo que funciona en uno no dice nada preciso sobre la prioridad de selección de perfil o la redacción de errores de otro, así que verifique con la documentación del demonio de este host.

Correlacione un intento de principio a fin: la dirección de origen del iniciador, la identidad ofrecida y los selectores propuestos, frente al mensaje de selección del respondedor y la entrada cargada que nombra. Los contadores de encapsulación y desencapsulación a cero solo dicen que las asociaciones observadas no han transportado esos paquetes; no nombran el extremo que rechazó la propuesta ni demuestran que existiera una entrada coincidente en ese momento.

Tras una corrección coordinada, confirme el perfil y la asociación seleccionados y luego pruebe el servicio realmente permitido y su ruta de respuesta. Una coincidencia de perfil habilita la negociación, y la negociación no es la última comprobación de acceso.