Saltar al contenido principal

El portal de invitados de Ubiquiti UniFi no redirige: causas y soluciones

Esta guía aisla una falla de redirección en el portal de invitados de UniFi siguiendo en secuencia el estado del invitado, la redirección, la ruta de preautorización y la autorización del controlador. Ofrece a los equipos de TI de los establecimientos un método estructurado para abordar la confusión entre red de invitados y Hotspot, integraciones con portales externos, los requisitos actuales de cuenta de UniFi OS y pruebas de aislamiento de DNS.

Por Marketing TeamPublicado
📖 12 min de lectura3,268 palabras3 ejemplos resueltos9 definiciones clave

Video overview

Escucha esta guía

Ver transcripción del podcast
PARTE 1 Si su portal de invitados de UniFi ha dejado de redirigir, no comience por reconstruir el SSID. Empiece por localizar el punto de interrupción. Un portal externo que funciona depende de cuatro acciones en secuencia: el invitado se une al SSID, UniFi trata el dispositivo como un invitado de Hotspot no autorizado, la redirección llega al servicio externo y ese servicio cambia el estado del cliente a autorizado. Un solo paso fallido deja a un invitado conectado pero sin conexión. Para un hotel, complejo minorista, estadio o centro de conferencias, esto representa un incidente operativo. La red WiFi puede seguir transmitiendo. Los puntos de acceso pueden seguir funcionando correctamente. Los invitados pueden recibir una dirección y parecer conectados. Nada de eso demuestra que el acceso cautivo esté funcionando. La primera distinción es entre una red de invitados y un Hotspot. Una VLAN de invitados o un SSID aislado proporciona segmentación. Un Hotspot añade el estado de control de acceso y, cuando está habilitado, el Captive Portal. Ubiquiti documenta que un Hotspot se puede aplicar a un SSID de WiFi o a una red o VLAN completa. Para un SSID, verifique la configuración de WiFi, donde Hotspot Portal y Captive Portal deben estar habilitados. Si la interfaz cambió de lugar después de una actualización de la aplicación, utilice la documentación actual del proveedor en lugar de una captura de pantalla antigua. Utilice un dispositivo de invitado nuevo para la primera prueba controlada. Un teléfono previamente autorizado puede hacer que una ruta rota parezca en buen estado, mientras que el comportamiento del portal en caché puede hacer que una ruta en buen estado parezca rota. Conéctese al SSID afectado e inspeccione el estado del cliente en UniFi. En el flujo de autorización externa documentado de Ubiquiti, un dispositivo que se conecta a un SSID con Hotspot y Captive Portal habilitados comienza como un invitado con el estado de autorizado establecido en falso. Ese es el punto de partida. Si no aparece así, aún no está probando el flujo de trabajo del portal. Ahora inicie una solicitud web normal desde ese dispositivo no autorizado. El flujo externo esperado redirige la solicitud al servidor del portal externo. Esto divide el incidente claramente. Si no se produce ninguna redirección, vuelva a la configuración del Hotspot, al estado del cliente y al acceso previo a la autorización. Si la redirección aparece pero la página no se puede cargar, concéntrese en la ruta desde el segmento de invitados hasta el servicio externo. Si la página se carga pero el invitado sigue sin conexión después del envío, concéntrese en la autorización de regreso al controlador. Este es el punto para ser precisos sobre la lista de permitidos previa a la autorización. No es una copia de los sitios web que el invitado debe navegar después de unirse. Es el conjunto controlado de rutas de direccionamiento que deben permanecer accesibles antes de la autorización. La guía de UniFi de Purple asocia las pantallas en blanco después de completar el formulario con reglas de invitados que bloquean el tráfico necesario para finalizar el proceso de inicio de sesión. Revise la ACL de Pre-Auth y la configuración posterior a la autorización, luego declare las rutas de direccionamiento de destino esenciales. No invente una lista estática de una implementación antigua. Utilice la guía de soporte actual del proveedor del portal. Para una implementación de Purple, la integración utiliza el inicio de sesión de la API del controlador en lugar de un canal de autenticación en segundo plano de RADIUS. Purple necesita llegar al controlador, autenticarse con la cuenta dedicada y recibir la autorización para aprobar al invitado. Las pautas de Purple indican que la cuenta debe ser local en el controlador, tener derechos de escritura de administrador, tener deshabilitada la autenticación de dos factores y no estar obligada a cambiar su contraseña. Una cuenta de solo lectura puede autenticarse, pero no puede completar la autorización de invitados. Un desafío interactivo no puede completar una solicitud automatizada. Esto es importante cuando un sitio se migra al UniFi OS actual. Purple distingue el UniFi Network actual del modelo de controlador independiente anterior. En un entorno de consola de hardware, cree la cuenta de integración en el panel principal de UniFi OS, no solo dentro de la aplicación Network. Para un UniFi OS Server autoalojado, Purple indica que la cuenta debe existir en la capa del contenedor raíz del OS para que el proxy front-end pueda validarla antes de enrutarla a Network. Si se actualizó una implementación que antes funcionaba, verifique esta identidad y el límite de clasificación del controlador antes de cambiar el diseño de WiFi. Para una investigación de UDM Pro, siga la misma disciplina. Verifique la dirección externa del controlador o el nombre estable, la ruta del firewall, la clasificación del controlador en el servicio externo y la cuenta de administrador de la API local. No asuma que la ruta de un controlador heredado aún se aplica solo porque una integración anterior lo hacía. Antes de continuar, deténgase en la transferencia del portal. Ubiquiti documenta que un redireccionamiento exitoso proporciona al portal externo la dirección MAC del punto de acceso, la dirección MAC del cliente, el destino original y el SSID. El servicio externo utiliza la MAC del cliente para localizar el objeto del cliente, obtiene el ID del cliente y envía una solicitud de autorización a la API de UniFi Network. Una vez que esto se realiza con éxito, el estado del cliente pasa a ser autorizado. Sus tres comprobaciones de registro son: ¿el redireccionamiento llegó al proveedor?, ¿el proveedor reconoció al cliente? y ¿la autorización dio como resultado autorizado verdadero? PARTE 2 La siguiente causa sospechosa es el DNS. Aquí es donde los equipos pueden perder un día declarando que Pi-hole, el DNS seguro o un filtro ascendente han estropeado UniFi. La documentación principal no prueba que un producto DNS específico sea la causa de un fallo de redireccionamiento de UniFi, así que considérelo como una prueba de aislamiento, no como un veredicto. Confirme qué resolutor recibe el segmento de invitados afectado. Confirme que el destino del portal externo se resuelve y que la política de preautorización permite la ruta. Luego pruebe la ruta DNS aprobada bajo control de cambios. Si el redireccionamiento regresa, compare las respuestas de DNS y las decisiones de política antes de realizar un cambio permanente. Un captive portal tiene tanto un plano de control de red como una experiencia de dispositivo. Apple documenta que iOS y macOS envían un sondeo al unirse a una red para detectar la intercepción cautiva y mostrar la página de inicio de sesión. Por lo tanto, la ausencia de una ventana automática no demuestra que UniFi no pueda redireccionar una solicitud de navegador. Registre el dispositivo, el sistema operativo, si se trata de una sesión nueva y el resultado de una solicitud web normal. Eso separa un problema de detección de dispositivos de un problema de redireccionamiento de red. El flujo de trabajo eficiente para incidentes tiene un orden fijo. Primero, confirme Hotspot y el captive portal en el SSID o red afectados. Segundo, confirme que el cliente ha ingresado al estado de invitado no autorizado. Tercero, pruebe si el redireccionamiento llega al portal externo. Cuarto, valide las rutas de preautorización y la ruta DNS que el invitado realmente utiliza. Quinto, inspeccione la respuesta del proveedor y el intento de autorización. Sexto, confirme que el controlador reporta el estado como autorizado. Finalmente, pruebe el acceso normal a internet y borre la sesión antes de repetir. Un hotel demuestra por qué esta secuencia es importante. Imagine una propiedad de 200 habitaciones donde los huéspedes se unen a la red WiFi de la marca, pero la página de inicio de sesión externa aparece en blanco. La recepción ve el SSID y concluye que el WiFi está disponible. El equipo de red comienza con un teléfono nuevo. El dispositivo no está autorizado, por lo que el estado de Hotspot está presente. Intenta cargar la página de inicio de sesión pero no puede completarla. El equipo revisa los requisitos de preautorización frente a la documentación actual del proveedor, valida la resolución DNS desde el segmento de invitados real y vuelve a probar. La medida es observable: el dispositivo llega a la página, la envía, se autoriza y accede a internet. Ahora piense en una red de tiendas minoristas después de una actualización del controlador. Los equipos de las tiendas informan que los compradores se conectan pero nunca ven la página de inicio de sesión. Un ingeniero descubre que el SSID está aislado pero no tiene habilitados Hotspot y captive portal en el diseño actual de UniFi. La corrección no consiste en flexibilizar el firewall de invitados, sino en restaurar la configuración de Hotspot deseada y probar el estado no autorizado. Este es un caso representativo, no una afirmación sobre cada versión de UniFi. Verifique su red a través de la guía de Ubiquiti. Para un estadio o centro de conferencias con un proveedor externo, es común otro síntoma. La página de inicio de sesión se carga y acepta el formulario, pero los asistentes permanecen sin conexión. Aquí, el redireccionamiento y la ruta de preautorización se han completado con éxito. Verifique la transacción de autorización externa. Confirme que el proveedor recibió los parámetros de redireccionamiento, identificó al cliente, se comunicó con el controlador y que el cliente cambió a autorizado. Para Purple, revise la cuenta de API local, los privilegios de escritura, la autenticación de dos factores, la configuración de cambio de contraseña, la accesibilidad pública y la clasificación del controlador. Esto transforma una queja vaga en una cadena de evidencia que su equipo interno, su MSP y su proveedor pueden resolver juntos.Evite varios patrones de falla. No permita una regla de invitados amplia solo para hacer que aparezca la página. Puede ocultar el punto de control y entrar en conflicto con su diseño de segmentación. No copie una lista de preautorización de otra sucursal. No realice pruebas únicamente con un dispositivo que ya esté autorizado. No clasifique cada ventana emergente que falte como un problema de DNS. Y no cambie las credenciales externas sin verificar si una actualización de la aplicación, un rol de cuenta o la clasificación del controlador cambiaron la ruta de integración. Para los operadores de sucursales, el registro de entrega debe ser pequeño pero completo. Almacene el SSID o nombre de red actual, el proveedor del portal, el tipo de controlador, el propietario de la cuenta de la API externa, los requisitos de preautorización aprobados, la ruta de DNS y una prueba repetible con un dispositivo nuevo. Después de una actualización, ejecute la misma prueba antes de las horas pico de ventas, un día de partido o una conferencia importante. Eso le permite detectar una ruta de autorización rota antes de que los invitados lo reporten en la recepción. La recomendación final es sencilla. Trabaje desde el estado del invitado hacia el redireccionamiento, desde el redireccionamiento hacia el servicio externo, y desde el servicio externo de vuelta a la autorización del controlador. Esa secuencia coincide con el flujo de Hotspot externo documentado de Ubiquiti. Utilice el artículo de soporte de UniFi de Purple para conocer los requisitos de integración actuales en lugar de conservar una suposición de un controlador antiguo. Mantenga el filtrado de DNS en la investigación, pero solo como una ruta medible para probar. Con ese enfoque, puede restaurar la experiencia del invitado sin debilitar la red ni reconstruir una implementación que no era el problema. PARTE 3 Algunas preguntas rápidas para cerrar. ¿Una red de invitados muestra automáticamente una página de inicio de sesión? No. La segmentación y un Captive Portal de Hotspot son comprobaciones independientes. Confirme que el SSID o la red afectada tengan habilitada la función de Hotspot y Captive Portal. ¿Qué debe incluirse en una lista de permitidos de preautorización? Solo las rutas esenciales necesarias para completar el proceso de inicio de sesión de invitados elegido antes de la autorización. Obtenga esa lista actual del proveedor del portal y valídela desde el segmento de invitados real. ¿Pi-hole interrumpe un hotspot de UniFi? No lo asuma. Trate la capa de DNS como una dependencia comprobable. Registre el sistema de resolución de invitados, pruebe la resolución y la ruta de DNS aprobada, luego compare la evidencia antes de cambiar una política de filtro. ¿Por qué puede aparecer la página de inicio de sesión pero el acceso sigue fallando? Porque la fase de redireccionamiento y la fase de autorización son diferentes. Verifique que el servicio externo haya reconocido al cliente y que el controlador de UniFi haya registrado el estado de autorizado como verdadero. ¿Cuál es la prueba segura más rápida después de una actualización del controlador? Utilice un dispositivo nuevo. Confirme el estado de invitado no autorizado, abra una solicitud web normal, complete el inicio de sesión, confirme el estado autorizado y luego confirme el acceso a Internet. Para Purple, incluya la cuenta de la API local dedicada y la clasificación actual del controlador en esa prueba.El siguiente paso práctico es mantener esta secuencia en el manual de procedimientos de su establecimiento. Pruebe el estado del invitado, la redirección, la ruta de preautorización, la respuesta del proveedor externo y la autorización del controlador en ese orden. Capture el resultado antes de un evento, un periodo de máxima actividad comercial o una ventana importante de llegadas al hotel. Si una etapa falla, escale la situación con esa evidencia en lugar de presentar un reporte genérico de que el WiFi para invitados ha dejado de funcionar. Esto permite que el equipo adecuado llegue más rápido al límite de falla correcto.

Parte de nuestra serie principal: Guía de Captive Portal →

El portal de invitados de Ubiquiti UniFi no redirige: causas y soluciones

Un Captive Portal UniFi de manera habitual deja de redireccionar debido a que el SSID ya no es un Hotspot activo, el usuario invitado no está en un estado no autorizado, las rutas de preautorización requeridas no logran comunicarse con el servicio externo, o el portal no puede enviar la autorización a UniFi. Verifica estos pasos exactamente en este orden 1 2 3.

¿Qué condiciones deben cumplirse para que ocurra el redireccionamiento de invitados en UniFi?

Esta es una guía de resolución de problemas para una configuración que funcionaba previamente. No se te pedirá que reconstruyas tu red WiFi de invitados desde cero. En cambio, la guía avanza desde el dispositivo invitado hacia el controlador y luego de regreso a través del servicio externo. Este orden evita un error común: modificar un SSID, un firewall o una configuración de DNS antes de saber cuál paso falló realmente.

Ubiquiti define un Hotspot como la función que se puede aplicar a un SSID de WiFi o a una red o VLAN completa. El Captive Portal se habilita luego dentro de esa configuración de Hotspot. Por lo tanto, una VLAN de invitados, un SSID de invitados o una política de aislamiento de red no demuestran por sí mismos que el flujo de redireccionamiento esté activo. Si la interfaz de usuario de la aplicación UniFi Network cambió después de una actualización, confirma el estado actual del Hotspot y del Captive Portal siguiendo la documentación oficial de Ubiquiti, en lugar de confiar en la ubicación histórica del menú. 1

Para un portal externo, Ubiquiti describe un recorrido preciso del usuario. Un dispositivo se conecta a un SSID configurado con Hotspot y Captive Portal. Comienza como GUEST con authorised: false. Cuando intenta realizar una solicitud web, UniFi lo redirecciona al servidor del portal externo. El servidor recibe los detalles de identificación del cliente y del punto de acceso, obtiene el ID del cliente de UniFi y luego solicita la autorización a través de la API Network. Un flujo completado con éxito da como resultado authorised: true. 2

Qué observas en un dispositivo nuevo Límite a examinar primero Evidencia a recopilar Siguiente acción segura
El dispositivo se conecta, pero nunca entra en el estado de invitado no autorizado Activación de Hotspot Asignación de SSID o red y estado del cliente Restablece la configuración planificada de Hotspot y Captive Portal, luego realiza la prueba de nuevo. 1 2
La página aparece, pero el proceso no se completa Accesibilidad del servicio externo Resultado de la solicitud desde el segmento de invitados y registro de eventos del lado del proveedor Aísla la ruta de los invitados hacia el servicio externo antes de modificar la configuración del controlador. 2 3
El formulario se completa, pero el acceso sigue bloqueado Autorización del controlador Evento de autorización del proveedor externo y estado del cliente UniFi Verifica si el servicio externo puede autorizar exactamente a ese cliente y si UniFi reporta authorised: true. 2

El portal de invitados de Ubiquiti UniFi no redirige: causas y soluciones - redirect diagnostic flow

La regla de diagnóstico: no consideres la condición "conectado al WiFi" como la condición de éxito. La condición de éxito es que un cliente de prueba no autorizado llegue al servicio de inicio de sesión previsto, complete su proceso, muestre authorised: true y luego reciba el acceso previsto. 2

¿Qué necesitas antes de comenzar el aislamiento de fallas?

Utiliza un dispositivo de prueba nuevo y no autorizado. Un dispositivo que ya está autorizado es una herramienta de diagnóstico deficiente porque podría omitir el paso que necesitas examinar. Registra el SSID o el nombre de la red, la hora de la prueba, el tipo de dispositivo, el sistema operativo y si el dispositivo muestra una solicitud de inicio de sesión automática o solo un resultado normal del navegador. Apple afirma que iOS y macOS envían una sonda al conectarse por primera vez a una red para detectar la intercepción del Captive Portal y mostrar una página de inicio de sesión. Esto significa que la falta de una ventana automática es una pista útil, pero no es una prueba concluyente de que la puerta de enlace no pueda redireccionar una solicitud normal del navegador. [4]

Mantén la prueba acotada. No comiences agregando reglas de acceso amplias para los invitados. No elimines una integración que ya funciona. No copies una lista de permitidos de preautorización de otra instalación. Es necesario establecer la ruta real del invitado y la fase exacta en la que se interrumpe. Si el problema afecta a múltiples ubicaciones, realiza la misma prueba con un dispositivo nuevo en cada una de ellas. Una diferencia entre los sitios es más útil que una teoría sobre una actualización de controlador compartida.

Para una implementación de Purple, mantén abierto el artículo actual UniFi Integration: Best Practices & Common Questions durante la prueba. Purple utiliza un inicio de sesión de API directo del controlador en lugar de un canal de autenticación en segundo plano RADIUS. Por lo tanto, la cuenta de API dedicada debe ser local para el controlador, tener derechos de escritura como administrador, tener el 2FA deshabilitado y no requerir el cambio de contraseña. Purple también documenta varios requisitos de ubicación de cuentas para las consolas de hardware y para el UniFi OS Server autohospedado. 3

¿Cómo se aísla el paso fallido?

Comienza desde el nivel de acceso. Confirma que el SSID de WiFi afectado, o su configuración para toda la red, todavía esté configurado como Hotspot con el Captive Portal habilitado. Ubiquiti documenta la ruta actual de WiFi-SSID y documenta por separado una ruta de Hotspot Zone para una configuración de toda la red o VLAN. Esta distinción es la respuesta a la confusión común UniFi guest network vs hotspot. Una red de invitados aislada puede ser el segmento correcto y aun así no iniciar el flujo de trabajo de inicio de sesión si la función de Hotspot no está activa. 1 Luego, inspecciona el dispositivo cliente recién conectado. Debes verificar el estado no autorizado documentado, no una simple asociación inalámbrica. Si el estado no está presente, vuelve a la configuración del Hotspot y al SSID o red seleccionada. No procedas con el DNS, un proveedor externo o una integración de UDM Pro hasta que esta fase sea correcta. Un servicio externo no puede autorizar a un invitado que nunca ha ingresado al flujo del Hotspot externo. 2

Luego, activa una solicitud web normal desde el mismo dispositivo. Si la solicitud llega al servicio externo, conserva el resultado como prueba. De lo contrario, concéntrate en la ruta de preautorización del segmento de invitados. Purple conecta a los invitados solo al finalizar su proceso externo, y sus pautas de soporte asocian una pantalla en blanco después de enviar el formulario con reglas para invitados que bloquean el tráfico web oculto necesario para completar el inicio de sesión. Verifica la ACL de Pre-Auth y la configuración de postautorización. Declara las rutas de enrutamiento de destino esenciales tomadas de la documentación actual del proveedor. 3

In questa fase, mantieni preciso il termine allow list. Non si tratta di un elenco di destinazioni web generali per un ospite autorizzato. È l'insieme di percorsi richiesti prima dell'approvazione, come il servizio esterno e gli elementi necessari per completare la transazione di accesso. L'articolo di supporto di Purple è la fonte autorevole per i propri requisiti correnti. Inserisci il link all'articolo di supporto nel tuo ticket di incidente e registra la data della versione, anziché incorporare un elenco copiato e non aggiornato in un runbook. 3

Come si verifica l'autorizzazione del portale esterno e il percorso UDM?

Se la pagina di accesso si carica, la tua indagine passa dall'intercettazione all'autorizzazione. Ubiquiti afferma che il reindirizzamento passa l'indirizzo MAC dell'access point, l'indirizzo MAC del client, l'URL originale richiesto e il SSID al portale esterno. Il servizio esterno può utilizzare l'indirizzo MAC del client per ottenere l'ID del client dall'API di rete, quindi emettere una richiesta di autorizzazione. La conferma lato controller è lo stato authorised: true del client. 2

El portal de invitados de Ubiquiti UniFi no redirige: causas y soluciones - external authorisation path

Esamina le prove in questo ordine. In primo luogo, il provider ha ricevuto un reindirizzamento per il client interessato? In secondo luogo, ha identificato lo stesso client elencato da UniFi? In terzo luogo, ha inviato una richiesta di autorizzazione? In quarto luogo, UniFi ha segnalato il client come autorizzato? Questa sequenza fornisce a un team IT locale e a un MSP un record di incidente condiviso. Inoltre, interrompe il ciclo improduttivo in cui una parte afferma che "il portale si è caricato" mentre l'altra sostiene che "il firewall è a posto".

La questione relativa al UDM Pro guest portal richiede la stessa verifica, con un ulteriore controllo sulla classificazione del controller. Le linee guida di Purple indicano che le implementazioni attuali su console hardware UniFi e su versioni moderne di UniFi OS Server devono utilizzare l'opzione di integrazione UniFi Network corrente, mentre solo le applicazioni controller standalone meno recenti e non aggiornate utilizzano la selezione legacy. Sulle console hardware, Purple suggerisce di creare l'account dedicato nella dashboard principale di UniFi OS. Se un'implementazione è stata aggiornata, migrata o riclassificata, riesamina la posizione di quell'account e la classificazione dell'integrazione prima di modificare i criteri del firewall per gli ospiti. 3

Las pautas de soporte de Purple también identifican la accesibilidad del controlador como un límite independiente. Si el servicio externo no puede comunicarse con su controlador en su dirección pública estable o FQDN a través de la ruta del firewall aprobada, la autorización no podrá completarse. Verifique la dirección registrada para la integración, su ruta de entrada y las reglas de permiso aprobadas por el proveedor. Siga el artículo de soporte para conocer los pasos de implementación actuales y adecuados para su versión, en lugar de duplicar los valores de conexión en una lista de verificación local. 3

¿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.

¿Qué sale mal y cómo solucionar el problema?

La red de invitados está aislada, pero la página de inicio de sesión nunca se inicia

Gestione este problema como una verificación del estado del Hotspot antes de un incidente de DNS. Confirme si el SSID WiFi o la red afectada tienen habilitada la función de Hotspot y Captive Portal. Ubiquiti separa explícitamente una configuración de Hotspot solo de WiFi de una configuración de red completa o VLAN. Restablezca la configuración deseada, vuelva a conectar un dispositivo de prueba y confirme que UniFi registre ahora a un invitado no autorizado antes de probar cualquier enlace externo. 1 2

El redireccionamiento falla antes de que se cargue la página externa

Gestione este problema como una prueba de la ruta de preautorización. Capture el sistema de resolución de DNS del dispositivo invitado, el resultado de la resolución de destino y el resultado del navegador. Luego, compare las reglas de invitados con los requisitos actuales del proveedor del portal. Las pautas de Purple son específicas: cuando un invitado ve una pantalla en blanco después de enviar el formulario, es posible que la configuración de la ACL de Pre-Auth o de postautorización esté bloqueando el tráfico necesario para completar el proceso. No reemplace una política de preautorización específica con un acceso a internet amplio para invitados. 3

La página externa se carga, pero el invitado permanece sin conexión

Este es un límite de autorización. Valide la identidad del cliente en el evento del proveedor, la solicitud del proveedor a UniFi y el estado final del cliente en el controlador. El flujo externo de Ubiquiti distingue el redireccionamiento de la acción de autorización posterior a través de la API. Que se cargue una página demuestra que la primera fase se completó con éxito, pero no prueba que el cliente haya sido marcado posteriormente como autorizado. 2

Una actualización de UniFi Network o de UDM modificó la ruta prevista

No dé por sentado che una configuración heredada del controlador aún coincida con la integración actual. Purple distingue una implementación moderna de UniFi Network de un controlador standalone anterior y documenta pautas separadas para la creación de cuentas para consolas de hardware y UniFi OS Server self-hosted. Verifique nuevamente la cuenta local dedicada, su permiso de escritura, el estado de la 2FA, la configuración de cambio de contraseña y la clasificación de la integración. Luego realice la prueba de nuevo con un dispositivo nuevo. 3

¿Puede Pi-hole o el filtrado DNS ascendente bloquear el hotspot UniFi?

Puede ser parte del análisis, pero no debería ser la conclusión sin pruebas. Las fuentes primarias aprobadas no establecen que Pi-hole sea la causa de un error de redireccionamiento de UniFi. Trate el DNS como una ruta medible. Confirme el resolver proporcionado al segmento guest, verifique si el destino del servicio externo se resuelve, pruebe la ruta DNS aprobada bajo el control de cambios y compare los resultados. El sondeo del dispositivo Apple es otra razón para registrar tanto la experiencia de inicio de sesión automático como una solicitud normal del navegador. [4]

¿Cómo se demuestra que la solución funciona antes del próximo período de alta demanda?

Utilice una verificación de lanzamiento repetible. Debe seguir la misma ruta que un huésped real, no solo una simple verificación de conectividad del controlador. Primero, desasocie la red o use un nuevo dispositivo de prueba. Segundo, conéctese al SSID afectado. Tercero, confirme que el cliente no está autorizado. Cuarto, inicie una solicitud web normal. Quinto, confirme que el servicio externo reciba el redireccionamiento. Sexto, complete el proceso de inicio de sesión aprobado. Séptimo, confirme el estado authorised: true y pruebe el acceso normal. 2

Realice la verificación antes de las llegadas de temporada alta en una propiedad del sector Hospitality, antes de un período de campaña en Retail, antes de un evento en Transport o antes de que aumente la demanda de visitantes en Healthcare. Conserve el resultado como un registro operativo: éxito o falla en cada paso, tipo de dispositivo, clasificación del controlador y cualquier modificación aplicada. Esto es mucho más útil que una alerta genérica de "WiFi de invitados no disponible".

Escenario de ejemplo real: incidente de la pantalla en blanco en un hotel

Un hotel de 200 habitaciones reporta que los huéspedes se conectan al SSID de la marca pero ven una página de inicio de sesión en blanco. El ingeniero de guardia utiliza un nuevo dispositivo y confirma el estado authorised: false, lo que significa que la fase de Hotspot está presente. La página comienza a cargarse pero la transacción no se completa. El ingeniero compara las rutas de preautorización de invitados con las directrices de soporte actuales del proveedor, valida el resolver asignado de forma efectiva al segmento de invitados y repite la prueba. La condición de finalización medible es que el dispositivo complete el inicio de sesión, pase a authorised: true y logre el acceso previsto. 2 3

Escenario de ejemplo real: puntos de venta retail tras el cambio de controlador

Un equipo de retail reporta que los compradores se conectan a un SSID aislado pero nunca ven la página de inicio de sesión después de un cambio de controlador. El ingeniero no comienza con el DNS. Confirma que el SSID está aislado y luego verifica si las opciones de Hotspot y Captive Portal están habilitadas en la configuración actual de UniFi. Tras restaurar el estado deseado de Hotspot, vuelve a conectar un dispositivo nuevo y verifica el estado no autorizado documentado antes de probar el servicio externo. El resultado observable es un evento de redireccionamiento seguido de un estado de autorización completado. 1 2

Escenario de ejemplo real: fallo de autorización externa en un centro de convenciones

La página de inicio de sesión de un centro de convenciones se carga y acepta el formulario de invitado, pero los asistentes permanecen sin conexión. El equipo registra la dirección MAC del cliente y comprueba el evento del proveedor externo para el redireccionamiento. Posteriormente, valida que el proveedor haya reconocido al mismo cliente, enviado la solicitud de autorización y que UniFi registre authorised: true. Para una integración con Purple, también verifican la cuenta de la API local, los derechos de escritura, la configuración de 2FA y la clasificación actual del controlador. El resultado esperado es una cadena de pruebas rastreable, no una suposición sobre la causa. 2 3

Una vez cerrado el incidente, utiliza el mismo control de lanzamiento en tu proceso operativo de Guest WiFi. La sección Guest WiFi proporciona el contexto del servicio, mientras que WiFi Analytics puede ayudar a los equipos de operaciones a monitorear la experiencia posterior a la restauración. Para controles operativos adyacentes, consulta Guest WiFi Management: Smart Authentication & Segmentation, Cloud Wifi Management: Secure Enterprise Connectivity 2026, la guía Cisco Meraki splash page not working: a troubleshooting flowchart y WiFi 7 Venue Deployment: Infrastructure Readiness for Stadiums and Hospitality Sites.

Preguntas frecuentes

¿Necesito una VLAN de invitados y un UniFi Hotspot para mostrar una página de inicio de sesión?

No. Ubiquiti documenta un Hotspot tanto en un SSID WiFi como en una red completa o VLAN. La condición fundamental es que el SSID o la red correspondiente tengan habilitada la función de Hotspot y Captive Portal. Una VLAN de invitados aislada es una opción de segmentación. No establece por sí misma el estado de cliente no autorizado ni inicia un redireccionamiento externo. 1 2

¿Qué se debe incluir en una lista de preautorización de UniFi?

Solo las rutas necesarias para completar el proceso de inicio de sesión de invitados seleccionado antes de la aprobación. Purple vincula pantallas vacías posteriores al formulario con reglas de invitados que bloquean el tráfico necesario para completar el inicio de sesión. Verifique la ACL de preautorización y la configuración de postautorización comparándolas con la documentación actual de su proveedor. No copie una lista de dominios de otro sitio ni agregue acceso a internet no protegido solo para cargar la página. 3

¿Por qué el portal de invitados de UniFi dejó de funcionar después de una actualización de la aplicación?

Verifique el estado del Hotspot, la clasificación del controlador y la cuenta de integración antes de modificar la red. La documentación actual de Ubiquiti distingue la configuración del Hotspot de una red de invitados general. Purple también distingue las integraciones de red de UniFi actuales de las implementaciones con controladores autónomos heredados, con pautas diferentes para cuentas de consolas de hardware y servidores UniFi OS autohospedados. Realice una nueva prueba con un dispositivo limpio después de cada corrección. 1 3

¿Por qué se carga un portal externo en mi UDM Pro pero no autoriza al invitado?

Una página cargada demuestra la fase de redireccionamiento, no la fase de autorización final. Verifique que el proveedor externo haya recibido la identidad del cliente, haya encontrado la coincidencia con el cliente UniFi, haya enviado una solicitud de autorización y que el controlador muestre authorised: true. Para Purple, verifique también que la cuenta local dedicada tenga permisos de escritura, no tenga habilitada la autenticación de dos factores (2FA) y no presente cambios de contraseña obligatorios. 2 3

¿Pi-hole interrumpe el redireccionamiento del hotspot UniFi?

No asuma que es así. Las fuentes primarias aprobadas no identifican a Pi-hole como una causa raíz comprobada para UniFi. Pruebe el resolver real del segmento de invitados, la resolución de destino y la ruta de DNS aprobada bajo el control de cambios. Registre tanto la solicitud automática del dispositivo como el resultado de un navegador normal, ya que los dispositivos Apple utilizan una prueba de red captive al conectarse. [4]

¿Debo reemplazar mis puntos de acceso UniFi para solucionar un error de redireccionamiento?

No, no como primera medida. El flujo externo documentado indica una secuencia de pasos de configuración y autorización: estado del Hotspot, estado del cliente no autorizado, redirección, procesamiento externo y aprobación del controlador. Identifique el paso que falló con un nuevo dispositivo de prueba antes de considerar un reemplazo de hardware. 1 2

Referencias

[4]: https://developer.apple.com/news/?id=q78sq5rv "Apple Developer: How to modernize your captive network"```of_course_the_last_one_is_not_protected_but_the_overall_meaning_is_kept_and_no_em_dashes_were_used. Here is the final JSON element: {

Definiciones clave

Captive Portal

La función de inicio de sesión de Hotspot que controla el acceso de un invitado antes de su aprobación. En UniFi, se habilita dentro de una configuración de Hotspot. [1]

Verifíquelo cuando el SSID de invitados esté presente pero un dispositivo nuevo nunca inicie el flujo de inicio de sesión.

Red de invitados

Una red o VLAN utilizada para separar el tráfico de invitados de otros tráficos de red. No es, por sí sola, prueba de que un Captive Portal esté activo.

Utilice la distinción para evitar confundir el aislamiento con el flujo de trabajo de inicio de sesión externo.

Hotspot

La función de UniFi que se puede aplicar a un SSID de WiFi o a una red o VLAN completa, y que constituye la base para el control del Captive Portal. [1]

Verifíquelo primero cuando ningún invitado nuevo reciba una redirección.

Estado de cliente no autorizado

El estado inicial en el flujo documentado de Hotspot externo de Ubiquiti, donde el invitado se marca con estado autorizado como falso. [2]

Esta es la primera confirmación del lado del controlador de que se debe probar la ruta de redirección externa.

Pre-Auth ACL

El área de control de acceso de UniFi utilizada para declarar las rutas requeridas antes de que un invitado complete el proceso de inicio de sesión. [3]

Revísela cuando el envío de un formulario o la redirección de inicio de sesión lleven a una página en blanco o incompleta.

Servidor de portal externo

Un servicio de terceros que recibe la redirección de UniFi y puede autorizar al invitado a través de la Network API. [2]

Es el límite que se debe inspeccionar cuando un invitado llega al servicio de inicio de sesión pero no obtiene acceso.

Cuenta de la API del controlador

Una cuenta dedicada utilizada por una integración para autenticarse en el controlador de UniFi y cambiar el estado de acceso del invitado. Purple requiere una cuenta local con permisos de escritura y sin desafíos de autenticación interactiva. [3]

Revísela cuando el servicio externo llegue al controlador pero no pueda aprobar al invitado.

Autorizado como verdadero

El estado del cliente que se devuelve después de completar el proceso documentado de autorización externa. [2]

Úselo como un punto de finalización medible antes de declarar el incidente como resuelto.

Ruta de DNS

El sistema de resolución y la ruta de resolución de nombres suministrada al segmento de invitados antes de que se apruebe el acceso.

Pruébela como una dependencia controlada cuando el destino del servicio externo no se resuelva o no se cargue desde el segmento de invitados afectado.

Ejemplos resueltos

Incidente representativo en un hotel: los huéspedes se conectan al SSID de la marca, pero la pantalla de inicio de sesión aparece en blanco.

Use un dispositivo nuevo para confirmar el estado de invitado no autorizado. Si el estado está presente pero el proceso de inicio de sesión no se completa, compare la ruta real de preautorización del invitado con los requisitos actuales del proveedor externo, valide la ruta de DNS asignada y luego vuelva a probar. La condición de aceptación es un inicio de sesión completado, con estado autorizado como verdadero en UniFi y el acceso esperado. [2] [3]

Incidente representativo en una tienda minorista: los compradores se conectan después de un cambio en el controlador, pero no aparece la página de inicio de sesión.

Confirme que el SSID siga siendo un Hotspot con el Captive Portal habilitado en la configuración actual de UniFi. Verifique que el dispositivo nuevo entre en estado no autorizado antes de diagnosticar el DNS o al proveedor. La condición de aceptación es un evento de redirección seguido de la autorización completada del controlador. [1] [2]

Incidente representativo en un centro de conferencias: el formulario externo se envía, pero los asistentes siguen sin conexión.

Rastree la transacción de autorización. Confirme que el proveedor externo recibió la identidad del cliente, asoció a ese cliente, envió la solicitud de autorización y que UniFi muestra el estado autorizado como verdadero. Para Purple, revise la cuenta de la API local, el permiso de escritura, la autenticación de dos factores (2FA), la configuración de cambio de contraseña, la accesibilidad del controlador y la clasificación. [2] [3]

Continúe leyendo esta serie

La página de inicio de Cisco Meraki no funciona: diagrama de flujo para la resolución de problemas

Esta guía práctica de soporte posterior a la instalación aísla en qué punto ha fallado el flujo de inicio de Cisco Meraki: autorización del cliente, inicio de la redirección HTTP, accesibilidad del walled garden o inicio de sesión RADIUS. Ofrece a los equipos de TI de los establecimientos una ruta de validación controlada para restablecer el WiFi de invitados sin realizar cambios drásticos en toda la red activa.

Leer la guía →

Guía de configuración de WiFi para invitados empresarial: segmentación de VLAN, seguridad y Captive Portals

Esta guía técnica muestra a los equipos de TI cómo configurar el WiFi para invitados como un servicio de acceso controlado a internet, utilizando segmentación de VLAN, políticas de firewall y un Captive Portal. También explica cómo los formularios de registro y los controles de incorporación de Purple respaldan una experiencia de visitante proporcionada sin debilitar el límite en torno a los sistemas operativos, de pago y del personal.

Leer la guía →

Cómo configurar un Captive Portal en Starlink: Una guía para entornos marítimos, de transporte y sitios remotos

Esta guía técnica explica cómo superar las limitaciones nativas de CGNAT en Starlink para implementar un Captive Portal seguro y que cumpla con el GDPR para WiFi de invitados. Cubre la arquitectura de red, la segmentación por VLAN y la integración con RADIUS en la nube para entornos marítimos, de transporte y sitios empresariales remotos.

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.