Solução de problemas de redirecionamento de Captive Portal: Resolvendo falhas de conexão de WiFi de convidados
Quando os convidados se conectam ao seu WiFi, mas não conseguem acessar a internet, a causa quase sempre é um redirecionamento de Captive Portal configurado incorretamente - não uma falha de hardware. Este guia fornece uma referência técnica detalhada para gerentes de TI, arquitetos de rede e CTOs para diagnosticar e resolver toda a cadeia de falhas: desde testes de conectividade no nível do sistema operacional e conflitos de certificado HSTS até lacunas de autorização RADIUS e esgotamento de DHCP. Ele mapeia cada modo de falha para uma correção concreta e mostra como a camada de nuvem agnóstica de hardware da Purple elimina esses problemas em implantações Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet.
Ouça este guia
Ver transcrição do podcast
Resumo executivo
A consulta "WiFi de convidados conectado, mas sem internet" é um dos tíquetes de suporte mais comuns em redes corporativas. O sintoma é visível para todos os visitantes; a causa é invisível para a maioria das equipes de TI até que entendam a cadeia de redirecionamento. Um Captive Portal (também chamado de página de login ou gateway de hotspot) intercepta a solicitação inicial de conectividade HTTP de um dispositivo e emite um redirecionamento HTTP 302 para uma página de login. Se qualquer etapa dessa cadeia falhar - probes bloqueados, conflitos de HSTS, falhas de walled garden, falhas de RADIUS ou exaustão de DHCP - o convidado não vê nada além de um ícone de WiFi conectado e sem internet. Este guia orienta você por todos os modos de falha, a mecânica dos protocolos subjacentes 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 logins anualmente (dados internos da Purple, 2024), e os padrões descritos aqui representam as causas raiz mais frequentes que vemos em implantações nos setores de hotelaria, varejo, transporte e setor público.
Detalhamento técnico
Como a detecção de Captive Portal realmente funciona
Todos os principais sistemas operacionais vêm com um mecanismo integrado para detectar se uma rede exige autenticação antes de conceder acesso à internet. Compreender esses mecanismos é a base de toda a solução de problemas de Captive Portal.
Quando um dispositivo se associa a um SSID, o SO envia uma solicitação HTTP GET não criptografada para uma URL predefinida. A tabela abaixo lista as URLs de probe por plataforma.
| Sistema operacional | URL de probe | 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 interceptar uma dessas solicitações e retornar um redirecionamento HTTP 302 apontando para a URL do Captive Portal, o SO reconhecerá que está atrás de um portal e abrirá um pseudonavegador (um WebView leve) para exibir a página de login. Se o probe for totalmente bloqueado, o SO informará "Sem conexão com a internet" e nunca tentará abrir o portal. Esta é a causa mais comum do sintoma "WiFi de convidados conectado, mas sem internet".
O problema do HSTS
HTTP Strict Transport Security (HSTS) é uma política de segurança da web definida na RFC 6797. Ela instrui os navegadores a recusar todas as conexõ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 ao Chrome, Firefox, Safari e Edge.
Quando um visitante abre um navegador e digita google.com, o navegador atualiza a solicitação para HTTPS antes que ela saia do dispositivo. O gateway não pode interceptar uma solicitação HTTPS e redirecioná-la de forma limpa - ele teria que apresentar um certificado para google.com, que ele não possui. O navegador detecta a incompatibilidade de certificado e exibe um aviso de segurança grave. O visitante não pode prosseguir para a página de login.
A arquitetura correta depende inteiramente das sondagens HTTP em nível de sistema operacional descritas acima. Essas sondagens usam HTTP simples para URLs não HSTS especificamente para que os gateways possam interceptá-las e redirecioná-las sem conflitos de certificado. Seu gateway deve interceptar essas sondagens HTTP e emitir o redirecionamento 302. Não tente interceptar o tráfego HTTPS para fins de Captive Portal.
O walled garden
Um walled garden é o conjunto de domínios e endereços IP que um dispositivo pode acessar antes de ser autenticado. Se o walled garden for muito estreito, a tela de autenticação poderá carregar, mas a autenticação falhará. Lacunas comuns incluem:
- Domínios de provedores de identidade: se você usa o Microsoft Entra ID, Okta ou Google Workspace para login social ou SSO, seus endpoints de autenticação devem estar no walled garden.
- Domínios de CDN e ativos: sua tela de autenticação pode carregar CSS, JavaScript ou fontes de uma rede de distribuição de conteúdo. Se esses domínios de CDN estiverem bloqueados, a página será renderizada incorretamente.
- Domínios de processadores de pagamento: se você cobra pelo acesso via Stripe ou outro processador, os domínios do SDK de JavaScript deles devem ser pré-autenticados.
- Domínios da plataforma Purple: o overlay de nuvem da Purple exige que o gateway acesse os servidores RADIUS e endpoints do portal da Purple. Eles 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 conecta seu gateway local à plataforma de autenticação. Quando um visitante preenche o formulário de login, o Captive Portal envia as credenciais para o servidor RADIUS. O servidor RADIUS retorna uma mensagem de Access-Accept ou Access-Reject. O gateway age com base nessa mensagem abrindo ou mantendo fechada a regra de firewall que concede acesso à internet.
A falha de autorização - em que um visitante faz login com sucesso na tela de autenticação, mas ainda não tem internet - quase sempre significa que o gateway não recebeu ou não processou a mensagem de Access-Accept. As causas comuns incluem uma senha compartilhada (shared secret) incorreta, portas UDP 1812 e 1813 bloqueadas por um firewall local ou o endereço IP do servidor RADIUS configurado incorretamente no gateway.
Exaustão de DHCP em ambientes de alta densidade
Em estádios, centros de conferências e hubs de transporte, a exaustão do DHCP é uma causa frequente de falhas de conexão que parece idêntica a um problema de Captive Portal. Se o pool de DHCP estiver cheio, um novo dispositivo se associa 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 alcança o Captive Portal. O dispositivo aparece como conectado ao SSID, mas sem internet.
Para locais como o Manchester Airports Group (MAG), onde o volume de passageiros atinge picos acentuados, as sub-redes devem ser dimensionadas para a contagem máxima de dispositivos simultâneos, não para a média. Tempos de lease curtos do DHCP (15 - 30 minutos para redes de visitantes transitórios) recuperam endereços de dispositivos que já saíram rapidamente.
Guia de implementação
As etapas a seguir se aplicam a qualquer plataforma de hardware - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks ou Fortinet - quando integrada com o overlay em nuvem da Purple.
Etapa 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 a URL do portal externo da Purple. Desative qualquer página de splash local no próprio controlador.
Etapa 2: Definir o walled garden. Adicione no mínimo os seguintes domínios: o portal da Purple e os endpoints RADIUS (consulte o guia de integração do seu hardware), as URLs de sonda de detecção de SO listadas acima, os domínios do seu provedor 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.
Etapa 3: Configurar o RADIUS. Insira os endereços IP do servidor RADIUS da Purple, o segredo compartilhado do seu painel da Purple e defina a porta de autenticação para 1812 e a porta de tarifação (accounting) para 1813. Verifique se o seu firewall local permite UDP de saída nessas portas.
Etapa 4: Definir parâmetros de sessão. Para hospitalidade e varejo, defina a duração da sessão para 24 horas com o cache de endereço MAC ativado. Isso evita que os convidados sejam forçados a se autenticar novamente durante uma única visita. Para ambientes de alta segurança, sessões mais curtas com reautenticação são apropriadas.
Etapa 5: Dimensionar o escopo do seu DHCP. Calcule a contagem máxima de dispositivos simultâneos para o seu local na capacidade de pico. Um restaurante de 500 lugares pode registrar 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.
Etapa 6: Testar em diferentes sistemas operacionais. Após a configuração, teste todo o fluxo em dispositivos iOS, Android e Windows. Cada um usa uma URL de sonda e uma implementação de WebView diferentes. Uma falha em uma plataforma enquanto as outras funcionam quase sempre indica uma lacuna no walled garden.
Boas práticas
As recomendações a seguir refletem padrões e modelos em mais de 80.000 implantaçõ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 Três SSIDs para governar todos: convidado, Passpoint e IoT WiFi para detalhes de arquitetura.
Use uma VLAN de convidados dedicada. Segmente o tráfego de convidados em sua própria VLAN para evitar movimentação lateral e simplificar as políticas de firewall. Este é um requisito do PCI-DSS se quaisquer dados de cartão de pagamento trafegarem pela rede.
Implemente opt-ins de escolha consciente. O GDPR exige que a coleta de dados no Captive Portal seja baseada em consentimento informado e afirmativo. Os opt-ins de escolha consciente da Purple apresentam as opções de coleta de dados de forma clara, com caixas de seleção separadas para cada finalidade. Isso não é opcional para locais que operam no Reino Unido ou na UE.
Monitore a integridade do portal proativamente. A plataforma de WiFi Analytics da Purple oferece visibilidade em tempo real sobre as taxas de sucesso de login, contagem de sessões e falhas de autenticação. Uma queda repentina nos logins 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 desenhado aumenta as taxas de opt-in e define as expectativas para a experiência de WiFi. Consulte Como causar uma ótima primeira impressão com seu guest WiFi para orientações de design.
-
Solução de problemas e mitigação de riscos
Quando um problema no Captive Portal for relatado, siga esta sequência de diagnóstico antes de fazer qualquer alteração de configuração.
Isole o ponto de falha. Pergunte ao convidado qual OS e navegador ele está usando. Teste o mesmo fluxo você mesmo no mesmo OS. Se o problema for específico de um OS, a causa é quase certamente a ausência de uma entrada de walled garden para a URL de teste desse OS.
Verifique a resolução DNS. A partir de um dispositivo na VLAN de convidados, tente resolver o hostname do Captive Portal. Se a resolução DNS falhar, o dispositivo não conseguirá alcançar a splash page, mesmo que o redirecionamento seja emitido corretamente. Verifique se o seu servidor DHCP está distribuindo endereços DNS confiáveis e se o gateway permite consultas DNS no estado pré-autenticação.
Capture o redirecionamento. Use as ferramentas de desenvolvedor do navegador (F12) ou uma captura de pacotes para observar a troca HTTP. Você deve ver a requisição de teste do OS seguida por uma resposta HTTP 302 contendo a URL do portal. Se você vir a requisição de teste, mas nenhuma resposta 302, o gateway não está interceptando corretamente. Se não vir nenhuma requisição de teste, o OS já determinou que tem acesso à internet (possivelmente a partir de um estado em cache) e não está enviando o teste. Verifique a comunicação RADIUS. No gateway, verifique os logs de contabilização RADIUS. Uma autenticação bem-sucedida produz um registro Accounting-Start. Se você não vir nenhum registro de contabilização após o login de um visitante, a comunicação RADIUS está corrompida. Verifique o segredo compartilhado, o IP do servidor e as regras de firewall.
Verifique a utilização de concessões DHCP. No servidor DHCP, revise a contagem atual de concessões em relação ao tamanho do pool. Se a utilização exceder 90%, você está se aproximando do esgotamento. Expanda o pool ou reduza o tempo de concessão imediatamente.
A tabela a seguir mapeia os sintomas mais comuns às suas causas raiz e à correção relevante.
| Sintoma | Causa raiz mais provável | Correção |
|---|---|---|
| O portal nunca aparece em nenhum dispositivo | Sonda do SO bloqueada pela ACL do gateway | Adicione as URLs de sonda à lista de permissões de pré-autenticação |
| O portal aparece no iOS, mas não no Android | URL de sonda do Android ausente no walled garden | Adicione connectivitycheck.gstatic.com ao walled garden |
| Erro de certificado HTTPS no carregamento do portal | Gateway interceptando HTTPS em vez de HTTP | Dependa apenas da interceptação de sonda HTTP |
| O portal carrega, mas não há internet após o login | RADIUS Access-Accept não recebido pelo gateway | Verifique o segredo compartilhado, as portas 1812/1813 e o IP do servidor RADIUS |
| O botão de login social falha silenciosamente | Domínio do provedor de identidade não está no walled garden | Adicione os endpoints do Microsoft Entra ID / Google Workspace |
| Os visitantes precisam se autenticar novamente a cada visita | Duração da sessão muito curta ou cache de MAC desativado | Defina a sessão para 24 horas, ative o cache de endereço MAC |
| Falhas intermitentes em horários de pico | Esgotamento do pool DHCP | Expanda a sub-rede, reduza o tempo de concessão |
ROI e impacto nos negócios
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 em um registro de dados primários - nome, e-mail, dados demográficos e frequência de visitas - que alimenta diretamente a automação de marketing e os programas de fidelidade.
Para um operador de hospitalidade como Premier Inn ou Whitbread, uma melhoria de 10% nas taxas de sucesso de autenticação do portal em uma propriedade de 700 estabelecimentos se traduz diretamente em dezenas de milhares de registros adicionais de aceitação por mês. Esses registros alimentam campanhas de e-mail personalizadas com taxas de abertura mensuravelmente mais altas do que listas compradas.
Para operadores de varejo , o Captive Portal é o ponto de entrada para entender o tempo de permanência do comprador, a frequência de visitas repetidas e o comportamento em vários locais. A Purple coletou 29 bilhões de pontos de dados (dados internos da Purple) em sua rede de locais de atendimento. Esses dados são tão bons quanto a taxa de autenticação que os gera.
Para hubs de transporte como o Manchester Airports Group, um WiFi para visitantes confiável é uma métrica de satisfação do passageiro acompanhada no nível da diretoria. Um portal que falha intermitentemente durante os períodos de pico de partida gera reclamações e prejudica o Net Promoter Score do local.Para ambientes de saúde , um WiFi para visitantes confiável reduz a pressão sobre a equipe clínica, que de outra forma teria que lidar com reclamações de conectividade, e apoia as métricas de experiência do paciente.
O SLA de 99,999% de disponibilidade da Purple garante que a sobreposição de nuvem em si não seja o ponto de falha. Quando ocorrem problemas no portal, a causa quase sempre é a configuração local - que este guia equipa você para resolver sem a necessidade de abrir um chamado de suporte.
Referências
[1] Troubleshooting Tip: General captive portal explanation, flow and troubleshooting. Fortinet Community, November 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, February 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, February 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 conecta a uma rede antes que o acesso total à internet seja concedido. O gateway intercepta a tentativa de conectividade HTTP inicial do dispositivo e o redireciona para a URL do portal.
O mecanismo por trás de cada página de login de WiFi de convidados, desde saguões de hotéis até saguões de estádios. Definido na RFC 8910.
Walled garden
O conjunto de domínios e endereços IP que um dispositivo pode acessar antes de concluir a autenticação no Captive Portal. O tráfego para destinos do walled garden ignora a necessidade de autenticação.
Deve incluir URLs de teste de SO, endpoints de provedores 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)
Um recurso 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 esse teste, o Windows informará "Sem acesso à internet" e nunca acionará o WebView do Captive Portal. A solução é adicionar a URL do NCSI à lista de permissões de pré-autenticação.
HSTS (HTTP Strict Transport Security)
Uma política de segurança web definida na RFC 6797 que instrui os navegadores a recusar conexões HTTP simples e a rejeitar qualquer certificado que não corresponda exatamente ao domínio.
Evita que gateways interceptem solicitações HTTPS para redirecionamento do Captive Portal. Os principais domínios, incluindo google.com, estão na lista de pré-carregamento do HSTS em todos os principais navegadores.
Redirecionamento HTTP 302
Um código de resposta HTTP padrão indicando que o recurso solicitado está temporariamente localizado em uma URI diferente, fornecida no cabeçalho Location.
O mecanismo que os gateways usam para desviar o teste de conectividade de um dispositivo para a página de login do Captive Portal. Alguns gateways usam HTTP 303 ou HTTP 200 com um corpo de redirecionamento em seu lugar.
RADIUS (Remote Authentication Dial-In User Service)
Um protocolo de rede que fornece gerenciamento centralizado de Autenticação, Autorização e Contabilização (AAA), operando em UDP nas portas 1812 (autenticação) e 1813 (contabilização).
A plataforma em nuvem da Purple atua como o servidor RADIUS. O gateway local (Meraki, Aruba, etc.) envia solicitações de autenticação para os servidores RADIUS da Purple e age com base na resposta Access-Accept ou Access-Reject.
Armazenamento em cache de endereço MAC
O processo de armazenar o identificador de hardware exclusivo de um dispositivo para reconhecer dispositivos que retornam e manter o estado da sessão sem exigir nova autenticação.
Permite a persistência da sessão em caso de desconexões breves e visitas repetidas dentro da janela de sessão. Essencial para ambientes de hotelaria 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 usuário, e não apenas no endereço IP ou MAC do dispositivo.
Permite controle de acesso granular, experiências personalizadas e atribuição precisa do comportamento da rede a usuários individuais em hardwares 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 em um pool DHCP foram atribuídos, impedindo que novos dispositivos obtenham um endereço e, portanto, 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 conectado ao SSID, mas não tem internet. Diagnosticado verificando a utilização de concessões DHCP no servidor.
Exemplos práticos
Um hotel de 200 quartos que usa pontos de acesso HPE Aruba relata que os hóspedes em dispositivos Android não conseguem acessar o Captive Portal, enquanto os usuários de iOS se conectam sem problemas. A equipe de TI confirmou que a URL do portal está acessível a partir da VLAN de gerenciamento.
A equipe 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. Esses domínios do Google quase certamente estão ausentes do walled garden. Adicioná-los à lista de permissões de pré-autenticação resolve o problema. A equipe também deve adicionar connectivitycheck.android.com como uma URL secundária de teste do Android. Depois de atualizar o walled garden, reinicie os SSIDs afetados e teste em um dispositivo Android com as configurações de fábrica para confirmar a correção, pois o estado de rede armazenado em cache em um dispositivo conectado anteriormente pode mascarar o resultado.
Uma rede de varejo com 150 dispositivos Cisco Meraki MX relata que os convidados se autenticam na splash page da Purple - o painel da Purple mostra logins bem-sucedidos - mas os convidados ainda não têm acesso à internet após preencherem o formulário. O problema afeta todos os locais simultaneamente.
Como a plataforma em nuvem da Purple mostra logins bem-sucedidos, a etapa de autenticação em si está funcionando. A falha está na etapa de autorização - o dispositivo Meraki não está recebendo ou agindo com base na mensagem RADIUS Access-Accept dos servidores RADIUS da Purple. A equipe deve verificar três coisas em sequência: primeiro, verificar se o segredo compartilhado do RADIUS no painel da Meraki corresponde exatamente ao segredo no portal da Purple (uma diferença de um único caractere causa falha silenciosa); segundo, confirmar se o tráfego UDP de saída nas portas 1812 e 1813 é permitido do dispositivo 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 esse tráfego. Como o problema afeta todos os 150 locais simultaneamente, a causa provavelmente é uma alteração na política de firewall centralizada ou uma alteração no endereço IP do servidor RADIUS da Purple que não foi propagada para as configurações do Meraki.
Questões práticas
Q1. Durante uma grande conferência em um local com capacidade para 5.000 pessoas, a equipe de TI recebe relatos de que centenas de participantes não conseguem acessar o portal de WiFi para 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 depois que o evento já estava em andamento, não no lançamento. Considere qual recurso se torna limitado à medida que mais dispositivos se conectam.
Ver resposta modelo
A causa mais provável é o esgotamento do pool DHCP. À medida que os participantes chegavam e se associavam ao SSID, o pool DHCP ficou cheio. Novos dispositivos se associam ao ponto de acesso, mas não conseguem obter um endereço IP, por isso nunca enviam a verificação HTTP necessária para acionar o Captive Portal. A correção imediata é 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 de longo prazo é dimensionar o pool DHCP para o número máximo de dispositivos simultâneos no próximo evento, não para a média.
Q2. Você implantou o Purple em pontos de acesso Ubiquiti UniFi em uma rede de varejo. A splash page carrega corretamente em todos os dispositivos. Os visitantes 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 logins como bem-sucedidos. O que você verifica primeiro?
Dica: A plataforma de nuvem registrou 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 nuvem foi concluída corretamente. A falha está na etapa de autorização RADIUS - o controlador UniFi não está recebendo ou agindo com base na mensagem Access-Accept dos servidores RADIUS do Purple. Verifique nesta ordem: (1) se o segredo compartilhado RADIUS no controlador UniFi corresponde exatamente ao segredo no painel do Purple; (2) se o 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á chegando.
Q3. Um gerente de TI de um hotel relata que os hóspedes que usam uma VPN em seus dispositivos não conseguem acessar o Captive Portal de forma alguma. Hóspedes sem VPN conectam-se normalmente. O hotel usa appliances Cisco Meraki MX. A equipe de TI deve alterar a configuração do Captive Portal para acomodar os usuários de VPN?
Dica: Considere o que uma VPN faz com o tráfego de rede do dispositivo antes que o Captive Portal possa interceptá-lo.
Ver resposta modelo
Não - a configuração do Captive Portal não precisa mudar. Um cliente VPN criptografa todo o tráfego do dispositivo antes de sair dele, incluindo a verificação de conectividade HTTP. O gateway não pode interceptar o tráfego de VPN criptografado, por isso nunca emite o redirecionamento 302. O hóspede deve desativar a VPN, concluir a autenticação no Captive Portal e, em seguida, reativar a VPN. Essa é uma limitação arquitetônica fundamental de Captive Portals e VPNs, não um erro de configuração. A equipe de TI deve adicionar uma observação às instruções de WiFi dos hóspedes aconselhando os usuários de VPN a desativarem suas VPNs antes de conectar.
Continue a ler esta série
Solucionando problemas de WiFi público: corrigindo 'Conectado, sem internet' e falhas de redirecionamento de splash page
Este guia de referência técnica de autoridade explica a mecânica subjacente da detecção de Captive Portal e detalha os seis principais modos de falha que impedem a conexão do WiFi de convidados. Ele fornece aos gerentes de TI e arquitetos de rede uma estrutura prática de solução de problemas para resolver problemas de redirecionamento HTTP, conflitos de DNS e desafios de randomização de MAC.
Principais 10 Causas de Timeouts de DHCP em Redes Sem Fio de Alta Densidade
Este guia de referência técnica definitivo identifica as dez principais causas de timeouts de DHCP em redes sem fio de alta densidade e fornece estratégias de remediação práticas e independentes de fornecedor. Projetado para líderes seniores de TI, arquitetos de rede e diretores de operações de locais de grande porte, ele abrange princípios profundos de engenharia, fluxos de trabalho de implementação passo a passo e resultados de negócios mensuráveis. Saiba como eliminar gargalos de conexão e otimizar sua infraestrutura de Wi-Fi para fornecer conectividade contínua em ambientes corporativos exigentes.
Usando Packet Capture (PCAP) para Diagnosticar Desempenho Lento de WiFi
Este guia de referência técnica fornece a gerentes de TI, arquitetos de rede e diretores de operações de locais um método estruturado em nível de pacote para diagnosticar e resolver o desempenho lento de WiFi corporativo usando a análise de Packet Capture (PCAP). Ao dissecar frames 802.11 brutos — incluindo taxas de retransmissão, utilização de tempo de antena (airtime) e metadados da camada física —, as equipes podem isolar gargalos da camada de RF de problemas de rede cabeada ou de aplicações com precisão. Aplicável a locais de alta densidade, incluindo hotéis, redes de varejo, estádios e centros de convenções, este guia oferece fluxos de trabalho de diagnóstico práticos, estudos de caso reais e etapas de correção de configuração para recuperar a capacidade da rede e proteger a experiência do convidado.