Networking

Problema En entornos donde coexisten Docker Swarm y Kubernetes, a menudo surge la necesidad de que contenedores de Swarm consuman servicios expuestos por pods de K8s (y viceversa). Cada orquestador crea su propio overlay de red, su propio DNS interno y, por defecto, no comparten rutas. Cuando los clústers están en redes distintas o en diferentes centros de datos, la comunicación se corta a menos que se establezca una capa de red externa que los una. El patrón típico es: “un micro‑servicio legado sigue en Swarm, pero la nueva funcionalidad está en K8s; ambos deben hablar sin re‑escribir código”. ...

Problema En entornos de auto‑hosting es frecuente combinar wg‑easy (interfaz web para WireGuard) con Caddy como terminador TLS y reverse proxy. El objetivo es acceder a https://wg-easy.example.com sin exponer puertos internos. Un síntoma típico es el mensaje del navegador “Can’t connect to the server” o un error de conexión TCP. El problema no es exclusivo de wg‑easy; ocurre siempre que el proxy no logra resolver o alcanzar el contenedor objetivo dentro de la red Docker. La raíz suele estar en la configuración de la red Docker, la definición del reverse_proxy en el Caddyfile o en la exposición de puertos del servicio wg‑easy. ...

Problema En entornos domésticos o de pequeña oficina es frecuente delegar la resolución de nombres internos a un Pi‑hole instalado en un contenedor LXC. El objetivo es que cualquier dispositivo que consulte DNS obtenga tanto la filtración de publicidad como los registros locales (por ejemplo test.lan). Cuando los dispositivos siguen enviando consultas al router y el router reenvía a un servidor externo (Cloudflare, Google), los nombres internos no se resuelven y el navegador muestra “server IP address could not be found”. El síntoma típico es: ...

Problema Montar un clúster Kubernetes en placas de bajo consumo (SBC) suele implicar recortes: una única interfaz de 1 GbE, almacenamiento en SD/eMMC, poca RAM y distribuciones ligeras como k3s. Estas limitaciones hacen que el entorno de pruebas no refleje la complejidad de un clúster de producción y, cuando se intenta escalar, aparecen cuellos de botella de red, pérdida de datos y problemas de consistencia. El reto real es conseguir un entorno “casi‑prod” con hardware limitado, manteniendo: ...

Problema Muchos entusiastas construyen su primer homelab combinando virtualización, routing y varios servicios sin una arquitectura clara. El resultado suele ser una red con VLANs mal aisladas, reglas de firewall inconsistentes y una gestión de credenciales que se vuelve difícil de auditar. Además, la transición a contenedores (Docker) y orquestadores (Kubernetes) se hace sin una base de pruebas adecuada, lo que genera cuellos de botella de hardware y problemas de seguridad que aparecen después de meses de operación. ...

Problema Muchos usuarios de self‑hosting tienen el router de su casa detrás de un NAT estricto, una IP pública dinámica o simplemente no quieren exponer directamente la dirección IP del ISP. En esos entornos, publicar un servicio (web, SSH, Plex, etc.) requiere una solución que atraviese el NAT sin abrir puertos innecesarios en el router y sin depender de servicios de terceros como DynDNS. La necesidad recurrente es crear un túnel fiable entre la red doméstica y un punto accesible en Internet, y luego redirigir el tráfico entrante hacia los servidores internos. ...

Problema Muchas organizaciones están migrando parte de su infraestructura a la nube, pero siguen manteniendo servidores locales para archivos, impresoras y aplicaciones legadas. El desafío surge cuando se necesita una única fuente de autenticación para usuarios y dispositivos que acceden a la red cableada o inalámbrica mediante 802.1X. En un entorno híbrido aparecen preguntas como: ¿Cómo combinar un controlador de dominio on‑premise con Azure AD/Entra ID sin duplicar políticas? ¿Quién emite los certificados para EAP‑TLS y cómo se distribuyen a laptops, teléfonos y BYOD? ¿Dónde encaja Cisco ISE cuando ya se usa Intune y Entra ID para gestión de dispositivos? ¿Qué protocolos deben estar activos (RADIUS, LDAP, SAML, OAuth) y cómo se sincronizan? El síntoma típico es una red que funciona parcialmente: los equipos unidos al dominio local se autentican, pero los dispositivos gestionados por Intune no pueden obtener acceso 802.1X, o los APs y switches siguen requiriendo configuraciones manuales de RADIUS que no se actualizan con los cambios de Azure AD. ...

Problema En entornos Windows con DNS integrado en Active Directory, la eliminación accidental de una zona primaria puede dejarla “zombie”: el objeto aparece como deleted en el contenedor CN=Deleted Objects, PowerShell la lista, pero la consola DNS Manager no la muestra y los clientes dejan de resolver. El síntoma típico es que consultas DNS devuelven NXDOMAIN y la zona no está visible en la GUI, aunque sigue existiendo como un objeto borrado con el sufijo -deleted-<guid>. La falta de una recuperación clara genera interrupciones de servicio y obliga a decidir entre restaurar desde el AD Recycle Bin, recrear la zona manualmente o realizar una restauración completa del controlador de dominio. ...

Problema En muchos despliegues de Kubernetes se usan dos capas de balanceo: un VIP gestionado por Keepalived y un HAProxy que reenvía el tráfico a los pods de Traefik. Cuando el tráfico proviene de la red interna (VPN, túnel) llega sin problemas, pero cualquier petición desde la WAN termina en un reset o en una respuesta 404 de un servidor inesperado (por ejemplo, Microsoft‑HTTPAPI/2.0). El dashboard de HAProxy muestra cero sesiones para la IP pública, mientras que las capturas del firewall indican que el paquete se ha encaminado al VIP. El síntoma típico es: ...

Problema En entornos donde WireGuard se usa como puente entre una máquina cliente y un servidor de retransmisión, es frecuente encontrarse con que el cliente envía paquetes pero el servidor nunca los contabiliza como tráfico recibido. El túnel parece “up”, los handshakes aparecen en el cliente, pero en el servidor la estadística de transferencia permanece en 0 B y la conexión nunca se establece. El síntoma típico es: wg show muestra la interfaz activa en ambos extremos. tcpdump confirma que los paquetes UDP llegan al puerto 51820 del servidor. No hay handshakes visibles en el servidor para el peer problemático. El tráfico de retorno (respuesta del servidor al cliente) tampoco llega. Este comportamiento se traduce en una VPN que solo permite tráfico en una dirección o, peor aún, que parece estar operativa pero no transporta datos. El problema puede aparecer en despliegues con máquinas virtuales, entornos de nube, o redes con NAT y reglas de firewall complejas. ...