Networking

Problema En muchos homelabs los servicios expuestos al exterior se acceden mediante un subdominio gestionado por un proveedor DNS externo (por ejemplo app.my.domain). Cuando el mismo subdominio se resuelve dentro de la red local, el tráfico suele salir a Internet y volver a entrar, lo que genera latencia innecesaria y, sobre todo, problemas de TLS: el certificado emitido para la IP pública no coincide con la IP interna y aplicaciones como Jellyfin rechazan la conexión. El patrón típico es: ...

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 de desarrollo o homelab es frecuente ejecutar Nginx Proxy Manager (NPM) dentro de Docker mientras que la aplicación que se desea exponer, como Jellyfin, corre directamente sobre Windows. Cuando el contenedor de NPM intenta enrutar el tráfico al host, el cliente recibe un 502 Bad Gateway y los logs indican connect() failed (111: Connection refused) while connecting to upstream "http://<IP>:8096/". El síntoma es idéntico aunque la IP usada sea la local del equipo, host.docker.internal o cualquier alias configurado. El problema no es DNS externo ni puertos del router; la falla ocurre dentro del stack de red de Docker/WSL2. ...

Problema En entornos híbridos es frecuente que una o más instancias de firewall virtual (por ejemplo FortiGate‑VM) se encarguen de los túneles IPsec que conectan la VPC de AWS con la red de la oficina corporativa. Cuando se despliegan dos firewalls idénticos, cada uno abre su propio túnel. El objetivo es que, si una instancia deja de responder —por falla del EC2, por problemas de software o por pérdida de la conexión a Internet— el tráfico de la VPC se redirija automáticamente al segundo túnel sin intervención manual. La dificultad radica en que AWS no ofrece un “IP SLA” integrado; la conmutación debe basarse en mecanismos de enrutamiento o de salud que el propio cliente configure. ...

Problema En entornos donde el mismo dominio (por ejemplo, example.domain) se utiliza tanto para servicios internos como para recursos expuestos al exterior, los administradores suelen querer que los clientes internos resuelvan los nombres internos directamente, mientras que cualquier nombre que no exista en la zona interna se delegue a un servidor externo (BIND9 en DMZ). La dificultad aparece cuando el DNS de Windows, que es autoritativo para la zona, responde con NXDOMAIN a cualquier registro que no tenga, impidiendo que la consulta sea reenviada automáticamente al servidor externo. Mantener dos zonas idénticas o crear registros “pinpoint” para cada host externo genera una carga operativa innecesaria y propensa a errores. ...

Problema En muchos homelabs se configura pfSense como router/DHCP‑server y se delega un dominio interno (por ejemplo *.lan) para que los dispositivos accedan a recursos como SMB shares mediante nombres amigables (smb://servidor.lan). Cuando el servidor de almacenamiento es TrueNAS y se le asigna un hostname estático (slab), la resolución DNS suele funcionar sin problemas. Sin embargo, es frecuente que, sin intervención aparente, los nombres dejan de resolverse y sólo se accede a los recursos mediante la dirección IP (192.168.x.x). El síntoma típico es: ...

Problema Varias aplicaciones iOS que consumen una API HTTPS alojada en AWS presentan fallos esporádicos al iniciar sesión como invitado. Los dispositivos afectados registran mensajes como “An SSL error has occurred” o “A TLS error caused the secure connection to fail”. La mayoría de los usuarios pueden conectarse sin problemas; el error aparece solo en una fracción de los clientes y de forma intermitente. La arquitectura típica incluye: Dominio con registro A apuntando a una dirección IPv4 pública de un ELB o de una instancia EC2. Certificado TLS válido (por ejemplo, ACM o Let’s Encrypt) sin registro AAAA. Cliente iOS que usa URLSession para realizar la petición. El desafío es determinar si el fallo ocurre antes de que el tráfico alcance AWS (por ejemplo, en la ruta del ISP, resolución DNS o traducción NAT64) o si la conexión llega a AWS y se rompe durante el handshake o en la capa de aplicación (Nginx, WAF, etc.). ...

Problema Muchos entornos híbridos usan Azure Point‑to‑Site (P2S) VPN para dar acceso a máquinas on‑premise o a laptops. Cuando la puerta de enlace está configurada para autenticarse con Microsoft Entra ID (antes Azure AD), la experiencia en Windows es fluida, pero en Linux aparecen dos obstáculos recurrentes: El cliente oficial Azure VPN Client para Linux quedó en preview, solo soporta Ubuntu 20.04/22.04 y fue retirado sin recibir parches. Los clientes genéricos (OpenVPN, strongSwan) esperan autenticación basada en certificados o RADIUS; no saben manejar un token JWT que Entra ID entrega mediante el flujo device‑code. El síntoma típico es que la conexión falla inmediatamente después de la fase de autenticación, con mensajes como “username/password authentication failed” o “TLS channel buffer overflow”. El problema no es exclusivo de una distribución; ocurre siempre que el token supera los buffers internos de OpenVPN. ...

Problema Muchos entornos de homelab o pequeñas oficinas dependen de un único enlace de Internet que, por limitaciones del ISP, ofrece ancho de banda insuficiente para varios equipos simultáneos. Cuando se habilita un túnel VPN como Cloudflare WARP en una máquina, la velocidad mejora notablemente, pero solo esa máquina se beneficia. La necesidad típica es proporcionar esa mejora a todos los servidores y contenedores sin instalar WARP en cada uno, manteniendo al mismo tiempo una política de “corte total” si el túnel falla. ...

Problema En muchos homelabs se combinan Pi‑hole como resolutor DNS interno, Nginx Proxy Manager (NPM) para la terminación TLS y Cloudflare Tunnel para exponer servicios al exterior. Cuando los navegadores dentro de la LAN intentan acceder a sub‑dominios gestionados por NPM, aparecen errores como ERR_SSL_UNRECOGNIZED_NAME_ALERT o ERR_QUIC_PROTOCOL_ERROR. La causa típica es que el cliente recibe una respuesta DNS que mezcla direcciones internas (IPv4) con registros externos (IPv6 o A) obtenidos de Cloudflare, lo que rompe la coincidencia del certificado y obliga al navegador a abortar la conexión TLS. ...