Networking

Problema En entornos con Proxmox, es frecuente que los administradores puedan conectarse a una VM desde la consola del host (por ejemplo, usando qm terminal) pero no desde otro equipo de la misma red. Los síntomas típicos incluyen: ssh: connect to host X.X.X.X port 22: No route to host Mensajes de “key exchange identification” o “Connection closed by remote host” al intentar abrir una sesión SSH. Imposibilidad de acceder a la interfaz web de la VM (puerto 80/443) desde clientes externos. El host Proxmox también muestra problemas de conectividad hacia dispositivos fuera de su VLAN. Estos fallos aparecen aunque el host y las VMs aparecen “running” en qm list, la configuración de red del host parece correcta y el firewall de Proxmox está habilitado sin reglas explícitas. ...

Problema En entornos con controladores de dominio (DC) basados en Windows Server Core, la obtención de un certificado para LDAPS suele ser más engorrosa que en servidores con GUI. La ausencia del MMC certlm.msc y de la opción “Request New Certificate” obliga a los administradores a recurrir a la línea de comandos o a herramientas remotas que no siempre rellenan automáticamente los campos de Subject y SAN. El síntoma típico es la imposibilidad de establecer una conexión LDAP sobre TLS (puerto 636) porque el DC no tiene un certificado válido o el certificado no está ubicado en el almacén correcto. ...

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 Muchos entusiastas de homelab empiezan con Raspberry Pi por su bajo costo y facilidad de despliegue. Con el tiempo, la carga de trabajo crece: más contenedores Docker, servicios que demandan CPU/GPU, y la necesidad de aislar tráfico mediante VLAN o DMZ. En ese punto, la arquitectura ARM se vuelve limitante y la migración a servidores x86 con Proxmox parece la solución natural. El reto consiste en trasladar datos, configuraciones y redes sin interrumpir servicios críticos, manteniendo la separación de tráfico (admin, DMZ, usuarios) y aprovechando hardware de 10 GbE. ...

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 Al montar un servidor de medios con Jellyfin dentro de un contenedor Docker, muchos administradores de homelab quieren que el tráfico pase por Tailscale para disponer de una red privada sin abrir puertos públicos. En la práctica, el proceso suele tropezar con dos obstáculos recurrentes: Conflicto de puertos: Docker reclama puertos que ya están reservados por servicios del host (por ejemplo, 443 para HTTPS). Resolución DNS interna: Cuando se asigna un nombre de dominio a la IP local del servidor, la resolución a través de Tailscale puede quedar atrapada en una entrada estática que apunta a la IP de la LAN, impidiendo que el contenedor se comunique correctamente durante la construcción o el arranque. El resultado típico es un error al intentar compilar o iniciar la imagen de Jellyfin, con mensajes que indican que el puerto 443 está “restricted” o que la conexión a la red Tailscale falla. El problema no es exclusivo de Jellyfin; cualquier servicio que requiera puertos estándar y dependa de DNS interno sufre el mismo patrón. ...

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 Al iniciar una VM de Windows Server 2022 (o 2019) sobre Proxmox, el registro de eventos muestra repetidamente Event ID 5719 (NETLOGON). El mensaje indica que el cliente no pudo contactar al controlador de dominio dentro del tiempo de espera. Tras unos minutos, la replicación y el inicio de sesión funcionan sin incidentes. El síntoma se repite en cada arranque, afecta a servidores que no son controladores de dominio y suele aparecer cuando la NIC está basada en VirtIO con multiqueue habilitado y la máquina usa el modelo q35. En entornos donde los DC ya están operativos, el error se reduce a una cuestión de sincronización de red durante el arranque. ...

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