Proxy

Problema En entornos homelab donde TrueNAS actúa como nodo de almacenamiento y también ejecuta contenedores Docker (a través de Dockhand o plugins), es frecuente querer exponer varios servicios mediante un único punto de entrada. El objetivo suele ser: Un reverse proxy que escuche en 80/443 en una IP dedicada. Certificados TLS válidos tanto para acceso externo (Let’s Encrypt) como para tráfico interno LAN, evitando que los dispositivos locales consuman ancho de banda de la nube. Resolución DNS interna que apunte los sub‑dominios al alias IP del proxy, sin interferir con la red de la ISP. Integración con herramientas de hardening (crowdsec, geoblocking, Suricata). El bloqueo típico ocurre cuando el contenedor del proxy no puede unirse a la red que TrueNAS ha configurado (bridge, macvlan o alias). El error se manifiesta como “network not found” o “port already allocated”, y la UI de Dockhand muestra que el contenedor está detenido. Sin una red adecuada, los certificados ACME no pueden validar dominios y la resolución DNS interna no funciona. ...

Problema En entornos donde Nginx actúa como reverse proxy para varios contenedores Docker, es frecuente encontrarse con que, de forma intermitente, el cliente recibe el certificado TLS del host “default” en lugar del certificado correspondiente al dominio solicitado. El síntoma típico es un error de certificate mismatch al abrir el sitio en el navegador o al ejecutar openssl s_client -servername <dominio> -connect <dominio>:443. La falla no ocurre siempre; en pruebas repetidas el mismo dominio puede devolver su certificado correcto en una ejecución y el certificado del host principal en otra. ...

Problema En entornos de producción con varios servicios Docker, es frecuente que los contenedores publiquen sus puertos directamente en la interfaz 0.0.0.0 del host. Esa práctica amplía la superficie de ataque porque cualquier cliente externo puede intentar conectar a esos puertos, aunque el objetivo sea que todo el tráfico pase por un reverse proxy. El desafío consiste en: Mantener los puertos internos del contenedor cerrados al host. Permitir que Nginx Proxy Manager (NPM) enrute peticiones HTTP/HTTPS al contenedor objetivo. Asegurar que la base de datos u otros servicios internos no queden expuestos accidentalmente. El problema se manifiesta típicamente con errores 504 o “Bad Gateway” cuando NPM no logra alcanzar el backend, aunque el contenedor esté activo y saludable. La causa suele estar en la configuración de redes Docker o en la forma en que se exponen los puertos. ...

Problema En entornos donde Nginx actúa como reverse proxy para uno o varios contenedores Docker, es frecuente encontrarse con respuestas 502 Bad Gateway o logs que indican connect() failed (111: Connection refused) while connecting to upstream. El síntoma típico es que el cliente (navegador, curl, Cloudflare Tunnel) llega a Nginx, pero Nginx no puede establecer la conexión TCP con el backend. El error se manifiesta como: 2026/07/05 02:31:31 [error] 22#22: *7 connect() failed (111: Connection refused) while connecting to upstream, client: X.X.X.X, server: example.com, request: "GET / HTTP/1.1", upstream: "http://172.29.0.2:8086/", host: "media.example.com" Este patrón aparece en cualquier stack que combine: ...

Problema En muchos homelabs los servicios internos (Forgejo, Home Assistant, etc.) necesitan HTTPS para evitar advertencias del navegador y para que otras aplicaciones confíen en ellos. El obstáculo típico es que el dominio público está asociado a una IP pública, mientras que los servicios residen en redes privadas (192.168.x.x). Cuando se crea un registro DNS que apunta directamente a la IP interna, los resolvers externos no pueden resolverlo y los clientes locales obtienen “Server not found”. Además, Let’s Encrypt rechaza la emisión de certificados si el dominio no es accesible públicamente o si la validación DNS‑01 falla por una configuración incorrecta del servidor DNS interno. ...

Problema En entornos donde una aplicación monolítica se ejecuta dentro de un contenedor y expone dos procesos –por lo general un frontend (Next.js, React, etc.) y un backend (NestJS, Express, etc.)– es frecuente colocar un servidor Nginx como reverse proxy interno. Cuando el proxy no logra establecer la conexión con el proceso backend, los navegadores devuelven un 502 Bad Gateway y, en la práctica, la UI queda atrapada en un bucle de carga (por ejemplo, al intentar iniciar sesión). El síntoma típico es una petición POST /api/... que nunca finaliza y, en los logs de Nginx, aparece: ...

Problema Al ejecutar wg‑easy dentro de un contenedor Docker en un router OpenWrt, los clientes WireGuard establecen la conexión pero pierden la capacidad de alcanzar tanto la LAN como la WAN. Las peticiones DNS (por ejemplo a 1.1.1.1) nunca llegan, y cualquier intento de ping a la puerta de enlace local devuelve Destination Port Unreachable. El síntoma típico es una interfaz tun0 activa en el cliente, tráfico visible en el contenedor, pero sin rutas de salida hacia la red del router ni hacia Internet. ...

Problema Muchas organizaciones usan Let’s Encrypt para automatizar la emisión de certificados TLS. Cuando el dominio está detrás de un firewall o no se puede servir HTTP, la validación DNS‑01 es la única opción viable. La API del proveedor DNS necesita credenciales (clave API, token, usuario/contraseña) y, en entornos sin una estrategia centralizada, esas credenciales terminan copiadas a cada servidor que ejecuta el cliente ACME. El patrón típico es: Un script de solicitud de certificado en cada host. Variables de entorno o archivos de configuración con la clave del DNS. Credenciales estáticas que permanecen en el disco indefinidamente. Este enfoque genera varios riesgos: exposición accidental, rotación imposible, falta de auditoría y, cuando se necesita un proceso de aprobación interno, no hay control sobre quién puede solicitar certificados. El problema se vuelve crítico al intentar desplegar certificados en dispositivos de borde (IPMI, impresoras, appliances) que no pueden almacenar secretos de forma segura. ...

Problema Muchos usuarios que autohospedan Navidrome quieren evitar la gestión de credenciales locales y delegar la autenticación a un proveedor externo (por ejemplo, Authentik). El reto surge cuando el reverse proxy no está configurado para reenviar la información de sesión o cuando el flujo OAuth2 no se completa porque falta un contenedor de “auth‑proxy”. El síntoma típico es que Navidrome muestra la página de login pero nunca redirige al usuario, o que la cabecera X-User esperada por Navidrome está vacía. ...

Problema En entornos Docker Swarm con un reverse proxy (por ejemplo, Traefik) y un proveedor de identidad (Authelia, Keycloak, etc.) es frecuente que los servicios que implementan OAuth2 necesiten redirigir al usuario a una URL de callback que apunta al host del clúster (ej. auth.example.com). Los contenedores que forman parte de una overlay network de Swarm no pueden alcanzar directamente la IP del nodo host ni el nombre DNS que resuelve a esa IP. La resolución DNS funciona, pero la petición nunca llega porque Docker aísla la red del contenedor del stack de red del host. El síntoma típico es: ...