Una regla de dominio VPN se rompe cuando un CDN cambia sus direcciones

Copias la dirección de una consulta en tu regla de enrutamiento, el sitio funciona y una semana después ya no. Nada de la regla ha cambiado. El servicio se movió a otra dirección de borde, el cliente resolvió otro nombre de host o la sesión pasó a IPv6. La decisión que tienes delante es si una regla basada en el nombre o un rango explícito es el instrumento adecuado para este servicio, y tres condiciones lo resuelven. Lo que sigue separa el nombre de la dirección, porque solo uno de los dos es estable.

Por qué una consulta no es un inventario

Una red de distribución de contenido responde con una dirección elegida para el resolutor, la región y el momento. Pregunta dos veces desde redes distintas y puedes obtener respuestas distintas. Pregunta una vez y trata la respuesta como la lista de direcciones del servicio, y la regla que escribas será una instantánea, no una regla. Ese es todo el problema de tratar una respuesta DNS como configuración.

Hay una segunda laguna. Un solo nombre de host visible rara vez cubre toda la aplicación, porque el inicio de sesión, los medios y el tráfico de API suelen usar nombres separados. Una regla construida a partir del nombre de host de la barra de direcciones puede cubrir la página y perder el vídeo, lo que se lee como un fallo parcial y no como un error de enrutamiento.

La tercera laguna es la familia de direcciones. Una regla solo para v4 no dice nada sobre el registro AAAA que el cliente puede preferir.

Tres condiciones que deciden regla de dominio o rangos

Primero, ¿publica el servicio un conjunto estable de prefijos que puedas poseer y documentar? Si lo hace, los rangos explícitos son honestos y baratos. Si no lo hace, una regla de dominio es el único mecanismo que puede seguir al servicio.

Segundo, ¿se actualiza el mecanismo de dominio de tu cliente? Una regla que se resuelve una vez al conectar y nunca más es una instantánea con mejor imagen de marca. Tercero, ¿el mecanismo cubre subdominios y ambas familias de direcciones, o solo los nombres que escribiste?

Responde esas tres y la elección suele ser obvia. Adivinar produce una regla que funciona en pruebas y falla en producción.

Prueba una sesión, no una página

Carga la página y luego realiza la operación que importa: iniciar sesión, empezar la reproducción, subir un archivo. Cada una puede llegar a un host distinto, y la que falla es la que tu regla pasó por alto.

Enumera con qué contacta realmente la sesión en lugar de qué muestra la página:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

Mantén visible el resolutor durante la comparación, porque una regla que funciona desde un resolutor y falla desde otro te habla de la respuesta del CDN, no del túnel. Un TTL corto también significa que la respuesta que registraste tiene fecha de caducidad.

Qué cubre realmente cada mecanismo

Los dos mecanismos parecen intercambiables en una página de ajustes y se comportan de forma distinta por dentro.

Una ruta de dirección del núcleo hace coincidir prefijos. No tiene idea de qué es un nombre de host, así que no puede seguir un servicio que cambia de direcciones. Una regla de dominio resuelve nombres y enruta el resultado; sigue al servicio, pero depende del resolutor, del comportamiento de actualización y del manejo de los subdominios por parte del cliente, así que una regla que sigue nombres debe probarse con el resolutor que el cliente usa realmente.

Ninguna es un superconjunto de la otra, y por eso mezclarlas sin una nota genera confusión más adelante.

Vuelve a comprobar cuando el servicio cambie

Tras una actualización del cliente o un cambio del servicio, ejecuta de nuevo la misma prueba de sesión. Una lista de direcciones que antes funcionaba es evidencia de aquel periodo, no un inventario permanente de la infraestructura del servicio.

Anota qué mecanismo cubre qué nombre de host y la fecha de la última verificación.

Esa nota es la diferencia entre una regla que puedes defender y una regla que nadie se atreve a tocar. Si el servicio publica su propia lista de prefijos, úsala y cita la fecha. Si no lo hace, dilo, y mantén la regla de dominio con su comportamiento de actualización escrito al lado.