Resolución del error "Conectado pero sin Internet" en redes WiFi de invitados

Resolución del error "Conectado pero sin internet" en redes WiFi de invitados: un informe técnico de Purple [INTRODUCCIÓN Y CONTEXTO - aproximadamente 1 minuto] Le damos la bienvenida a la serie de informes técnicos de Purple. Soy su anfitrión y hoy abordaremos uno de los problemas más persistentes y frustrantes en las redes de recintos empresariales: el error de "conectado, sin internet" en redes WiFi de invitados. Si gestiona la infraestructura WiFi en un hotel, una cadena de tiendas, un estadio o un centro de conferencias, seguro que se ha encontrado con esto. El dispositivo de un invitado muestra la barra de cobertura al máximo, está asociado a su punto de acceso, se le ha asignado una dirección IP y, sin embargo, el navegador no carga nada. El Captive Portal nunca aparece. El invitado llama a recepción. Su equipo de soporte realiza una prueba de ping, todo parece estar en orden sobre el papel y, aun así, el problema persiste. La cuestión es la siguiente: en la gran mayoría de los casos que encuentro en despliegues empresariales, no se trata de un fallo de hardware, ni de una configuración incorrecta del cortafuegos, ni de un problema de ancho de banda en el sentido tradicional. Es un problema de tiempos de respuesta de DNS, y casi siempre lo desencadena la congestión de la red. Hoy quiero explicarle detalladamente por qué ocurre esto, cómo diagnosticarlo de forma fiable y cómo el despliegue de un filtro DNS empresarial resuelve este cuello de botella de manera permanente. [ANÁLISIS TÉCNICO DETALLADO - aproximadamente 5 minutos] Comencemos con los aspectos fundamentales. Cuando el dispositivo de un invitado se conecta a su red WiFi, lo primero que debe hacer (antes de poder cargar una sola página web, antes de que su Captive Portal pueda redirigirlo y antes de que se produzca cualquier autenticación) es resolver un nombre de dominio a una dirección IP a través de DNS. El Domain Name System es la agenda telefónica de internet. Sin él, su dispositivo no tiene forma de saber a dónde enviar el tráfico. Ahora, aquí es donde empieza el problema. La mayoría de los dispositivos de consumo (iPhones, terminales Android, ordenadores portátiles con Windows) tienen un mecanismo integrado llamado sonda de detección de Captive Portal. En iOS, por ejemplo, el dispositivo envía una solicitud HTTP a un endpoint de Apple conocido, como captive.apple.com. En Android, accede a connectivitycheck.gstatic.com. En Windows, sondea msftconnecttest.com. Estas sondas están diseñadas para detectar si la red requiere una página de inicio de sesión antes de conceder acceso a internet. El punto crítico es este: estas sondas dependen de las DNS. El dispositivo primero debe resolver el nombre de dominio del endpoint de la sonda antes de poder enviar la solicitud HTTP. Y esa consulta DNS tiene un tiempo de espera límite (normalmente entre uno y cinco segundos, según el sistema operativo). Si el servidor de resolución DNS de su red no responde dentro de ese plazo, el dispositivo concluye que la red no tiene conectividad a internet, a pesar de que está completamente asociado y tiene una dirección IP válida. Ese es el error de "conectado, sin internet". No es un fallo de conectividad, es un fallo en la respuesta de DNS.¿Por qué falla el DNS en una red congestionada? Esta es la parte que pilla por sorpresa a muchos equipos. Las consultas DNS se envían por defecto a través de UDP, en el puerto 53. UDP es un protocolo sin conexión: no hay saludo, ni confirmación, ni retransmisión en la capa de transporte. Si un paquete DNS se descarta debido a la congestión de la red, el cliente simplemente espera hasta que expira el tiempo de espera y luego vuelve a intentarlo o desiste. En una red WiFi de invitados con cientos o miles de dispositivos concurrentes - piense en un estadio durante un partido, un hotel lleno o un centro de conferencias durante una ponencia -, el enlace ascendente y el resolvedor DNS pueden saturarse muy rápidamente. El problema se ve agravado por el hecho de que las redes de invitados suelen compartir un único resolvedor DNS ascendente, a menudo el resolvedor por defecto del ISP o uno público como 8.8.8.8. Cuando todos los dispositivos de la red intentan simultáneamente detectar el Captive Portal, ejecutan actualizaciones de aplicaciones en segundo plano y realizan consultas DNS para redes sociales y servicios de streaming, ese único resolvedor se convierte en un cuello de botella. Los tiempos de respuesta de las consultas pasan de la franja habitual de menos de 50 milisegundos a cientos o incluso miles de milisegundos. Empiezan a producirse tiempos de espera agotados. Los errores de "conectado, sin internet" comienzan a llegar en masa. También hay un segundo mecanismo que conviene comprender: el agotamiento del TTL. Las respuestas DNS incluyen un valor de tiempo de vida (TTL) que indica al dispositivo receptor cuánto tiempo debe almacenar en caché la dirección IP resuelta. En una red congestionada donde los dispositivos se asocian y desasocian constantemente - algo habitual en espacios de alta densidad -, las entradas almacenadas en caché caducan y deben volver a resolverse con frecuencia. Esto aumenta la carga de consultas DNS en el resolvedor precisamente cuando la red está sometida a la mayor presión. Ahora bien, la respuesta tradicional a este problema es aumentar el ancho de banda: mejorar el enlace ascendente, añadir más puntos de acceso e implementar políticas de QoS. Todas estas son medidas válidas, pero no abordan la causa raíz. La causa raíz es que su ruta de resolución DNS no está optimizada para entornos de invitados de alta densidad. Y eso es exactamente lo que soluciona un filtro DNS empresarial. Un filtro DNS empresarial - como la capacidad de filtrado DNS dentro de la plataforma de WiFi de invitados de Purple - funciona como un resolvedor DNS local de alto rendimiento que se sitúa entre sus dispositivos de invitados e internet. En lugar de reenviar cada consulta a un resolvedor público remoto, mantiene una caché local de los dominios resueltos con más frecuencia, gestiona de forma nativa las sondas de detección del Captive Portal y aplica un filtrado basado en políticas para bloquear los dominios maliciosos o no conformes antes de que lleguen al resolvedor ascendente. El resultado es una reducción drástica de la latencia de las consultas DNS - normalmente pasando de tiempos de espera agotados de dos a tres segundos a respuestas de menos de 200 milisegundos -, lo que significa que las sondas de detección del Captive Portal tienen éxito al primer intento, el error de "conectado, sin internet" desaparece y el tiempo de incorporación de los invitados se reduce considerablemente. Desde el punto de vista de los estándares, esta arquitectura se alinea con las recomendaciones de IEEE 802.11 para despliegues de alta densidad y ayuda a cumplir con los requisitos de gestión de datos de GDPR al permitir registrar y auditar las consultas DNS - lo cual es relevante si opera bajo una licencia del sector público o de hostelería. También respalda los requisitos de segmentación de red de PCI-DSS al garantizar que el tráfico DNS de invitados esté aislado de su infraestructura de resolución corporativa. [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES - aproximadamente 2 minutos] Permítame ofrecerle una guía práctica para el despliegue. Cuando se implementa un filtro DNS empresarial en una red WiFi de invitados, hay tres decisiones de configuración que determinarán su éxito o fracaso. En primer lugar, la ubicación del resolvedor. Su filtro DNS debe desplegarse lo más cerca posible de la red de invitados - idealmente en la misma VLAN o subred que sus puntos de acceso de invitados. Cada salto entre el dispositivo del invitado y el resolvedor añade latencia. Si su filtro DNS está ubicado en un centro de datos remoto y su red de invitados está en un hotel en Manchester, está añadiendo un tiempo de ida y vuelta que anula el propósito. Utilice un dispositivo local o un filtro DNS basado en la nube con un punto de presencia regional. En segundo lugar, el paso de DNS del Captive Portal. Este es el error de configuración más común que veo. Cuando despliega un filtro DNS, debe asegurarse de que el propio dominio del Captive Portal - la URL a la que se redirige a los invitados para la autenticación - esté en la lista de permitidos del filtro. Si el filtro bloquea o retrasa la resolución del dominio de su Captive Portal, volverá a crear exactamente el problema que intentaba resolver. Pruebe siempre de forma explícita la resolución del Captive Portal después de desplegar cualquier política de filtrado DNS. En tercer lugar, el ajuste de TTL. Configure su resolvedor DNS local para ofrecer TTL cortos para los dominios de prueba de detección del Captive Portal - Apple, Google, Microsoft - de modo que los dispositivos vuelvan a realizar consultas con frecuencia y obtengan siempre una respuesta local rápida, en lugar de esperar a que caduque una entrada en caché y luego recurrir a un resolvedor ascendente congestionado. Un TTL de 30 a 60 segundos para estos dominios específicos es un punto de partida razonable. El error que debe evitar es el filtrado excesivo. Algunos equipos despliegan listas de bloqueo DNS muy agresivas que bloquean involuntariamente dominios utilizados por aplicaciones legítimas de los invitados - servicios de streaming, endpoints de VPN corporativas, almacenamiento en la nube. Esto genera un tipo diferente de ticket de soporte, pero es igualmente perjudicial para la experiencia del invitado. Comience con una política conservadora, supervise los registros de consultas DNS para detectar dominios bloqueados y perfeccione la configuración durante un período de dos semanas antes de bloquearla de forma definitiva. [PREGUNTAS Y RESPUESTAS RÁPIDAS - aproximadamente 1 minuto] Permítame repasar las preguntas que me hacen con más frecuencia sobre este tema. "¿Puedo usar simplemente 8.8.8.8 como mi resolvedor DNS de invitados?" Puede hacerlo, pero bajo carga sufrirá tiempos de espera agotados (timeouts). Un resolvedor local o regional siempre superará el rendimiento de un resolvedor público en una red congestionada. "¿Afecta esto a los despliegues de WPA3?" No - WPA3 mejora la seguridad de la autenticación pero no cambia la ruta de resolución de DNS. El mismo problema de tiempo de espera de DNS ocurre independientemente del estándar de cifrado en uso. "¿Cómo sé si el DNS es la causa real de mis errores de 'conectado, sin internet'?" Realice una captura de paquetes en la VLAN de invitados durante las horas de mayor carga. Filtre el tráfico del puerto UDP 53. Si ve consultas de DNS sin una respuesta correspondiente en un plazo de dos segundos, el tiempo de espera de DNS es el culpable. "¿Ayuda un filtro de DNS corporativo con el cumplimiento normativo?" Sí - el registro de consultas de DNS proporciona un registro de auditoría que respalda las obligaciones de responsabilidad del GDPR y puede ayudar con la respuesta a incidentes. La plataforma de Purple incluye este registro de forma nativa. [RESUMEN Y PRÓXIMOS PASOS - aproximadamente 1 minuto] En resumen: el error de "conectado, sin internet" en la red WiFi de invitados es, en su gran mayoría, un problema de tiempos de DNS causado por la congestión de la red que satura una ruta de resolución no optimizada. La solución no es más ancho de banda - es un filtro de DNS corporativo local de alto rendimiento que resuelva las sondas de detección del Captive Portal rápidamente, mantenga un caché local y aplique filtrado basado en políticas para reducir la carga de consultas ascendentes. Las tres cosas que debe hacer esta semana: realizar una captura de paquetes de DNS durante las horas de mayor carga para confirmar el diagnóstico; revisar la ubicación actual de su servidor de resolución de DNS e identificar si es local o remoto; y evaluar el despliegue de un filtro de DNS corporativo en su VLAN de invitados. Si desea profundizar en alguno de estos aspectos, la documentación de la plataforma Purple cubre la configuración del filtro de DNS en detalle, y las guías de optimización de WiFi de invitados en purple.ai merecen ser revisadas junto con este informe. Gracias por escuchar - nos vemos en el próximo episodio. [FIN DEL EPISODIO]