Cómo configurar un DNS de horizonte dividido para acceder a aplicaciones internas y remotas

Usa el mismo nombre de host de la aplicación en todas partes, pero devuelve una dirección de proxy privada a los clientes internos y VPN de confianza, y el punto de conexión público o del túnel a los clientes externos. Mantén idéntico el nombre TLS en ambas rutas.

El DNS de horizonte dividido es útil cuando NAT loopback no está disponible o cuando el tráfico local debe permanecer en la LAN. Falla cuando los clientes omiten el resolver previsto, persisten respuestas obsoletas o el punto de conexión interno sirve un certificado diferente. Define las dos vistas, reduce los TTL antes de la migración y prueba la resolución por separado de HTTPS.

Define las vistas interna y externa

Elige un FQDN para cada aplicación. En el DNS público, apúntalo al proxy, túnel o gateway accesible externamente; en el DNS interno, sobrescríbelo con la dirección privada del proxy local.

No crees un nombre de host diferente, exclusivo para uso interno, solo para evitar el trabajo con certificados, a menos que la aplicación admita dos URL canónicas. Un solo nombre mantiene coherentes los marcadores, las devoluciones de llamada y los clientes móviles cuando cambia la ubicación.

Documenta qué subredes reciben la vista interna. Es posible que las redes de invitados necesiten la respuesta pública, mientras que la LAN de confianza y los clientes VPN de acceso remoto reciben la respuesta privada a través del resolver que tienen asignado.

Haz determinista la selección del resolver

Anuncia el resolver interno mediante DHCP y mediante el perfil de VPN. Consúltalo explícitamente primero y, después, consulta a través del sistema operativo para detectar una caché local o un desvío mediante DNS cifrado.

Las cachés de los resolvers y las distintas bibliotecas DNS pueden producir resultados inesperados; este catálogo de fallos comunes del DNS explica por qué un cambio autoritativo puede no aparecer de inmediato en el cliente.

Vacía solo las cachés pertinentes después de confirmar que el registro es correcto en el origen. Si un navegador administrado usa su propio resolver cifrado, aplica una política aprobada o acepta la ruta pública en lugar de editar repetidamente la zona local.

Alinea el proxy, el certificado y el comportamiento de la aplicación

Ambos puntos de conexión deben presentar un certificado válido para el FQDN compartido y dirigir ese host a la misma identidad de aplicación. Una advertencia de certificado significa que el DNS llegó a un punto de conexión, pero este no está configurado para el nombre solicitado.

Verifica las redirecciones, los WebSockets, las URL de devolución de llamada y la URL externa de la aplicación. Un proxy local que redirige a una dirección IP o a un nombre de host diferente invalida el diseño de un solo nombre.

Si la aplicación usa una subruta, mantén sincronizadas su URL base y la ruta del proxy. La lista de comprobación de ZimaSpace para las actualizaciones del contenedor de Jellyfin ayuda a conservar la configuración del proxy, los montajes y las URL antes de realizar un cambio.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Prueba las transiciones entre el acceso interno y remoto

En una red Wi-Fi, registra el servidor DNS, la dirección devuelta, el certificado y el resultado de la aplicación. Repite la prueba con datos móviles y la Wi-Fi desactivada; la dirección debería cambiar, mientras que el nombre de host y la identidad del certificado deben mantenerse iguales.

Conéctate a la VPN desde una red externa y repite la prueba. Si la VPN debe usar la ruta privada, pero recibe la respuesta pública, corrige la asignación de DNS o el enrutamiento antes de cambiar la configuración de la aplicación.

Por último, mueve un cliente entre redes y espera a que transcurra el TTL. Detente cuando las tres rutas sean deterministas; revierte la sobrescritura interna si los clientes llegan al proxy equivocado o si no puedes controlar qué resolver utilizan.