Cómo solucionar el error «Conectado pero sin internet» en la WiFi para invitados

El error de conectado pero sin internet en el WiFi para invitados se produce cuando las comprobaciones de conectividad fallan antes de que se cargue el portal cautivo. En recintos con mucha afluencia, las consultas DNS por el puerto UDP 53 (RFC 1035) agotan el tiempo de espera durante los picos de congestión. Para solucionarlo, es necesario apuntar los ámbitos DHCP de invitados a un filtro DNS con caché, completar los dominios del jardín vallado (walled garden) en los controladores como Cisco Meraki y revisar las reglas de modelado de tráfico.

¿Qué aspecto tiene el mensaje "conectado, sin internet" en el WiFi para invitados?

El invitado ve todas las barras de señal y se ha unido a la red, pero no se carga nada. La página de inicio de sesión nunca aparece, por lo que no puede aceptar los términos ni iniciar sesión. A continuación, se dirige a la recepción, al punto de información o al mostrador de atención al cliente.

Cada sistema operativo formula la advertencia de forma diferente. El equipo de soporte de su recinto debe reconocer todas ellas:

• Windows muestra "Sin Internet" debajo del nombre de la red.
• Android muestra "Conectado sin internet" o "Es posible que internet no esté disponible".
• iPhone e iPad muestran "Sin conexión a internet" debajo del nombre de la red.

Las tres proceden del mismo mecanismo. Tras unirse a la red, el dispositivo solicita una dirección web conocida para probar la conexión. Si esa prueba devuelve la página esperada, el dispositivo considera que la conexión funciona. Si devuelve una página de inicio de sesión, el dispositivo abre el portal cautivo. Si no recibe respuesta alguna, el dispositivo informa de que no hay internet.

Antes de que el dispositivo pueda solicitar cualquiera de estas páginas, tiene que buscar el hostname a través del DNS. Esa búsqueda es donde comienzan la mayoría de los fallos de alta densidad.

¿Qué suele causar los errores de conectado sin internet en el WiFi para invitados?

Tiempos de espera agotados de DNS en una red congestionada

El DNS (Domain Name System) convierte un hostname en una dirección IP. La mayoría de las consultas DNS viajan a través del puerto UDP 53, tal y como se define en el RFC 1035. UDP no tiene retransmisión integrada, por lo que una consulta descartada simplemente espera al propio temporizador de reintento del dispositivo.

La congestión se produce por ráfagas. Piense en el descanso de un partido en un estadio, en el momento de dejar la habitación por la mañana en un hotel o en la llegada de un tren a la estación. Cientos de dispositivos se conectan en cuestión de segundos y todos envían una búsqueda a la vez. Si el solucionador se encuentra a varios saltos de distancia a través de un enlace WAN saturado, las consultas se retrasan o se pierden. El dispositivo se rinde, el portal nunca se abre y el invitado ve el mensaje "sin internet".

Los otros motivos habituales

El DNS es la causa más común en recintos muy concurridos, pero no la única. Descarte también estas opciones:

• Entradas faltantes en el jardín vallado (walled garden). El jardín vallado es la lista de dominios a los que un dispositivo puede acceder antes de iniciar sesión. Si falta su portal o sus recursos, la página no se puede cargar.
• Agotamiento del fondo común (pool) de direcciones DHCP. Si el fondo común de direcciones se agota, los dispositivos se asignan a sí mismos una dirección 169.254.x.x y no pueden acceder a nada.
• Límites de velocidad o limitación de QoS en el puerto UDP 53. Un límite por cliente o por SSID establecido de forma demasiado estricta puede dejar sin servicio a los DNS durante un pico de tráfico.
• DNS cifrado. DNS sobre HTTPS (DoH, RFC 8484) y DNS sobre TLS (DoT, RFC 7858) envían consultas a resolutores externos. Un portal cautivo que bloquee dichos resolutores detiene la consulta antes del inicio de sesión.
• Una interrupción en la red previa (upstream). Si el propio enlace WAN no funciona, fallan todos los dispositivos y también todos los puertos cableados.

¿Cómo determinar cuál es la causa?

Comience por el patrón, no por el hardware. Utilice esta matriz para acotar la causa antes de modificar nada.

Tres comprobaciones que puede realizar su equipo de soporte

1. Compruebe la dirección IP del dispositivo. Una dirección 169.254.x.x indica un problema de DHCP, no de DNS. Una dirección normal dentro del rango de invitados significa que el dispositivo se ha conectado correctamente.
2. Mida el tiempo de una consulta desde un dispositivo de prueba. Ejecute nslookup captive.apple.com desde un portátil en la red de invitados. Una respuesta lenta o fallida durante un periodo de gran actividad confirma un cuello de botella en los DNS.
3. Capture paquetes en la VLAN de invitados. Una VLAN (LAN virtual) separa el tráfico de invitados de sus otras redes. Filtre la captura en udp port 53 y busque consultas que no tengan la correspondiente respuesta.

A continuación, compruebe cuándo se producen los errores. En WiFi Analytics, compare los volúmenes de conexión e inicio de sesión con las horas en que los invitados notifican los problemas. Los fallos que coinciden con sus horas de mayor actividad apuntan claramente a la congestión.

¿Cómo soluciona el cuello de botella un filtro DNS empresarial?

Un filtro DNS empresarial es un resolutor que usted controla, ubicado cerca de la red de invitados. Sustituye al resolutor público o del ISP distante que el DHCP asigna actualmente. Realiza tres funciones que eliminan el agotamiento del tiempo de espera.

Responde desde la caché. Los nombres de host de comprobación de conectividad se solicitan miles de veces por hora en un recinto con mucho tráfico. Un filtro cercano responde a las consultas repetidas desde su caché, por lo que nunca atraviesan el enlace WAN congestionado.

Descarta el tráfico no deseado de forma anticipada. Las consultas hacia categorías maliciosas o bloqueadas se rechazan en el propio filtro. Esto libera capacidad de la red WAN para las consultas que realmente importan.

Registra cada consulta. Obtendrá un registro de qué dominios han fallado, cuándo y con qué frecuencia. Esto convierte las suposiciones en pruebas objetivas la próxima vez que un responsable informe de un problema.

Dónde ubicarlo

En el caso de una infraestructura distribuida, como una cadena de comercio minorista con cientos de ubicaciones pequeñas, un filtro en la nube con ubicaciones de borde (edge) cercanas suele ser la opción más práctica. Para una única ubicación de gran tamaño, como un estadio o un centro de conferencias, un resolutor alojado en las propias instalaciones mantiene las búsquedas completamente fuera de la WAN. En ambos casos, proporcione dos direcciones de resolutor en el DHCP para que un único fallo no caiga la red.

Dos ajustes que determinan el éxito

En primer lugar, permita los dominios de su portal cautivo en el filtro. Un filtro que bloquee o retrase el portal recreará exactamente el error que intentaba solucionar. En segundo lugar, mantenga el DNS de invitados separado del DNS corporativo. La normativa PCI DSS considera la segmentación de red como el método para mantener la red de invitados fuera del alcance del entorno de datos de tarjetahabientes.

¿Cómo solucionarlo en cada fabricante y sistema operativo?

En sus puntos de acceso y controlador

Purple es independiente del hardware y funciona como una capa superpuesta en la nube sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. La solución sigue los mismos tres pasos en todos ellos:

1. Actualice los servidores DNS en el ámbito DHCP de invitados para que apunten a su filtro DNS empresarial.
2. Complete el jardín vallado (walled garden). Cisco Meraki, HPE Aruba y Ruckus utilizan el término "walled garden". Siga el artículo de configuración de Purple correspondiente a su fabricante, en el que se detallan los dominios exactos que debe permitir.
3. Compruebe la modulación del tráfico de invitados para que los límites por cliente no estrangulen el puerto UDP 53 durante un pico de uso.

No copie la configuración entre distintos fabricantes. Los nombres de los menús y los valores predeterminados varían, por lo que debe consultar la propia documentación del fabricante junto con el artículo de configuración de Purple.

En el dispositivo del invitado

Cuando un solo invitado se ve afectado y los demás se conectan correctamente, su equipo de soporte puede seguir estos pasos:

• Olvidar la red y volver a unirse para activar una nueva comprobación de conectividad.
• Abrir una dirección http:// simple en el navegador para forzar la aparición del portal.
• En Android, configure el DNS privado en Automático. Un proveedor de DNS privado fijo puede bloquear la búsqueda antes de inicie sesión.
• Pausar cualquier aplicación VPN hasta que el invitado haya iniciado sesión.

Casos prácticos

Las siguientes cifras son ilustrativas y no proceden de una implementación real específica. Utilícelas como modelo de lo que debe medir en sus propias instalaciones.

Un hotel de 200 habitaciones a la hora del desayuno

Situación. Las quejas en recepción sobre la falta de conexión a Internet se concentran entre las 7:00 y las 9:00, cuando los huéspedes consultan el correo electrónico antes de realizar el proceso de salida. Los puntos de acceso muestran una señal óptima y tiempo de aire disponible. El DHCP de invitados asigna el resolutor del proveedor de servicios de Internet (ISP), situado a varios saltos de distancia a través de una línea saturada.

Acción realizada. El responsable de TI ejecutó nslookup durante las horas puntas y observó que las búsquedas fallaban por completo. El equipo reconfiguró el DHCP de invitados para apuntar a un filtro DNS en la nube, añadió los dominios del portal al jardín vallado y mantuvo el DNS de invitados separado de la red de gestión del establecimiento.

Resultado. Medido en analíticas de WiFi y en el registro de recepción, el porcentaje de usuarios que completaron el proceso en el portal en horas puntas aumentó del 81% al 97%. Las reclamaciones sobre el WiFi en recepción cayeron de unas 15 por mañana a dos. Para obtener más información sobre las redes de hoteles para huéspedes, consulte nuestras páginas de hostelería.

Un estadio con capacidad para 30.000 personas en el descanso

Situación. Los aficionados informaban de que estaban "conectados sin internet" en todos los descansos, mientras que los primeros diez minutos de cada parte transcurrían sin problemas. Las capturas de paquetes en la red de VLAN para invitados mostraron consultas DNS sin respuesta durante el pico de tráfico.

Qué se hizo. El arquitecto de red desplegó un resolutor local con alternativa en la nube. El equipo eliminó el límite de velocidad por cliente que restringía el puerto UDP 53 y movió el ámbito DHCP al nuevo resolutor.

Resultado. Las consultas DNS sin respuesta durante el descanso cayeron del 12% a menos del 1% en las capturas posteriores. Los inicios de sesión de los aficionados durante el intervalo aumentaron un 40% con respecto al partido anterior.

¿Cómo evitar que los errores de conectado sin internet vuelvan a producirse?

• Nunca confíe únicamente en un resolutor público distante. El DNS público ofrece un buen rendimiento en general, pero un resolutor situado a varios saltos añade un retraso incontrolable durante un pico de tráfico.
• Configure alertas para las consultas DNS sin respuesta. Configure su firewall o switch principal para marcar el aumento de caídas en el puerto UDP 53 en la red de invitados, lo que señala tiempos de espera agotados antes de que los invitados se den cuenta.
• Revise las listas de bloqueo de filtros DNS cada mes. Las categorías demasiado agresivas rompen aplicaciones legítimas y generan nuevas incidencias de soporte.
• Establezca un periodo de retención de registros. Los registros DNS vinculan las direcciones IP con los dominios visitados, por lo que debe tratarlos como datos personales conforme al GDPR.
• Adopte la norma RFC 8910 si su hardware lo admite. Permite que el DHCP indique al dispositivo dónde está el portal cautivo, de modo que el dispositivo depende menos de una búsqueda de comprobación de conectividad.
• Considere Passpoint para visitantes habituales. Passpoint (también llamado Hotspot 2.0) y OpenRoaming permiten que los dispositivos se unan de forma segura sin un portal cautivo, lo que elimina este modo de fallo por completo para ellos.

Purple gestiona el WiFi para invitados en más de 80.000 recintos activos en más de 90 países, con 500 millones de usuarios e inicios de sesión al año. Desde salas de espera en el sector de la sanidad hasta trenes, el patrón se mantiene: solucione el DNS antes de comprar ancho de banda.

Preguntas frecuentes

¿Necesitamos nuevos puntos de acceso para solucionar los errores de conectado sin internet?

No, en la mayoría de los casos no es necesario. Cuando el error coincide con las horas puntas, la causa suele ser la resolución DNS, no el hardware del punto de acceso. La solución consiste en un cambio de configuración: apunte el DHCP de invitados a un filtro DNS empresarial cercano, complete el walled garden y revise las reglas de modelado de tráfico. Reemplace el hardware solo después de que las capturas de paquetes muestren que los propios puntos de acceso descartan tráfico con cargas normales, y tras haber descartado problemas de DHCP y DNS.

¿Funciona Purple con el hardware que ya poseemos?

Sí, Purple funciona en los puntos de acceso que ya tiene. Purple es independiente del hardware y se despliega como una capa superpuesta en la nube sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. No es necesario reemplazar la infraestructura existente. Purple publica un artículo de configuración para cada proveedor, en el que se enumeran los dominios del entorno aislado (walled garden) que su controlador necesita para que el portal cautivo se cargue antes de que los invitados inicien sesión.

¿Un filtro DNS empresarial ralentizará nuestra red WiFi para invitados?

No, un filtro DNS bien ubicado suele acelerar las búsquedas. Se sitúa más cerca de la red de invitados que un ISP o un resolutor público y responde a las búsquedas repetidas desde su memoria caché. El riesgo reside en la ubicación y la configuración, no en el filtrado en sí. Proporcione dos direcciones de resolutor para tener redundancia y permita los dominios de su portal cautivo para que el filtro nunca retrase la página de inicio de sesión.

¿Por qué no proporcionar a los invitados un resolutor público como 8.8.8.8?

Puede hacerlo, pero no soluciona los tiempos de espera por congestión. Un resolutor público sigue estando al otro lado de su enlace WAN, por lo que cada búsqueda compite con el aumento repentino de tráfico que causa el fallo. Además, no le ofrece filtrado ni registros de consultas para la resolución de problemas. Un filtro empresarial cercano responde desde la caché, rechaza categorías no deseadas y registra cada búsqueda fallida, algo que el DNS público no puede hacer por usted.

¿Cómo gestionamos los registros de consultas DNS en virtud del GDPR?

Trate los registros DNS como datos personales, ya que vinculan las direcciones IP con los dominios que ha visitado un dispositivo. Establezca un período de retención definido, restrinja el acceso a su equipo de redes y seguridad, y registre la finalidad en su aviso de privacidad. Purple cuenta con la certificación ISO 27001 y cumple con el GDPR, y el proveedor de su filtro DNS debería mostrar una certificación equivalente antes de enrutar el tráfico de invitados a través de él.

¿Cuánto esfuerzo requiere el despliegue?

El cambio en sí es pequeño; las pruebas requieren la mayor parte del esfuerzo. Debe actualizar los servidores DNS en el ámbito DHCP de invitados, añadir los dominios del portal a la lista de permitidos del filtro y comprobar el entorno aislado (walled garden). Planifique las pruebas durante una hora punta real, como el periodo de desayunos o un descanso de partido, ya que una tarde tranquila no reproducirá la congestión que causó el error.

¿Eliminarán el error Passpoint o OpenRoaming?

Sí, para los dispositivos que los utilizan. Passpoint y OpenRoaming permiten que los dispositivos se conecten de forma segura sin un portal cautivo, por lo que no hay ningún portal que pueda fallar. Los visitantes que acceden por primera vez y los dispositivos que no tienen un perfil de Passpoint siguen utilizando el portal cautivo, por lo que sigue necesitando un DNS rápido y un entorno aislado (walled garden) completo. Ejecute ambos juntos: Passpoint para los visitantes habituales y un portal optimizado para todos los demás.