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 «conectado, sin internet» en las redes WiFi de invitados. Si gestiona la infraestructura WiFi de un hotel, una cadena de tiendas, un estadio o un centro de conferencias, seguro que se ha topado con esto. El dispositivo de un invitado muestra todas las barras de cobertura, 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 se abre. El invitado llama a recepción. Su equipo de soporte realiza una prueba de ping, todo parece correcto sobre el papel y, aun así, el problema se sigue repitiendo. 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 sincronización 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 forma permanente. [ANÁLISIS TÉCNICO DETALLADO — aproximadamente 5 minutos] Empecemos por lo fundamental. 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 realice cualquier autenticación) es resolver un nombre de dominio a una dirección IP a través de DNS. El Sistema de Nombres de Dominio es la guía telefónica de internet. Sin él, el dispositivo no tiene forma de saber a dónde enviar el tráfico. Ahora bien, aquí es donde empieza el problema. La mayoría de los dispositivos de consumo (iPhones, terminales Android, 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 conocido de Apple, 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 debe resolver primero 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 (normalmente entre uno y cinco segundos, según el sistema operativo). Si el resolutor DNS de su red no responde dentro de ese plazo, el dispositivo concluye que la red no tiene conectividad a internet, a pesar de estar totalmente asociado y tener una dirección IP válida. Ese es el error «conectado, sin internet». No es un fallo de conectividad: es un fallo de respuesta de las DNS. Entonces, ¿por qué falla el DNS en una red congestionada? Esta es la parte que pilla desprevenidos 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 de tres vías (handshake), 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 (timeout) y luego lo vuelve a intentar o desiste. En una red WiFi de invitados con cientos o miles de dispositivos concurrentes (piense en un estadio durante un partido, un hotel al completo 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 un resolvedor público como 8.8.8.8. Cuando todos los dispositivos de la red intentan simultáneamente sondear la detección del Captive Portal, ejecutar actualizaciones de aplicaciones en segundo plano y realizar 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 del rango normal de menos de 50 milisegundos a cientos o incluso miles de milisegundos. Comienzan a producirse timeouts. Los errores de "conectado, sin internet" empiezan a llegar en masa. También existe un segundo mecanismo que conviene entender: 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 (lo cual es habitual en espacios de alta densidad), las entradas almacenadas en caché caducan y deben volver a resolverse con frecuencia. Esto incrementa la carga de consultas DNS en el resolvedor precisamente cuando la red está bajo 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, 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 resuelve 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 y el internet ascendente. En lugar de reenviar cada consulta a un resolvedor público remoto, mantiene una caché local de los dominios resueltos con frecuencia, gestiona las sondas de detección del Captive Portal de forma nativa 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 de timeouts 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 disminuye significativamente. Desde la perspectiva de los estándares, esta arquitectura se alinea con las recomendaciones de IEEE 802.11 para despliegues de alta densidad y facilita el cumplimiento de los requisitos de tratamiento de datos del 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 es compatible con los requisitos de segmentación de red de PCI DSS al garantizar que el tráfico DNS de invitados esté aislado de la 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. Al implementar un filtro DNS empresarial en una red WiFi de invitados, hay tres decisiones de configuración que determinarán el éxito o el fracaso. En primer lugar, la ubicación del resolutor. 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 resolutor 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 Mánchester, estará 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 directo de DNS del Captive Portal. Este es el error de configuración más común que suelo ver. Al desplegar 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 la resolución del Captive Portal de forma explícita tras desplegar cualquier política de filtrado DNS. En tercer lugar, el ajuste del TTL. Configure su resolutor 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 resolutor 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 agresivas que, de forma involuntaria, bloquean dominios utilizados por aplicaciones legítimas de los invitados: servicios de streaming, endpoints de VPN corporativas o 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 identificar dominios bloqueados y perfeccione la configuración durante un periodo de dos semanas antes de bloquearla definitivamente. [PREGUNTAS Y RESPUESTAS RÁPIDAS — aproximadamente 1 minuto] Permítame repasar las preguntas que me formulan con más frecuencia sobre este tema. "¿Puedo usar simplemente 8.8.8.8 como mi resolutor DNS de invitados?" Puede hacerlo, pero bajo carga sufrirá tiempos de espera agotados. Un resolutor local o regional siempre superará el rendimiento de un resolutor 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 por 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 empresarial con el cumplimiento normativo?" Sí — el registro de consultas de DNS proporciona una pista de auditoría que respalda las obligaciones de rendición de cuentas del GDPR y puede ayudar en 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 "conectado, sin internet" en la red WiFi de invitados es, en su gran mayoría, un problema de sincronización 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 empresarial local de alto rendimiento que resuelva rápidamente las sondas de detección del Captive Portal, mantenga una caché local y aplique un 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 empresarial en su VLAN de invitados. Si desea profundizar en cualquiera de estos aspectos, la documentación de la plataforma de Purple cubre la configuración del filtro de DNS en detalle, y vale la pena revisar las guías de optimización de WiFi de invitados en purple.ai junto con este informe. Gracias por escuchar — nos vemos en el próximo episodio. [FIN DEL EPISODIO]