Saltar al contenido principal

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

Esta guía aísla los fallos de redirección del portal de invitados de UniFi analizando 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 resolver la confusión entre red de invitados y Hotspot, integraciones con portales externos, los requisitos actuales de las cuentas de UniFi OS y pruebas de aislamiento de DNS.

Por Marketing TeamPublicado
📖 12 min de lectura3,230 palabras3 ejemplos prácticos9 definiciones clave

Video overview

Escuchar esta guía

Ver transcripción del podcast
PARTE 1 Si su portal de invitados de UniFi ha dejado de redirigir, no empiece por reconstruir el SSID. Comience por localizar el punto de transferencia que está fallando. Un portal externo que funciona correctamente depende de cuatro acciones secuenciales: el invitado se conecta al SSID, UniFi trata el dispositivo como un invitado de Hotspot no autorizado, la redirección llega al servicio externo y dicho servicio cambia el estado del cliente a autorizado. Un solo fallo en esta transferencia deja al invitado conectado pero sin conexión a internet. Para un hotel, un comercio, un estadio o un centro de conferencias, esto representa un incidente operativo. Es posible que la red WiFi siga transmitiendo. Los puntos de acceso pueden estar en perfecto estado. Los invitados pueden recibir una dirección IP y parecer conectados. Nada de eso demuestra que el acceso cautivo esté funcionando. La primera diferencia radica entre una red de invitados y un Hotspot. Una VLAN de invitados o un SSID aislado proporcionan 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 tras una actualización de la aplicación, utilice la documentación actual del fabricante 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 estar en buen estado, mientras que el comportamiento del portal guardado 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 la autorización establecida en falso. Ese es el punto de partida. Si esto no aparece, 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 con claridad. Si no se produce la redirección, vuelva a la configuración del Hotspot, al estado del cliente y al acceso de preautorización. Si aparece la redirección pero la página no se carga, cé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, céntrese en la autorización de vuelta al controlador. Este es el momento de ser precisos con la lista de permitidos de preautorización. No es una lista de sitios web por los que el invitado deba navegar después de conectarse. Es el conjunto controlado de rutas de enrutamiento que deben seguir siendo accesibles antes de la autorización. La guía de UniFi de Purple asocia las pantallas en blanco tras 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 preautorización y la configuración de postautorización, y luego declare las rutas de enrutamiento de destino esenciales. No invente una lista estática a partir de un despliegue antiguo. Utilice la guía de soporte actual del proveedor del portal. Para un despliegue 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 autoridad para aprobar al invitado. La guía de Purple especifica que la cuenta debe ser local en el controlador, tener derechos de escritura de administrador, tener desactivada la autenticación de doble factor y que no se le obligue 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 establecimiento se traslada al UniFi OS actual. Purple distingue el UniFi Network actual del modelo de controlador independiente anterior. En un parque de consolas de hardware, cree la cuenta de integración en el panel principal de UniFi OS, no solo dentro de la aplicación de 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 ha actualizado un despliegue que antes funcionaba, compruebe esta identidad y el límite de clasificación del controlador antes de cambiar el diseño de la WiFi. Para una investigación de UDM Pro, siga la misma disciplina. Verifique la dirección del controlador externo 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 una ruta de controlador heredada sigue aplicándose solo porque una integración anterior lo hiciera. 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 la ID del cliente y envía una solicitud de autorización a la API de UniFi Network. Una vez que esto tiene éxito, el estado del cliente pasa a estar autorizado. Sus tres comprobaciones de registro son: ¿llegó el redireccionamiento al proveedor?, ¿reconoció el proveedor 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 demuestra que un producto DNS concreto sea la causa de un fallo de redireccionamiento de UniFi, así que trátelo 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. A continuación, pruebe la ruta DNS aprobada bajo control de cambios. Si el redireccionamiento vuelve a funcionar, compare las respuestas 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 una prueba al unirse a una red para detectar la intercepción del portal 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 redirigir una solicitud del 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 el Hotspot y el Captive Portal en el SSID o red afectados. Segundo, confirme que el cliente ha entrado en el 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 utiliza realmente. Quinto, inspeccione la respuesta del proveedor y el intento de autorización. Sexto, confirme que el controlador informa 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 WiFi de la marca, pero la página externa de inicio de sesión está en blanco. Recepción ve el SSID y concluye que la 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. El resultado es observable: el dispositivo llega a la página, la envía, se autoriza y accede a Internet. Ahora tomemos un comercio minorista tras 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 el Hotspot y el Captive Portal en el diseño actual de UniFi. La corrección no consiste en relajar el cortafuegos de invitados. Consiste en restaurar la configuración de Hotspot prevista y probar el estado no autorizado. Este es un caso representativo, no una afirmación sobre cada lanzamiento de UniFi. Verifique su entorno a través de la guía de Ubiquiti. Para un estadio o un lugar 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 siguen sin conexión. Aquí, el redireccionamiento y la ruta de preautorización han funcionado. Compruebe la transacción de autorización externa. Confirme que el proveedor recibió los parámetros de redireccionamiento, identificó al cliente, contactó con el controlador y que el cliente cambió a autorizado. Para Purple, revise la cuenta de la API local, los privilegios de escritura, la autenticación de doble factor, la configuración de cambio de contraseña, la accesibilidad pública y la clasificación del controlador. Esto convierte una queja imprecisa en una cadena de pruebas que su equipo interno, MSP y proveedor pueden resolver juntos. Evite varios patrones de fallo. No permita una regla de invitado amplia simplemente 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 ubicación. No realice pruebas únicamente con un dispositivo ya autorizado. No clasifique cada ventana emergente que falta como un problema de DNS. Y no cambie las credenciales externas sin comprobar si una actualización de la aplicación, el rol de la cuenta o la clasificación del controlador cambiaron la ruta de integración. Para los operadores de locales, el registro de entrega debe ser pequeño pero completo. Guarde 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 DNS y una prueba repetible con un dispositivo nuevo. Después de una actualización, ejecute la misma prueba antes de las horas punta de actividad, 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 informen en recepción. La recomendación final es sencilla. Trabaje desde el estado de invitado hasta la redirección, desde la redirección hasta 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 mantener una suposición de un controlador antiguo. Mantenga el filtrado DNS en la investigación, pero solo como una ruta medible que probar. Con este enfoque, puede restablecer la experiencia del invitado sin debilitar la red ni reconstruir un despliegue que no era el problema. PARTE 3 Unas pocas preguntas rápidas para terminar. ¿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 distintas. Confirme que el SSID o la red afectada tiene 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 del invitado 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 por defecto. Trate la capa DNS como una dependencia comprobable. Registre el sistema de resolución de invitados, pruebe la resolución y la ruta DNS aprobada y, a continuación, compare las pruebas antes de cambiar una política de filtrado. ¿Por qué puede aparecer la página de inicio de sesión pero fallar el acceso? Porque la fase de redirección y la fase de autorización son diferentes. Compruebe 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 paso siguiente más práctico es registrar 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 un intervalo importante de llegadas al hotel. Si una fase falla, escale la incidencia con esa evidencia en lugar de un informe genérico de que el WiFi para invitados ha dejado de funcionar. Esto permite que el equipo adecuado se dirija al límite de fallo correcto más rápidamente.

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

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

Un Captive Portal UniFi suele dejar de redirigir porque el SSID ya no es un Hotspot activo, el usuario invitado no se encuentra en estado no autorizado, las rutas de preautorización requeridas no logran llegar al servicio externo o el portal no consigue comunicar la autorización a UniFi. Verifica estos pasos exactamente en este orden 1 2 3.

¿Qué condiciones deben cumplirse para que se produzca la redirección de invitados de UniFi?

Esta es una guía para la resolución de problemas de una configuración que antes funcionaba. No se te pedirá que reconstruyas tu red WiFi de invitados desde cero. Por el contrario, la guía avanza desde el dispositivo invitado hacia el controlador, para luego regresar 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 qué paso ha fallado realmente.

Ubiquiti define un Hotspot como la funcionalidad que se puede aplicar a un SSID WiFi o a una red o VLAN completa. El Captive Portal se habilita después dentro de esa configuración de Hotspot. En consecuencia, 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 redirección esté activo. Si la interfaz de usuario de la aplicación UniFi Network ha cambiado después de una actualización, confirma el estado actual de Hotspot y 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 de usuario preciso. 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 redirige 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 UniFi y, a continuación, solicita la autorización a través de la API Network. Un flujo completado correctamente se traduce en authorised: true. 2

Qué observas en un nuevo dispositivo Límite a examinar primero Pruebas a recopilar Siguiente acción segura
El dispositivo se conecta, pero nunca entra en el estado de invitado no autorizado Activación del Hotspot SSID o asignación de red y estado del cliente Restablece la configuración planificada de Hotspot y Captive Portal, y luego vuelve a realizar la prueba. 1 2
El dispositivo no está autorizado, pero no aparece ninguna página de inicio de sesión externa Redirección y ruta de preautorización Resultado de la solicitud del navegador, política de invitados y ruta DNS Verifique las rutas de enrutamiento de preautorización requeridas comparándolas con las directrices actuales del proveedor del portal. 3
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ísle la ruta de los invitados hacia el servicio externo antes de cambiar los ajustes 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 Verifique si el servicio externo es capaz de autorizar exactamente a ese cliente y si UniFi informa authorised: true. 2

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

La regla de diagnóstico: no considere la condición "conectado al WiFi" como la condición de éxito. La condición de éxito es un cliente de prueba no autorizado que llega al servicio de inicio de sesión previsto, completa su proceso, muestra authorised: true y luego recibe el acceso previsto. 2

¿Qué necesita antes de comenzar el aislamiento de fallos?

Utilice un dispositivo de prueba nuevo y no autorizado. Un dispositivo ya autorizado es una mala herramienta de diagnóstico porque podría omitir el paso que necesita examinar. Registre 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 un probe al conectarse por primera vez a una red para detectar la interceptació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 pasarela no pueda redirigir una solicitud normal del navegador. 4

Mantenga la prueba acotada. No comience agregando reglas de acceso amplias para los invitados. No elimine una integración que funcione. No copie 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 varias ubicaciones, realice 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 del controlador compartido.

Per una distribuzione Purple, tieni aperto l'articolo corrente UniFi Integration: Best Practices & Common Questions durante il test. Purple utilizza un login API diretto del controller anziché un canale di autenticazione in background RADIUS. L'account API dedicato deve quindi essere locale rispetto al controller, avere diritti di scrittura come amministratore, avere il 2FA disabilitato e non richiedere la modifica della password. Purple documenta anche diversi requisiti di posizionamento dell'account per le console hardware e per il UniFi OS Server self-hosted. 3

Come si isola il passaggio non riuscito?

Inizia dal livello di accesso. Conferma che lo SSID WiFi interessato, o la relativa configurazione dell'intera rete, sia ancora impostato come Hotspot con Captive Portal abilitato. Ubiquiti documenta l'attuale percorso WiFi-SSID e documenta separatamente un percorso Hotspot Zone per una configurazione dell'intera rete o VLAN. Questa distinzione è la risposta alla comune confusione UniFi guest network vs hotspot. Una rete ospite isolata può essere il segmento corretto e non riuscire comunque ad avviare il flusso di lavoro di accesso se la funzione Hotspot non è attiva. 1 Successivamente, ispeziona il client appena connesso. Devi verificare lo stato non autorizzato documentato, non una semplice associazione wireless. Se lo stato non è presente, torna alla configurazione del Hotspot e al SSID o alla rete selezionata. Non procedere con il DNS, un provider esterno o un'integrazione UDM Pro finché questa fase non è corretta. Un servizio esterno non può autorizzare un ospite che non è mai entrato nel flusso dell'Hotspot esterno. 2

Quindi attiva una normale richiesta web dallo stesso dispositivo. Se la richiesta raggiunge il servizio esterno, conserva il risultato come prova. In caso contrario, concentrati sul percorso di pre-autorizzazione del segmento ospiti. Purple connette gli ospiti solo al completamento del loro processo esterno, e le sue linee guida di supporto associano una schermata vuota dopo l'invio del modulo a regole per gli ospiti che bloccano il traffico web nascosto necessario per completare l'accesso. Verifica l'ACL di Pre-Auth e le impostazioni di post-autorizzazione. Dichiara i percorsi di instradamento di destinazione essenziali tratti dalla documentazione corrente del provider. 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 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

Le linee guida di supporto di Purple identificano inoltre la raggiungibilità del controller come un confine separato. Se il servizio esterno non riesce a raggiungere il tuo controller al suo indirizzo pubblico stabile o FQDN attraverso il percorso approvato del firewall, l'autorizzazione non può essere completata. Verifica l'indirizzo registrato per l'integrazione, il relativo percorso in entrata e le regole di consenso approvate dal provider. Segui l'articolo di supporto per i passaggi di implementazione correnti e appropriati per la versione, anziché riprodurre i valori di connessione in una checklist locale. 3

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

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

Cosa va storto e come risolvere il problema?

La rete ospite è isolata, ma la pagina di accesso non si avvia mai

Gestisci questo problema come una verifica dello stato dell'Hotspot prima di un incidente DNS. Conferma se l'SSID WiFi o la rete interessata ha la funzione Hotspot e Captive Portal abilitata. Ubiquiti separa esplicitamente una configurazione Hotspot solo WiFi da una configurazione dell'intera rete o VLAN. Ripristina la configurazione desiderata, riconnetti un nuovo dispositivo e conferma che UniFi registri ora un ospite non autorizzato prima di testare qualsiasi collegamento esterno. 1 2

Il reindirizzamento fallisce prima che la pagina esterna venga caricata

Gestisci questo problema come un test del percorso di pre-autorizzazione. Acquisisce il resolver DNS del dispositivo ospite, il risultato della risoluzione di destinazione e l'esito del browser. Successivamente, confronta le regole degli ospiti con i requisiti attuali del provider del portale. Le linee guida di Purple sono specifiche: quando un ospite visualizza una schermata vuota dopo l'invio del modulo, le impostazioni della Pre-Auth ACL o di post-autorizzazione potrebbero bloccare il traffico necessario per completare il processo. Non sostituire una policy di pre-autorizzazione mirata con un ampio accesso internet per gli ospiti. 3

La pagina esterna si carica, ma l'ospite rimane offline

Questo è un limite di autorizzazione. Convalida l'identità del client nell'evento del provider, la richiesta del provider a UniFi e lo stato finale del client del controller. Il flusso esterno di Ubiquiti distingue il reindirizzamento dalla successiva azione di autorizzazione tramite API. Il caricamento di una pagina dimostra che la prima fase è avvenuta, ma non prova che il client sia stato successivamente contrassegnato come autorizzato. 2

Un aggiornamento di UniFi Network o di UDM ha modificato il percorso previsto

No asuma che una configuración heredada del controlador siga coincidiendo con la integración actual. Purple distingue un despliegue moderno 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 autohospedado. Verifique de nuevo 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 de nuevo la prueba con un nuevo dispositivo. 3

¿Pueden Pi-hole o el filtrado DNS ascendente bloquear el punto de acceso de UniFi?

Puede formar parte del análisis, pero no debería ser la conclusión sin pruebas. Las fuentes principales aprobadas no establecen que Pi-hole sea la causa de un error de redirección de UniFi. Trate el DNS como una ruta medible. Confirme el resolver proporcionado al segmento de invitados, compruebe si la dirección del servicio externo se resuelve, pruebe la ruta DNS aprobada bajo el control de cambios y compare los resultados. La sonda 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 periodo de mayor actividad?

Utilice una verificación de lanzamiento repetible. Debería seguir la misma ruta que un invitado real, no una simple comprobación de conectividad únicamente del controlador. En primer lugar, desasocie la red o utilice un nuevo dispositivo de prueba. En segundo lugar, conéctese al SSID afectado. En tercer lugar, confirme que el cliente no está autorizado. En cuarto lugar, inicie una solicitud web normal. En quinto lugar, confirme que el servicio externo recibe la redirección. En sexto lugar, complete el proceso de inicio de sesión aprobado. En séptimo lugar, confirme el estado authorised: true y pruebe el acceso normal. 2

Realice la verificación antes de las llegadas de mayor actividad en un establecimiento del sector Hospitality, antes de un periodo de campaña en el 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: resultado positivo o negativo en cada paso, tipo de dispositivo, clasificación del controlador y cualquier modificación aplicada. Esto es mucho más útil que un aviso genérico de "WiFi de invitados no disponible".

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

Un hotel de 200 habitaciones informa de que los huéspedes se conectan al SSID de la marca pero ven una página de inicio de sesión vacía. 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 consiga el acceso previsto. 2 3

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

Un equipo de retail informa de que los compradores se conectan a un SSID aislado pero nunca ven la página de inicio de sesión tras un cambio de controlador. El ingeniero no empieza por el DNS. Confirma que el SSID está aislado y, a continuación, 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 la autorización externa en un palacio de congresos

La página de inicio de sesión de un palacio de congresos se carga y acepta el formulario de invitado, pero los asistentes siguen sin conexión. El equipo registra la dirección MAC del cliente y comprueba el evento del proveedor externo para el redireccionamiento. A continuación, 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 comprueban la cuenta API local, los derechos de escritura, la configuración 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 supervisar la experiencia posterior al restablecimiento. Para consultar controles operativos relacionados, 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 red correspondiente tenga 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 introducir 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 asocia las 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 contrastándolas con la documentación actual de su proveedor. No copie una lista de dominios de otro sitio ni añada un 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 distingue además las integraciones de red UniFi actuales de las implementaciones con controladores autónomos legacy, con directrices diferentes para las cuentas de consolas de hardware y UniFi OS Server autohospedado. Realice de nuevo la 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?

Que se cargue la página 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 disponga de permisos de escritura, no tenga habilitada la 2FA y no presente cambios obligatorios de contraseña. 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 principal probada para UniFi. Pruebe el resolver real del segmento de invitados, la resolución de destino y la ruta 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 un sondeo 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 documentato 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. Localice el paso fallido con un nuevo dispositivo de prueba antes de considerar una sustitución de hardware. 1 2

Referencias

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é activo pero un dispositivo nuevo no llegue a iniciar el flujo de inicio de sesión.

Guest network

Una red o VLAN utilizada para separar el tráfico de invitados de otros tráficos de red. No constituye, por sí misma, prueba de que haya un Captive Portal activo.

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

Hotspot

La función de UniFi aplicable a un SSID de WiFi o a toda una red o VLAN, que sirve de base para el control del Captive Portal. [1]

Verifíquelo en primer lugar cuando ningún dispositivo nuevo reciba una redirección.

Unauthorised client state

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

Esta es la primera confirmación en el controlador de que se debe poner a prueba la ruta de redirección externa.

Pre-Auth ACL

El área de control de acceso de UniFi que se utiliza 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 derivación al inicio de sesión cargue una página en blanco o incompleta.

External portal server

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

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

Controller API account

Una cuenta dedicada que utiliza una integración para autenticarse en el controlador 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 interactivos. [3]

Revísela cuando el servicio externo logre comunicarse con el controlador pero no pueda aprobar al invitado.

Authorised true

El estado del cliente que se devuelve una vez completado el proceso documentado de autorización externa. [2]

Utilícelo como un punto de finalización medible antes de declarar resuelto el incidente.

DNS path

La ruta de resolución de nombres y del servidor de resolución proporcionada al segmento de invitados antes de que se apruebe el acceso.

Póngala a prueba como una dependencia controlada cuando el destino del servicio externo no se resuelva o no se cargue desde el segmento de invitados afectado.

Ejemplos prácticos

Incidente típico en hoteles: los huéspedes se conectan al SSID corporativo, pero la pantalla de inicio de sesión aparece en blanco.

Utilice un dispositivo nuevo para confirmar el estado de invitado no autorizado. Si este estado se confirma pero el proceso de inicio de sesión no se completa, compare la ruta de preautorización real del invitado con los requisitos actuales del proveedor externo, valide la ruta de DNS asignada y vuelva a probar. La condición de aceptación es que el inicio de sesión se complete con éxito, el estado figure como autorizado en UniFi y el acceso funcione como se espera. [2] [3]

Incidente típico en tiendas: los clientes se conectan tras un cambio en el controlador, pero no aparece la página de inicio de sesión.

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

Incidente típico en centros 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, identificó la coincidencia con dicho cliente, envió la solicitud de autorización y que UniFi muestra el estado de autorizado como verdadero. Para Purple, revise la cuenta de la API local, los permisos de escritura, la autenticación de doble factor, 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 splash de Cisco Meraki no funciona: diagrama de flujo para la resolución de problemas

Esta guía práctica de mantenimiento aísla el punto exacto donde ha fallado un flujo de splash de Cisco Meraki: autorización del cliente, inicio de redirección HTTP, accesibilidad del walled garden o inicio de sesión RADIUS. Proporciona a los equipos de TI de los establecimientos una ruta de pruebas controlada para restablecer el WiFi de invitados sin realizar cambios drásticos en una red en producción.

Leer la guía →

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

Esta guía técnica muestra a los equipos de TI cómo configurar el WiFi de invitados como un servicio controlado de acceso a internet, mediante segmentación por 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 admiten una experiencia de visitante proporcionada sin debilitar el límite en torno a los sistemas de personal, pago y operativos.

Leer la guía →

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

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

Leer la guía →

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

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