Cómo resolver el error de Conectado pero sin Internet en el WiFi de invitados

Resolviendo el error de Conectado pero sin Internet en el WiFi de invitados — Un informe técnico de Purple [INTRODUCCIÓN Y CONTEXTO — aproximadamente 1 minuto] Bienvenido 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 el WiFi de invitados. Si administra la infraestructura WiFi en un hotel, cadena de tiendas, estadio o centro de conferencias, seguro ha visto esto. El dispositivo de un invitado muestra todas las barras de señal, 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 la recepción. Su equipo de soporte realiza una prueba de ping, todo parece estar bien en papel y, sin embargo, el problema sigue ocurriendo. La realidad es esta: en la gran mayoría de los casos que encuentro en implementaciones empresariales, esto no es una falla de hardware, ni una mala configuración del firewall, ni 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 exactamente por qué sucede esto, cómo diagnosticarlo de manera confiable y cómo la implementación de un filtro DNS empresarial resuelve este cuello de botella de forma permanente. [ANÁLISIS TÉCNICO PROFUNDO — aproximadamente 5 minutos] Comencemos con 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, antes de que ocurra cualquier autenticación) es resolver un nombre de dominio a una dirección IP a través de DNS. El Domain Name System es el directorio telefónico de Internet. Sin él, su dispositivo no tiene forma de saber a dónde enviar el tráfico. Ahora, aquí es donde comienza el problema. La mayoría de los dispositivos de consumo (iPhones, teléfonos Android, laptops con Windows) tienen un mecanismo integrado llamado prueba de detección del Captive Portal. En iOS, por ejemplo, el dispositivo envía una solicitud HTTP a un endpoint conocido de Apple, algo como captive.apple.com. En Android, accede a connectivitycheck.gstatic.com. En Windows, prueba con msftconnecttest.com. Estas pruebas están diseñadas para detectar si la red requiere una página de inicio de sesión antes de otorgar acceso a Internet. El punto crítico es este: estas pruebas dependen de DNS. El dispositivo primero debe resolver el nombre de dominio del endpoint de prueba antes de poder enviar la solicitud HTTP. Y esa consulta DNS tiene un tiempo de espera, que suele ser de entre uno y cinco segundos, según el sistema operativo. Si el sistema de resolución DNS de su red no responde dentro de ese plazo, el dispositivo concluye que la red no tiene conectividad a Internet, aunque esté completamente asociado y tenga una dirección IP válida. Ese es el error "conectado, sin internet". No es una falla de conectividad, es una falla de respuesta de DNS. Entonces, ¿por qué falla el DNS en una red congestionada? Esta es la parte que toma por sorpresa a muchos equipos. Las consultas DNS se envían a través de UDP de forma predeterminada, 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 expire el tiempo de espera y luego vuelve a intentarlo o se rinde. En una red WiFi de invitados con cientos o miles de dispositivos simultáneos (piense en un estadio durante un partido, un hotel lleno o un centro de conferencias durante una presentación), el enlace ascendente y el sistema de resolución DNS pueden saturarse muy rápidamente. El problema se complica por el hecho de que las redes de invitados suelen compartir un único sistema de resolución DNS ascendente, a menudo el predeterminado del ISP o uno público como 8.8.8.8. Cuando todos los dispositivos de la red intentan detectar el Captive Portal al mismo tiempo, ejecutan actualizaciones de aplicaciones en segundo plano y realizan consultas DNS para redes sociales y servicios de streaming, ese único sistema de resolución se convierte en un cuello de botella. Los tiempos de respuesta de las consultas aumentan de un rango normal de menos de 50 milisegundos a cientos o incluso miles de milisegundos. Comienzan a ocurrir tiempos de espera. Los errores de "conectado, sin internet" empiezan a multiplicarse. También hay un segundo mecanismo que vale la pena comprender: el agotamiento del TTL. Las respuestas DNS incluyen un valor de tiempo de vida (TTL) que le 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 común en recintos 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 sistema de resolución precisamente cuando la red está bajo mayor presión. Ahora, la respuesta tradicional a este problema es aumentar el ancho de banda: actualizar el enlace ascendente, agregar 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 sistema de resolución DNS local de alto rendimiento que se ubica entre los dispositivos de sus invitados y el Internet ascendente. En lugar de reenviar cada consulta a un sistema de resolución público remoto, mantiene una caché local de los dominios resueltos con frecuencia, maneja las pruebas de detección del Captive Portal de forma nativa y aplica un filtrado basado en políticas para bloquear dominios maliciosos o que no cumplen con las normas antes de que lleguen al sistema de resolución ascendente. El resultado es una reducción drástica de la latencia de las consultas DNS (normalmente de tiempos de espera de dos a tres segundos a respuestas de menos de 200 milisegundos), lo que significa que las pruebas de detección del Captive Portal tienen éxito en el primer intento, el error "conectado, sin internet" desaparece y el tiempo de onboarding de los invitados disminuye significativamente. Desde la perspectiva de los estándares, esta arquitectura se alinea con las recomendaciones de IEEE 802.11 para implementaciones de alta densidad y respalda el cumplimiento de los requisitos de manejo de datos de GDPR al permitirle registrar y auditar las consultas DNS, lo cual es relevante si opera bajo una licencia del sector público o de hotelería. También respalda los requisitos de segmentación de red de PCI DSS al garantizar que el tráfico DNS de los invitados esté aislado de la infraestructura de resolución corporativa. [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES — aproximadamente 2 minutos] Permítame darle una guía práctica de implementación. Cuando implemente un filtro DNS empresarial en una red WiFi de invitados, hay tres decisiones de configuración que determinarán su éxito o fracaso. Primero, la ubicación del sistema de resolución. Su filtro DNS debe implementarse 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 sistema de resolución agrega latencia. Si su filtro DNS está en un centro de datos remoto y su red de invitados está en un hotel en Monterrey, está agregando un tiempo de ida y vuelta que anula el propósito. Utilice un dispositivo local o un filtro DNS entregado desde la nube con un punto de presencia regional. Segundo, el paso libre de DNS para el Captive Portal. Esta es la configuración incorrecta más común que veo. Cuando implementa 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 en el 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 después de implementar cualquier política de filtrado DNS. Tercero, el ajuste del TTL. Configure su sistema de resolución 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 siempre obtengan una respuesta local rápida en lugar de esperar a que caduque una entrada almacenada en caché y luego recurrir a un sistema de resolución ascendente congestionado. Un TTL de 30 a 60 segundos para estos dominios específicos es un buen punto de partida. El error que debe evitar es el filtrado excesivo. Algunos equipos implementan listas de bloqueo de DNS muy agresivas que bloquean sin querer 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 igual de perjudicial para la experiencia del invitado. Comience con una política conservadora, monitoree los registros de consultas DNS para identificar dominios bloqueados y ajuste la configuración durante un período de dos semanas antes de bloquearla por completo. [PREGUNTAS Y RESPUESTAS RÁPIDAS — aproximadamente 1 minuto] Repasemos las preguntas que me hacen con más frecuencia sobre este tema. "¿Puedo usar simplemente 8.8.8.8 como mi sistema de resolución DNS de invitados?" Puede hacerlo, pero bajo carga experimentará tiempos de espera. Un sistema de resolución local o regional siempre superará a un sistema de resolución público en una red congestionada. "¿Afecta esto a las implementaciones 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 pico de carga. Filtre por el tráfico del puerto UDP 53. Si ve consultas DNS sin la respuesta correspondiente en un plazo de dos segundos, el tiempo de espera de DNS es el culpable. "¿Ayuda un filtro DNS empresarial con el cumplimiento de normas?" Sí. El registro de consultas DNS proporciona un historial de auditoría que respalda las obligaciones de rendición de cuentas de 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 "conectado, sin internet" en el 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, sino un filtro DNS empresarial local de alto rendimiento que resuelva rápidamente las pruebas 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 DNS durante las horas pico para confirmar el diagnóstico; revisar la ubicación actual de su sistema de resolución DNS e identificar si es local o remoto; y evaluar la implementación de un filtro DNS empresarial en su VLAN de invitados. Si desea profundizar en cualquiera de estos temas, la documentación de la plataforma de Purple cubre la configuración del filtro 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 la próxima entrega. [FIN DEL EPISODIO]