Saltar al contenido principal
Español (México)

Solución del error "Conectado pero sin internet" en la red WiFi para invitados

Usted podrá diagnosticar por qué los invitados ven el mensaje "conectado, sin internet" en la red WiFi para invitados y solucionar la causa mediante un cambio de configuración, sin necesidad de hardware nuevo. La guía muestra cómo separar los tiempos de espera agotados de DNS de las fallas de DHCP, jardín amurallado (walled garden) y límites de velocidad, para luego implementar un filtro DNS empresarial cercano en los puntos de acceso con los que ya cuenta.

Por Tom HackettPublicado Actualizado
📖 10 min de lectura2,815 palabras2 ejemplos resueltos3 preguntas de práctica10 definiciones clave

Video overview

Escucha esta guía

Ver transcripción del podcast
Cómo resolver el error "Conectado pero sin internet" en redes WiFi para 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 corporativos: el error de "conectado, sin internet" en redes WiFi para invitados. Si usted administra la infraestructura WiFi de un hotel, una cadena minorista, un estadio o un centro de convenciones, se habrá encontrado con esto. El dispositivo del 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 portal cautivo nunca abre. El invitado llama a la recepción. Su equipo de soporte ejecuta una prueba de ping, todo parece estar bien en papel y, aun así, el problema vuelve a ocurrir. El punto es este: en la gran mayoría de los casos con los que me encuentro en las implementaciones corporativas, no se trata de una falla de hardware, ni de una mala configuración del firewall, ni de un problema de ancho de banda en el sentido tradicional. Es un problema de tiempos de espera de DNS y casi siempre se desencadena por la congestión de la red. Hoy quiero explicarle exactamente por qué sucede esto, cómo diagnosticarlo de forma confiable y cómo la implementación de un filtro DNS corporativo resuelve el cuello de botella de manera 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 cargar una sola página web, antes de que su portal cautivo pueda redirigirlo y antes de que se realice cualquier autenticación) es resolver un nombre de dominio a una dirección IP mediante DNS. El sistema de nombres de dominio (DNS) es la libreta de contactos 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 Windows) tienen un mecanismo integrado denominado prueba de detección de portal cautivo. En iOS, por ejemplo, el dispositivo envía una solicitud HTTP a un extremo conocido de Apple, como captive.apple.com. En Android, consulta connectivitycheck.gstatic.com. En Windows, sondea msftconnecttest.com. Estas pruebas 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 pruebas dependen del DNS. El dispositivo debe resolver primero el nombre de dominio del extremo de la prueba antes de poder enviar la solicitud HTTP. Y esa consulta DNS tiene un tiempo de espera (por lo general de entre uno y cinco segundos, según el sistema operativo). Si el resolvedor DNS de su red no responde dentro de ese lapso, 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 de "conectado, sin internet". No es una falla de conectividad: es una falla en la respuesta de DNS. ¿Por qué falla el DNS en una red congestionada? Esta es la parte que toma desprevenidos a muchos equipos. Las consultas de 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 negociación, no hay confirmación de recepció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 venza el tiempo de espera y luego reintenta o se rinde. En una red WiFi para invitados con cientos o miles de dispositivos concurrentes - piense en un estadio durante un partido, un hotel a máxima capacidad, un centro de conferencias durante una conferencia magistral - el enlace ascendente y el resolvedor DNS se pueden saturar muy rápidamente. El problema se complica aún más por el hecho de que las redes de invitados suelen compartir un solo resolvedor DNS ascendente, a menudo el resolvedor predeterminado del ISP o un resolvedor público como 8.8.8.8. Cuando cada dispositivo de la red intenta detectar simultáneamente el portal cautivo, ejecuta actualizaciones de aplicaciones en segundo plano y realiza 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 aumentan desde el rango normal inferior a los 50 milisegundos hasta cientos o incluso miles de milisegundos. Comienzan a producirse tiempos de espera agotados. Los errores de "conectado, sin internet" empiezan a aparecer de forma masiva. También existe un mecanismo secundario 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 - algo común en recintos de alta densidad - las entradas en caché vencen y se deben volver a resolver con frecuencia. Esto aumenta 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 destinarle más ancho de banda: actualizar el enlace ascendente, agregar 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 resuelve un filtro DNS empresarial. Un filtro DNS empresarial - como la capacidad de filtrado DNS dentro de la plataforma de WiFi para invitados de Purple - funciona como un resolvedor DNS local de alto rendimiento que se ubica entre sus dispositivos de invitados e 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 verificaciones de detección del portal cautivo de forma nativa y aplica un filtrado basado en políticas para bloquear dominios maliciosos o no conformes antes de que lleguen al resolvedor ascendente. El resultado es una reducción dramática en la latencia de las consultas DNS - por lo general, de tiempos de espera de dos a tres segundos a respuestas inferiores a 200 milisegundos - lo que significa que las verificaciones de detección del portal cautivo tienen éxito al primer intento, el error de "conectado, sin internet" desaparece y el tiempo de incorporación de los invitados se reduce 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 GDPR al permitirle registrar y auditar consultas DNS, lo cual es relevante si opera bajo una licencia del sector público o de la industria de la hospitalidad. También respalda los requisitos de segmentación de red PCI DSS al garantizar que el tráfico DNS de los invitados esté aislado de su infraestructura de resolución corporativa. [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES - aproximadamente 2 minutos] Permítame darle una guía práctica para la implementación. Cuando implementa un filtro DNS empresarial en una red WiFi para invitados, hay tres decisiones de configuración que determinarán si tiene éxito o no. En primer lugar, la ubicación del resolvedor. 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 para invitados. Cada salto entre el dispositivo del invitado y el resolvedor agrega latencia. Si su filtro DNS se encuentra en un centro de datos remoto y su red de invitados está en un hotel en Mánchester, está agregando un tiempo de ida y vuelta que anula el propósito. Utilice un equipo local o un filtro DNS basado en la nube con un punto de presencia regional. En segundo lugar, el paso a través de DNS del portal cautivo. Esta es la falla de configuración más común que veo. Cuando implementa un filtro DNS, debe asegurarse de que el propio dominio del portal cautivo (la URL a la que se redirige a los invitados para la autenticación) esté en la lista blanca del filtro. Si el filtro bloquea o retrasa la resolución del dominio de su portal cautivo, recreará exactamente el problema que intentaba resolver. Siempre pruebe la resolución del portal cautivo de forma explícita después de implementar cualquier política de filtrado DNS. En tercer lugar, el ajuste del TTL. Configure su resolvedor DNS local para ofrecer TTL cortos para los dominios de prueba de detección del portal cautivo (Apple, Google, Microsoft) para que los dispositivos vuelvan a realizar consultas con frecuencia y siempre obtengan una respuesta local rápida, en lugar de esperar a que venza una entrada en caché y luego recurrir a un resolvedor de origen saturado. Un TTL de 30 a 60 segundos para estos dominios específicos es un punto de partida razonable. El error que debe evitarse es el filtrado excesivo. Algunos equipos implementan listas de bloqueo DNS agresivas que bloquean de manera involuntaria dominios utilizados por aplicaciones legítimas de los invitados: servicios de streaming, puntos de enlace VPN corporativos, 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, monitoree los registros de consultas DNS para detectar dominios bloqueados y realice ajustes durante un período de dos semanas antes de bloquear la configuración. [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 para invitados?" Puede hacerlo, pero bajo carga se agotará el tiempo de espera. Un resolvedor local o regional siempre superará el rendimiento de un resolvedor público en una red saturada. "¿Esto afecta 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'?" Ejecute una captura de paquetes en la VLAN de invitados durante la hora pico. Filtre para el tráfico del puerto UDP 53. Si ve consultas de DNS sin la respuesta correspondiente en dos segundos, el tiempo de espera de DNS es el culpable. "¿Un filtro DNS empresarial ayuda con el cumplimiento?" Sí - el registro de consultas DNS proporciona una pista 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 predominantemente un problema de tiempos del DNS causado por la congestión de la red que sobrecarga una ruta de resolución no optimizada. La solución no es más ancho de banda - es 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 filtrado basado en políticas para reducir la carga de consultas hacia arriba. Las tres cosas que debe hacer esta semana: ejecutar una captura de paquetes DNS durante la hora pico para confirmar el diagnóstico; revisar la ubicación actual de su resolvedor 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 el próximo episodio. [FIN DEL EPISODIO]

Parte de nuestra serie principal: Guía de WiFi para invitados →

El error de conectado pero sin internet en el WiFi para invitados ocurre cuando las comprobaciones de conectividad fallan antes de que cargue el Captive Portal. En recintos con mucho tráfico, las consultas DNS del puerto UDP 53 (RFC 1035) agotan el tiempo de espera durante la congestión. Resolverlo requiere apuntar los alcances DHCP para invitados a un filtro DNS con almacenamiento en caché, completar los dominios del Walled Garden en todos los controladores como Cisco Meraki y revisar las reglas de conformación de tráfico (traffic shaping).

¿Cómo se ve "conectado, sin internet" en el WiFi para invitados?

El invitado ve barras de señal completa y una red unida, pero nada carga. La página de inicio de sesión nunca aparece, por lo que no pueden aceptar los términos ni iniciar sesión. Luego caminan hacia la recepción, el punto de ayuda o el mostrador de servicio.

Cada sistema operativo redacta la advertencia de manera 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 y iPad muestran "Sin conexión a Internet" debajo del nombre de la red.

Las tres provienen del mismo mecanismo. Después de unirse, 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 Captive Portal. Si no recibe ninguna respuesta, el dispositivo informa "sin internet".

Sistema operativo Hostname de comprobación de conectividad Lo que ve el invitado al fallar
iOS, iPadOS, macOS captive.apple.com "Sin conexión a Internet"
Android connectivitycheck.gstatic.com "Conectado sin internet"
Windows 10 y 11 www.msftconnecttest.com "Sin internet"

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

¿Qué causa habitualmente los errores de conectado sin internet en el WiFi para invitados?

Tiempos de espera de DNS agotados en una red congestión

DNS (Sistema de Nombres de Dominio) convierte un hostname en una dirección IP. La mayoría de las consultas DNS viajan a través del puerto UDP 53, como se define en 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 llega en ráfagas. Piense en el medio tiempo en un estadio, el check-out del desayuno en un hotel o un tren que llega a una estación. Cientos de dispositivos se unen en cuestión de segundos y cada uno envía una búsqueda a la vez. Si el solucionador se encuentra a varios saltos de distancia a través de un enlace WAN ocupado, las consultas se retrasan o se descartan. El dispositivo se rinde, el portal nunca se abre y el invitado ve "sin internet".

Los otros sospechosos habituales

El DNS es la causa más común en recintos con mucho tráfico, pero no la única. Descarte también lo siguiente:

  • Entradas del Walled Garden faltantes. El Walled Garden 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 pool de DHCP. Si el pool de direcciones se agota, los dispositivos se asignan a sí mismos una dirección 169.254.x.x y no pueden alcanzar nada.
  • Límites de velocidad o restricción de QoS en el puerto UDP 53. Un límite por cliente o por SSID configurado de forma demasiado estricta puede dejar sin recursos a 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 resolvedores externos. Un walled garden que bloquee esos resolvedores detiene la consulta antes del inicio de sesión.
  • Una interrupción en el enlace ascendente. Si el enlace WAN se cae, fallan todos los dispositivos y también fallan 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 delimitar la causa antes de cambiar cualquier configuración.

Lo que observa Causa más probable Primera acción
Los errores se disparan en horas pico predecibles, funciona bien en horas de poco tráfico Tiempos de espera agotados de DNS por congestión Apunte el DHCP de visitantes a un filtro DNS con caché cercano
Todos los dispositivos fallan, todo el día Interrupción de la WAN ascendente o servidor DNS incorrecto en DHCP Pruebe el enlace WAN y la configuración DNS del DHCP
El dispositivo muestra una dirección 169.254.x.x Pool de DHCP agotado Amplíe el pool o reduzca el tiempo de concesión (lease)
El portal comienza a cargar pero se detiene o muestra una página en blanco Faltan dominios del portal en el walled garden Agregue los dominios desde su artículo de configuración de Purple
Solo fallan algunos dispositivos Android o laptops DNS privado, DoT o DoH configurado en el dispositivo Solicite al visitante que cambie el DNS privado a Automático
Falla solo al superar un número determinado de dispositivos por AP Límites de velocidad o QoS en el puerto UDP 53 Revise las reglas de moldeo de tráfico (traffic-shaping) del SSID de visitantes

Tres comprobaciones que su equipo de soporte puede ejecutar

  1. Verifique la dirección IP del dispositivo. Una dirección 169.254.x.x apunta a un problema de DHCP, no de DNS. Una dirección normal en el rango de visitantes significa que el dispositivo se unió correctamente.
  2. Mida el tiempo de una consulta desde un dispositivo de prueba. Ejecute nslookup captive.apple.com desde una laptop en la red de visitantes. Una respuesta lenta o fallida durante un periodo de alto tráfico confirma un cuello de botella en DNS.
  3. Capture paquetes en la VLAN de visitantes. Una VLAN (LAN virtual) separa el tráfico de visitantes de sus otras redes. Filtre la captura en udp port 53 y busque consultas que no tengan respuesta coincidente.

Luego, verifique cuándo ocurren los errores. En WiFi Analytics, compare los volúmenes de conexión e inicio de sesión con las horas en que los visitantes reportan problemas. Los fallos que coinciden con sus horas de mayor actividad apuntan claramente a una congestión.

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

Un filtro DNS empresarial es un resolvedor bajo su control, ubicado cerca de la red de visitantes. Reemplaza al resolvedor público o del ISP distante que el DHCP entrega actualmente. Realiza tres funciones que eliminan el agotamiento del tiempo de espera.

Responde desde la caché. Los nombres de host para verificación de conectividad se solicitan miles de veces por hora en un entorno concurrido. 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 filtro. Eso libera capacidad de la WAN para las consultas que realmente importan.

Registra cada consulta. Obtienes un registro de qué dominios fallaron, cuándo y con qué frecuencia. Eso convierte las suposiciones en evidencia la próxima vez que un gerente reporte un problema.

Dónde ubicarlo

Para una propiedad distribuida, como una cadena de retail con cientos de sitios pequeños, un filtro en la nube con ubicaciones edge cercanas suele ser la opción más práctica. Para un solo sitio grande, como un estadio o centro de conferencias, un resolvedor alojado en el sitio mantiene las búsquedas completamente fuera de la WAN. En ambos casos, asigne dos direcciones de resolvedor en DHCP para que una sola falla no caiga la red.

Dos configuraciones que definen el éxito

Primero, permite los dominios de tu Captive Portal en el filtro. Un filtro que bloquea o retrasa el portal recrea exactamente el error que intentabas solucionar. Segundo, mantén el DNS de invitados separado del DNS corporativo. PCI-DSS considera la segmentación de red como la forma de mantener una red de invitados fuera del alcance de tu entorno de datos de cuentahabientes.

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.

¿Cómo lo solucionas en cada fabricante y sistema operativo?

En tus puntos de acceso y controlador

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

  1. Actualiza los servidores DNS en el alcance DHCP de invitados a tu filtro DNS empresarial.
  2. Completa el walled garden. Cisco Meraki, HPE Aruba y Ruckus utilizan el término "walled garden". Sigue el artículo de configuración de Purple para tu fabricante, que enumera los dominios exactos que debes permitir.
  3. Verifica la catalogación de tráfico (traffic shaping) de invitados para que los límites por cliente no estrangulen el puerto UDP 53 durante un pico de uso.

No copies configuraciones entre fabricantes. Los nombres de los meñús y los valores predeterminados difieren, por lo que debes consultar la documentación del propio fabricante junto con el artículo de configuración de Purple.

En el dispositivo del invitado

Cuando un solo invitado se ve afectado y todos los demás están bien, tu equipo de soporte puede intentar estos pasos:

  • Olvidar la red y volver a conectarse 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, configura el DNS privado en Automático. Un proveedor de DNS privado fijo puede bloquear la búsqueda antes de iniciar sesión.
  • Pausar cualquier aplicación VPN hasta que el invitado haya iniciado sesión.

Escenarios de trabajo

Las siguientes cifras son ilustrativas y no provienen de una implementación específica. Úsalas como modelo de lo que debes medir en tu propio recinto.

Un hotel de 200 habitaciones a la hora del desayuno

Situación. Las quejas en la recepción sobre "sin internet" se concentran entre las 7:00 a. m. y las 9:00 a. m., cuando los huéspedes revisan su correo electrónico antes de realizar el checkout. Los puntos de acceso muestran una señal saludable y tiempo de aire disponible. El DHCP de invitados entrega el resolvedor del ISP, ubicado a varios saltos a través de una línea ocupada.

Lo que se hizo. El gerente de TI ejecutó nslookup durante las horas pico y vio que las búsquedas fallaban por completo. El equipo apuntó el DHCP de invitados a un filtro DNS en la nube, agregó los dominios del portal al walled garden y mantuvo el DNS de invitados separado de la red de administración de la propiedad.

Resultado. Medido en WiFi Analytics y en el registro de recepción, los inicios de sesión completados en el portal durante las horas pico aumentaron del 81% al 97%. Las quejas de WiFi en la recepción cayeron de unas 15 por la mañana a solo dos. Para obtener más información sobre redes para huéspedes en hoteles, visite nuestras páginas de hotelería.

Un estadio para 30,000 personas a mitad del partido

Situación. Los aficionados reportaban "conectado sin internet" en cada medio tiempo, mientras que los primeros diez minutos de cada tiempo funcionaban sin problemas. Las capturas de paquetes en la VLAN de invitados mostraron consultas DNS sin respuesta durante las horas pico de tráfico.

Lo que se hizo. El arquitecto de red implementó un solucionador local con respaldo en la nube. El equipo eliminó el límite de velocidad por cliente que restringía el puerto UDP 53 y movió el alcance DHCP al nuevo solucionador.

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

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

  • Nunca confíe únicamente en un solucionador público distante. El DNS público funciona bien en general, pero un solucionador a varios saltos de distancia añade un retraso que no puede controlar durante un pico de tráfico.
  • Configure alertas para consultas DNS sin respuesta. Configure su firewall o switch principal para marcar el aumento de caídas del puerto UDP 53 en la red de invitados, lo que indica tiempos de espera agotados antes de que los usuarios lo noten.
  • Revise las listas de bloqueo de filtros DNS cada mes. Las categorías demasiado agresivas rompen aplicaciones legítimas y generan nuevos tickets 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 el estándar RFC 8910 si su hardware lo admite. Permite que el DHCP indique al dispositivo dónde se encuentra el Captive Portal, de modo que el dispositivo dependa menos de una búsqueda de comprobación de conectividad.
  • Considere Passpoint para visitantes recurrentes. Passpoint (también llamado Hotspot 2.0) y OpenRoaming permiten que los dispositivos se conecten de forma segura sin un Captive Portal, lo que elimina este tipo de falla por completo para ellos.

Purple opera Guest WiFi en más de 80,000 ubicaciones activas 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 atención médica 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 pico, la causa suele ser la resolución DNS y no el hardware del punto de acceso. La solución es 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 moldeo de tráfico. Reemplace el hardware solo después de que las capturas de paquetes muestren que los propios puntos de acceso están descartando tráfico con cargas normales, y una vez que haya descartado problemas de DHCP y DNS.

¿Purple funciona con el hardware que ya tenemos?

Sí, Purple funciona en los puntos de acceso que ya tiene. Purple es independiente del hardware y se despliega como una superposición en la nube en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. No es necesario reemplazar su infraestructura. Purple publica un artículo de configuración para cada proveedor, donde se enumeran los dominios del jardín vallado que necesita su controlador 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 ponga lentitud a la página de inicio de sesión.

¿Por qué no simplemente asignar 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 la sobrecarga de tráfico que causa la falla. Tampoco le ofrece filtrado ni registros de consultas para la solución de problemas. Un filtro empresarial cercano responde desde la memoria 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 bajo el GDPR?

Trate los registros DNS como datos personales, ya que vinculan direcciones IP con los dominios que visitó un dispositivo. Establezca un periodo de retención definido, restrinja el acceso a su equipo de red y seguridad, y registre el propósito en su aviso de privacidad. Purple cuenta con la certificación ISO 27001 y cumple con el GDPR, y su proveedor de filtro DNS debe mostrar una certificación equivalente antes de canalizar el tráfico de invitados a través de él.

¿Cuánto esfuerzo requiere el despliegue?

El cambio en sí es pequeño; la mayor parte del esfuerzo se dedica a las pruebas. Actualice los servidores DNS en el alcance DHCP de invitados, agregue los dominios del portal a la lista de permitidos del filtro y verifique el jardín vallado. Planifique las pruebas durante un pico real, como las horas de mayor afluencia en el desayuno o el medio tiempo de un evento, ya que una tarde tranquila no reproducirá la congestión que causó el error.

¿Passpoint o OpenRoaming eliminarán el error?

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 un portal que pueda fallar. Los visitantes primerizos y los dispositivos sin un perfil de Passpoint siguen utilizando el portal cautivo, por lo que aún necesita un DNS rápido y un jardín vallado completo. Ejecute ambos juntos: Passpoint para visitantes recurrentes y un portal optimizado para todos los demás.

Definiciones clave

Portal cautivo

La página de inicio de sesión que ofrece una red de invitados antes de conceder acceso a internet. RFC 8910 define una opción de DHCP y de anuncio de router IPv6 que indica al dispositivo la dirección API del portal, evitando que tenga que inferir el portal a partir de una solicitud web fallida.

Sus invitados aceptan los términos o inician sesión aquí. Si el portal nunca se abre, no pueden conectarse a internet y el problema llega a la recepción o al punto de ayuda.

Verificación de conectividad

Una solicitud HTTP que envía cada sistema operativo a un nombre de host conocido tras unirse a una red: captive.apple.com en iOS, iPadOS y macOS; connectivitycheck.gstatic.com en Android; y www.msftconnecttest.com en Windows 10 y 11. La página esperada significa que hay conexión, una página de inicio de sesión activa el portal y la falta de respuesta significa "sin internet".

Esta comprobación genera cada variante de la advertencia que ve su equipo de soporte. Depende primero de una búsqueda DNS, que es donde comienzan las fallas en entornos de alta densidad.

DNS (Sistema de nombres de dominio)

El protocolo que resuelve nombres de host en direcciones IP, especificado en RFC 1035. La mayoría de las consultas viajan a través del puerto UDP 53, el cual no tiene retransmisión integrada, por lo que una consulta descartada debe esperar el temporizador de reintento del propio dispositivo.

Cuando cientos de dispositivos se conectan al mismo tiempo y el resolvedor se encuentra a través de un enlace WAN saturado, las búsquedas agotan el tiempo de espera y el portal nunca se abre.

Filtro DNS empresarial

Un resolvedor bajo su control, ubicado cerca de la red de invitados, que responde las búsquedas repetidas desde la memoria caché, rechaza consultas para categorías maliciosas o bloqueadas y registra cada consulta por dominio, hora y frecuencia.

Reemplaza al resolvedor público o del ISP distante en su alcance DHCP para invitados. Impleméntelo en la nube para propiedades distribuidas o de forma local para un solo recinto de gran tamaño.

Jardín amurallado (walled garden)

La lista de dominios a los que un dispositivo puede acceder antes de la autenticación en una red de portal cautivo. Cisco Meraki, HPE Aruba y Ruckus utilizan el término en la configuración de sus controladores.

Si faltan los dominios o recursos de su portal, la página se detiene o se muestra en blanco. El artículo de configuración por proveedor de Purple enumera los dominios exactos que se deben permitir.

Agotamiento del fondo de DHCP

El estado en el que un servidor de Protocolo de configuración dinámica de host (RFC 2131) no tiene direcciones libres disponibles en su alcance, por lo que los dispositivos nuevos se asignan a sí mismos una dirección de enlace local 169.254.x.x y no pueden acceder a nada.

Una dirección 169.254.x.x en un dispositivo de invitado indica un problema de DHCP, no de DNS. Amplíe el fondo o reduzca los tiempos de concesión.

DNS sobre HTTPS (DoH) y DNS sobre TLS (DoT)

Transportes DNS cifrados: DoH lleva las consultas dentro de HTTPS como se especifica en RFC 8484, y DoT las lleva sobre una sesión TLS como se especifica en RFC 7858. Ambos envían búsquedas a resolutores fuera de su red.

Un jardín vallado que bloquee esos resolutores externos detiene la búsqueda antes del inicio de sesión. En Android, pida al invitado que configure el DNS privado en Automático.

VLAN (VLAN)

Un segmento de red lógico definido por el etiquetado IEEE 802.1Q, el cual separa el tráfico de invitados de otras redes en una infraestructura de conmutación compartida.

Capture paquetes en la VLAN de invitados filtrados en el puerto UDP 53 para encontrar consultas sin respuesta. La segmentación también mantiene el tráfico de invitados fuera del alcance del entorno de datos de titulares de tarjetas PCI DSS.

Passpoint (Hotspot 2.0) y OpenRoaming

Passpoint, también llamado Hotspot 2.0, se basa en el descubrimiento de red IEEE 802.11u y en la autenticación basada en puertos IEEE 802.1X para que un dispositivo con un perfil se una de forma segura sin un portal cautivo. OpenRoaming extiende esto a través de las redes participantes.

Los visitantes recurrentes con un perfil nunca llegan al portal, por lo que este modo de falla desaparece para ellos. Los visitantes de primera vez aún necesitan un DNS rápido y un jardín vallado completo.

Datos personales del GDPR (registros de DNS)

Bajo el UK GDPR y el GDPR de la UE, la información que vincula un identificador como una dirección IP con la actividad se considera datos personales, lo cual requiere un propósito definido, una retención limitada y un acceso restringido.

Los registros de filtrado de DNS vinculan las direcciones IP con los dominios visitados. Establezca un periodo de retención, restrinja el acceso a su equipo de red y seguridad, y registre la finalidad en su aviso de privacidad.

Ejemplos resueltos

Un hotel de 200 habitaciones recibe quejas en la recepción sobre la falta de internet entre las 7:00 a. m. y las 9:00 a. m. Los puntos de acceso muestran una señal en buen estado y tiempo de aire libre, pero el DHCP para invitados asigna el resolvedor del ISP a través de varios saltos en una línea saturada. ¿Qué debe hacer el administrador de TI? (Las cifras son ilustrativas).

El administrador de TI ejecutó nslookup desde una laptop en la red de invitados durante la hora pico y observó que las búsquedas fallaban por completo, lo que confirmó un cuello de botella en el DNS en lugar de una falla de radio. El equipo apuntó el DHCP de invitados a un filtro DNS en la nube para que las búsquedas repetidas de verificación de conectividad se respondieran desde la memoria caché. Agregaron los dominios del portal al jardín amurallado (walled garden) para que la página de inicio de sesión se cargara antes de ingresar. Mantuvieron el DNS de invitados separado de la red de administración de la propiedad para preservar la segmentación. Según las mediciones en WiFi Analytics y el registro de la recepción, los inicios de sesión completados en el portal durante las horas pico aumentaron del 81 % al 97 %, y las quejas en recepción disminuyeron de unas 15 por la mañana a solo dos.

Los aficionados en un estadio con capacidad para 30,000 personas reportan el estado "conectado sin internet" durante cada medio tiempo, mientras que los primeros diez minutos de cada tiempo funcionan sin problemas. Las capturas de paquetes en la red VLAN para invitados muestran consultas DNS sin respuesta durante la saturación de tráfico. ¿Cómo debe responder el arquitecto de red? (Las cifras son ilustrativas).

El patrón indicaba congestión, por lo que el arquitecto implementó un resolvedor local con respaldo en la nube. Mantener las búsquedas en el sitio las eliminó por completo de la WAN durante la saturación. El equipo también detectó y eliminó un límite de velocidad por cliente que restringía el puerto UDP 53, lo que dejaba sin recursos al DNS cuando miles de dispositivos se conectaban al mismo tiempo. Migraron el alcance de DHCP para invitados al nuevo resolvedor. Las capturas de seguimiento mostraron que las consultas DNS sin respuesta durante el medio tiempo cayeron del 12 % a menos del 1 %. Los inicios de sesión de los aficionados durante el intervalo aumentaron un 40 % en comparación con el partido anterior.

Preguntas de práctica

Q1. El director de TI de un estadio nota que, durante el medio tiempo, miles de usuarios se conectan al WiFi pero no logran acceder al portal cautivo. El switch central muestra caídas intensas de paquetes UDP. ¿Deberían aumentar el ancho de banda de la WAN de 2 Gbps a 5 Gbps?

Sugerencia: Considere qué protocolo se está descartando y si está relacionado con el ancho de banda de la carga útil o con los límites de estado de conexión.

Ver respuesta modelo

No. Aumentar el ancho de banda WAN no resolverá el problema. Las caídas de paquetes UDP indican que el firewall o el resolutor no pueden manejar el volumen masivo de consultas DNS concurrentes (agotamiento de la tabla de estado o límites de CPU). El enfoque correcto es implementar un filtro DNS local de alto rendimiento en el extremo para almacenar en caché y responder a estas consultas localmente, eliminando por completo el cuello de botella de la WAN.

Q2. Acaba de implementar un filtro DNS empresarial en la red de invitados de un hotel. Los invitados ahora pueden resolver sitios web públicos rápidamente, pero cuando se conectan por primera vez, no se les redirige a la página de inicio de sesión del hotel. ¿Cuál es el error de configuración más probable?

Sugerencia: Piense en el nombre de dominio de la propia página de inicio de sesión.

Ver respuesta modelo

El error más probable es que el dominio propio del portal cautivo no se haya incluido explícitamente en la lista blanca (paso directo o passthrough) en el filtro DNS. El filtro está bloqueando o retrasando la resolución de la URL del portal, lo que impide que la redirección se complete.

Q3. Una organización del sector público requiere que todo el tráfico de WiFi para invitados se registre durante 90 días para cumplir con las políticas de seguridad. ¿Cómo ayuda la implementación de un filtro DNS empresarial con este requisito?

Sugerencia: Considere qué datos procesa un filtro DNS en comparación con un firewall estándar.

Ver respuesta modelo

Un filtro DNS empresarial registra de forma nativa todas las consultas DNS realizadas por los dispositivos cliente. Esto proporciona una pista de auditoría clara y buscable de qué dominios se solicitaron y cuándo, satisfaciendo el requisito de registro de 90 días sin necesidad de realizar una inspección profunda de paquetes en todo el tráfico cifrado de carga útil HTTPS.

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 ocurre en horas pico, la causa suele ser la resolución DNS, no el hardware del punto de acceso. La solución es un cambio de configuración: apunte el DHCP de invitados a un filtro DNS empresarial cercano, complete el jardín vallado y revise las reglas de moldeo 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 se ejecuta en los puntos de acceso que ya tiene. Purple es independiente del hardware y se implementa como una superposición en la nube en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. No requiere reemplazo de infraestructura. Purple publica un artículo de configuración para cada proveedor, enumerando los dominios del jardín vallado que requiere su controlador 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 agilizar las búsquedas. Se sitúa más cerca de la red de invitados que un ISP o un resolvedor público y responde a las búsquedas repetidas desde su caché. El riesgo reside en la ubicación y la configuración, no en el filtrado en sí. Proporcione dos direcciones de resolución para ofrecer redundancia y permita los dominios de su portal cautivo para que el filtro nunca demore la página de inicio de sesión.

¿Por qué no simplemente asignar a los invitados un resolvedor público como 8.8.8.8?

Puede hacerlo, pero esto no soluciona los tiempos de espera agotados por congestión. Un resolvedor público sigue estando al otro lado de su enlace WAN, por lo que cada búsqueda compite con el aumento de tráfico que causa la falla. Además, no le ofrece filtrado ni registros de consultas para la solució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 manejamos los registros de consultas DNS bajo el GDPR?

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

¿Cuánto esfuerzo requiere la implementación?

El cambio en sí es pequeño; la mayor parte del esfuerzo se va en las pruebas. Debe actualizar los servidores DNS en el alcance DHCP de invitados, agregar los dominios del portal a la lista de permitidos del filtro y verificar el walled garden. Planifique hacer las pruebas durante un pico real de tráfico, como el desayuno o el medio tiempo de un partido, ya que una tarde tranquila no reproducirá la congestión que causó el error.

¿Passpoint o OpenRoaming eliminarán el error?

Sí, para los dispositivos que los utilizan. Passpoint y OpenRoaming permiten que los dispositivos se conecten de forma segura sin un Captive Portal, por lo que no hay ningún portal que pueda fallar. Los visitantes por primera vez y los dispositivos sin un perfil Passpoint siguen utilizando el Captive Portal, por lo que aún necesita un DNS rápido y un walled garden completo. Ejecute ambos a la vez: Passpoint para visitantes habituales y un portal optimizado para todos los demás.

Fuentes

  1. RFC 1035: Domain names, implementation and specification
  2. RFC 8484: DNS queries over HTTPS (DoH)
  3. RFC 7858: DNS over Transport Layer Security (DoT)
  4. RFC 8910: Captive-portal identification in DHCP and Router Advertisements
  5. RFC 2131: Dynamic Host Configuration Protocol
  6. PCI Security Standards Council: PCI DSS
  7. Information Commissioner's Office: UK GDPR guidance

Continúe leyendo esta serie

Uso de captura de paquetes (PCAP) para diagnosticar un rendimiento lento de WiFi

Esta guía de referencia técnica proporciona a los gerentes de TI, arquitectos de red y directores de operaciones de instalaciones una metodología estructurada a nivel de paquetes para diagnosticar y resolver el rendimiento lento de WiFi empresarial mediante el análisis de captura de paquetes (PCAP). Al disecar tramas raw 802.11 -incluyendo tasas de retransmisión, utilización de tiempo de aire y metadatos de la capa física-, los equipos pueden aislar con precisión los cuellos de botella de la capa de RF de los problemas de cableado o de aplicaciones. Aplicable en instalaciones de alta densidad como hoteles, cadenas de retail, estadios y centros de conferencias, esta guía ofrece flujos de trabajo de diagnóstico prácticos, casos de estudio del mundo real y pasos de remediación de configuración para recuperar la capacidad de la red y proteger la experiencia del huésped.

Leer la guía →

Por qué la WiFi de su estadio se ralentiza (y cómo solucionarlo)

Esta guía técnica autorizada examina la causa raíz de la congestión de la WiFi en los estadios - el tráfico de fondo simultáneo de 50,000 dispositivos que cargan anuncios programáticos y telemetría - y proporciona un plano arquitectónico detallado para implementar el filtrado DNS perimetral como estrategia de mitigación principal. Diseñado para Directores de TI, CTOs y Arquitectos de Red, ofrece una guía de implementación práctica, casos de estudio del mundo real y marcos de ROI medibles para ayudar a los operadores de recintos a recuperar el ancho de banda y ofrecer conectividad de alto rendimiento a escala.

Leer la guía →

¿Por qué nuestro WiFi de invitados es tan lento? Diagnóstico de la congestión de red

Esta guía diagnostica los factores ocultos de la congestión del WiFi de invitados - telemetría en segundo plano, redes publicitarias programáticas y actualizaciones automáticas de sistemas operativos - que colectivamente consumen hasta el 40% del ancho de banda del WiFi público antes de que un invitado siquiera abra un navegador. Proporciona un marco de implementación por fases y neutral respecto al proveedor para filtrado de DNS y políticas de QoS que recuperan ese ancho de banda, mejoran la experiencia del invitado y ofrecen un ROI medible. Dirigido a Directores de TI y Gerentes de Operaciones en los sectores de hospitalidad, retail, eventos y entornos del sector público.

Leer la guía →

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.