Saltar para o conteúdo principal

Ubiquiti UniFi guest portal not redirecting: causes and fixes

Este guia isola uma falha de redirecionamento do portal de convidados UniFi ao seguir a sequência do estado do convidado, redirecionamento, rota de pré-autorização e autorização do controlador. Oferece às equipas de TI de locais públicos um método fundamentado para resolver a confusão entre rede de convidados e Hotspot, transições para portais externos, requisitos atuais de conta do UniFi OS e testes de isolamento de DNS.

By Marketing TeamPublished
📖 12 min de leitura3,061 palavras3 exemplos práticos9 definições principais

Ouça este guia

Ver transcrição do podcast
PARTE 1 Se o seu portal de convidados UniFi parou de redirecionar, não comece por reconstruir o SSID. Comece por localizar a falha na entrega. Um portal externo funcional depende de quatro ações em sequência: o convidado adere ao SSID, a UniFi trata o dispositivo como um convidado Hotspot não autorizado, o redirecionamento chega ao serviço externo e esse serviço altera o estado do cliente para autorizado. Uma única falha de entrega deixa o convidado ligado, mas sem acesso à internet. Para um hotel, superfície comercial, estádio ou centro de conferências, isto é um incidente operacional. A rede WiFi pode continuar a transmitir. Os pontos de acesso podem continuar operacionais. Os convidados podem receber um endereço IP e parecer ligados. Nada disso prova que o acesso por Captive Portal está a funcionar. A primeira distinção a fazer é entre uma rede de convidados e um Hotspot. Uma VLAN de convidados ou um SSID isolado fornece segmentação. Um Hotspot adiciona o estado de controlo de acesso e, quando ativado, o Captive Portal. A Ubiquiti documenta que um Hotspot pode ser aplicado a um SSID WiFi ou a uma rede ou VLAN inteira. Para um SSID, verifique a configuração do WiFi, onde o Hotspot Portal e o Captive Portal devem estar ativados. Se a interface mudou de lugar após uma atualização da aplicação, utilize a documentação atual do fabricante em vez de uma captura de ecrã antiga. Utilize um dispositivo de teste limpo para o primeiro teste controlado. Um telemóvel previamente autorizado pode fazer com que um caminho com falhas pareça saudável, enquanto o comportamento do portal em cache pode fazer com que um caminho saudável pareça com falhas. Ligue-se ao SSID afetado e inspecione o estado do cliente no UniFi. No fluxo de autorização externa documentado da Ubiquiti, um dispositivo que se liga a um SSID com Hotspot e Captive Portal ativos começa como um convidado com o estado de autorização definido como falso. Esse é o ponto de partida. Se este estado estiver ausente, ainda não está a testar o fluxo de trabalho do portal. Agora, force um pedido web normal a partir desse dispositivo não autorizado. O fluxo externo esperado redireciona o pedido para o servidor do portal externo. Isto divide o incidente de forma clara. Se não ocorrer nenhum redirecionamento, volte à configuração do Hotspot, ao estado do cliente e ao acesso pré-autorização. Se o redirecionamento aparecer mas a página não carregar, foque-se na rota do segmento de convidados para o serviço externo. Se a página carregar mas o convidado continuar sem acesso após a submissão, foque-se na autorização de regresso ao controlador. Este é o momento de ser preciso com a lista de permissões de pré-autorização. Não se trata de uma cópia dos websites que o convidado deve navegar após aderir. É o conjunto controlado de rotas de encaminhamento que devem permanecer acessíveis antes da autorização. As orientações da Purple para UniFi associam os ecrãs em branco após a conclusão do formulário a regras de convidados que bloqueiam o tráfego necessário para concluir o processo de início de sessão. Reveja a ACL de Pré-Autorização e as definições pós-autorização e, em seguida, declare as rotas de destino essenciais. Não invente uma lista estática baseada numa implementação antiga. Utilize o suporte atual do fornecedor do portal.Para uma implementação Purple, a integração utiliza o início de sessão da API do controlador em vez de um canal de autenticação em segundo plano RADIUS. O Purple precisa de aceder ao controlador, autenticar-se com a conta dedicada e receber autorização para aprovar o convidado. As orientações do Purple indicam que a conta deve ser local ao controlador, ter direitos de escrita de administrador, ter a autenticação de dois fatores desativada e não ser forçada a alterar a sua palavra-passe. Uma conta de leitura pode autenticar-se, mas não consegue concluir a autorização do convidado. Um desafio interativo não consegue concluir um pedido automatizado. Isto é importante quando um local transita para o UniFi OS atual. O Purple distingue o UniFi Network atual do modelo de controlador autónomo mais antigo. Numa infraestrutura de consola física, crie a conta de integração no painel principal do UniFi OS, e não apenas dentro da aplicação Network. Para um UniFi OS Server auto-hospedado, o Purple indica que a conta deve existir na camada de contentor do SO raiz para que o proxy de front-end a possa validar antes do encaminhamento para a Network. Se uma implementação que funcionava anteriormente foi atualizada, verifique esta identidade e o limite de classificação do controlador antes de alterar o design de WiFi. Para uma investigação no UDM Pro, siga a mesma disciplina. Verifique o endereço do controlador externo ou nome estável, o caminho da firewall, a classificação do controlador no serviço externo e a conta de administrador local da API. Não assuma que um caminho de controlador legado ainda se aplica apenas porque uma integração mais antiga o fazia. Antes de prosseguir, faça uma pausa na transferência do portal. A Ubiquiti documenta que um redirecionamento bem-sucedido fornece ao portal externo o endereço MAC do ponto de acesso, o endereço MAC do cliente, o destino original e o SSID. O serviço externo utiliza o MAC do cliente para localizar o objeto do cliente, obtém o ID do cliente e envia um pedido de autorização para a API do UniFi Network. Assim que este processo for bem-sucedido, o estado do cliente passa a autorizado. As suas três verificações de registo são: o redirecionamento chegou ao fornecedor, o fornecedor reconheceu o cliente e a autorização resultou em autorizado verdadeiro? PARTE 2 A causa suspeita seguinte é o DNS. É aqui que as equipas podem perder um dia ao declarar que o Pi-hole, o DNS seguro ou um filtro a montante avariou o UniFi. A documentação principal não prova que um produto de DNS específico seja a causa de uma falha de redirecionamento do UniFi, por isso trate-o como um teste de isolamento e não como um veredito. Confirme qual o resolvedor que o segmento de convidados afetado recebe. Confirme que o destino do portal externo resolve e que a política de pré-autorização permite a rota. Em seguida, teste o caminho de DNS aprovado sob controlo de alterações. Se o redirecionamento voltar, compare as respostas de DNS e as decisões de política antes de efetuar uma alteração permanente. Um Captive Portal possui tanto um plano de controlo de rede como uma experiência de dispositivo. A Apple documenta que o iOS e o macOS enviam uma sonda ao ligarem-se a uma rede para detetar a interceção cativa e exibir a página de início de sessão. A ausência de uma janela automática não prova, portanto, que a UniFi não consiga redirecionar um pedido do navegador. Registe o dispositivo, o sistema operativo, se se trata de uma nova sessão e o resultado de um pedido web normal. Isso separa um problema de deteção do dispositivo de um problema de redirecionamento de rede. O fluxo de trabalho de incidentes eficiente tem uma ordem fixa. Primeiro, confirme o Hotspot e o Captive Portal no SSID ou rede afetada. Segundo, confirme que o cliente entrou no estado de convidado não autorizado. Terceiro, teste se o redirecionamento chega ao portal externo. Quarto, valide os caminhos de pré-autorização e a rota de DNS que o convidado realmente utiliza. Quinto, inspecione a resposta do fornecedor e a tentativa de autorização. Sexto, confirme se o controlador reporta como autorizado. Finalmente, teste o acesso normal à internet e limpe a sessão antes de repetir. O caso de um hotel demonstra por que razão esta sequência é importante. Imagine uma propriedade de 200 quartos onde os hóspedes se ligam ao WiFi de marca, mas a página de início de sessão externa está em branco. A receção vê o SSID e conclui que o WiFi está disponível. A equipa de rede começa com um telemóvel limpo. O dispositivo não está autorizado, pelo que o estado de Hotspot está presente. Este tenta carregar a página de início de sessão, mas não consegue concluir. A equipa analisa os requisitos de pré-autorização face à documentação atual do fornecedor, valida a resolução de DNS a partir do segmento real de convidados e volta a testar. A medida é observável: o dispositivo chega à página, submete-a, fica autorizado e acede à internet. Vejamos agora o caso de uma rede de lojas após uma atualização do controlador. As equipas das lojas reportam que os clientes se ligam mas nunca veem a página de início de sessão. Um engenheiro descobre que o SSID está isolado, mas não tem o Hotspot e o Captive Portal ativos no esquema atual da UniFi. A correção não passa por afrouxar a firewall de convidados. Passa por restaurar a configuração de Hotspot pretendida e testar o estado não autorizado. Este é um caso representativo, não uma afirmação sobre todas as versões da UniFi. Verifique a sua infraestrutura através do guia da Ubiquiti. Para um estádio ou local de conferências com um fornecedor externo, outro sintoma é comum. A página de início de sessão carrega e aceita o formulário, mas os participantes continuam offline. Aqui, o redirecionamento e o caminho de pré-autorização foram superados. Verifique a transação de autorização externa. Confirme se o fornecedor recebeu os parâmetros de redirecionamento, identificou o cliente, contactou o controlador e se o cliente mudou para autorizado. Para a Purple, reveja a conta de API local, os privilégios de escrita, a autenticação de dois fatores, a configuração de alteração de palavra-passe, a acessibilidade pública e a classificação do controlador. Isto transforma uma reclamação vaga numa cadeia de provas que a sua equipa interna, MSP e fornecedor podem analisar em conjunto.Evite vários padrões de falha. Não permita uma regra geral de convidados apenas para fazer a página aparecer. Isso pode ocultar o ponto de controlo e entrar em conflito com o seu design de segmentação. Não copie uma lista de pré-autorização de outro local. Não teste apenas com um dispositivo já autorizado. Não classifique todos os pop-ups em falta como um problema de DNS. E não altere credenciais externas sem verificar se uma atualização de aplicação, função de conta ou classificação de controlador alterou o caminho de integração. Para operadores de locais, o registo de entrega deve ser pequeno mas completo. Armazene o SSID ou nome de rede atual, o fornecedor do portal, o tipo de controlador, o proprietário da conta API externa, os requisitos de pré-autorização aprovados, o caminho de DNS e um teste repetível com dispositivo novo. Após uma atualização, execute o mesmo teste antes do pico de atividade, de um dia de jogo ou de uma grande conferência. Isso permite detetar um caminho de autorização corrompido antes que os convidados o reportem na receção. A recomendação final é simples. Trabalhe a partir do estado do convidado para o redirecionamento, do redirecionamento para o serviço externo e do serviço externo de volta para a autorização do controlador. Essa sequência corresponde ao fluxo de Hotspot externo documentado da Ubiquiti. Utilize o artigo de suporte UniFi da Purple para os requisitos de integração atuais em vez de manter um pressuposto de controlador antigo. Mantenha a filtragem de DNS na investigação, mas apenas como um caminho mensurável a testar. Com esta abordagem, pode restaurar a experiência do convidado sem enfraquecer a rede ou reconstruir uma implementação que não era o problema. PARTE 3 Algumas perguntas rápidas para terminar. Uma rede de convidados mostra automaticamente uma página de início de sessão? Não. A segmentação e um Captive Portal de Hotspot são verificações separadas. Confirme se o SSID ou rede afetada tem a função de Hotspot e Captive Portal ativada. O que pertence a uma lista de permissões de pré-autorização? Apenas as rotas essenciais necessárias para concluir o processo de início de sessão de convidado escolhido antes da autorização. Obtenha essa lista atual junto do fornecedor do portal e valide-a a partir do segmento de convidados real. O Pi-hole corrompe um hotspot UniFi? Não assuma isso. Trate a camada de DNS como uma dependência testável. Registe o resolvedor de convidados, teste a resolução e a rota de DNS aprovada e, em seguida, compare as evidências antes de alterar uma política de filtragem. Por que razão a página de início de sessão pode aparecer mas o acesso continuar a falhar? Porque a fase de redirecionamento e a fase de autorização são diferentes. Verifique se o serviço externo reconheceu o cliente e se o controlador UniFi registou "authorized true" (autorizado como verdadeiro). Qual é o teste seguro mais rápido após uma atualização do controlador? Utilize um dispositivo novo. Confirme o estado de convidado não autorizado, abra um pedido web normal, conclua o início de sessão, confirme o estado autorizado e, em seguida, confirme o acesso à internet. Para a Purple, inclua a conta API local dedicada e a classificação atual do controlador nesse teste.O passo seguinte mais prático é manter esta sequência no manual de procedimentos do seu espaço. Teste o estado do visitante, o redirecionamento, a rota de pré-autorização, a resposta do fornecedor externo e a autorização do controlador, por essa ordem. Registe o resultado antes de um evento, de um período de pico de atividade ou de uma grande janela de chegadas ao hotel. Se uma fase falhar, encaminhe o problema com essa evidência em vez de enviar um relatório genérico a indicar que o WiFi de convidados deixou de funcionar. Isso faz com que a equipa certa chegue ao limite de falha correto mais rapidamente.

Parte da nossa série principal: Guia de Captive Portal

Ubiquiti UniFi guest portal not redirecting: causes and fixes

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: causes and fixes - 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: causes and fixes - 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

Tem dúvidas sobre a sua configuração específica?

A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.

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

Definições Principais

Captive Portal

A função de início de sessão do Hotspot que controla o acesso de um convidado antes da aprovação. No UniFi, é ativada dentro de uma configuração de Hotspot. [1]

Verifique isto quando o SSID de convidados estiver presente mas um dispositivo novo nunca iniciar o fluxo de início de sessão.

Guest network

Uma rede ou VLAN utilizada para separar o tráfego de convidados de outro tráfego de rede. Não constitui, por si só, prova de que um Captive Portal está ativo.

Utilize esta distinção para evitar confundir o isolamento com o fluxo de trabalho de início de sessão externo.

Hotspot

A funcionalidade UniFi que se pode aplicar a um SSID de WiFi ou a uma rede ou VLAN inteira e serve de base para o controlo do Captive Portal. [1]

Verifique isto primeiro quando nenhum convidado novo receber um redirecionamento.

Unauthorised client state

O estado inicial no fluxo de Hotspot externo documentado pela Ubiquiti, onde o convidado é marcado como autorizado "false". [2]

Esta é a primeira confirmação do lado do controlador de que o caminho de redirecionamento externo deve ser testado.

Pre-Auth ACL

A área de controlo de acessos do UniFi utilizada para declarar as rotas necessárias antes de um convidado concluir o processo de início de sessão. [3]

Reveja isto quando a submissão de um formulário ou a transição para o início de sessão resultar numa página em branco ou incompleta.

External portal server

Um serviço de terceiros que recebe o redirecionamento do UniFi e pode autorizar o convidado através da Network API. [2]

É a fronteira a inspecionar quando um convidado acede ao serviço de início de sessão mas não obtém acesso.

Controller API account

Uma conta dedicada utilizada por uma integração para autenticar no controlador UniFi e alterar o estado de acesso do convidado. A Purple exige uma conta local com direitos de escrita e sem desafio de autenticação interativa. [3]

Reveja isto quando o serviço externo alcança o controlador mas não consegue aprovar o convidado.

Authorised true

O estado do cliente devolvido após a conclusão do processo de autorização externo documentado. [2]

Utilize isto como um ponto de conclusão mensurável antes de declarar o incidente como resolvido.

DNS path

O resolvedor e a rota de resolução de nomes fornecidos ao segmento de convidados antes de o acesso ser aprovado.

Teste isto como uma dependência controlada quando o destino do serviço externo não resolve ou não carrega a partir do segmento de convidados afetado.

Exemplos Práticos

Incidente representativo num hotel: os convidados associam-se ao SSID da marca, mas o ecrã de início de sessão está em branco.

Utilize um dispositivo novo para confirmar o estado de convidado não autorizado. Se o estado estiver presente mas o processo de início de sessão não terminar, compare o caminho real de pré-autorização de convidados com os requisitos atuais do fornecedor externo, valide o caminho de DNS atribuído e, em seguida, volte a testar. A condição de aceitação é um início de sessão concluído, com estado de autorizado "true" no UniFi e o acesso esperado. [2] [3]

Incidente representativo no retalho: os clientes ligam-se após uma alteração no controlador, mas não surge nenhuma página de início de sessão.

Confirme se o SSID permanece como um Hotspot com o Captive Portal ativado na configuração atual do UniFi. Verifique se o dispositivo novo entra no estado não autorizado antes de diagnosticar o DNS ou o fornecedor. A condição de aceitação é um evento de redirecionamento seguido da conclusão da autorização do controlador. [1] [2]

Incidente representativo num espaço de conferências: o formulário externo é submetido, mas os participantes continuam offline.

Rastreie a transação de autorização. Confirme se o fornecedor externo recebeu a identidade do cliente, associou esse cliente, enviou o pedido de autorização e se o UniFi mostra autorizado "true". Para a Purple, reveja a conta local de API, permissão de escrita, 2FA, definição de alteração de palavra-passe, acessibilidade do controlador e classificação. [2] [3]

Tem dúvidas sobre a sua configuração específica?

A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.