Cómo configurar anulaciones de DNS local para varios proxies inversos

Eva Wong

IceWhale author

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

How to Configure Local DNS Overrides for Multiple Reverse Proxies - Zima Store Online

Crea una asignación local autorizada para cada nombre de aplicación y dirígela a exactamente una dirección de proxy inverso por red de cliente. No crees anulaciones comodín en conflicto en varios servidores DNS.

Varios proxies se vuelven confusos cuando el mismo dominio público se reutiliza internamente: un portátil puede consultar el router, un contenedor puede consultar un resolvedor local y un teléfono puede usar DNS cifrado. El resultado puede parecer un fallo del proxy o del certificado, aunque el cliente simplemente haya recibido la dirección incorrecta. Inventaría los nombres, resolvedores, oyentes del proxy y certificados antes de añadir registros.

Asigna nombres a los límites del proxy

Enumera cada FQDN de aplicación y el proxy que termina su conexión TLS. Usa registros específicos para las excepciones y reserva un comodín únicamente para un dominio cuyo espacio de nombres completo pertenezca a un solo proxy.

Evita asignar al mismo nombre dos registros A privados, a menos que ambos proxies estén activos intencionadamente y configurados de forma idéntica. DNS devuelve direcciones, no el estado del servicio, por lo que unos registros de equilibrio de carga improvisados pueden enviar a la mitad de los clientes a un proxy que carece de la ruta o del certificado.

Mantén separados los nombres de administración de los nombres orientados a los usuarios. Si un nombre de host de administración nunca debe resolverse en una red de invitados, colócalo en una vista o un resolvedor disponible únicamente para la VLAN de confianza, en lugar de depender de que el proxy lo oculte después.

Coloca las anulaciones en el resolvedor que realmente usan los clientes

Crea la zona local o las anulaciones de host en el servicio DNS anunciado por DHCP para esa red. Dirige cada nombre de aplicación a la dirección LAN de su proxy responsable, no al contenedor de la aplicación ni automáticamente a la dirección WAN pública.

Los clientes y las aplicaciones pueden usar bibliotecas y cachés de resolvedor diferentes, por lo que el comportamiento de DNS puede permanecer oculto. Verifica el servidor mostrado en la salida de la consulta en lugar de asumir que se consultó la anulación del router.

Desactiva o ten en cuenta el DNS cifrado del lado del cliente durante la prueba. Si el cliente evita deliberadamente el DNS local, las anulaciones de horizonte dividido no pueden afectarlo; elige una política de DNS administrada, un registro público más enrutamiento hairpin o un resolvedor proporcionado por una VPN.

Haz coincidir las rutas del proxy, TLS y las URL de la aplicación

En cada proxy, configura únicamente los nombres de host que tenga asignados y confirma que el certificado cubra esos nombres. Una respuesta DNS correcta seguida del certificado equivocado demuestra que el tráfico llegó a un oyente, pero no al host virtual previsto.

Prueba la ruta ascendente desde el propio proxy y, después, prueba el nombre de host público desde un cliente. Si el acceso directo al origen funciona, pero el nombre de host devuelve un sitio predeterminado, corrige la coincidencia del host en el proxy antes de volver a cambiar DNS.

Para las aplicaciones alojadas bajo una ruta, mantén alineadas la ruta del proxy y la URL base de la aplicación. La guía de ZimaSpace sobre retirar Jellyfin de forma segura también muestra por qué DNS, las rutas del proxy, el reenvío y las ACL deben registrarse conjuntamente.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

Verifica cada red y define la reversión

Consulta el FQDN directamente contra el resolvedor local previsto y, después, a través de la ruta normal del sistema operativo. Ambas respuestas deben apuntar al mismo proxy para esa red, y el TTL debe coincidir con la política local.

Abre la aplicación desde la LAN de confianza, la VLAN de invitados o multimedia y la VPN, según corresponda. Registra la dirección resuelta, el nombre del certificado, el estado HTTP y la redirección final; estas observaciones permiten identificar si el fallo está en DNS, TLS, el enrutamiento del proxy o la aplicación.

Elimina los registros duplicados obsoletos solo después de que todos los clientes superen las pruebas. Revierte la anulación más reciente si distintos clientes alternan entre proxies y deja de ampliar el comodín hasta que los registros del resolvedor demuestren qué servidor respondió a cada solicitud fallida.