Networking

Problema En muchos entornos de Active Directory se utiliza un alias DNS (por ejemplo ad.contoso.com) para referenciar al controlador de dominio principal. Cuando se migra a LDAP sobre SSL (LDAPS, puerto 636) los clientes verifican que el nombre que aparecen en la conexión exista dentro del certificado del DC. Si el certificado solo contiene el FQDN real del servidor (dc01.contoso.com) la validación falla y aparece un aviso de “nombre no encontrado en el certificado”. ...

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 En oficinas pequeñas o sucursales, es frecuente separar dispositivos críticos (cámaras, impresoras, equipos médicos) en VLAN distintas y colocar un firewall de perímetro como puerta de enlace. Cuando una impresora multifunción debe escanear a una carpeta compartida en un PC ubicado en otra VLAN, el proceso se bloquea: el trabajo queda en “Resending…”, termina con “TX Incomplete” o simplemente no aparece la carpeta. El síntoma típico es que ICMP funciona entre subredes pero SMB (puertos 445/139) es rechazado. El cliente ve “Network path not found” al intentar acceder a \\IP\share. La causa suele estar en la configuración del firewall, reglas de zona o políticas de inspección que impiden el tráfico de capa 4/7 entre VLAN. ...

Problema En entornos donde los nodos de Kubernetes dependen de un firewall/router como OPNsense, una configuración errónea del gateway DHCP o la ausencia de reglas de NAT saliente puede dejar al clúster sin acceso a Internet sin generar alertas visibles. Los síntomas típicos son: Pods que no pueden descargar imágenes de contenedores aunque el DNS responda. kubectl get pods muestra contenedores en estado ImagePullBackOff o CrashLoopBackOff. Herramientas de diagnóstico dentro del nodo (por ejemplo ping a direcciones externas) fallan, mientras que el firewall sigue respondiendo a pings locales. La red interna funciona (comunicación entre pods y servicios) pero cualquier tráfico que requiera salir del LAN se pierde. Este patrón se repite en homelabs y pequeñas infraestructuras donde la configuración de red se gestiona de forma automática y los cambios de DHCP pueden pasar desapercibidos durante semanas. ...

Problema En entornos Docker Compose donde un contenedor actúa como gateway entre dos redes (por ejemplo, una red privada y una pública), es habitual usar iptables con la regla MASQUERADE para que el tráfico saliente parezca provenir de la interfaz externa del gateway. Cuando la regla no se aplica, los paquetes siguen mostrando la IP interna del contenedor origen, lo que provoca fallos de conectividad y respuestas rechazadas por los servidores remotos. El síntoma típico es observar, con tcpdump, la IP del contenedor interno en la capa IP del tráfico que sale por la interfaz pública del gateway. ...

Problema En entornos distribuidos es frecuente que la sede central aloje los servicios de Active Directory (AD), DNS y DHCP, mientras que las sucursales solo disponen de conectividad de red. El reto consiste en permitir que un equipo Windows en la sucursal se una al dominio gestionado en la sede, usando exclusivamente una Site‑to‑Site VPN. La pregunta típica es: ¿esta arquitectura funciona en producción o solo sirve para laboratorios? Además, cuando la unión falla, los síntomas suelen ser “no se encuentra el controlador de dominio”, “error de DNS” o “tiempo de espera agotado”. El objetivo de este artículo es describir un enfoque genérico que permita diagnosticar y resolver esos problemas, independientemente de la topología exacta o del hardware VPN empleado. ...

Problema Los entornos homelab que se extienden a la nube suelen combinar hardware propio (rack, switches, firewalls) con servidores dedicados (por ejemplo, en Hetzner). Cuando la cantidad de servicios crece —SSO, almacenamiento, monitorización, contenedores— la tabla de firewall puede inflar rápidamente, llegando a cientos de reglas. Mantener esa lista coherente, evitar colisiones y garantizar que todo el tráfico pase exclusivamente por un túnel WireGuard se vuelve complejo. El síntoma típico es: ...

Problema Muchos profesionales en transición hacia IT o Security carecen de acceso a entornos reales. La única forma de demostrar competencias a reclutadores es a través de laboratorios caseros que reproduzcan una infraestructura de red, virtualización y monitoreo. El reto consiste en armar un entorno completo (router, VLAN, SIEM, monitoring, honeypot, ticketing) con un presupuesto limitado y sin depender de hardware de última generación. Además, el laboratorio debe ser lo suficientemente modular para añadir o remover componentes sin romper la arquitectura. ...

Problema En entornos con varias sedes, a menudo se desea que los equipos de una oficina remota se autentiquen contra el mismo controlador de dominio que la sede central. La arquitectura típica consiste en un túnel IPsec site‑to‑site entre los firewalls de ambas ubicaciones y, sobre ese túnel, los clientes Windows intentan unirse al dominio. El reto no es solo “abrir el túnel”, sino garantizar que los servicios de AD (LDAP, Kerberos, DNS) sean accesibles y que el tráfico de descubrimiento de dominio fluya sin interrupciones. Cuando alguna de esas piezas falla, el proceso de unión se queda en “no se encontró el dominio” o “error de autenticación”. ...