Selectores de tráfico de IPsec: qué cubren y qué no

Los selectores de tráfico nombran el tráfico interior que protege un acuerdo de IPsec, y el par se negocia en lugar de suponerse. Dos extremos pueden autenticarse perfectamente entre sí y aun así discrepar sobre qué paquetes pertenecen dentro del túnel. Esa discrepancia es invisible en el estado de la conexión, que normalmente informa de un túnel sano. Leer los selectores desde ambos extremos y luego perseguir un destino lo encuentra más rápido que cualquier cantidad de edición de política.

Léelos desde ambos extremos

Cada extremo describe su propio lado como local y el otro lado como remoto. El mismo par de prefijos aparece por tanto intercambiado en las dos configuraciones, y eso es correcto y no contradictorio. Invertir la perspectiva es lo primero que hay que hacer cuando un acuerdo que funciona parece equivocado sobre el papel. Comparar dos archivos uno al lado del otro sin intercambiarlos produce una discrepancia que no existe.

Los valores no siempre son subredes únicas. Los selectores de IKEv2 pueden llevar rangos de direcciones, números de protocolo y rangos de puertos, y así es como una política protege un servicio en lugar de toda una red. Un selector más estrecho que el tráfico previsto produce un túnel que transporta algunos destinos y excluye otros en silencio.

Escribe ambos lados en una tabla antes de cambiar nada. El ejercicio suele resolver la cuestión sin tocar ningún archivo de configuración.

El estrechamiento es decisión del respondedor

El iniciador propone, y el respondedor puede aceptar solo un subconjunto. IKEv2 permite al respondedor estrechar los selectores de tráfico ofrecidos, y el resultado estrechado es lo que realmente se instala. Leer la configuración del iniciador describe, por tanto, una oferta, no el acuerdo.

Por eso una subred añadida al cliente puede producir un túnel que funciona y que aun así rechaza el nuevo destino. El servidor estrechó la oferta hasta lo que su política permite, mientras el archivo del cliente todavía enumera el rango más amplio. Solo el estado negociado muestra la verdad: en Linux, ip xfrm policy y la lista de child SA en la documentación de IKEv2 de strongSwan informan de lo instalado y no de lo solicitado. Cuando los dos discrepan, la política del respondedor es la que hay que cambiar.

Una propuesta rechazada es un síntoma distinto de una estrechada. El rechazo aparece en el registro de negociación y no deja ninguna asociación child.

Sigue un destino de extremo a extremo

Elige un destino real junto con la dirección de origen que el cliente usaría para él, y luego sigue ese par por tres decisiones independientes. La ruta elige un camino, el selector decide si ese camino está protegido, y el cortafuegos decide si el paquete está permitido. Cada uno puede fallar por su cuenta, y un selector amplio no repara ninguno de los otros.

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

La consulta de ruta nombra la interfaz y la dirección de origen que llevarían el paquete. La lista de políticas muestra si existe una política de túnel coincidente para ese par, incluida su dirección y su nivel. La lista de SA muestra los selectores child negociados junto con contadores, así que una asociación child con cero paquetes tras haber intentado tráfico es la firma de selectores que excluyen lo que se envía. Tres órdenes, tres respuestas distintas, y solo una de ellas explica una caída silenciosa.

Si los contadores child se mueven mientras la aplicación sigue fallando, el problema está más allá del túnel. Eso traslada la investigación al receptor o al cortafuegos del host remoto y no a los selectores.

Mantén los dos objetivos separados

Proteger una subred de oficina y enviar toda la navegación por una salida remota son requisitos distintos con selectores distintos. Un perfil construido para uno rara vez sirve para el otro, y mezclarlos produce o una fuga o una división rota. Ampliar el rango protegido significa cambiar ambos extremos y su política de reenvío, porque un cambio unilateral se convierte en una propuesta rechazada. Es la forma más común de que un túnel que funcionaba deje de funcionar tras una edición pequeña.

Los selectores describen la cobertura criptográfica, las rutas eligen caminos, y las aplicaciones imponen sus propios permisos. Un túnel que lo cubre todo sigue sin poder alcanzar un servicio ligado a loopback, y una ruta hacia el túnel sigue necesitando un selector que incluya el destino. Comprueba los tres contra la misma petición de prueba, y la discrepancia se nombrará sola.