Nombre de punto final de VPN frente a nombre de servicio privado: dos responsables

Dos nombres pueden describir la misma sucursal y responder preguntas completamente distintas. vpn.branch.example indica a un par remoto dónde encontrar el punto final de VPN, y debe resolverse antes de que exista ningún túnel. inventory.branch.example indica a un usuario autorizado dónde vive una aplicación privada, y solo importa una vez que el túnel está levantado. Mantener uno de ellos no hace nada por el otro.

Nombre los dos registros antes de depurar cualquiera de ellos

Anote ambos con sus responsables. Para el punto final, registre quién actualiza la dirección pública y cómo el cliente VPN refresca su respuesta. Para el servicio, registre quién es dueño de la dirección privada, qué zona contiene el registro y qué resolutores deben responder por él.

Esa lista corta evita el diagnóstico erróneo más común en este ámbito: reiniciar un túnel de sucursal que funciona para reparar un registro que vive por completo dentro de él. El túnel es el transporte del nombre del servicio; no es su autoridad.

Cuando se propone un cambio, pregunte cuál de los dos registros toca. Si nadie puede responder, el cambio no está listo para programarse.

El punto final debe resolverse antes de que exista ningún túnel

Suponga que la conexión a internet de la sucursal recibe una dirección pública nueva. El actualizador del punto final publica la dirección nueva, y la implementación remota de VPN debe poder leer la respuesta cambiada. Cualquier resolutor que proporcione esa respuesta debe ser alcanzable sin el túnel, o el cliente persigue un nombre que solo puede resolver después de conectarse a lo que no puede encontrar.

Esa dependencia de arranque merece decirse con claridad, porque es fácil crearla por accidente cuando todos los resolutores internos están detrás de la VPN. Mantenga una ruta previa al túnel para la consulta del punto final y confirme el comportamiento de reconexión del cliente en lugar de suponer que una respuesta nueva se recoge de inmediato.

El DNS dinámico también tiene límites que la actualización del registro no puede cruzar. Actualizar un registro no abre ningún puerto de cortafuegos, no crea ninguna asignación NAT y no demuestra ninguna identidad de par. Una dirección publicada con un puerto cerrado da un cliente que resuelve correctamente y aun así no puede conectarse a nada.

Por último, un cliente en ejecución puede seguir usando un punto final en caché hasta que se reconecte. Separe la publicación, la caché y la política de reconexión en sus notas, para que un par obsoleto no se confunda con un actualizador averiado.

El nombre del servicio describe dónde vive la aplicación

Ahora suponga que el túnel se mantiene sano pero el servidor de inventario se traslada de 172.26.14.20 a 172.26.14.35. El registro público del punto final no se ve afectado, mientras que el registro privado del servicio debe cambiar. Usar una dirección reservada para ese servicio, o una asignación estática, hace que esto sea más raro; una ruta de actualización autorizada cubre las veces en que eso es intencionado.

Aquí se confunden dos mecanismos de actualización. RFC 2136 define un protocolo para añadir y eliminar registros DNS en una zona, mientras que un proveedor comercial de DNS dinámico puede exponer una API HTTP completamente distinta para otro propósito. Usar uno no implica que el otro exista en su entorno. Compruebe qué mecanismo acepta realmente su zona antes de escribir un actualizador contra él.

Una respuesta privada correcta es solo la primera condición. Para que un llamador remoto la use, el cliente necesita un resolutor que porte la zona privada, una política que permita consultas a ese resolutor y reenvío para la dirección que vuelve. Un nombre que resuelve a una dirección que el cliente no puede alcanzar produce un tiempo de espera que parece un fallo del servidor.

Pruebe las dos rutas por separado

Compruebe el punto final desde fuera del túnel y el servicio desde dentro, y guarde los resultados como dos hechos independientes:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Si falla la primera consulta, el problema es la publicación pública o la ruta de resolución previa al túnel, y ningún cambio interno ayudará. Si la segunda devuelve una dirección pero la tercera no muestra ninguna ruta por el túnel, la capa DNS está bien y la política de reenvío no.

Ejecute el par después de cada cambio de dirección y anote qué registro se movió. Un traspaso que solo dice «se actualizó el DNS» deja al siguiente ingeniero adivinando cuál de los dos ciclos de vida se ejecutó realmente.