Networking

Problema En muchos homelabs se implementan varias VLAN para aislar servicios críticos (DMZ, gestión, IoT, invitados, etc.). Cuando la tabla de PVID (Port VLAN ID) no está alineada con la lógica de firewall, aparecen síntomas como: Caídas intermitentes de SSID o rendimiento Wi‑Fi por debajo de 500 Mbps. Latencia alta y pérdida de paquetes en enlaces Ethernet que deberían estar por encima de 850 Mbps. Regla de firewall que “no debería” bloquear tráfico, pero lo hace, provocando que una VLAN no pueda comunicarse con otra ni con el router. Reinicios de contenedores o VMs que dependen de DNS/Internet cuando el tráfico se filtra por una VLAN equivocada. El patrón es claro: la segmentación está bien diseñada, pero la asignación de PVID a puertos físicos o a enlaces troncales está mal configurada, lo que genera “storm” de tráfico no etiquetado o etiquetado incorrectamente. ...

Problema Los usuarios que ejecutan servicios auto‑alojados (Immich, Nextcloud, Jellyfin, etc.) detrás de un CGNAT suelen recurrir a Cloudflare Tunnel para exponer sus aplicaciones sin una IP pública. La solución funciona bien para tráfico web típico, pero Cloudflare impone un límite de 100 MB al cuerpo de la petición cuando el túnel actúa como proxy. Subidas de vídeos, backups de fotos o cualquier archivo grande se interrumpen con errores de “request entity too large”. El síntoma es idéntico sin importar la aplicación: la carga falla justo después de alcanzar los 100 MB y el cliente muestra un mensaje de error de Cloudflare. ...

Problema En muchos homelabs la tentación de añadir varios dispositivos (NAS, servidores, Raspberry Pi, APs) lleva a una red plana donde todos los equipos comparten el mismo broadcast. Esa arquitectura simplifica la configuración inicial, pero rápidamente se vuelve un riesgo: dispositivos IoT pueden comprometerse y, sin aislamiento, pueden atacar máquinas de gestión o servidores críticos. El patrón recurrente es la necesidad de segmentar la red en zonas lógicas (trusted, internal, iot, guest, servers) y, al mismo tiempo, ofrecer a los usuarios finales una forma sencilla de acceder a servicios internos mediante nombres de dominio amigables y certificados válidos. Cuando la segmentación se combina con un proxy inverso como Nginx Proxy Manager (NPM) y una autoridad de certificación externa (Let’s Encrypt vía DNS‑01), la complejidad de la configuración aumenta y los errores de enrutamiento, firewall o resolución DNS son comunes. ...

Problema En entornos domésticos o de pequeña empresa que usan routers basados en Linux, la mayoría de los sistemas de monitoreo se reduce a umbrales estáticos: “RTT > 300 ms → alerta”. Ese enfoque funciona mientras la red es estable, pero falla en el momento en que un nodo empieza a degradarse lentamente. La latencia sube gradualmente, el jitter varía y el tráfico se redistribuye, pero ninguno de esos valores cruza el límite definido. El resultado es una interrupción inesperada que solo se detecta cuando el usuario ya está experimentando buffering o caídas de conexión. El patrón típico es: múltiples proxies o enlaces con métricas que cambian de forma correlacionada, pero sin que ninguna métrica individual sea “mala”. Necesitamos una forma de observar la estructura global del conjunto de nodos y detectar cuándo esa estructura se está deformando. ...

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