Networking

Problema En entornos con varios controladores de dominio (DC) que también actúan como servidores DNS, es frecuente que una actualización de seguridad (por ejemplo, un parche OOB) cause una interrupción del servicio DNS. El síntoma típico es la aparición masiva de eventos Netlogon 5775 indicando que la eliminación dinámica de registros SRV (por ejemplo, _kerberos._tcp.<site>.contoso.com) falló con código de respuesta RCODE 5 (Refused). El fallo se propaga rápidamente: los clientes no pueden localizar controladores, la autenticación se vuelve intermitente y, en el peor de los casos, el propio DC queda sin acceso a su zona DNS, impidiendo incluso abrir dnsmgmt.msc. El resultado es una caída de toda la infraestructura de Active Directory y, por extensión, de los servicios que dependen de ella. ...

Problema En entornos donde se delega la terminación TLS al kernel (kTLS), el flujo de recepción de datos depende de una ruta de código que asume la existencia de un socket buffer (skb) para cada registro TLS. Cuando un registro TLS 1.3 de longitud cero llega desde la lista de recepción (rx_list), el kernel escribe directamente en el buffer de usuario sin crear un skb. La lógica posterior del bucle de recepción, sin embargo, sigue esperando un skb y termina accediendo a memoria no inicializada. El resultado es una condición de desreferencia que permite la ejecución arbitraria de código en el contexto del proceso que consume la conexión. ...

Problema Muchos proyectos de aprendizaje o pruebas de concepto terminan con una VPC “todo en uno” donde las instancias privadas reciben IP pública o el tráfico sale sin control. El patrón que suele romperse es la separación clara entre subredes públicas (bastión, NAT) y subredes privadas (cargas de trabajo), junto con una configuración de Terraform que mezcla recursos sin módulos reutilizables. Cuando el diseño no sigue las mejores prácticas, aparecen problemas de conectividad, exposición accidental y dificultad para escalar o migrar a producción. ...

Problema En entornos con varios Domain Controllers (DC) basados en Windows Server 2019 (o versiones cercanas), es frecuente que, después de una operación de metadata cleanup o de cambios manuales en la configuración DNS, uno o más DC dejen de poder localizar el dominio. Los síntomas típicos son: Mensaje “Naming information cannot be located because: The specified domain does not exist or could not be contacted”. Fallos de Group Policy, errores 1054 y 1126 en el visor de eventos. Replicación inter‑DC interrumpida (eventos 5012, 2921, 1003). Herramientas como dcdiag y nltest reportan que no se encuentra un Global Catalog (GC) ni un DC disponible. El problema no está limitado a un caso puntual; cualquier alteración que rompa la cadena de confianza DNS‑AD o que elimine objetos de la base de datos sin actualizar la topología de replicación puede desencadenar este patrón. ...

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 Los administradores de homelab suelen depender de una VPN tradicional (WireGuard, OpenVPN) para conectarse a sus servidores desde cualquier ubicación. En redes públicas —hospitales, aeropuertos, campus— los firewalls pueden bloquear puertos UDP o protocolos desconocidos, dejando la VPN inoperativa. La alternativa que muchos están probando es un túnel Cloudflare + WARP: el cliente WARP se conecta a la red de Cloudflare y, mediante cloudflared, se expone un túnel HTTPS que lleva el tráfico a la máquina interna. ...

Problema En entornos de auto‑hosting es frecuente necesitar acceder a una aplicación web que corre dentro de Docker desde fuera de la red local. La solución típica es abrir puertos en el router o instalar el cliente VPN de Tailscale directamente en el host. Ambas opciones tienen inconvenientes: los puertos expuestos quedan visibles a Internet y la instalación del cliente VPN modifica la pila de red del sistema operativo, provocando conflictos con otras VPN, con iCloud Private Relay o con la configuración DNS del host. El objetivo es obtener un endpoint HTTPS accesible solo desde dispositivos autorizados, sin tocar la configuración de red del host y sin exponer la máquina completa a la tailnet. ...

Problema En entornos mixtos Windows / Linux es frecuente que una aplicación Linux necesite consultar usuarios y grupos en un dominio Active Directory (AD). La comunicación LDAP sin cifrado funciona sin problemas, pero cuando se intenta forzar LDAPS (LDAP sobre TLS/SSL, puerto 636) aparecen errores de verificación de certificado como: CONNECTED(00000003) depth=0 CN = my.server.dc verify error:num=20:unable to get local issuer certificate depth=0 CN = my.server.dc verify error:num=21:unable to verify the first certificate Este mensaje indica que el cliente Linux no confía en la cadena de certificación que presenta el controlador de dominio. El patrón se repite en muchos setups: el certificado del DC se ha exportado, se ha copiado al host Linux y se ha ejecutado update-ca-certificates, pero openssl s_client sigue sin validar la cadena. El problema no es exclusivo de un dominio concreto; cualquier organización que use certificados internos emitidos por su propia AD Certificate Services puede tropezar con la misma situación. ...

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. ...