Networking

Problema En entornos donde se ha re‑diseñado la red (VLANs, nuevos switches, cambios de DNS) es frecuente que los controladores de dominio (Domain Controllers) y los servidores que dependen de ellos (por ejemplo, un servidor de aplicaciones que usa LDAP/LDAPS) pierdan la capacidad de establecer una sesión TCP en los puertos 389 (LDAP) y 636 (LDAPS). Los síntomas típicos son: Ping y resolución de nombres funcionan sin problemas. nslookup devuelve la IP correcta del DC. Cualquier intento de abrir una conexión LDAP (por ejemplo, ldapsearch, herramientas de AD, o aplicaciones que usan LDAP) falla con timeout o “connection refused”. Desactivar el firewall de Windows en el DC no cambia nada. Desde el DC hacia el servidor AD sí se abre el puerto 389, lo que indica que el camino inverso está operativo. Este patrón indica que la capa de red está fragmentada: la ruta de ida (cliente → DC) está bloqueada o mal encaminada, mientras que la ruta de vuelta (DC → cliente) sigue funcionando. ...

Problema Los firewalls basados en pfSense suelen estar en producción durante meses o años. Cuando el proyecto lanza una versión mayor, como la 2.9.0, aparecen tres tipos de fricción recurrente: Actualización interrumpida – el proceso de upgrade falla o deja el appliance sin acceso a la UI. Incompatibilidad de certificados – los nuevos requisitos de fuerza TLS hacen que los certificados auto‑generados o de CAs internos dejen de ser aceptados. Nuevas opciones de NAT o algoritmos criptográficos – la configuración existente no reconoce los cambios y el tráfico comienza a comportarse de forma inesperada. Cualquier sysadmin que haya intentado subir una versión de pfSense en un entorno de producción sabe que, aunque la actualización sea “un clic”, la realidad está en los detalles que quedan fuera del asistente gráfico. ...

Problema Los entusiastas de homelab suelen iniciar con una única conexión a Internet y un servidor pequeño. Cuando añaden una segunda línea de fibra, múltiples VLAN, servicios de seguridad, monitorización y contenedores, el consumo de CPU, RAM y ancho de banda crece rápidamente. El patrón que se repite es: sobre‑dimensionar la arquitectura sin una planificación de recursos ni una estrategia de escalado, lo que genera: Saturación de la CPU en el nodo que ejecuta OPNsense y Proxmox simultáneamente. Contención de memoria cuando varios LXC (ntopng, Immich, Paperless, etc.) compiten por los 16 GB disponibles. Ruido y calor excesivo en hardware antiguo, obligando a mover equipos a ubicaciones no ideales. Complejidad de red (dos WAN, VLANs, DNS‑over‑TLS, NTPsec) que se vuelve difícil de depurar sin una base estructurada. El objetivo de la guía es proporcionar un marco reutilizable para planificar, implementar y escalar un homelab multi‑WAN sin caer en los cuellos de botella típicos. ...

Problema En muchos entornos corporativos el acceso a los recursos administrativos de Windows (por ejemplo, los admin shares C$, ADMIN$) se realiza sobre SMB (puerto 445). Cuando el tráfico queda sin cifrar, cualquier atacante que intercepte la red puede leer o modificar datos, y los controles de firewall tradicionales no impiden que máquinas no autorizadas establezcan la conexión. La necesidad típica es “encapsular” SMB dentro de IPSec para que solo hosts y usuarios explícitos puedan comunicarse, y que cualquier intento fuera de la política sea descartado antes de que llegue a la capa de aplicación. ...

Problema En entornos Windows es frecuente que una tarjeta Ethernet muestre Estado: Connected, Link Speed correcto (por ejemplo 1 Gbps) y, sin embargo, no reciba una dirección IP válida del servidor DHCP. En lugar de una dirección del rango de la subred, el adaptador termina con una dirección 169.254.x.x (APIPA). El síntoma típico incluye: Ping a la puerta de enlace del router falla con “General failure”. ipconfig /renew devuelve Unable to contact your DHCP server. La conexión Wi‑Fi funciona sin problemas, lo que descarta un problema general de red. El adaptador es de alta velocidad (Realtek Gaming 2.5GbE Family Controller) pero negocia a 1 Gbps. Este patrón aparece tanto en equipos de escritorio como en laptops que usan controladores de red recientes y cables certificados. El objetivo del artículo es ofrecer un método reutilizable para diagnosticar y resolver este tipo de fallos, sin depender de un caso concreto. ...

Problema En entornos de auto‑hosting es frecuente querer que una aplicación específica, como SearXNG, utilice una VPN para todas sus peticiones externas. La necesidad surge cuando se desea ocultar la IP del servidor, evitar bloqueos geográficos o simplemente separar el tráfico de búsqueda del resto del tráfico de la máquina. El reto consiste en forzar que solo el proceso que corre bajo el usuario searxng (UID 999) salga por la interfaz wg-<nombre> sin afectar a los demás servicios ni romper la conectividad de la propia VM. ...

Problema En entornos Linux que requieren acceso a recursos protegidos por Azure VPN Point‑to‑Site (P2S) con autenticación Entra ID, la única herramienta oficial es un cliente GUI. Cuando se ejecuta en contenedores, CI/CD runners o servidores sin sesión de escritorio, esa dependencia se vuelve un bloqueo. El síntoma típico es que la conexión nunca se establece; el proceso OpenVPN finaliza después del handshake con un error de autenticación, aunque el usuario ya haya iniciado sesión con az login. La raíz del problema no es la falta de un token, sino que el cliente oficial usa un client‑id propio (41b23e61‑6c1e‑4545‑b367‑cd054e0ed4b4) como audiencia del token. Un token genérico de Azure CLI no coincide y el gateway lo descarta. ...

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