Resolução de Problemas de Redirecionamento de Captive Portal: Como Resolver Falhas de Ligação de WiFi de Convidados
Quando os convidados se ligam ao seu WiFi mas não conseguem aceder à internet, a causa é quase sempre um 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 exaustão de DHCP. Mapeia cada modo de falha para uma correção concreta e mostra como a plataforma de cloud agnóstica de hardware da Purple elimina estes problemas em implementações Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.
Ouça este guia
Ver transcrição do podcast
Resumo executivo
A pesquisa "WiFi de convidados ligado mas sem internet" é um dos tickets 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é que compreendam a cadeia de redirecionamento. Um Captive Portal (também designado por página de splash ou gateway de hotspot) interceta a sonda de conectividade HTTP inicial de um dispositivo e emite um redirecionamento HTTP 302 para uma página de início de sessão. Se algum passo nessa cadeia falhar - sondas bloqueadas, conflitos HSTS, falhas no walled garden, falhas de RADIUS ou exaustão de DHCP - o convidado não vê nada além de um ícone de WiFi ligado e sem internet. Este guia orienta-o através de cada modo de falha, da mecânica do protocolo subjacente e das alterações de configuração que as 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 de 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 SO envia um pedido HTTP GET não encriptado para um URL predefinido. A tabela abaixo lista os URLs de sonda por plataforma.
| Sistema operativo | URL da sonda | 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 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 intercetar um destes pedidos e devolver um redirecionamento HTTP 302 a apontar para o URL do Captive Portal, o SO reconhece que está atrás de um portal e abre um pseudonavegador (um WebView leve) para apresentar a página de splash. Se a sonda for totalmente bloqueada, o SO comunica "Sem ligação à internet" e nunca tenta abrir o portal. Esta é a causa individual mais comum do sintoma "WiFi de convidados ligado mas sem internet".
O problema do HSTS
O HTTP Strict Transport Security (HSTS) é uma política de segurança web definida no RFC 6797. Instruiu os browsers a recusar todas as ligações HTTP simples a um domínio e a rejeitar qualquer certificado que não corresponda exactamente. Domínios principais, 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 browser e digita google.com, o browser actualiza o pedido para HTTPS antes de este sair do dispositivo. O gateway não consegue interceptar um pedido HTTPS e redireccioná-lo de forma limpa - teria de apresentar um certificado para google.com, o qual não possui. O browser detecta a incoerência do certificado e apresenta um aviso de segurança grave. O convidado não consegue aceder à página de início de sessão.
A arquitectura correcta baseia-se inteiramente nos testes HTTP ao nível do sistema operativo descritos acima. Esses testes utilizam HTTP simples para URLs não-HSTS especificamente para que os gateways os possam interceptar e redireccionar sem conflitos de certificados. O seu gateway deve interceptar estes testes HTTP e emitir o redireccionamento 302. Não tente interceptar tráfego HTTPS para efeitos de Captive Portal.
O jardim vedado (walled garden)
Um jardim vedado é 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 página de entrada (splash page) poderá ser carregada, mas a autenticação irá falhar. As lacunas comuns incluem:
- Domínios do fornecedor de identidade: Se utilizar o Microsoft Entra ID, Okta ou Google Workspace para início de sessão social ou SSO, os respectivos endpoints de autenticação devem estar no jardim vedado.
- Domínios de CDN e de recursos: A sua página de entrada pode carregar CSS, JavaScript ou tipos de letra a partir de uma rede de distribuição 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 SDK de JavaScript correspondentes devem ser pré-autenticados.
- Domínios da plataforma Purple: A sobreposição na nuvem da Purple exige que o gateway aceda aos servidores RADIUS e aos 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 falha 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 preenche 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 de Aceitação de Acesso (Access-Accept) ou Rejeição de Acesso (Access-Reject). O gateway actua com base nessa mensagem, abrindo ou mantendo fechada a regra de firewall que concede acesso à internet.
A falha de autorização - em que um convidado inicia sessão com sucesso na página de entrada mas continua sem internet - significa quase sempre que o gateway não recebeu ou não processou a mensagem de Access-Accept. As causas comuns incluem uma chave partilhada (shared secret) incorrecta, portas UDP 1812 e 1813 bloqueadas por uma firewall local ou o endereço IP do servidor RADIUS configurado incorrectamente 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 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 acede 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, não para a média. Tempos de concessão (lease times) de DHCP curtos (15 a 30 minutos para redes de visitantes transitórios) recuperam rapidamente os endereços de 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 cloud overlay da Purple.
Passo 1: Configurar o SSID para captive portal externo. No seu controlador de hardware, configure o SSID de convidados para redirecionar clientes não autenticados para o URL do portal externo da Purple. Desative qualquer página splash local no próprio controlador.
Passo 2: Definir o walled garden. Adicione, no mínimo, os seguintes domínios: os endpoints do portal e RADIUS da Purple (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 splash utilizem.
Passo 3: Configurar o RADIUS. Introduza os endereços IP do servidor RADIUS da Purple, o segredo partilhado do seu painel 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 UDP de saída nestas portas.
Passo 4: Configurar os parâmetros de sessão. Para hotelaria e retalho, configure a duração da sessão para 24 horas com a colocação em cache de endereços MAC ativada. 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 âmbito DHCP. Calcule o número máximo de dispositivos simultâneos para o seu local na capacidade máxima. Um restaurante com 500 lugares pode registar 800 dispositivos durante um serviço movimentado. Dimensione o pool DHCP para 1000 endereços com um tempo de concessão 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.
-
Melhores práticas
As seguintes recomendações refletem normas e padrões em mais de 80.000 implementações em locais da Purple.
Separe as redes de convidados e funcionários. 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 Three SSIDs to rule them all: guest, Passpoint, and IoT WiFi para mais detalhes sobre a arquitetura.
Utilize uma VLAN de convidados dedicada. 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 opt-ins de escolha consciente. O GDPR exige que a recolha de dados no Captive Portal seja baseada num consentimento informado e afirmativo. Os opt-ins de escolha consciente da Purple apresentam as opções de recolha de dados de forma clara, com caixas de seleção separadas para cada finalidade. Isto não é opcional para locais que operam no Reino Unido ou na UE.
Monitorize a integridade 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, contagens 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 marca consistente. A splash page é a primeira interação com a marca que um convidado tem com a sua rede. Um portal bem desenhado aumenta as taxas de opt-in e define as expectativas para a experiência de WiFi. Consulte How to make a great first impression with your guest WiFi para obter orientações de design.
-
Resolução de problemas e mitigação de riscos
Quando um problema no Captive Portal for reportado, 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 (OS) e o navegador que está a utilizar. Teste o mesmo fluxo no mesmo OS. Se o problema for específico do OS, a causa é quase de certeza a falta de uma entrada de walled garden para o URL de teste desse OS.
Verifique a resolução de DNS. A partir de um dispositivo na VLAN de convidados, tente resolver o nome de anfitrião 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 DNS fiáveis e se o gateway permite consultas 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 HTTP. Deverá ver o pedido de teste do OS seguido por uma resposta HTTP 302 contendo 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 nenhum pedido de teste, o OS 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 contabilidade (accounting) do RADIUS. Uma autenticação bem-sucedida produz um registo Accounting-Start. Se não vir registos de contabilidade após a ligação de um convidado, a comunicação RADIUS está interrompida. 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á prestes a esgotar as concessões. Expanda o pool ou reduza o tempo de concessão imediatamente.
A tabela seguinte mapeia os sintomas mais comuns às suas causas de raiz e à respetiva correção.
| Sintoma | Causa de raiz 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 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 ao carregar o 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 reautenticar 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 horas de ponta | Esgotamento do pool DHCP | Expanda a sub-rede, reduza o tempo de concessão |
ROI e impacto empresarial
Cada falha do 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 primários - nome, e-mail, dados demográficos e frequência de visitas - que alimenta diretamente a automatização de marketing e os programas de fidelidade.
Para um operador de hotelaria como a Premier Inn ou a Whitbread, uma melhoria de 10% nas taxas de sucesso de autenticação do portal numa propriedade de 700 estabelecimentos traduz-se diretamente em dezenas de milhares de registos adicionais de consentimento (opt-in) por mês. Esses registos alimentam campanhas de e-mail personalizadas com taxas de abertura mensuravelmente superiores às de listas compradas.
Para 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) na sua rede de locais. Esses dados valem apenas o equivalente à 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 maior afluência de partidas gera reclamações e prejudica o Net Promoter Score do local. Para ambientes de cuidados de saúde , um WiFi para 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 99.999% de tempo de atividade da Purple garante que o próprio overlay na nuvem não é o ponto de falha. Quando ocorrem problemas no portal, a causa é quase sempre a configuração local - o 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 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 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 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 a tentativa de ligação HTTP inicial do dispositivo e redireciona-a 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 aceder antes de concluir a autenticação no Captive Portal. O tráfego para destinos no walled garden ignora o requisito de autenticação.
Deve incluir URLs de diagnóstico do SO, endpoints de fornecedores de identidade, domínios de 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 consulta `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 diagnóstico, o Windows reporta "Sem acesso à internet" e nunca aciona o 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 principais domínios, 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 se encontra temporariamente num URI diferente, fornecido no cabeçalho Location.
O mecanismo que os gateways utilizam para desviar o teste de ligação de um dispositivo para a página de início de sessão do Captive Portal. Alguns gateways utilizam HTTP 303 ou HTTP 200 com um corpo de redirecionamento.
RADIUS (Remote Authentication Dial-In User Service)
Um protocolo de rede que fornece gestão centralizada de Autenticação, Autorização e Contabilização (AAA), operando em UDP nas portas 1812 (autenticação) e 1813 (contabilização).
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.
Registo em cache do endereço 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 de sessão. Essencial para ambientes hoteleiros onde os hóspedes se deslocam entre áreas.
Identity-Based Networks
O modelo de arquitetura da Purple no qual as políticas de acesso, atribuição de VLAN e análises 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 acesso 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 conjunto DHCP foram atribuídos, impedindo que novos dispositivos obtenham um endereço e, portanto, cheguem ao Captive Portal.
Comum em locais de alta densidade durante períodos de pico. Manifesta-se de forma idêntica a uma falha do Captive Portal - o dispositivo mostra-se ligado ao SSID mas não tem internet. Diagnosticado ao verificar a utilização de concessão DHCP no servidor.
Exemplos Práticos
Um hotel de 200 quartos que utiliza pontos de acesso HPE Aruba relata que os convidados com 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 está acessí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 captive.apple.com, que provavelmente já está na lista de permissões. Os dispositivos Android testam connectivitycheck.gstatic.com e 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 connectivitycheck.android.com como um URL de teste secundário para 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 de rede em cache num dispositivo previamente ligado pode mascarar o resultado.
Uma cadeia de retalho com 150 equipamentos Cisco Meraki MX relata que os convidados se autenticam na splash page da Purple - o painel 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 simultaneamente.
Uma vez que a plataforma de cloud 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 agir de acordo com 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 RADIUS no painel Meraki corresponde exatamente ao segredo no portal Purple (uma diferença de um único caráter causa uma falha silenciosa); segundo, confirmar se 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 simultaneamente, a causa é provavelmente uma alteração na política de firewall centralizada 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 grande conferência num espaço com 5000 lugares, 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 evento já estar em curso, 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 DHCP. À medida que os participantes chegavam e se associavam ao SSID, o pool DHCP esgotava-se. Os novos dispositivos associam-se ao access point, mas não conseguem obter um endereço IP, pelo que nunca enviam o probe HTTP necessário para acionar o Captive Portal. A correção imediata é reduzir o tempo de lease do DHCP para 15 minutos (recuperando os endereços de 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 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 retalho. A splash page carrega corretamente em todos os dispositivos. Os convidados preenchem o formulário de recolha de e-mail e veem uma mensagem de sucesso. Mas quando tentam navegar, não têm acesso à internet. O painel do Purple mostra as ligações como bem-sucedidas. 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 logins 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 coincide exatamente com o 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 hóspedes que utilizam uma VPN nos seus dispositivos não conseguem aceder de todo ao Captive Portal. Os hóspedes sem VPN ligam-se normalmente. O hotel utiliza dispositivos Cisco Meraki MX. A equipa de TI deve alterar a configuração do Captive Portal para acomodar utilizadores de VPN?
Dica: Considere o que uma VPN faz ao tráfego de rede do dispositivo antes que o Captive Portal o possa intercetar.
Ver resposta modelo
Não - a configuração do Captive Portal não precisa de ser alterada. Um cliente VPN encripta todo o tráfego do dispositivo antes de este sair do mesmo, incluindo o probe de conectividade HTTP. O gateway não consegue intercetar tráfego VPN encriptado, pelo que nunca emite o redirecionamento 302. O hóspede deve desativar a sua VPN, concluir a autenticação no Captive Portal e, em seguida, reativar 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
Resolução de Problemas em WiFi Público: Como Corrigir 'Ligado, Sem Internet' e Falhas de Redirecionamento da Página Splash
Este guia de referência técnica autorizado explica o funcionamento subjacente da deteção de Captive Portal e detalha os seis principais modos de falha que impedem o WiFi de convidados de se ligar. Fornece aos gestores de TI e arquitetos de rede uma metodologia prática de resolução de problemas para resolver falhas de redirecionamento HTTP, conflitos de DNS e desafios de randomização de MAC.
As 10 Principais Causas de DHCP Timeouts em Redes Sem Fios de Alta Densidade
Este guia de referência técnica autoritário identifica as dez principais causas de DHCP timeouts em redes sem fios de alta densidade e fornece estratégias de remediação acionáveis e neutras em relação ao fabricante. Concebido para líderes seniores de TI, arquitetos de rede e diretores de operações de espaços, abrange princípios de engenharia aprofundados, fluxos de trabalho de implementação passo a passo e resultados de negócio mensuráveis. Saiba como eliminar estrangulamentos de ligação e otimizar a sua infraestrutura sem fios para fornecer uma conectividade contínua em ambientes empresariais exigentes.
Utilizar a Captura de Pacotes (PCAP) para Diagnosticar o Desempenho Lento do WiFi
Este guia de referência técnica fornece aos gestores de TI, arquitetos de rede e diretores de operações de espaços uma metodologia estruturada ao nível dos pacotes para diagnosticar e resolver o desempenho lento do WiFi empresarial utilizando a análise de Captura de Pacotes (PCAP). Ao dissecar tramas 802.11 brutas — incluindo taxas de retransmissão, utilização de tempo de antena e metadados da camada física — as equipas podem isolar estrangulamentos na camada de RF de problemas com fios ou de aplicações com precisão. Aplicável a espaços de alta densidade, incluindo hotéis, cadeias de retalho, estádios e centros de conferências, este guia oferece fluxos de trabalho de diagnóstico práticos, estudos de caso do mundo real e passos de remediação de configuração para recuperar a capacidade da rede e proteger a experiência do utilizador.