Networking

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 Muchos profesionales de infraestructura y soporte técnico llegan a un punto donde el salario actual no cubre el costo de vida y la progresión de carrera se estanca. El patrón típico incluye: años de experiencia autodidacta sin títulos formales ni certificaciones reconocidas, un puesto de “IT Manager” o “Sysadmin” con remuneración por debajo del promedio del mercado, escasa demanda local para roles especializados (Network, Systems) y dificultad para acceder a oportunidades internacionales por barreras de certificación y costos de visa. El desafío es convertir ese bagaje técnico en un perfil que sea competitivo tanto en el mercado local como en plataformas de trabajo remoto o en países con salarios más altos. ...

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 Montar un entorno de auto‑hosting que sea estable, seguro y fácil de escalar suele colapsar cuando se combinan varios componentes críticos: firewall, segmentación de red, acceso remoto y monitorización. El patrón típico es que el administrador tiene que lidiar con configuraciones aisladas, documentación dispersa y fallos de integración que aparecen al conectar Docker a una red VLAN protegida por pfSense, o al intentar que Zabbix descubra dispositivos detrás de un VPN. El resultado es un lab que funciona a medias, con puertos abiertos sin control, contenedores que no alcanzan los recursos de red y alertas perdidas. ...

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