Saltar al contenido principal

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

Esta guía aisla un fallo de redirección en el portal de invitados de UniFi mediante el seguimiento secuencial del 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 documentado para abordar la confusión entre la red de invitados y el Hotspot, las transferencias a portales externos, los requisitos actuales de las cuentas de UniFi OS y las pruebas de aislamiento de DNS.

By Marketing TeamPublished
📖 12 min de lectura3,061 palabras3 ejemplos resueltos9 definiciones clave

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 di solito smette di reindirizzare perché l'SSID non è più un Hotspot attivo, l'utente ospite non si trova nello stato non autorizzato, i percorsi di pre-autorizzazione richiesti non riescono a raggiungere il servizio esterno, o il portale non riesce a comunicare l'autorizzazione a UniFi. Verifica questi passaggi esattamente in questo ordine 1 2 3 .

Quali condizioni devono essere soddisfatte affinché avvenga il reindirizzamento ospite UniFi?

Questa è una guida per la risoluzione dei problemi di una configurazione precedentemente funzionante. Non ti verrà chiesto di ricostruire la tua rete WiFi ospiti da zero. Al contrario, la guida procede dal dispositivo ospite verso il controller, per poi tornare indietro attraverso il servizio esterno. Questo ordine previene un errore comune: modificare un SSID, un firewall o un'impostazione DNS prima di sapere quale passaggio ha effettivamente fallito.

Ubiquiti definisce un Hotspot come la funzionalità che può essere applicata a un SSID WiFi o a un'intera rete o VLAN. Il Captive Portal viene poi abilitato all'interno di quella configurazione Hotspot. Di conseguenza, una VLAN ospiti, un SSID ospiti o una policy di isolamento della rete non dimostrano di per sé che il flusso di reindirizzamento sia attivo. Se l'interfaccia utente dell'applicazione UniFi Network è cambiata dopo un aggiornamento, conferma lo stato attuale di Hotspot e Captive Portal seguendo la documentazione ufficiale di Ubiquiti, invece di fare affidamento sulla posizione storica del menu. 1

Per un portale esterno, Ubiquiti descrive un percorso utente preciso. Un dispositivo si connette a un SSID configurato con Hotspot e Captive Portal. Inizia come GUEST con authorised: false. Quando tenta di effettuare una richiesta web, UniFi lo reindirizza al server del portale esterno. Il server riceve i dettagli identificativi del client e dell'access point, ottiene l'ID del client UniFi, quindi richiede l'autorizzazione tramite l'API Network. Un flusso completato correttamente si traduce in authorised: true. 2

Cosa osservi su un nuovo dispositivo Limite da esaminare per primo Prove da raccogliere Prossima azione sicura
Il dispositivo si connette, ma non entra mai nello stato di ospite non autorizzato Attivazione dell'Hotspot SSID o assegnazione di rete e stato del client Ripristina la configurazione pianificata di Hotspot e Captive Portal, quindi esegui nuovamente il test. 1 2
Il dispositivo non è autorizzato, ma non appare alcuna pagina di accesso esterna Reindirizzamento e percorso di pre-autorizzazione Risultato della richiesta del browser, policy ospiti e percorso DNS Verifica i percorsi di instradamento di pre-autorizzazione richiesti confrontandoli con le linee guida attuali del provider del portale. 3
La pagina appare, ma il processo non si completa Raggiungibilità del servizio esterno Esito della richiesta dal segmento ospiti e registro degli eventi lato provider Isola il percorso degli ospiti verso il servizio esterno prima di modificare le impostazioni del controller. 2 3
Il modulo viene completato, ma l'accesso rimane bloccato Autorizzazione del controller Evento di autorizzazione del provider esterno e stato del client UniFi Verifica se il servizio esterno è in grado di autorizzare esattamente quel client e se UniFi segnala authorised: true. 2

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

La regola diagnostica: non considerare la condizione "connesso al WiFi" come la condizione di successo. La condizione di successo è un client di test non autorizzato che raggiunge il servizio di accesso previsto, completa il relativo processo, mostra authorised: true e quindi riceve l'accesso previsto. 2

Di cosa hai bisogno prima di iniziare l'isolamento dei guasti?

Utilizza un dispositivo di test fresco e non autorizzato. Un dispositivo già autorizzato è uno strumento diagnostico scadente perché potrebbe saltare il passaggio che devi esaminare. Registra lo SSID o il nome della rete, l'ora del test, il tipo di dispositivo, il sistema operativo e se il dispositivo visualizza una richiesta di accesso automatica o solo un normale risultato del browser. Apple afferma che iOS e macOS inviano un probe al primo accesso a una rete per rilevare l'intercettazione del Captive Portal e visualizzare una pagina di accesso. Ciò significa che la mancanza di una finestra automatica è un indizio utile, ma non è una prova conclusiva che il gateway non possa reindirizzare una normale richiesta del browser. 4

Tieni il test circoscritto. Non iniziare aggiungendo ampie regole di accesso per gli ospiti. Non eliminare un'integrazione funzionante. Non copiare un elenco di consentiti di pre-autorizzazione da un'altra struttura. È necessario stabilire il percorso effettivo dell'ospite e la fase esatta in cui si interrompe. Se il problema riguarda più sedi, esegui lo stesso test con un dispositivo fresco in ciascuna di esse. Una differenza tra i siti è più utile di una teoria su un aggiornamento del controller condiviso.

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

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

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

Non dare per scontato che una configurazione legacy del controller corrisponda ancora all'integrazione corrente. Purple distingue un moderno deployment UniFi Network da un controller standalone precedente e documenta linee guida separate per la creazione di account per console hardware e UniFi OS Server self-hosted. Verificare nuovamente l'account locale dedicato, la sua autorizzazione di scrittura, lo stato della 2FA, l'impostazione di modifica della password e la classificazione dell'integrazione. Quindi eseguire nuovamente il test con un nuovo dispositivo. 3

Pi-hole o il filtraggio DNS a monte possono bloccare l'hotspot UniFi?

Può far parte dell'analisi, ma non dovrebbe essere la conclusione senza prove. Le fonti primarie approvate non stabiliscono che Pi-hole sia la causa di un errore di reindirizzamento UniFi. Tratta il DNS come un percorso misurabile. Conferma il resolver fornito al segmento guest, verifica se la destinazione del servizio esterno si risolve, testa il percorso DNS approvato sotto controllo delle modifiche e confronta i risultati. Il probe del dispositivo Apple è un altro motivo per registrare sia l'esperienza di accesso automatico sia una normale richiesta del browser. 4

Come si dimostra che la soluzione funziona prima del successivo periodo di punta?

Utilizza una verifica di rilascio ripetibile. Dovrebbe seguire lo stesso percorso di un vero ospite, non un semplice controllo di connettività del solo controller. Per prima cosa, dissocia la rete o utilizza un nuovo dispositivo di test. In secondo luogo, connettiti all'SSID interessato. In terzo luogo, conferma che il client non è autorizzato. In quarto luogo, avvia una normale richiesta web. In quinto luogo, conferma che il servizio esterno riceva il reindirizzamento. In sesto luogo, completa il processo di accesso approvato. In settimo luogo, conferma lo stato authorised: true e testa il normale accesso. 2

Esegui la verifica prima degli arrivi di punta in una struttura del settore Hospitality , prima di un periodo di campagna nel Retail , prima di un evento nei Transport o prima che aumenti la domanda dei visitatori nell' Healthcare . Conserva il risultato come registro operativo: esito positivo o negativo a ogni passaggio, tipo di dispositivo, classificazione del controller ed eventuale modifica applicata. Questo è molto più fruibile rispetto a un generico avviso di "guest WiFi non disponibile".

Scenario di esempio reale: incidente della schermata vuota in un hotel

Un hotel da 200 camere segnala che gli ospiti si collegano all'SSID del brand ma visualizzano una pagina di accesso vuota. L'ingegnere di turno utilizza un nuovo dispositivo e conferma lo stato authorised: false, il che significa che la fase di Hotspot è presente. La pagina inizia a caricarsi ma la transazione non si completa. L'ingegnere confronta i percorsi di pre-autorizzazione guest con le attuali linee guida di supporto del provider, convalida il resolver effettivamente assegnato al segmento guest e ripete il test. La condizione di completamento misurabile è che il dispositivo completi l'accesso, passi a authorised: true e raggiunga l'accesso previsto. 2 3

Scenario di esempio reale: punti vendita retail dopo la modifica del controller

Un team retail segnala che gli acquirenti si connettono a un SSID isolato ma non vedono mai la pagina di accesso dopo una modifica del controller. L'ingegnere non inizia con il DNS. Conferma che il SSID è isolato, quindi verifica se le opzioni Hotspot e Captive Portal sono abilitate nella configurazione UniFi corrente. Dopo aver ripristinato lo stato Hotspot desiderato, riconnette un nuovo dispositivo e verifica lo stato non autorizzato documentato prima di testare il servizio esterno. Il risultato osservabile è un evento di reindirizzamento seguito da uno stato di autorizzazione completato. 1 2

Scenario di esempio reale: guasto dell'autorizzazione esterna in una sede congressuale

La pagina di accesso di una sede congressuale si carica e accetta il modulo ospite, ma i partecipanti rimangono offline. Il team registra l'indirizzo MAC del client e controlla l'evento del provider esterno per il reindirizzamento. Successivamente convalida che il provider abbia riconosciuto lo stesso client, inviato la richiesta di autorizzazione e che UniFi registri authorised: true. Per un'integrazione Purple, verificano anche l'account API locale, i diritti di scrittura, l'impostazione 2FA e la classificazione corrente del controller. Il risultato atteso è una catena di prove tracciabile, non una supposizione sulla causa. 2 3

Una volta chiuso l'incidente, utilizza lo stesso controllo di rilascio nel tuo processo operativo Guest WiFi. La sezione Guest WiFi fornisce il contesto del servizio, mentre WiFi Analytics può aiutare i team operativi a monitorare l'esperienza post-ripristino. Per i controlli operativi adiacenti, consulta Guest WiFi Management: Smart Authentication & Segmentation , Cloud Wifi Management: Secure Enterprise Connectivity 2026 , la guida Cisco Meraki splash page not working: a troubleshooting flowchart e WiFi 7 Venue Deployment: Infrastructure Readiness for Stadiums and Hospitality Sites .

Domande frequenti

Ho bisogno di una VLAN guest e di un UniFi Hotspot per mostrare una pagina di accesso?

No. Ubiquiti documenta un Hotspot sia su un SSID WiFi che su un'intera rete o VLAN. La condizione fondamentale è che il relativo SSID o rete abbia la funzione Hotspot e Captive Portal abilitata. Una VLAN guest isolata è una scelta di segmentazione. Non stabilisce di per sé lo stato di client non autorizzato né avvia un reindirizzamento esterno. 1 2

Cosa dovrebbe essere inserito in una lista di pre-autorizzazione UniFi?

Solo i percorsi necessari per completare il processo di accesso guest selezionato prima dell'approvazione. Purple collega schermate vuote post-modulo a regole guest che bloccano il traffico necessario per completare l'accesso. Verifica l'ACL di pre-autorizzazione e le impostazioni di post-autorizzazione confrontandole con la documentazione attuale del tuo provider. Non copiare un elenco di domini da un altro sito o aggiungere un accesso a internet non protetto solo per caricare la pagina. 3

Perché il portale guest UniFi ha smesso di funzionare dopo un aggiornamento dell'applicazione?

Verifica lo stato dell'Hotspot, la classificazione del controller e l'account di integrazione prima di modificare la rete. La documentazione attuale di Ubiquiti distingue la configurazione dell'Hotspot da una rete guest generale. Purple distingue inoltre le attuali integrazioni di rete UniFi dalle implementazioni con controller autonomi legacy, con linee guida diverse per gli account per console hardware e UniFi OS Server auto-ospitato. Esegui nuovamente il test con un dispositivo pulito dopo ogni correzione. 1 3

Perché un portale esterno si carica sul mio UDM Pro ma non autorizza l'ospite?

Una pagina caricata dimostra la fase di reindirizzamento, non la fase di autorizzazione finale. Verifica che il provider esterno abbia ricevuto l'identità del client, trovato la corrispondenza con il client UniFi, inviato una richiesta di autorizzazione e che il controller mostri authorised: true. Per Purple, verifica anche che l'account locale dedicato disponga dei permessi di scrittura, non abbia la 2FA e non presenti modifiche obbligatorie della password. 2 3

Pi-hole interrompe il reindirizzamento dell'hotspot UniFi?

Non dare per scontato che sia così. Le fonti primarie approvate non identificano Pi-hole come una causa principale comprovata per UniFi. Testa il resolver effettivo del segmento guest, la risoluzione di destinazione e il percorso DNS approvato sotto il controllo delle modifiche. Registra sia la richiesta automatica del dispositivo che il risultato di un normale browser, poiché i dispositivi Apple utilizzano un probe di rete captive quando si connettono. 4

Devo sostituire i miei access point UniFi per risolvere un errore di reindirizzamento?

No, non come prima misura. Il flusso esterno documentato indica una sequenza di passaggi di configurazione e autorizzazione: stato dell'Hotspot, stato del client non autorizzato, reindirizzamento, elaborazione esterna e approvazione del controller. Individua il passaggio non riuscito con un nuovo dispositivo di test prima di considerare una sostituzione hardware. 1 2

Riferimenti

Definiciones clave

Captive Portal

La función de inicio de sesión del 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 que se utiliza para separar el tráfico de los 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 toda una red o VLAN, 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 de Hotspot externo documentado por Ubiquiti, donde el invitado se marca con estado de autorizado "false". [2]

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

ACL de preautenticación

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

Cuenta de la API del controlador

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

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

Autorizado true

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

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

Ruta de DNS

La ruta del sistema de resolución y de resolución de nombres que se proporciona 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 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.

Utilice 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 de autorizado "true" 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 una autorización completada en el controlador. [1] [2]

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

Rastree la transacción de autorización. Confirme que el proveedor externo haya recibido la identidad del cliente, que coincida con ese cliente, que haya enviado la solicitud de autorización y que UniFi muestre el estado de autorizado "true". Para Purple, revise la cuenta local de la API, 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]

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