Networking

Problema Muchos entornos híbridos usan Azure Point‑to‑Site (P2S) VPN para dar acceso a máquinas on‑premise o a laptops. Cuando la puerta de enlace está configurada para autenticarse con Microsoft Entra ID (antes Azure AD), la experiencia en Windows es fluida, pero en Linux aparecen dos obstáculos recurrentes: El cliente oficial Azure VPN Client para Linux quedó en preview, solo soporta Ubuntu 20.04/22.04 y fue retirado sin recibir parches. Los clientes genéricos (OpenVPN, strongSwan) esperan autenticación basada en certificados o RADIUS; no saben manejar un token JWT que Entra ID entrega mediante el flujo device‑code. El síntoma típico es que la conexión falla inmediatamente después de la fase de autenticación, con mensajes como “username/password authentication failed” o “TLS channel buffer overflow”. El problema no es exclusivo de una distribución; ocurre siempre que el token supera los buffers internos de OpenVPN. ...

Problema Muchos entornos de homelab o pequeñas oficinas dependen de un único enlace de Internet que, por limitaciones del ISP, ofrece ancho de banda insuficiente para varios equipos simultáneos. Cuando se habilita un túnel VPN como Cloudflare WARP en una máquina, la velocidad mejora notablemente, pero solo esa máquina se beneficia. La necesidad típica es proporcionar esa mejora a todos los servidores y contenedores sin instalar WARP en cada uno, manteniendo al mismo tiempo una política de “corte total” si el túnel falla. ...

Problema En muchos homelabs se combinan Pi‑hole como resolutor DNS interno, Nginx Proxy Manager (NPM) para la terminación TLS y Cloudflare Tunnel para exponer servicios al exterior. Cuando los navegadores dentro de la LAN intentan acceder a sub‑dominios gestionados por NPM, aparecen errores como ERR_SSL_UNRECOGNIZED_NAME_ALERT o ERR_QUIC_PROTOCOL_ERROR. La causa típica es que el cliente recibe una respuesta DNS que mezcla direcciones internas (IPv4) con registros externos (IPv6 o A) obtenidos de Cloudflare, lo que rompe la coincidencia del certificado y obliga al navegador a abortar la conexión TLS. ...

Problema Muchas organizaciones están obligadas por sus equipos de arquitectura y seguridad a eliminar el tráfico DNS sin cifrar. El DNS tradicional funciona sobre UDP/53 y, aunque es rápido, permite a cualquier punto de la red inspeccionar nombres de dominio, filtrar contenido o incluso lanzar ataques de envenenamiento. Cuando la política exige “encrypted DNS”, los equipos de red deben sustituir la resolución tradicional por alguna variante de DNS over HTTPS (DoH), DNS over TLS (DoT) o DNS over QUIC (DoQ). ...

Problema En redes domésticas y de pequeñas oficinas es habitual combinar dos capas distintas: un filtro DNS que decide si un nombre debe resolverse y una política de salida que determina por qué túnel o interfaz pasa el tráfico. Cuando ambas capas están desacopladas, cada nuevo dispositivo o categoría de aplicación obliga a crear reglas en al menos dos lugares diferentes (lista de bloqueo y tabla de rutas). El resultado es una configuración fragmentada que se vuelve difícil de auditar, propensa a errores y que requiere scripts o glue manual para mantener la coherencia. Además, la mayoría de las soluciones populares (Pi‑hole, AdGuard Home) no ofrecen una forma nativa de redirigir tráfico DNS a un túnel específico por dispositivo, lo que obliga a usar VPNs o reglas de firewall externas que no siempre se alinean con la lógica de bloqueo. ...

Problema En muchos homelabs el acceso externo se hace a través de un VPS que actúa como punto de entrada. El VPS abre los puertos 80/443, crea un túnel WireGuard hacia la red doméstica y reenvía el tráfico a un reverse proxy (Nginx, HAProxy, etc.) que ya está gestionando los contenedores Docker. El inconveniente típico es que, al usar NAT (por ejemplo iptables -t nat -A POSTROUTING -j MASQUERADE) en el VPS, la dirección IP que llega al reverse proxy es la del túnel, no la del cliente original. ...

Problema En entornos de producción es habitual validar que un balanceador de carga solo exponga los puertos que la arquitectura requiere. Cuando se ejecuta un escáner de puertos (por ejemplo, nmap) contra la dirección DNS o IP de un Network Load Balancer (NLB) y aparecen puertos diferentes a los configurados en los listeners, el resultado genera dudas de seguridad y de configuración. El síntoma típico es: Un listener configurado únicamente en 443/tcp. El escáner muestra puertos adicionales (p. ej. 2000/tcp, 5060/tcp) como open o filtered. El comportamiento se repite en varias ejecuciones y en diferentes rangos de IP. Este patrón no es exclusivo de un caso puntual; ocurre en cualquier despliegue donde el NLB está delante de instancias EC2, contenedores o servicios en VPC y donde la visibilidad del tráfico se confunde entre el propio NLB y los recursos backend. ...

Problema En muchos homelabs la tentación es conectar todos los dispositivos a un único broadcast domain por comodidad. Con el tiempo esa arquitectura se vuelve frágil: un equipo comprometido puede acceder a servidores críticos, el tráfico de invitados congestiona la red y la gestión de políticas de seguridad se vuelve un caos. El patrón que surge es la necesidad de segmentar la red en varios dominios lógicos (trusted, guest, servers, DMZ) y aplicar reglas de firewall entre ellos, manteniendo conectividad entre sitios remotos mediante protocolos ligeros como RIP y ofreciendo acceso remoto seguro con SSL‑VPN. El reto no es solo crear los VLANs, sino asegurarse de que la segmentación sea coherente, que las rutas se propaguen correctamente y que la política de firewall no se “derrite” con el tiempo. ...

Problema En muchos laboratorios domésticos y entornos de pruebas se necesita correlacionar los logs de un firewall o dispositivo de seguridad con el tráfico real que atraviesa la red. La dificultad radica en capturar paquetes solo cuando se lo requiere, sin mantener una captura continua que llene discos y genere ruido. El patrón típico es: Un tráfico de prueba se genera contra un firewall (por ejemplo, para validar un perfil de IPS). Se desea iniciar una captura de paquetes en el punto de salida del firewall, con una duración limitada (30 s, 2 min, etc.). La captura debe guardarse en un servidor central para su posterior análisis junto a los logs del firewall. Los retos habituales son: configurar el mirroring sin impactar el rendimiento, disparar la captura de forma remota y asegurarse de que el archivo resultante sea accesible y consistente. ...

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