Vai al contenuto principale

Ubiquiti UniFi guest portal not redirecting: cause e soluzioni

Questa guida isola un errore di reindirizzamento del portale ospiti UniFi analizzando in sequenza lo stato dell'ospite, il reindirizzamento, la rotta di pre-autorizzazione e l'autorizzazione del controller. Fornisce ai team IT delle sedi un metodo collaudato per affrontare la confusione tra rete ospiti e Hotspot, i passaggi ai portali esterni, i requisiti attuali dell'account UniFi OS e i test di isolamento DNS.

By Marketing TeamPublished
📖 12 minuti di lettura3,061 parole3 esempi pratici9 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast
PARTE 1 Se il tuo portale ospiti UniFi ha smesso di reindirizzare, non iniziare ricostruendo l'SSID. Inizia individuando l'interruzione nel passaggio di consegne. Un Captive Portal esterno funzionante dipende da quattro azioni in sequenza: l'ospite si collega all'SSID, UniFi tratta il dispositivo come un ospite Hotspot non autorizzato, il reindirizzamento raggiunge il servizio esterno e tale servizio cambia lo stato del client in autorizzato. Un solo passaggio fallito lascia l'ospite connesso ma offline. Per un hotel, un'attività di vendita al dettaglio, uno stadio o un centro congressi, questo rappresenta un incidente operativo. La rete WiFi potrebbe continuare a trasmettere. Gli access point potrebbero risultare attivi e funzionanti. Gli ospiti potrebbero ricevere un indirizzo IP e apparire connessi. Niente di tutto ciò prova che l'accesso tramite Captive Portal stia funzionando. La prima distinzione da fare è tra una rete ospiti e un Hotspot. Una VLAN ospiti o un SSID isolato forniscono la segmentazione. Un Hotspot aggiunge lo stato di controllo degli accessi e, quando abilitato, il Captive Portal. La documentazione Ubiquiti indica che un Hotspot può essere applicato a un SSID WiFi o a un'intera rete o VLAN. Per un SSID, verifica la configurazione WiFi, dove l'Hotspot Portal e il Captive Portal devono essere abilitati. Se l'interfaccia è cambiata dopo un aggiornamento dell'applicazione, utilizza la documentazione aggiornata del fornitore anziché un vecchio screenshot. Utilizza un nuovo dispositivo ospite per il primo test controllato. Un telefono precedentemente autorizzato può far sembrare funzionante un percorso interrotto, mentre il comportamento del portale memorizzato nella cache può far sembrare interrotto un percorso funzionante. Connettiti all'SSID interessato e controlla lo stato del client in UniFi. Nel flusso di autorizzazione esterno documentato da Ubiquiti, un dispositivo che si connette a un SSID con Hotspot e Captive Portal abilitati inizia come ospite con lo stato autorizzato impostato su falso. Questo è il punto di partenza. Se questo stato non è presente, non stai ancora testando il flusso di lavoro del portale. Ora avvia una normale richiesta web da quel dispositivo non autorizzato. Il flusso esterno previsto reindirizza la richiesta al server del portale esterno. Questo divide chiaramente l'incidente. Se non si verifica alcun reindirizzamento, torna alla configurazione dell'Hotspot, allo stato del client e all'accesso di pre-autorizzazione. Se il reindirizzamento appare ma la pagina non si carica, concentrati sul percorso dal segmento ospiti al servizio esterno. Se la pagina si carica ma l'ospite rimane offline dopo l'invio, concentrati sull'autorizzazione di ritorno verso il controller. Questo è il momento di essere precisi riguardo alla lista di accesso consentito prima dell'autorizzazione. Non si tratta di una copia dei siti web che l'ospite dovrebbe navigare dopo essersi connesso. È l'insieme controllato di percorsi di instradamento che devono rimanere raggiungibili prima dell'autorizzazione. Le linee guida UniFi di Purple collegano le schermate vuote dopo il completamento del modulo a regole per gli ospiti che bloccano il traffico necessario per completare il processo di login. Esamina l'ACL di Pre-Auth e le impostazioni di post-autorizzazione, quindi dichiara i percorsi di instradamento di destinazione essenziali. Non inventare un elenco statico da una vecchia implementazione. Utilizza le linee guida di supporto correnti del fornitore del portale. Per una distribuzione Purple, l'integrazione utilizza il login tramite API del controller anziché un canale di autenticazione in background RADIUS. Purple deve raggiungere il controller, autenticarsi con l'account dedicato e ricevere l'autorizzazione per approvare l'ospite. Le linee guida di Purple indicano che l'account deve essere locale al controller, avere diritti di scrittura amministratore, avere l'autenticazione a due fattori disabilitata e non essere forzato a cambiare la password. Un account di sola lettura può autenticarsi ma non può completare l'autorizzazione dell'ospite. Una richiesta interattiva non può completare una richiesta automatizzata. Questo è importante quando una sede passa al sistema operativo UniFi OS attuale. Purple distingue l'attuale UniFi Network dal vecchio modello di controller autonomo. Su un parco macchine con console hardware, crea l'account di integrazione nel dashboard principale di UniFi OS, non solo all'interno dell'applicazione Network. Per i server UniFi OS auto-ospitati, Purple afferma che l'account deve esistere al livello del container root del sistema operativo, in modo che il proxy front-end possa convalidarlo prima di instradarlo verso Network. Se una distribuzione precedentemente funzionante è stata aggiornata, verifica questa identità e il limite di classificazione del controller prima di modificare il design WiFi. Per un'indagine su UDM Pro, segui la stessa disciplina. Verifica l'indirizzo del controller esterno o il nome stabile, il percorso del firewall, la classificazione del controller nel servizio esterno e l'account amministratore locale dell'API. Non dare per scontato che un percorso legacy del controller sia ancora valido solo perché lo era per una vecchia integrazione. Prima di procedere, soffermati sul passaggio del portale. La documentazione Ubiquiti indica che un reindirizzamento riuscito fornisce al portale esterno l'indirizzo MAC dell'access point, l'indirizzo MAC del client, la destinazione originale e l'SSID. Il servizio esterno utilizza il MAC del client per individuare l'oggetto client, ottiene l'ID del client e invia una richiesta di autorizzazione all'API di UniFi Network. Una volta completata con successo, lo stato del client diventa autorizzato. I tre controlli dei log da effettuare sono: il reindirizzamento ha raggiunto il provider? Il provider ha riconosciuto il client? L'autorizzazione ha restituito "authorised true"? PARTE 2 La successiva causa sospetta è il DNS. Questo è il punto in cui i team possono perdere una giornata dichiarando che Pi-hole, il DNS sicuro o un filtro a monte hanno interrotto UniFi. La documentazione principale non dimostra che un particolare prodotto DNS sia la causa di un errore di reindirizzamento UniFi, quindi consideralo come un test di isolamento, non come un verdetto. Conferma quale resolver riceve il segmento ospiti interessato. Conferma che la destinazione del portale esterno si risolva e che la policy di pre-autorizzazione consenta la rotta. Successivamente, testa il percorso DNS approvato sotto controllo delle modifiche. Se il reindirizzamento viene ripristinato, confronta le risposte DNS e le decisioni sulle policy prima di apportare una modifica permanente. Un Captive Portal comprende sia un piano di controllo di rete che un'esperienza utente sul dispositivo. Apple documenta che iOS e macOS inviano un probe quando si connettono a una rete per rilevare l'intercettazione del captive e mostrare la pagina di accesso. La mancata comparsa della finestra automatica, pertanto, non dimostra che UniFi non sia in grado di reindirizzare la richiesta di un browser. Registra il dispositivo, il sistema operativo, se si tratta di una nuova sessione e il risultato di una normale richiesta web. Questo permette di distinguere un problema di rilevamento del dispositivo da un problema di reindirizzamento di rete. Il flusso di lavoro efficiente per la gestione degli incidenti segue un ordine fisso. Primo, conferma che Hotspot e Captive Portal siano abilitati sull'SSID o sulla rete interessata. Secondo, conferma che il client sia entrato nello stato di ospite non autorizzato. Terzo, verifica se il reindirizzamento raggiunge il portale esterno. Quarto, convalida i percorsi di pre-autorizzazione e la rotta DNS effettivamente utilizzata dall'ospite. Quinto, ispeziona la risposta del provider e il tentativo di autorizzazione. Sesto, conferma che il controller segnali lo stato di autorizzato. Infine, testa il normale accesso a internet e cancella la sessione prima di ripetere il test. Il caso di un hotel dimostra perché questa sequenza sia fondamentale. Immagina una struttura da 200 camere in cui gli ospiti si connettono al WiFi aziendale, ma la pagina di accesso esterna appare vuota. La reception vede l'SSID e conclude che il WiFi è disponibile. Il team di rete inizia il test con un telefono appena connesso. Il dispositivo non è autorizzato, quindi lo stato Hotspot è attivo. Tenta di caricare la pagina di accesso ma non riesce a completare l'operazione. Il team verifica i requisiti di pre-autorizzazione confrontandoli con la documentazione aggiornata del provider, convalida la risoluzione DNS dall'effettivo segmento ospiti e ripete il test. Il risultato è misurabile: il dispositivo raggiunge la pagina, invia i dati, viene autorizzato e accede a internet. Prendiamo ora il caso di una catena di negozi dopo l'aggiornamento di un controller. I team dei negozi segnalano che i clienti si connettono ma non visualizzano mai la pagina di accesso. Un tecnico scopre che l'SSID è isolato ma non ha le funzioni Hotspot e Captive Portal abilitate nel layout UniFi corrente. La correzione non consiste nell'allentare le regole del firewall per gli ospiti, bensì nel ripristinare la configurazione Hotspot prevista e verificare lo stato non autorizzato. Questo è un caso rappresentativo, non una valutazione su ogni singolo rilascio di UniFi. Verifica la tua infrastruttura consultando la guida di Ubiquiti. Per uno stadio o un centro congressi che utilizza un provider esterno, è comune un altro sintomo. La pagina di accesso si carica e accetta il modulo, ma i visitatori rimangono offline. In questo caso, il reindirizzamento e il percorso di pre-autorizzazione hanno funzionato. Controlla la transazione di autorizzazione esterna. Conferma che il provider abbia ricevuto i parametri di reindirizzamento, identificato il client, contattato il controller e che il client sia passato allo stato autorizzato. Per Purple, verifica l'account API locale, i privilegi di scrittura, l'autenticazione a due fattori, le impostazioni di modifica password, l'accessibilità pubblica e la classificazione del controller. Questo trasforma un reclamo generico in una catena di prove su cui il tuo team interno, il tuo MSP e il tuo provider possono lavorare insieme in modo coordinato. Evita diversi schemi di errore. Non consentire una regola generica per gli ospiti solo per far apparire la pagina. Può oscurare il punto di controllo e andare in conflitto con il tuo design di segmentazione. Non copiare un elenco di pre-autorizzazione da un'altra sede. Non testare solo con un dispositivo già autorizzato. Non classificare ogni pop-up mancante come un problema di DNS. E non modificare le credenziali esterne senza verificare se un aggiornamento dell'applicazione, un ruolo dell'account o una classificazione del controller hanno modificato il percorso di integrazione. Per i gestori delle sedi, il verbale di consegna deve essere breve ma completo. Memorizza l'SSID o il nome della rete corrente, il fornitore del portale, il tipo di controller, il proprietario dell'account API esterno, i requisiti di pre-autorizzazione approvati, il percorso DNS e un test ripetibile con un dispositivo nuovo. Dopo un aggiornamento, esegui lo stesso test prima delle ore di punta, di un giorno di partita o di una conferenza importante. Questo ti consente di rilevare un percorso di autorizzazione interrotto prima che gli ospiti lo segnalino alla reception. La raccomandazione finale è semplice. Lavora dallo stato dell'ospite al reindirizzamento, dal reindirizzamento al servizio esterno e dal servizio esterno di nuovo all'autorizzazione del controller. Questa sequenza corrisponde al flusso esterno di Hotspot documentato da Ubiquiti. Utilizza l'articolo di supporto UniFi di Purple per i requisiti di integrazione correnti anziché mantenere una vecchia configurazione del controller. Includi il filtraggio DNS nell'indagine, ma solo come percorso misurabile da testare. Con questo approccio, puoi ripristinare l'esperienza degli ospiti senza indebolire la rete o ricostruire una distribuzione che non era il problema. PARTE 3 Alcune domande rapide per concludere. Una rete ospiti mostra automaticamente una pagina di accesso? No. La segmentazione e un Captive Portal Hotspot sono controlli separati. Conferma che l'SSID o la rete interessata abbiano la funzione Hotspot e Captive Portal abilitata. Cosa deve essere incluso in una lista di pre-autorizzazione consentita? Solo i percorsi essenziali necessari per completare il processo di accesso degli ospiti scelto prima dell'autorizzazione. Prendi l'elenco aggiornato dal fornitore del portale e convalidalo dal segmento ospiti effettivo. Pi-hole interrompe un hotspot UniFi? Non darlo per scontato. Tratta il livello DNS come una dipendenza testabile. Registra il risolutore ospite, testa la risoluzione e il percorso DNS approvato, quindi confronta le prove prima di modificare una politica di filtro. Perché la pagina di accesso può apparire ma l'accesso fallisce comunque? Perché la fase di reindirizzamento e la fase di autorizzazione sono diverse. Verifica che il servizio esterno abbia riconosciuto il client e che il controller UniFi abbia registrato lo stato autorizzato come vero. Qual è il test sicuro più rapido dopo un aggiornamento del controller? Utilizza un dispositivo nuovo. Conferma lo stato di ospite non autorizzato, apri una normale richiesta web, completa l'accesso, conferma lo stato autorizzato e quindi conferma l'accesso a internet. Per Purple, includi in questo test l'account API locale dedicato e la classificazione corrente del controller. Il passo successivo più pratico consiste nel conservare questa sequenza nel manuale operativo della tua sede. Testa lo stato dell'ospite, il reindirizzamento, il percorso di pre-autorizzazione, la risposta del provider esterno e l'autorizzazione del controller in questo preciso ordine. Registra il risultato prima di un evento, di un periodo di picco delle vendite o di una finestra temporale di arrivi significativi in hotel. Se una fase fallisce, scala il problema presentando queste prove concrete anziché un report generico in cui si segnala semplicemente che il WiFi per gli ospiti ha smesso di funzionare. Questo consente di indirizzare tempestivamente il team corretto verso la specifica area del guasto.

Parte della nostra serie principale: Guida al Captive Portal

Ubiquiti UniFi guest portal not redirecting: cause e soluzioni

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

Ubiquiti UniFi guest portal not redirecting: cause e soluzioni - 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

Ubiquiti UniFi guest portal not redirecting: cause e soluzioni - 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

Hai domande sulla tua configurazione specifica?

Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.

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

Definizioni chiave

Captive Portal

La funzione di accesso Hotspot che controlla l'accesso di un ospite prima dell'approvazione. In UniFi, viene abilitata all'interno di una configurazione Hotspot. [1]

Verificare questo elemento quando l'SSID ospite è presente ma un nuovo dispositivo non avvia mai il flusso di accesso.

Rete ospiti

Una rete o VLAN utilizzata per separare il traffico degli ospiti da altro traffico di rete. Non è, di per sé, una prova che un Captive Portal sia attivo.

Utilizzare questa distinzione per evitare di confondere l'isolamento con il flusso di lavoro di accesso esterno.

Hotspot

La funzionalità UniFi che può essere applicata a un SSID WiFi o a un'intera rete o VLAN e costituisce la base per il controllo del Captive Portal. [1]

Verificare prima questo elemento quando nessun nuovo ospite riceve un reindirizzamento.

Stato del client non autorizzato

Lo stato iniziale nel flusso Hotspot esterno documentato da Ubiquiti, in cui l'ospite è contrassegnato con autorizzazione impostata su false. [2]

Questa è la prima conferma lato controller che il percorso di reindirizzamento esterno dovrebbe essere sottoposto a test.

Pre-Auth ACL

L'area di controllo degli accessi di UniFi utilizzata per dichiarare le rotte necessarie prima che un ospite completi il processo di accesso. [3]

Verificare questo elemento quando l'invio di un modulo o il passaggio all'accesso porta a una pagina vuota o incompleta.

Server del portale esterno

Un servizio di terze parti che riceve il reindirizzamento UniFi e può autorizzare l'ospite tramite l'API di rete. [2]

È il confine da ispezionare quando un ospite raggiunge il servizio di accesso ma non ottiene l'abilitazione.

Account API del controller

Un account dedicato utilizzato da un'integrazione per autenticarsi nel controller UniFi e modificare lo stato di accesso degli ospiti. Purple richiede un account locale con diritti di scrittura e senza richiesta di autenticazione interattiva. [3]

Verificare questo elemento quando il servizio esterno raggiunge il controller ma non può approvare l'ospite.

Autorizzato true

Lo stato del client restituito dopo il completamento del processo di autorizzazione esterna documentato. [2]

Utilizzare questo stato come punto di completamento misurabile prima di dichiarare risolto l'incidente.

Percorso DNS

Il risolutore e la rotta di risoluzione dei nomi forniti al segmento ospite prima che l'accesso venga approvato.

Testare questo elemento come dipendenza controllata quando la destinazione del servizio esterno non si risolve o non si carica dal segmento ospite interessato.

Esempi pratici

Caso rappresentativo in un hotel: gli ospiti si collegano all'SSID personalizzato, ma la schermata di accesso rimane vuota.

Utilizzare un nuovo dispositivo per verificare lo stato di ospite non autorizzato. Se lo stato è presente ma il processo di accesso non si completa, confrontare il percorso effettivo di pre-autorizzazione dell'ospite con i requisiti attuali del provider esterno, convalidare il percorso DNS assegnato e riprovare. La condizione di accettazione è un accesso completato, lo stato autorizzato impostato su true in UniFi e l'accesso previsto funzionante. [2] [3]

Caso rappresentativo in un negozio: i clienti si connettono dopo una modifica al controller, ma non appare alcuna pagina di accesso.

Confermare che l'SSID rimanga un Hotspot con Captive Portal abilitato nella configurazione attuale di UniFi. Verificare che il nuovo dispositivo entri nello stato non autorizzato prima di diagnosticare problemi legati al DNS o al provider. La condizione di accettazione è un evento di reindirizzamento seguito dal completamento dell'autorizzazione del controller. [1] [2]

Caso rappresentativo in un centro congressi: il modulo esterno viene inviato, ma i partecipanti rimangono offline.

Tracciare la transazione di autorizzazione. Confermare che il provider esterno abbia ricevuto l'identità del client, associato tale client, inviato la richiesta di autorizzazione e che UniFi mostri lo stato autorizzato impostato su true. Per Purple, verificare l'account API locale, i permessi di scrittura, la 2FA, l'impostazione di modifica password, la raggiungibilità del controller e la classificazione. [2] [3]

Hai domande sulla tua configurazione specifica?

Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.