Networking

Problema En entornos de producción que usan Azure, los cambios de configuración predeterminada y la retirada de SKUs de máquinas virtuales pueden romper pipelines de CI/CD, scripts de aprovisionamiento y políticas de seguridad. Cuando Microsoft anuncia que Trusted Launch será el modo por defecto para cualquier VM Gen2, o que los SKUs cc_v5 de máquinas confidenciales se retirarán, los equipos se ven obligados a revisar plantillas Bicep/Terraform, scripts de PowerShell y procesos de despliegue. Además, la llegada de funcionalidades como Azure Virtual Network Routing Appliance (VNRA), Azure Firewall explicit proxy, Route Server route maps y IPv6 Private Link implica que los diseños de red que antes funcionaban sin esas opciones pueden quedar desalineados con las mejores prácticas actuales. El patrón típico es: una actualización de plataforma introduce un nuevo comportamiento por defecto o elimina recursos, y el código de infraestructura existente no se adapta, generando fallos en despliegues, errores de compatibilidad o brechas de seguridad. ...

Problema En entornos de producción con varios servicios Docker, es frecuente que los contenedores publiquen sus puertos directamente en la interfaz 0.0.0.0 del host. Esa práctica amplía la superficie de ataque porque cualquier cliente externo puede intentar conectar a esos puertos, aunque el objetivo sea que todo el tráfico pase por un reverse proxy. El desafío consiste en: Mantener los puertos internos del contenedor cerrados al host. Permitir que Nginx Proxy Manager (NPM) enrute peticiones HTTP/HTTPS al contenedor objetivo. Asegurar que la base de datos u otros servicios internos no queden expuestos accidentalmente. El problema se manifiesta típicamente con errores 504 o “Bad Gateway” cuando NPM no logra alcanzar el backend, aunque el contenedor esté activo y saludable. La causa suele estar en la configuración de redes Docker o en la forma en que se exponen los puertos. ...

Problema En entornos corporativos es habitual que el controlador inalámbrico (WLC) de Cisco delegue la autenticación 802.1X a un servidor RADIUS externo. Cuando se reemplaza un ISE por un NPS (Network Policy Server) de Windows, muchos administradores observan que los clientes nunca llegan a autenticarse: el WLC muestra errores como %DOT1X-3-AAA_AUTH_SEND_FAIL o %DOT1X-3-ABORT_AUTH, mientras que el NPS no registra ninguna solicitud. El síntoma típico es: Cliente lanza EAPOL‑Start, el WLC intenta enviar un Access‑Request al NPS y falla. En los logs del WLC aparecen “Unable to send AAA message” y “Authentication Aborted”. En el NPS no hay entradas de autenticación ni de accounting. Este patrón indica que la comunicación RADIUS entre el controlador y el servidor está rota o mal interpretada, no que el cliente sea el culpable. ...

Problema Muchos homelabs empiezan con hardware barato (Raspberry Pi, mini‑NAS) y van añadiendo servicios a medida que aparecen necesidades. Con el tiempo la cantidad de contenedores, redes Docker y túneles VPN crece hasta que la gestión se vuelve engorrosa: cada nodo tiene su propio firewall, DNS local y reverse proxy, y la topología de red está fragmentada. Cuando se adquiere un servidor más potente, la tentación es migrar todo a una única plataforma de virtualización, pero surge la duda de cómo reorganizar VMs/LXC, si mantener la malla WireGuard y cómo simplificar la cadena de DNS/Proxy sin perder la flexibilidad que ofrecían los nodos independientes. ...

Problema Exponer servicios auto‑hospedados (media, archivos, gestión de fotos, etc.) directamente a Internet aumenta la superficie de ataque. Cada aplicación necesita su propio certificado TLS, reglas de firewall y actualizaciones de seguridad. Cuando varios servicios comparten el mismo host, un compromiso en uno puede escalar rápidamente a los demás o a la red interna. La necesidad recurrente es disponer de una capa única que: Termine TLS una sola vez. Redirija el tráfico al contenedor correspondiente. Aísle cada servicio a nivel de red. Bloquee patrones de ataque antes de que lleguen a la aplicación. Causa Los fallos habituales provienen de combinaciones de configuraciones débiles: ...

Problema Los administradores de firewalls basados en pfSense Plus empiezan a recibir la versión Release Candidate 26.07, que introduce el controlador Netgate Nexus. El nuevo GUI está escrito en Go y reemplaza al legado PHP, pero su activación no es automática. En entornos de producción o laboratorios de pruebas, la transición al Nexus suele generar: Inaccesibilidad al puerto 8443 después de habilitar el controlador. Fallos en servicios dependientes (DNS Resolver, IPsec, OpenVPN) que siguen usando la pila antigua. Incompatibilidades con máquinas virtuales que no exponen la información de hardware requerida por Nexus. Dificultad para validar que componentes como CoreDNS, Threatgate o Snort v3 están realmente activos. El reto es habilitar el Nexus de forma segura, validar su correcto funcionamiento y volver atrás sin interrumpir el tráfico crítico. ...

Problema En entornos de homelab o pequeñas infraestructuras es frecuente lanzar varios servicios en contenedores Docker y conectar todos ellos a la red predeterminada bridge. Esa configuración permite que cualquier contenedor alcance a otro usando su dirección IP y puerto expuesto, lo que rompe la premisa de “aislamiento por diseño”. Cuando varios servicios comparten la misma subred, un atacante que comprometa un contenedor puede explorar libremente los demás, y usuarios de la LAN pueden saltarse reglas de VLAN porque el tráfico nunca sale del host. El objetivo típico es que solo el reverse proxy sea la puerta de entrada y que el resto de contenedores queden invisibles para la red local y entre sí. ...

Problema En entornos híbridos donde los controladores de dominio (DC) están tanto on‑premises como en Azure, los servidores Windows suelen apuntar al DC de Azure para resolver nombres internos. Cuando se habilitan Private Endpoints (por ejemplo, para Azure Files) se crea una zona DNS privada como privatelink.file.core.windows.net. Si la resolución de esa zona no llega al Azure DNS Private Resolver, los clientes no pueden autenticar ni montar recursos compartidos. El síntoma típico es un error de autenticación al intentar mapear un drive o una falla de resolución de *.privatelink.* desde máquinas en Azure o desde la red on‑prem. ...

Problema Muchas organizaciones pequeñas‑medianas llegan a un punto en el que la infraestructura está fragmentada: varios dominios de Active Directory sin relación entre sí, servidores con sistemas operativos fuera de soporte, equipos de red que se acercan al final de su vida útil y, sobre todo, ausencia de documentación. El resultado es una base de TI que se vuelve imposible de gestionar, arriesga la continuidad del negocio y dificulta cualquier proyecto de modernización. El reto consiste en ordenar esa complejidad antes de introducir cambios estructurales como migraciones a nuevas plataformas de virtualización o a proveedores de red diferentes. ...

Problema En entornos con Active Directory, los equipos con Windows 11 25H2 pueden presentar un bloqueo total del subsistema de seguridad (LSASS/LSAIso) cuando se realiza cualquier operación que dependa de SSPI o Kerberos. El síntoma típico es que aplicaciones como curl --negotiate, RDP, Chrome (proxy auth) o PuTTY (GSSAPI) quedan colgadas indefinidamente. Un diagnóstico rápido muestra que klist get tgt se detiene en Current LogonId is 0:0x… y, curiosamente, Wireshark no captura tráfico en los puertos 88/TCP, 88/UDP, 53 o 389. Herramientas de red básicas (ping, telnet) siguen funcionando, lo que indica que el problema no está en la conectividad física sino en la capa de autenticación local. ...