Por qué tu regla de túnel dividido dejó de coincidir con un servicio

El túnel dividido suele fallar de una de dos maneras. O el tráfico que debería ir dentro del túnel lo rodea, o el tráfico que debería quedarse fuera acaba dentro. El fallo de la regla obsoleta es el primero, y es el más confuso, porque la regla se aplica exactamente como está escrita. Lo que cambió es el destino: el servicio ahora responde en una dirección que la regla nunca nombró, y nada en el túnel está mal.

Qué fija la regla y qué devuelve el DNS

Una regla de túnel dividido es una afirmación estática sobre destinos, normalmente expresada como un prefijo, una ruta o una lista de direcciones. Se evalúa contra el destino del paquete en el momento del envío. Un nombre de host es una consulta que devuelve un conjunto de direcciones con una vigencia y una caché, y la respuesta puede variar según el resolutor, el tipo de consulta y el minuto.

Esos dos objetos nunca negocian entre sí. La regla sigue coincidiendo con el prefijo que recibió, el servicio sigue cambiando la dirección que entrega, y la brecha entre ambos se ensancha en silencio. Por eso el síntoma aparece tras una migración del proveedor o una renovación de certificado y no tras un cambio de configuración. Nadie editó el túnel, así que nadie mira el túnel, y el diagnóstico se desplaza hacia la aplicación en lugar de la política.

Tres formas en que se rompe la coincidencia

El caso obvio es un servicio que se trasladó: el operador le dio otra dirección, el DNS siguió, y la excepción no. El segundo es una familia de direcciones que la regla nunca cubrió, lo que ocurre cuando un nombre empieza a devolver registros AAAA que una excepción solo para IPv4 ignora. El tercero es una diferencia de resolutor: una vista interna y una pública pueden devolver direcciones distintas para el mismo nombre, así que la dirección que usa tu aplicación no es la que usaste para probar.

Una conexión en caché es una cuarta variante y es fácil de pasar por alto. La aplicación puede seguir hablando con una dirección que resolvió hace una hora, lo que significa que tu consulta reciente y su socket abierto no coinciden en dónde vive el servicio.

Lee el destino que la aplicación usa de verdad

Pregunta al sistema operativo y a la tabla de sockets, no a una pestaña del navegador. La consulta responde a qué resuelve el nombre ahora mismo, y la tabla de sockets muestra la dirección a la que está conectado el proceso, que puede ser más antigua. Ejecuta ambas antes de formar una teoría, porque la diferencia entre ellas es en sí misma la respuesta en aproximadamente la mitad de los casos.

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

Luego compara con lo que cubre la regla. Si la dirección actual queda fuera de la excepción y la solicitud sigue fallando, has encontrado la causa sin tocar la configuración del túnel. Si la aplicación está conectada a una dirección que coincide con la regla y la solicitud sigue fallando, el problema está más allá del túnel y esta es la investigación equivocada.

Repara el mecanismo, no el síntoma

Si el producto admite direccionamiento mantenido basado en dominios, úsalo y sigue su comportamiento documentado de actualización y alcance. Eso sustituye una conjetura estática por una respuesta mantenida, a costa de depender de que la función funcione como se documenta.

Si el diseño se apoya en una lista estática, dale un responsable y un plan de actualización. Ese plan debería decir cómo se descubre la dirección, quién aprueba el cambio y con qué rapidez se espera que la lista siga una migración del proveedor. Una lista sin responsable es una futura caída con una causa conocida.

No amplíes la excepción a una gran red vecina solo para capturar cada dirección que viste durante una prueba corta. Eso no es una reparación; es un cambio permanente en la frontera de seguridad, y dejará que servicios no relacionados eviten el túnel en silencio mientras la regla exista.

Verifica las dos mitades de la intención

Un diseño de túnel dividido tiene dos intenciones, y una reparación debería preservar ambas. El servicio protegido debe pasar por el túnel, y las categorías excluidas deben seguir rodeándolo. Prueba una conexión nueva al destino reparado y luego prueba algo que se supone que debe quedarse fuera.

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

Anota la nueva dirección, el mecanismo que elegiste y la fecha. Esa nota es lo que impide que la siguiente persona concluya que la VPN ignoró al azar su propia configuración.