Networking

Problema En entornos con equipos Windows 11 unidos a dominio, es frecuente que al bloquear la sesión y volver a introducir las credenciales aparezca el mensaje “Your credentials could not be verified” o “You could not be signed in”. El bloqueo impide el acceso inmediato, obliga a reiniciar la máquina o a esperar a que el caché de credenciales se agote. El síntoma se reproduce tanto en equipos conectados directamente a la red corporativa como en usuarios que acceden mediante VPN. ...

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 En varios entornos corporativos los clientes Windows 10/11 pueden ejecutar gpupdate sin problemas, pero gpupdate /force devuelve “The processing of Group Policy failed. Windows could not resolve the computer (or user) name.” solo cuando la máquina está conectada a la red inalámbrica. La falla ocurre en cualquier dispositivo, sin importar fabricante, arquitectura ni imagen de sistema. Cuando el mismo equipo se conecta por cable a cualquier VLAN, el comando se completa exitosamente. ...

Problema En muchos homelabs el entusiasmo por añadir hardware, VLANs y contenedores lleva a una arquitectura que funciona, pero que rápidamente se vuelve difícil de mantener. El patrón típico es: Un servidor Proxmox que aloja varios LXCs no privilegiados. Múltiples VLANs creadas en un switch gestionado para separar tráfico de gestión, laboratorio, invitados y dispositivos de confianza. Un firewall virtual (Debian o similar) que actúa como puerta de enlace entre esas VLANs y el ISP. Herramientas de orquestación caseras que intentan automatizar la creación de redes y contenedores. El síntoma más común es que, tras añadir una nueva VLAN o LXC, aparecen problemas de conectividad inter‑VLAN, reglas de firewall que no se aplican o contenedores que pierden acceso a recursos críticos (DNS, NTP, almacenamiento). La raíz del problema suele estar en la falta de una guía estructurada que una la configuración de Proxmox, el switch gestionado y la orquestación de contenedores. ...

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 entornos de producción basados en OCI (Oracle Cloud Infrastructure) o cualquier nube pública, es frecuente que una instancia en una subnet pública necesite acceder a APIs externas mediante HTTPS. Cuando la conectividad falla de forma intermitente o total, los síntomas típicos son: curl https://api.ejemplo.com nunca devuelve una respuesta, se agota el timeout de conexión. Descargas de paquetes (apt update, yum install) fallan aleatoriamente. Algunas URLs (GitHub, PECL) funcionan sin problemas, mientras que otras (Fastly, servicios de IA) presentan pérdida de paquetes desde el primer salto fuera del edge de la nube. Herramientas de diagnóstico como mtr o traceroute muestran que los primeros dos hops (edge de OCI y el punto de handoff del ISP) son 0 % loss, pero a partir del tercer hop la pérdida sube a 100 % o a valores altos. El patrón es claro: la ruta está intacta dentro de la VCN, el problema aparece en la capa de tránsito regional o de peering con el ISP del datacenter. Este tipo de “blackhole” suele afectar sólo a ciertos rangos de IP (por ejemplo, bloques de Fastly o de un proveedor de IA) y no a la internet en general. ...

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