Networking

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

Problema En entornos donde se conecta una red on‑premise (por ejemplo, un UniFi UDM Pro) a una VPC de AWS mediante un túnel Site‑to‑Site (S2S), es frecuente que el tráfico IP funcione pero la resolución de nombres internos falle. El síntoma típico es que las consultas DNS llegan al endpoint de Route 53 Inbound Resolver (IP 10.x.x.x) y devuelven NXDOMAIN o respuestas vacías, mientras que otras aplicaciones que usan TCP/53 pueden abrir la conexión sin timeout. El problema no se limita a UniFi; cualquier firewall/router que reenvíe consultas a un resolver privado de AWS puede presentar el mismo comportamiento si la cadena de encaminamiento o los atributos del resolver no están alineados. ...

Problema En entornos con varios servidores Proxmox es frecuente disponer de enlaces de distinta velocidad (1 GbE y 10 GbE) y de diferentes topologías (VLAN de gestión, enlaces agregados, enlaces dedicados a almacenamiento). El objetivo es: Mantener conectividad de gestión independiente del tráfico de datos. Usar enlaces LACP para agregación de ancho de banda y redundancia. Permitir que los nodos sin 10 GbE sigan operando sin forzar todo el tráfico por los puertos de 10 GbE. Implementar failover automático cuando un enlace o un nodo falla, sin perder conectividad de clúster ni de máquinas virtuales. Aprovechar la capa de SDN de Proxmox para segmentar subredes sin crear una red física compleja. Cuando se combina Open vSwitch (OVS) con la pila SDN de Proxmox, aparecen limitaciones: OVS no admite “bond stacking” (un bond dentro de otro bond) y algunos drivers (p. ej. i40e) no soportan RSTP. La solución debe funcionar con cualquier NIC que tenga soporte de Linux y permitir que los enlaces de 1 GbE y 10 GbE se utilicen de forma independiente según la carga. ...

Problema En muchos homelabs se busca maximizar la relación costo‑beneficio usando la menor cantidad de hardware posible. Un escenario típico es ejecutar un router OpenWrt como máquina virtual dentro de Proxmox y, al mismo tiempo, habilitar la replicación ZFS y la alta disponibilidad (HA) del propio clúster. La pregunta que surge con frecuencia es: ¿es más fiable un router virtualizado dentro del clúster HA que un router físico dedicado? El problema subyacente es la necesidad de mantener conectividad de red incluso cuando una o más piezas de hardware fallan, sin perder acceso remoto para diagnóstico y reparación. ...

Problema En entornos de homelab o pequeñas oficinas es frecuente usar una única subred amplia (por ejemplo 10.0.0.0/8) para simplificar la asignación de direcciones IP. Después de actualizar o reconfigurar un switch gestionado, varios hosts dejan de comunicarse con el firewall pfSense/Netgate: los intentos de SSH, HTTP o cualquier otro puerto interno terminan en connection timed out. La regla predeterminada “Allow LAN to any” parece estar activa, y los cables están conectados correctamente, pero el tráfico interno simplemente no pasa. ...

Problema En muchos homelabs la tendencia natural es añadir más nodos, discos y servicios sin replantear la arquitectura de red. El resultado típico es una red fragmentada donde: Las VLANs se crean de forma ad‑hoc y los switches aplican reglas implícitas que el administrador no ve. El firewall de capa 3 introduce reglas automáticas que generan “cajas negras” y hacen que el tráfico legítimo se pierda o se ralentice. El ancho de banda de la WAN (por ejemplo 100 Mbps) se convierte en cuello de botella cuando los discos mecánicos intentan servir datos a alta velocidad. La mezcla de diferentes sistemas de almacenamiento (TrueNAS, NAS viejo, discos SATA) sin una política de cache o tiering genera latencias inesperadas. El síntoma más frecuente es una degradación progresiva del rendimiento y fallos intermitentes en servicios críticos (VMs, contenedores, backups) que aparecen cuando la red ya está saturada o cuando una regla de firewall oculta bloquea una ruta necesaria. ...

Problema En muchos entornos domésticos el router suministrado por el ISP no permite configuraciones avanzadas como VLANs, QoS o firewall granular. Cuando el objetivo es crear una red segmentada —por ejemplo, separar servidores de virtualización, dispositivos IoT y tráfico de invitados— el router del ISP se vuelve un cuello de botella. La solución típica es colocar un router VLAN‑aware detrás del equipo del ISP y delegar toda la lógica de red a este segundo dispositivo. Sin embargo, sin acceso directo al WAN del ISP, la única forma de exponer el router VLAN‑aware al exterior es mediante la función DMZ del router del ISP. El reto consiste en saber si esta arquitectura es viable, qué limitaciones tiene y cómo mitigar los riesgos de seguridad y de rendimiento. ...

Problema Al ejecutar wg‑easy dentro de un contenedor Docker en un router OpenWrt, los clientes WireGuard establecen la conexión pero pierden la capacidad de alcanzar tanto la LAN como la WAN. Las peticiones DNS (por ejemplo a 1.1.1.1) nunca llegan, y cualquier intento de ping a la puerta de enlace local devuelve Destination Port Unreachable. El síntoma típico es una interfaz tun0 activa en el cliente, tráfico visible en el contenedor, pero sin rutas de salida hacia la red del router ni hacia Internet. ...