Resolução de Problemas de Redirecionamento de Captive Portal: Como Resolver Falhas de Ligação no WiFi de Convidados
Quando os convidados se ligam ao seu WiFi mas não conseguem aceder à internet, a causa é quase sempre um redirecionamento de captive portal mal configurado - e não uma falha de hardware. Este guia fornece uma referência técnica aprofundada para gestores de TI, arquitetos de rede e CTOs para diagnosticar e resolver toda a cadeia de falhas: desde sondas de conectividade ao nível do SO e conflitos de certificados HSTS até falhas de autorização RADIUS e esgotamento de DHCP. Mapeia cada modo de falha para uma correção concreta e mostra como o overlay de nuvem independente de hardware da Purple elimina estes problemas em implementações Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.
Video overview
Ouça este guia
Ver transcrição do podcast
Parte da nossa série principal: Guia de Captive Portal →
Resumo executivo
A pesquisa "WiFi de convidados ligado mas sem internet" é um dos pedidos de suporte mais comuns nas redes empresariais. O sintoma é visível para todos os visitantes; a causa é invisível para a maioria das equipas de TI até compreenderem a cadeia de redirecionamento. Um Captive Portal (também designado por página de splash ou gateway de hotspot) intercepta a tentativa inicial de ligação HTTP de um dispositivo e emite um redirecionamento HTTP 302 para uma página de início de sessão. Se qualquer passo dessa cadeia falhar - sondagens bloqueadas, conflitos de HSTS, lacunas no walled garden, falhas de RADIUS ou esgotamento de DHCP - o convidado vê apenas um ícone de WiFi ligado e sem internet. Este guia explica todos os modos de falha, a mecânica do protocolo subjacente e as alterações de configuração que os resolvem. A Purple opera em mais de 80 000 locais ativos, processando 440 milhões de inícios de sessão anualmente (dados internos da Purple, 2024), e os padrões aqui descritos representam as causas raiz mais frequentes que vemos em implementações de hotelaria, retalho, transportes e setor público.
Análise técnica detalhada
Como funciona realmente a deteção de Captive Portal
Todos os principais sistemas operativos incluem um mecanismo integrado para detetar se uma rede requer autenticação antes de conceder acesso à internet. Compreender estes mecanismos é a base de toda a resolução de problemas de Captive Portal.
Quando um dispositivo se associa a um SSID, o OS envia um pedido HTTP GET não encriptado para um URL predefinido. A tabela abaixo lista os URLs de sondagem por plataforma.
| Sistema operativo | URL de sondagem | Resposta esperada |
|---|---|---|
| iOS / macOS | http://captive.apple.com/hotspot-detect.html |
HTTP 200 com corpo específico |
| Android (Google) | http://connectivitycheck.gstatic.com/generate_204 |
HTTP 204 No Content |
| Windows (NCSI) | http://www.msftconnecttest.com/connecttest.txt |
HTTP 200 com o corpo "Microsoft Connect Test" |
| Chrome (todas as plataformas) | http://www.gstatic.com/generate_204 |
HTTP 204 No Content |
| Firefox | http://detectportal.firefox.com/success.txt |
HTTP 200 |
Se o gateway interceptar um destes pedidos e devolver um redirecionamento HTTP 302 a apontar para o URL do Captive Portal, o OS reconhece que está atrás de um portal e abre um pseudonavegador (um WebView leve) para apresentar a página de splash. Se a sondagem for totalmente bloqueada, o OS comunica "Sem ligação à internet" e nunca tenta abrir o portal. Esta é a causa única mais comum do sintoma "WiFi de convidados ligado mas sem internet".
O problema do HSTS
HTTP Strict Transport Security (HSTS) é uma política de segurança web definida no RFC 6797. Esta instrui os navegadores a recusar todas as ligações HTTP simples a um domínio e a rejeitar qualquer certificado que não corresponda exatamente. Os principais domínios, incluindo google.com, facebook.com e a maioria dos sites bancários, estão na lista de pré-carregamento HSTS integrada no Chrome, Firefox, Safari e Edge.
Quando um convidado abre um navegador e escreve google.com, o navegador atualiza o pedido para HTTPS antes de este sair do dispositivo. O gateway não consegue interceptar um pedido HTTPS e redirecioná-lo de forma limpa - teria de apresentar um certificado para google.com, o qual não possui. O navegador deteta a incompatibilidade de certificados e apresenta um aviso de segurança grave. O convidado não consegue avançar para a página de início de sessão.
A arquitetura correta depende inteiramente das sondagens HTTP ao nível do SO descritas acima. Essas sondagens utilizam HTTP simples para URLs não HSTS especificamente para que os gateways as possam interceptar e redirecionar sem conflitos de certificados. O seu gateway deve interceptar estas sondagens HTTP e emitir o redirecionamento 302. Não tente interceptar tráfego HTTPS para efeitos de Captive Portal.
O jardim vedado (walled garden)
Um jardim vedado (walled garden) é o conjunto de domínios e endereços IP que um dispositivo pode alcançar antes de ser autenticado. Se o jardim vedado for demasiado restrito, a splash page poderá carregar mas a autenticação irá falhar. As lacunas comuns incluem:
- Domínios de fornecedores de identidade: Se utilizar o Microsoft Entra ID, Okta ou Google Workspace para início de sessão social ou SSO, os seus endpoints de autenticação devem estar no jardim vedado.
- Domínios de CDN e ativos: A sua splash page pode carregar CSS, JavaScript ou tipos de letra a partir de uma rede de entrega de conteúdos (CDN). Se esses domínios de CDN estiverem bloqueados, a página será apresentada com erros.
- Domínios de processadores de pagamento: Se cobrar pelo acesso através do Stripe ou de outro processador, os domínios do respetivo SDK JavaScript devem estar pré-autenticados.
- Domínios da plataforma Purple: O overlay de nuvem da Purple exige que o gateway alcance os servidores RADIUS e os endpoints do portal da Purple. Estes estão documentados nos guias de integração de hardware da Purple para cada plataforma suportada.
RADIUS e a lacuna de autorização
O RADIUS (Remote Authentication Dial-In User Service) é o protocolo que liga o seu gateway local à plataforma de autenticação. Quando um convidado conclui o formulário de início de sessão, o Captive Portal envia as credenciais para o servidor RADIUS. O servidor RADIUS devolve uma mensagem Access-Accept ou Access-Reject. O gateway atua com base nessa mensagem, abrindo ou mantendo fechada a regra de firewall que concede acesso à internet.
A lacuna de autorização - onde um convidado inicia sessão com sucesso na splash page mas continua sem internet - significa quase sempre que o gateway não recebeu ou não processou a mensagem Access-Accept. As causas comuns incluem uma chave secreta partilhada incorreta, portas UDP 1812 e 1813 bloqueadas por uma firewall local, ou o endereço IP do servidor RADIUS configurado incorretamente no gateway.
Esgotamento de DHCP em ambientes de alta densidade
Em estádios, centros de conferências e hubs de transporte, a exaustão de DHCP é uma causa frequente de falhas de ligação que parece idêntica a um problema de captive portal. Se o pool de DHCP estiver cheio, um novo dispositivo associa-se ao ponto de acesso, mas nunca recebe um endereço IP. Sem um endereço IP, o dispositivo não consegue enviar a sonda HTTP e nunca chega ao captive portal. O dispositivo é apresentado como ligado ao SSID mas não tem internet.
Para locais como o Manchester Airports Group (MAG), onde os volumes de passageiros atingem picos acentuados, as sub-redes devem ser dimensionadas para o número máximo de dispositivos simultâneos e não para a média. Tempos de lease de DHCP curtos (15 a 30 minutos para redes de visitantes transitórios) recuperam rapidamente os endereços dos dispositivos que já saíram.
Guia de implementação
Os passos seguintes aplicam-se a qualquer plataforma de hardware - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet - quando integrada com a sobreposição de nuvem da Purple.
Passo 1: Configurar o SSID para captive portal externo. No seu controlador de hardware, configure o SSID de convidado para redirecionar clientes não autenticados para o URL do portal externo da Purple. Desative qualquer página de splash local no próprio controlador.
Passo 2: Definir o walled garden. Adicione, no mínimo, os seguintes domínios: o portal da Purple e os endpoints RADIUS (consulte o seu guia de integração de hardware), os URLs de sonda de deteção de SO listados acima, os domínios do seu fornecedor de identidade (Microsoft Entra ID, Okta ou Google Workspace) e quaisquer domínios de CDN que os recursos da sua página de splash utilizem.
Passo 3: Configurar o RADIUS. Insira os endereços IP do servidor RADIUS da Purple, o segredo partilhado do seu painel de controlo da Purple e configure a porta de autenticação para 1812 e a porta de accounting para 1813. Verifique se a sua firewall local permite tráfego UDP de saída nestas portas.
Passo 4: Definir parâmetros de sessão. Para hotelaria e retalho, defina a duração da sessão para 24 horas com o cache de endereços MAC ativado. Isto evita que os convidados sejam forçados a autenticar-se novamente durante uma única visita. Para ambientes de alta segurança, são adequadas sessões mais curtas com nova autenticação.
Passo 5: Dimensionar o seu escopo de DHCP. Calcule o número máximo de dispositivos simultâneos para o seu local na capacidade de pico. Um restaurante de 500 lugares pode registar 800 dispositivos durante um serviço movimentado. Dimensione o pool de DHCP para 1.000 endereços com um tempo de lease de 30 minutos.
Passo 6: Testar em vários sistemas operativos. Após a configuração, teste o fluxo completo em dispositivos iOS, Android e Windows. Cada um utiliza um URL de sonda e uma implementação de WebView diferentes. Uma falha numa plataforma enquanto as outras funcionam é, quase sempre, uma lacuna no walled garden.
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.
Melhores práticas
As seguintes recomendações refletem padrões e boas práticas em mais de 80.000 implementações de locais da Purple.
Separe as redes de convidados e de colaboradores. Execute pelo menos três SSIDs: Guest WiFi, Staff WiFi e uma rede IoT. O tráfego de convidados deve ser isolado dos sistemas internos. Consulte o nosso guia sobre Três SSIDs para a todos governar: guest, Passpoint e IoT WiFi para detalhes de arquitetura.
Utilize uma VLAN dedicada para convidados. Segmente o tráfego de convidados na sua própria VLAN para impedir movimentos laterais e simplificar a política de firewall. Este é um requisito do PCI-DSS se quaisquer dados de cartões de pagamento passarem pela rede.
Implemente opções de consentimento explícito. O GDPR exige que a recolha de dados no Captive Portal seja baseada num consentimento informado e afirmativo. As opções de consentimento explícito da Purple apresentam as escolhas de recolha de dados de forma clara, com caixas de seleção separadas para cada finalidade. Isto não é opcional para estabelecimentos que operam no Reino Unido ou na UE.
Monitorize a saúde do portal de forma proativa. A plataforma de WiFi Analytics da Purple fornece visibilidade em tempo real sobre as taxas de sucesso de início de sessão, contagem de sessões e falhas de autenticação. Uma queda repentina nos inícios de sessão bem-sucedidos é um aviso prévio de um problema de RADIUS ou de walled garden antes que os convidados comecem a reclamar.
Aplique uma identidade de marca consistente. A splash page é a primeira interação de marca que um convidado tem com a sua rede. Um portal bem concebido aumenta as taxas de consentimento e define as expectativas para a experiência de WiFi. Consulte Como causar uma excelente primeira impressão com o seu guest WiFi para orientações de design.
-
Resolução de problemas e mitigação de riscos
Quando for comunicado um problema no Captive Portal, siga esta sequência de diagnóstico antes de efetuar qualquer alteração de configuração.
Isole o ponto de falha. Pergunte ao convidado qual o sistema operativo e navegador que está a utilizar. Teste o mesmo fluxo no mesmo sistema operativo. Se o problema for específico do sistema operativo, a causa é quase certamente a falta de uma entrada de walled garden para o URL de teste desse sistema operativo.
Verifique a resolução de DNS. A partir de um dispositivo na VLAN de convidados, tente resolver o hostname do Captive Portal. Se a resolução de DNS falhar, o dispositivo não conseguirá aceder à splash page, mesmo que o redirecionamento seja emitido corretamente. Verifique se o seu servidor DHCP está a distribuir endereços de DNS fiáveis e se o gateway permite consultas de DNS no estado de pré-autenticação.
Capture o redirecionamento. Utilize as ferramentas de programador do navegador (F12) ou uma captura de pacotes para observar a troca de HTTP. Deverá ver o pedido de teste do sistema operativo seguido de uma resposta HTTP 302 que contém o URL do portal. Se vir o pedido de teste mas nenhuma resposta 302, o gateway não está a intercetar corretamente. Se não vir qualquer pedido de teste, o sistema operativo já determinou que tem acesso à internet (possivelmente a partir de um estado em cache) e não está a enviar o teste. Verifique a comunicação RADIUS. No gateway, verifique os registos de monitorização (accounting logs) do RADIUS. Uma autenticação bem-sucedida produz um registo Accounting-Start. Se não vir registos de monitorização após o início de sessão de um convidado, a comunicação RADIUS está corrompida. Verifique o segredo partilhado, o IP do servidor e as regras de firewall.
Verifique a utilização de concessões DHCP. No servidor DHCP, reveja a contagem de concessões atual em relação ao tamanho do pool. Se a utilização exceder os 90%, está próximo do esgotamento. Expanda o pool ou reduza o tempo de concessão imediatamente.
A tabela seguinte correlaciona os sintomas mais comuns com as respetivas causas de origem e a correção relevante.
| Sintoma | Causa de origem mais provável | Correção |
|---|---|---|
| O portal nunca aparece em nenhum dispositivo | Sonda do SO bloqueada pela ACL do gateway | Adicione os URLs de sonda à lista de permissões de pré-autenticação |
| O portal aparece em iOS, mas não em Android | URL de sonda do Android em falta no walled garden | Adicione connectivitycheck.gstatic.com ao walled garden |
| Erro de certificado HTTPS no carregamento do portal | Gateway a intercetar HTTPS em vez de HTTP | Confie apenas na interceção de sondas HTTP |
| O portal carrega, mas não há internet após o início de sessão | RADIUS Access-Accept não recebido pelo gateway | Verifique o segredo partilhado, as portas 1812/1813 e o IP do servidor RADIUS |
| O botão de início de sessão social falha silenciosamente | Domínio do fornecedor de identidade não está no walled garden | Adicione os endpoints do Microsoft Entra ID / Google Workspace |
| Os convidados têm de se autenticar novamente a cada visita | Duração da sessão demasiado curta ou cache de MAC desativada | Defina a sessão para 24 horas, ative a cache de endereços MAC |
| Falhas intermitentes em períodos de pico | Esgotamento do pool DHCP | Expanda a sub-rede, reduza o tempo de concessão |
-
ROI e impacto empresarial
Cada falha no Captive Portal é um evento de captura de dados perdido. A plataforma de Guest WiFi da Purple converte cada autenticação bem-sucedida num registo de dados proprietários - nome, e-mail, dados demográficos e frequência de visitas - que alimenta diretamente a automatização de marketing e os programas de fidelização.
Para um operador de hotelaria como a Premier Inn ou a Whitbread, uma melhoria de 10% nas taxas de sucesso de autenticação no portal numa propriedade de 700 estabelecimentos traduz-se diretamente em dezenas de milhares de registos adicionais de consentimento por mês. Esses registos impulsionam campanhas de e-mail personalizadas com taxas de abertura mensuravelmente superiores às de listas compradas.
Para os operadores de retalho, o Captive Portal é o ponto de entrada para compreender o tempo de permanência dos compradores, a frequência de visitas repetidas e o comportamento em vários locais. A Purple já recolheu 29 mil milhões de pontos de dados (dados internos da Purple) em toda a sua rede de recintos. Esses dados são tão bons quanto a taxa de autenticação que os gera.
Para hubs de transportes como o Manchester Airports Group, um WiFi para convidados fiável é uma métrica de satisfação dos passageiros monitorizada ao nível da administração. Um portal que falha intermitentemente durante os períodos de pico de partidas gera reclamações e prejudica o Net Promoter Score do local. Para ambientes de cuidados de saúde, um WiFi de visitantes fiável reduz a pressão sobre a equipa clínica que, de outra forma, teria de lidar com reclamações de conectividade, e apoia as métricas de experiência do paciente.
O SLA de uptime de 99.999% da Purple garante que a própria plataforma de cloud não é o ponto de falha. Quando ocorrem problemas no portal, a causa é quase sempre a configuração local - que este guia o capacita a resolver sem abrir um pedido de suporte.
Referências
[1] Troubleshooting Tip: General captive portal explanation, flow and troubleshooting. Fortinet Community, novembro de 2024. https://community.fortinet.com/fortigate-3/troubleshooting-tip-general-captive-portal-explanation-flow-and-troubleshooting-188409
[2] RFC 8910: Captive-Portal Identification in DHCP and Router Advertisements. IETF. https://www.rfc-editor.org/info/rfc8910
[3] Network Connectivity Status Indicator overview for Windows. Microsoft Learn, fevereiro de 2025. https://learn.microsoft.com/en-us/windows-server/networking/ncsi/ncsi-overview
[4] 7 Captive Portal Problems That Break Guest WiFi (And Quick Fixes). Spotipo, fevereiro de 2026. https://www.spotipo.com/post/troubleshooting-captive-portals-common-issues
[5] Solution for HSTS issues with captive portal. Ubiquiti Community. https://community.ui.com/questions/Solution-for-HSTS-issues-with-captive-portal/17b033e7-3dfe-4830-af8f-bf6ead23d8b0
Definições Principais
Captive portal
Uma página web apresentada a um dispositivo que se liga a uma rede antes de lhe ser concedido acesso total à internet. O gateway intercepta o teste inicial de conectividade HTTP do dispositivo e redireciona-o para o URL do portal.
O mecanismo por trás de cada página de login de WiFi de convidados, desde átrios de hotéis a recintos de estádios. Definido no RFC 8910.
Walled garden
O conjunto de domínios e endereços IP que um dispositivo pode alcançar antes de concluir a autenticação no Captive Portal. O tráfego para os destinos do walled garden ignora o requisito de autenticação.
Deve incluir os URLs de teste do SO, endpoints de fornecedores de identidade, domínios CDN e domínios de processadores de pagamento. Um walled garden mal configurado é a segunda causa mais comum de falhas no Captive Portal.
NCSI (Network Connectivity Status Indicator)
Uma funcionalidade do Windows que testa `msftconnecttest.com` para determinar se o dispositivo tem acesso à internet ou se está atrás de um Captive Portal. Definido na documentação de rede da Microsoft.
Se o gateway bloquear este teste, o Windows reporta "Sem acesso à internet" e nunca aciona a WebView do Captive Portal. A solução é adicionar o URL do NCSI à lista de permissões de pré-autenticação.
HSTS (HTTP Strict Transport Security)
Uma política de segurança web definida no RFC 6797 que instrui os navegadores a recusar ligações HTTP simples e a rejeitar qualquer certificado que não corresponda exatamente ao domínio.
Impede que os gateways interceptem pedidos HTTPS para redirecionamento do Captive Portal. Os domínios principais, incluindo google.com, estão na lista de pré-carregamento HSTS em todos os principais navegadores.
Redirecionamento HTTP 302
Um código de resposta HTTP padrão que indica que o recurso solicitado está temporariamente localizado num URI diferente, fornecido no cabeçalho Location.
O mecanismo que os gateways utilizam para desviar o teste de conectividade de um dispositivo para a página de login do Captive Portal. Alguns gateways utilizam HTTP 303 ou HTTP 200 com um corpo de redirecionamento em alternativa.
RADIUS (Remote Authentication Dial-In User Service)
Um protocolo de rede que fornece gestão centralizada de Autenticação, Autorização e Auditoria (AAA), funcionando através de UDP nas portas 1812 (autenticação) e 1813 (auditoria).
A plataforma de nuvem da Purple funciona como o servidor RADIUS. O gateway local (Meraki, Aruba, etc.) envia pedidos de autenticação para os servidores RADIUS da Purple e age com base na resposta Access-Accept ou Access-Reject.
Cache de endereços MAC
O processo de armazenamento do identificador de hardware exclusivo de um dispositivo para reconhecer dispositivos que regressam e manter o estado da sessão sem exigir nova autenticação.
Permite a persistência da sessão em desligamentos breves e visitas repetidas dentro da janela temporal de sessão. Essencial para ambientes de hotelaria onde os clientes se movem entre áreas.
Identity-Based Networks
O modelo de arquitetura da Purple no qual as políticas de acesso, a atribuição de VLAN e a análise são aplicadas com base na identidade autenticada do utilizador, e não apenas no endereço IP ou MAC do dispositivo.
Permite o controlo de acessos granular, experiências personalizadas e a atribuição precisa do comportamento da rede a utilizadores individuais em hardware Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.
Esgotamento de DHCP
Uma condição na qual todos os endereços IP disponíveis num pool de DHCP foram atribuídos, impedindo que novos dispositivos obtenham um endereço e, consequentemente, que alcancem o Captive Portal.
Comum em locais de alta densidade durante períodos de pico. Manifesta-se de forma idêntica a uma falha no Captive Portal - o dispositivo mostra-se ligado ao SSID mas não tem internet. Diagnosticado ao verificar a utilização de concessões DHCP no servidor.
Exemplos Práticos
Um hotel de 200 quartos que utiliza pontos de acesso HPE Aruba reporta que os convidados em dispositivos Android não conseguem aceder ao captive portal, enquanto os utilizadores de iOS se ligam sem problemas. A equipa de TI confirmou que o URL do portal é alcançável a partir da VLAN de gestão.
A equipa de TI deve inspecionar o walled garden de pré-autenticação no controlador HPE Aruba. Os dispositivos iOS testam o captive.apple.com, que provavelmente já está na lista de permissões. Os dispositivos Android testam o connectivitycheck.gstatic.com e o clients3.google.com/generate_204. Estes domínios da Google estão quase de certeza ausentes do walled garden. Adicioná-los à lista de permissões de pré-autenticação resolve o problema. A equipa deve também adicionar o connectivitycheck.android.com como um URL secundário de teste de Android. Depois de atualizar o walled garden, reinicie os SSIDs afetados e teste num dispositivo Android reposto de fábrica para confirmar a correção, uma vez que o estado da rede em cache num dispositivo ligado anteriormente pode mascarar o resultado.
Uma cadeia de retalho com 150 equipamentos Cisco Meraki MX reporta que os convidados se autenticam na splash page da Purple - o painel de controlo da Purple mostra inícios de sessão bem-sucedidos - mas os convidados continuam sem acesso à internet após preencherem o formulário. O problema afeta todas as localizações em simultâneo.
Como a plataforma em nuvem da Purple mostra inícios de sessão bem-sucedidos, a etapa de autenticação em si está a funcionar. A falha está na etapa de autorização - o equipamento Meraki não está a receber ou a processar a mensagem RADIUS Access-Accept dos servidores RADIUS da Purple. A equipa deve verificar três coisas em sequência: primeiro, verificar se o segredo partilhado do RADIUS no painel de controlo da Meraki corresponde exatamente ao segredo no portal da Purple (uma diferença de um único caráter causa uma falha silenciosa); segundo, confirmar que o tráfego UDP de saída nas portas 1812 e 1813 é permitido a partir do equipamento Meraki para os endereços IP do servidor RADIUS da Purple; terceiro, verificar se uma alteração recente na rede introduziu uma regra de firewall ou política NAT que bloqueia este tráfego. Como o problema afeta todas as 150 localizações em simultâneo, a causa é provavelmente uma alteração centralizada na política de firewall ou uma alteração de endereço IP do servidor RADIUS da Purple que não foi propagada para as configurações Meraki.
Perguntas de Prática
Q1. Durante uma conferência de grande escala num espaço com capacidade para 5000 pessoas, a equipa de TI recebe relatos de que centenas de participantes não conseguem aceder ao portal de WiFi de convidados. Os pontos de acesso mostram contagens normais de associação. O problema começou 45 minutos após o início do evento. Qual é a causa mais provável e qual é a solução imediata?
Dica: O problema começou após o início do evento, não no lançamento. Considere qual o recurso que fica limitado à medida que mais dispositivos se ligam.
Ver resposta modelo
A causa mais provável é a exaustão do pool de DHCP. À medida que os participantes chegaram e se associaram ao SSID, o pool de DHCP esgotou-se. Os novos dispositivos associam-se ao access point mas não conseguem obter um endereço IP, pelo que nunca enviam o teste HTTP necessário para acionar o Captive Portal. A correção imediata consiste em reduzir o tempo de lease do DHCP para 15 minutos (recuperando os endereços dos dispositivos que já saíram mais rapidamente) e, se possível, expandir o pool adicionando uma segunda sub-rede. A correção a longo prazo é dimensionar o pool de DHCP para o número máximo de dispositivos simultâneos no próximo evento, e não para a média.
Q2. Implementou o Purple em access points Ubiquiti UniFi numa cadeia de lojas. A splash page carrega corretamente em todos os dispositivos. Os convidados preenchem o formulário de captura de e-mail e veem uma mensagem de sucesso. Mas quando tentam navegar, não têm acesso à internet. O painel do Purple mostra os inícios de sessão como bem-sucedidos. O que verifica primeiro?
Dica: A plataforma cloud registou a autenticação. A falha está na etapa de aplicação local.
Ver resposta modelo
Como o painel do Purple mostra inícios de sessão bem-sucedidos, a etapa de autenticação na cloud foi concluída corretamente. A falha está na etapa de autorização RADIUS - o controlador UniFi não está a receber ou a agir sobre a mensagem Access-Accept dos servidores RADIUS do Purple. Verifique por esta ordem: (1) se o segredo partilhado RADIUS no controlador UniFi corresponde exatamente ao segredo no painel do Purple; (2) se o tráfego UDP de saída nas portas 1812 e 1813 é permitido do controlador para os endereços IP do servidor RADIUS do Purple; (3) se os endereços IP do servidor RADIUS configurados no controlador UniFi estão atualizados (o Purple pode tê-los atualizado). Uma captura de pacotes no controlador confirmará se a mensagem Access-Accept está a chegar.
Q3. O gestor de TI de um hotel relata que os convidados que utilizam uma VPN nos seus dispositivos não conseguem aceder ao Captive Portal de todo. Os convidados sem VPN ligam-se normalmente. O hotel utiliza equipamentos Cisco Meraki MX. A equipa de TI deve alterar a configuração do Captive Portal para acomodar os utilizadores de VPN?
Dica: Considere o que uma VPN faz ao tráfego de rede do dispositivo antes de o Captive Portal o conseguir intercetar.
Ver resposta modelo
Não - a configuração do Captive Portal não precisa de ser alterada. Um cliente de VPN encripta todo o tráfego do dispositivo antes de este sair do dispositivo, incluindo o teste de conectividade HTTP. O gateway não consegue intercetar tráfego VPN encriptado, pelo que nunca emite o redirecionamento 302. O convidado tem de desativar a sua VPN, concluir a autenticação no Captive Portal e, em seguida, voltar a ativar a VPN. Esta é uma limitação arquitetural fundamental dos Captive Portals e das VPNs, não um erro de configuração. A equipa de TI deve adicionar uma nota às instruções de WiFi para convidados, aconselhando os utilizadores de VPN a desativarem a sua VPN antes de se ligarem.
Continue a ler esta série
Portal de convidados Ubiquiti UniFi não redireciona: causas e correções
Este guia isola uma falha de redirecionamento do portal de convidados UniFi ao seguir sequencialmente o estado do convidado, o redirecionamento, a rota de pré-autorização e a autorização do controlador. Oferece às equipas de TI dos recintos um método fundamentado para resolver a confusão entre rede de convidados e Hotspot, transições de portais externos, requisitos atuais de conta do UniFi OS e testes de isolamento de DNS.
Cisco Meraki splash page não funciona: um fluxograma de resolução de problemas
Este guia prático de segundo dia isola onde falhou um fluxo de splash do Cisco Meraki: autorização do cliente, início de redirecionamento HTTP, acessibilidade do walled garden ou início de sessão RADIUS. Oferece às equipas de TI dos locais um caminho de evidências controlado, para que possam restaurar o Guest WiFi sem efetuar alterações amplas numa infraestrutura ativa.
Guia de Configuração de WiFi para Visitantes Empresariais: Segmentação de VLAN, Segurança e Portais Cativos
Este guia técnico mostra às equipas de TI como configurar o WiFi para Visitantes como um serviço controlado de acesso à internet, utilizando segmentação de VLAN, política de firewall e um captive portal. Também explica como os formulários de registo e controlos de adesão do Purple apoiam uma experiência de visitante proporcional sem enfraquecer o limite em torno dos sistemas operacionais, de pagamento e dos funcionários.
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.