Networking

Problema En entornos con Windows Server que ofrecen Remote Desktop Services (RDS), es frecuente que un usuario experimente una desconexión limpia y, al intentar reconectar, reciba el código de error 0x904 sin mensaje adicional. El síntoma típico es: La sesión aparece como Disconnected en el listado de sesiones. No se pueden iniciar nuevas sesiones con ese mismo usuario. Otros usuarios pueden conectarse sin problemas. No aparecen eventos relevantes en los logs de Terminal Services, System o Application. Este patrón suele aparecer cuando el servidor está alojado en una máquina virtual (por ejemplo, bajo Proxmox, Hyper‑V o VMware) y el cliente accede a través de una VPN basada en IKEv2. La combinación de una sesión RDP “zombie” y una caché de credenciales corrupta puede bloquear al usuario de forma persistente hasta que el servidor se reinicia. ...

Problema Los equipos de infraestructura suelen necesitar una visión periódica del estado de sus dispositivos de red: interfaces operativas, protocolos de enrutamiento, sincronización de tiempo, etc. Las herramientas tradicionales (ping, nmap, scripts ad‑hoc) devuelven texto libre, lo que obliga a parsear salida con expresiones regulares frágiles. Además, la falta de un formato estructurado complica la integración con pipelines CI/CD, sistemas de monitorización y procesos de gestión de cambios. Cuando varios dispositivos de diferentes vendors están involucrados, la heterogeneidad de comandos y la ausencia de un mecanismo de “snapshot → diff” hacen que la detección de desviaciones sea manual y propensa a errores. ...

Problema En entornos donde OPNSense actúa como firewall, servidor OpenVPN y host de servicios como Caddy y Unbound, es frecuente que los clientes VPN pierdan la capacidad de resolver nombres internos (por ejemplo homeassistant.mynetwork.local) y, como consecuencia, no puedan alcanzar los sitios publicados por el reverse proxy. La conectividad IP (ping, acceso a interfaces LAN) funciona, pero cualquier solicitud basada en el nombre de dominio interno devuelve NXDOMAIN o timeout. El síntoma se reproduce tanto en IPv4 como en IPv6 y ocurre únicamente cuando el tráfico proviene de la interfaz tun0 del túnel VPN. ...

Problema En un homelab o cualquier entorno self‑hosted es frecuente ejecutar varios servicios detrás de un proxy inverso. Cada servicio necesita TLS para evitar tráfico en texto plano, pero la validación HTTP‑01 de Let’s Encrypt no funciona cuando el objetivo está aislado en la red local o no es accesible desde Internet. El reto es decidir entre certificados auto‑firmados y certificados públicos obtenidos mediante el desafío DNS‑01, y además garantizar que la renovación y rotación sean automáticas y seguras. ...

Problema Al montar varios servicios (gateway LLM, agente de mensajería, servidor multimedia y escritorio remoto) en una única VM de 4 vCPU, es frecuente encontrarse con que los contenedores arrancan, los puertos parecen abiertos y, sin embargo, nada responde. Los logs aparecen vacíos o con mensajes genéricos como “command not found” o “permission denied”. La raíz suele ser una combinación de reglas de firewall invisibles, políticas de reinicio que no reintentan, y permisos de usuario que no coinciden con los archivos creados durante la instalación. ...

Problema Al actualizar a una versión reciente de pfSense Plus, muchos administradores descubren que el nuevo Netgate Nexus controller no está disponible o que, una vez habilitado, el firewall muestra comportamientos extraños: caída del DNS, reglas de firewall que no se aplican o incluso bloqueos de tráfico. El patrón típico es: después de la actualización, el GUI tradicional sigue activo, pero la opción “Enable Nexus” está gris o, al activarla, el puerto 8443 no responde. En entornos de producción, donde la disponibilidad del DNS interno y la consistencia de las listas de bloqueo (Threatgate) son críticas, este tipo de interrupción puede generar alertas de monitoreo y tickets de soporte. ...

Problema En entornos de virtualización con Proxmox, los administradores suelen disponer de servidores con múltiples interfaces de red: algunas de 1 Gb para gestión y otras de 10 Gb para tráfico de máquinas virtuales (VMs) o para la comunicación del clúster. El reto consiste en conectar de forma eficiente todas esas NICs a un switch de 10 Gb, garantizando que: El tráfico de gestión no compita con el de las VMs. El clúster de Proxmox pueda usar la red de alta velocidad para replicación y HA. Los dispositivos de almacenamiento (por ejemplo, un Synology) puedan seguir operando sin crear cuellos de botella. El problema se vuelve crítico cuando se añaden nodos con diferentes generaciones de hardware (Dell R640, HP DL360 Gen9/Gen10) y cuando se planea escalar a varios nodos y VMs de bajo consumo, pero con requisitos de ancho de banda razonables. ...

Problema En entornos RDS (Remote Desktop Services) es habitual que los usuarios necesiten imprimir desde sus sesiones remotas usando las impresoras locales. Windows suele manejar la redirección mediante Easy Print, que abstrae el driver del cliente y lo reemplaza por un driver universal en el servidor. Cuando los clientes son macOS, la cadena de redirección a veces se rompe: la sesión RDP no muestra ninguna impresora, Get-Printer no lista dispositivos y el visor de eventos del Session Host genera el Event ID 1111 indicando un driver inesperado (por ejemplo “Microsoft Print To PDF”). El síntoma es idéntico en varios clientes macOS, mientras que los equipos Windows redirigen sin problemas. ...

Problema Muchas pymes y oficinas remotas utilizan los dispositivos Meraki MX como puerta de enlace VPN. Desde hace poco, Meraki permite túneles IKEv2/IPsec, que son mucho más rápidos que los basados en TLS/DTLS. El inconveniente habitual es que la autenticación se limita a usuario y contraseña contra un servidor RADIUS, sin soporte nativo para MFA ni para certificados de cliente. En entornos donde la identidad está gestionada por Azure AD/Entra ID, los administradores buscan una forma de exigir MFA antes de que el RADIUS acepte la conexión, pero sin adquirir licencias de AnyConnect Premium o desplegar una infraestructura AD completa. ...

Problema En entornos con múltiples servidores y subredes, es frecuente que el cliente SSH logre establecer la conexión TCP (el banner “Connection established” aparece) y luego se quede esperando sin mostrar la solicitud de contraseña ni ningún mensaje de error. El proceso parece colgar en el primer intercambio de datos después del handshake. El síntoma típico es: debug1: Connecting to 10.x.x.x [10.x.x.x] port 22. debug1: Connection established. debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4 y nada más. La sesión funciona desde otras máquinas, pero falla de forma consistente desde un host específico (por ejemplo, un jump server). La causa rara vez está en el daemon SSH; suele estar en la capa de red que impide que el paquete de banner del cliente llegue al servidor o que la respuesta del servidor regrese al cliente. ...