Lista de permitidos de extremos VPN: la actualización de DNS que olvidaste

Escribir vpn.example.com en una excepción de cortafuegos se siente como suscribirse a DNS. Lo que suele ocurrir es una traducción al cargar, tras la cual la regla guarda direcciones y nada las actualiza. Dos componentes comparten ahora el trabajo: el resolutor que responde y el cortafuegos que almacena. La mayoría de las caídas de extremos empiezan donde esa entrega nunca se diseñó.

Un nombre de host en una regla no es una suscripción en vivo

Algunas herramientas resuelven un nombre cuando se carga la configuración; otras conservan un nombre de host y lo vuelven a resolver según su propio calendario; otras solo aceptan direcciones. La configuración visible rara vez dice cuál. Los ejemplos de la documentación suelen suponer el caso de carga, por eso la diferencia sorprende a la gente durante una migración. Lee el comportamiento de la implementación antes de suponer que se notará un cambio de dirección, porque una lista de permitidos obsoleta se ve exactamente como una que funciona hasta que el extremo se mueve.

Una regla que nombra el host correcto aún puede permitir la dirección equivocada. Esa brecha es el mito, no un error de ortografía.

El TTL de la caché no es el temporizador de tu cortafuegos

Los registros DNS tienen un tiempo de vida, y los resolutores almacenan respuestas en caché durante ese periodo. La especificación DNS define ese comportamiento de caché, pero rige los datos DNS, no el almacén de direcciones separado de un cortafuegos. Un TTL corto no crea una tarea de actualización donde no existe. El almacenamiento en caché también ocurre en más de una capa, así que la respuesta que ve un terminal puede no ser la que vio el cortafuegos.

Haz tres preguntas al producto real: cuándo resuelve, dónde guarda el resultado y qué desencadena una actualización. Si la respuesta solo es al arrancar, una sesión longeva puede sobrevivir a la dirección a la que se la admitió.

dig +short vpn.example.com
resolvectl query vpn.example.com

Diseña la actualización y el fallo como una sola política

Una excepción mantenida necesita respuestas explícitas: qué desencadena una actualización antes de que el cliente elija una dirección nueva, cómo cambia el conjunto permitido sin abrir una ventana temporal amplia y cuándo se eliminan las entradas obsoletas. Escribe esas respuestas junto a la regla.

Elige el comportamiento ante fallos deliberadamente. Conservar la dirección antigua puede preservar una sesión y dejar un permiso obsoleto; vaciar el conjunto puede bloquear la recuperación. Ninguno debería ser un resultado accidental de una búsqueda fallida. Escribe el comportamiento elegido en el runbook para que el siguiente operador no improvise bajo presión.

Mantén también estrecho el DNS de arranque. Una excepción incondicional de resolutor público es una ruta DNS directa para todo lo que coincide, no solo para el nombre del extremo.

Demuestra el cambio del extremo, no la primera conexión

Usa el gestor compatible del cliente si ya coordina la resolución y el bloqueo. En un host PF gestionado por el sitio, mantén la propiedad y el plan de recuperación del sitio en lugar de copiar la sintaxis de la tabla de nombres de host de otra plataforma con un comportamiento de ciclo de vida distinto.

Con una prueba aprobada e inocua, compara la dirección que selecciona el cliente con el conjunto permitido activo antes y después de un cambio controlado. Cubre una búsqueda fallida, la eliminación de una entrada que ya no es válida y, cuando se admita, una familia de direcciones distinta. El túnel previsto debería recuperarse mientras el tráfico directo no relacionado permanece bajo la política. Una primera conexión correcta solo demuestra que la traducción inicial resultó correcta por casualidad.