La política de IPsec se está tragando tu tráfico local: cómo saberlo

La impresora del escritorio deja de responder en el momento en que el túnel se levanta, y nada en la configuración del túnel menciona la impresora. Lo que suele haber pasado es que se escribió un rango protegido lo bastante amplio como para incluirla, así que la máquina ahora intenta cifrar tráfico que debía quedarse en el segmento local. Leer la política instalada explica la captura; reducirla en el lugar correcto mantiene protegido el tráfico remoto. El recorrido desde la petición fallida hasta la política coincidente lleva unos minutos.

Sigue el flujo antes de cambiar un selector

Empieza por la petición que falla y anota cuatro valores: la dirección de origen que usa la máquina, el destino exacto, la ruta que elige el kernel y la política que coincide con ese par.

Esos cuatro datos deciden si la captura es deliberada o accidental. Un destino que cae dentro del selector remoto está protegido por diseño, aunque el diseño fuera erróneo. Un destino fuera de él que aun así se captura significa que algo más está coincidiendo, y cambiar el selector no ayudará. Ambos casos son habituales, y los distingue un solo comando.

Hazlo antes de editar nada, porque el caso interesante es la subred local que se solapa con un rango privado que la conexión protege. Prefijos conocidos como 192.168.0.0/16 aparecen en muchas redes, y un selector escrito para uno de ellos puede cubrir el tuyo sin que lo notes.

Tres tipos de local que se comportan distinto

Un destino asignado a este host, un destino en el mismo enlace y un destino detrás de otra interfaz son tres casos diferentes. El kernel trata cada uno de forma distinta cuando decide si el tráfico necesita protección.

El tráfico generado por la propia puerta de enlace tampoco es lo mismo que el tráfico reenviado desde un cliente. Una política que parece correcta para el tráfico reenviado puede capturar la propia sesión de administración de la puerta de enlace, y así es como un administrador pierde el acceso mientras arregla el túnel.

El hábito útil es nombrar el caso en voz alta: ¿este paquete viene de mí, va a mi enlace o pasa por mí? Cada respuesta apunta a un lugar distinto donde reducir. Escribir el caso también evita que la siguiente persona repita el mismo trabajo.

Cuando el rango protegido es todo un espacio privado, los tres casos pueden caer dentro a la vez, y el síntoma pasa a ser una máquina que no alcanza nada salvo el extremo del túnel.

Lee la política instalada, no el archivo

Los archivos de configuración describen la intención; el kernel guarda las políticas que coinciden de verdad. Muestra ambos y trata una discrepancia como el primer hallazgo.

Estos comandos muestran la ruta elegida para el destino y las políticas instaladas en cada dirección:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

La ruta te dice qué interfaz usaría el paquete. La lista de políticas te dice si después se aplica una plantilla a ese paquete, y el listado de conexiones muestra qué selectores cree haber instalado el demonio. Si el destino aparece en un selector remoto, has encontrado la captura sin adivinar.

Reduce el selector o evita el destino

Hay dos reparaciones admitidas y responden a preguntas distintas. Reducir el selector dice que esta conexión solo protege un rango menor, lo cual es correcto cuando el rango amplio fue un error. Añadir una excepción dice que este destino concreto no debe protegerse nunca, lo cual es correcto cuando el rango protegido es realmente amplio y un destino es la excepción.

Elige la primera cuando puedas, porque un selector más pequeño es más fácil de razonar y aparece en la definición de la conexión. Elige la segunda cuando el rango amplio sea intencionado y la excepción sea un host o una subred que puedas nombrar.

Ambas pertenecen a la configuración dueña de la conexión. Una regla en tiempo de ejecución añadida a mano desaparece en la siguiente reconexión, y el fallo vuelve en un momento en que nadie recuerda el apaño.

Excepciones que sobreviven a una reinstalación

Después del cambio, repite la misma petición inofensiva y mira los mismos contadores. El destino local debería responder, y el destino remoto previsto debería seguir mostrando tráfico cifrado.

Estas dos comprobaciones confirman que la excepción sobrevivió y que la protección no:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Luego desconecta y reconecta el túnel a propósito, y repite ambas. Una excepción que funciona antes de la reconexión y falla después se aplicó en la capa equivocada, que es la forma más habitual de que este problema vuelva.