Solucionando Problemas de Redirecionamento de Captive Portal: Resolvendo Falhas de Conexão de WiFi de Visitantes
Quando os visitantes se conectam ao seu WiFi mas não conseguem acessar a internet, a causa quase sempre é um captive portal mal configurado - não uma falha de hardware. Este guia fornece uma referência técnica aprofundada para gerentes de TI, arquitetos de rede e CTOs para diagnosticar e resolver toda a cadeia de falhas: desde testes de conectividade em nível de SO e conflitos de certificado HSTS até lacunas de autorização RADIUS e esgotamento de DHCP. Ele mapeia cada modo de falha para uma solução concreta e mostra como a sobreposição 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 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 consulta "guest WiFi connected but no internet" (WiFi de convidados conectado, mas sem internet) é um dos chamados 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 compreendam a cadeia de redirecionamento. Um Captive Portal (também chamado de splash page ou hotspot gateway) intercepta a tentativa inicial de conexão HTTP de um dispositivo e emite um redirecionamento HTTP 302 para uma página de login. Se qualquer etapa dessa cadeia falhar - sondagens bloqueadas, conflitos de HSTS, falhas de walled garden, falhas de RADIUS ou exaustão de DHCP - o convidado vê apenas um ícone de WiFi conectado e nenhuma 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 de hotelaria, varejo, transporte e setor público.
Análise técnica aprofundada
Como a detecção de Captive Portal realmente funciona
Todo sistema operacional principal vem 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 sondagem por plataforma.
| Sistema operacional | 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 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 pseudo-navegador (um WebView leve) para exibir a splash page. Se a sondagem for totalmente bloqueada, o SO relatará "Sem conexão com a internet" e nunca tentará abrir o portal. Esta é a causa individual mais comum do sintoma "guest WiFi connected but no internet".
O problema do HSTS
HTTP Strict Transport Security (HSTS) é uma política de segurança web definida na RFC 6797. Ela instrui os navegadores a recusarem todas as conexões HTTP simples para um domínio e a rejeitarem qualquer certificado que não corresponda exatamente. Grandes 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 consegue interceptar uma solicitação HTTPS e redirecioná-la de forma limpa - ele teria que apresentar um certificado para google.com, o qual ele não possui. O navegador detecta a incompatibilidade de certificado e exibe um aviso de segurança grave. O visitante não consegue 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 jardim murado (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 pode 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 JavaScript deles devem ser pré-autenticados.
- Domínios da plataforma Purple: o overlay de nuvem da Purple exige que o gateway alcance os servidores RADIUS e os endpoints de 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 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 lacuna de autorização - em que um visitante faz login com sucesso na tela de autenticação, mas continua sem internet - quase sempre significa que o gateway não recebeu ou não processou a mensagem de Access-Accept. Causas comuns incluem uma chave secreta compartilhada incompatível, portas UDP 1812 e 1813 bloqueadas por um 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, o esgotamento do DHCP é uma causa frequente de falhas de conexão que parecem idênticas a um problema no 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 pode enviar a sonda HTTP e nunca chega ao captive portal. O dispositivo aparece como conectado ao SSID, mas fica 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 concessão (lease time) 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
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 a sobreposição de nuvem da Purple.
Etapa 1: Configurar o SSID para captive portal externo. No seu controlador de hardware, configure o SSID de visitantes para redirecionar clientes não autenticados para a URL do portal externo da Purple. Desative qualquer splash page local no próprio controlador.
Etapa 2: Definir o walled garden. Adicione os seguintes domínios, no mínimo: os endpoints de portal e RADIUS da Purple (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 ativos da sua splash page utilizem.
Etapa 3: Configurar o RADIUS. Insira os endereços IP do servidor RADIUS da Purple, o segredo compartilhado do seu painel 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 hotelaria e varejo, defina a duração da sessão para 24 horas com o cache de endereço MAC ativado. Isso evita que os visitantes 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 DHCP. Calcule a contagem máxima de dispositivos simultâneos para o seu local na capacidade de pico. Um restaurante com 500 assentos pode registrar 800 dispositivos durante um serviço movimentado. Dimensione o pool de DHCP para 1.000 endereços com um tempo de concessão de 30 minutos.
Etapa 6: Testar em diferentes sistemas operacionais. Após a configuração, teste o fluxo completo em dispositivos iOS, Android e Windows. Cada um usa uma URL de sonda e uma implementação de WebView diferente. Uma falha em uma 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 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.
Melhores práticas
As recomendações a seguir refletem padrões estabelecidos 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 dominar todos: WiFi de convidados, Passpoint e IoT para detalhes de arquitetura.
Use uma VLAN de convidados dedicada. Segmente o tráfego de convidados em sua própria VLAN para evitar a movimentação lateral e simplificar as políticas de firewall. Este é um requisito do PCI-DSS se houver dados de cartões de pagamento trafegando 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 estabelecimentos 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 no RADIUS ou no walled garden antes que os convidados comecem a reclamar.
Aplique uma identidade visual 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 excelente primeira impressão com o seu WiFi de convidados para orientações de design.
-
Resoluçã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 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á acessar a splash page mesmo se o redirecionamento for emitido corretamente. Verifique se o seu servidor DHCP está distribuindo endereços DNS confiáveis e se o gateway permite consultas DNS no estado de 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 solicitação de teste do OS seguida por uma resposta HTTP 302 contendo a URL do portal. Se você vir a solicitação de teste, mas nenhuma resposta 302, o gateway não está interceptando corretamente. Se não vir nenhuma solicitação de teste, o OS já determinou que possui 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 tarifação (accounting) do RADIUS. Uma autenticação bem-sucedida produz um registro Accounting-Start. Se você não vir registros de tarifação após o login de um convidado, a comunicação RADIUS está com falha. Verifique o segredo compartilhado, o IP do servidor e as regras de firewall.
Verifique a utilização de concessão 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 os 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 do walled garden | Adicione connectivitycheck.gstatic.com ao walled garden |
| Erro de certificado HTTPS no carregamento do portal | Gateway interceptando HTTPS em vez de HTTP | Confie apenas na interceptação de sonda HTTP |
| O portal carrega, sem 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 convidados devem se autenticar novamente a cada visita | Duração da sessão muito curta ou armazenamento em cache de MAC desativado | Defina a sessão para 24 horas, ative o armazenamento em cache de endereço MAC |
| Falhas intermitentes nos 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 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 opt-in por mês. Esses registros impulsionam campanhas de e-mail personalizadas com taxas de abertura comprovadamente mais altas do que as de 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 estabelecimentos. 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 Guest WiFi confiável é uma métrica de satisfação dos passageiros acompanhada no nível da diretoria. Um portal que falha de forma intermitente 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 tempo de atividade da Purple garante que a sobreposição em nuvem não seja o ponto de falha. Quando ocorrem problemas no portal, a causa quase sempre é a configuração local - a qual este guia capacita você a resolver sem abrir um ticket 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 conecta a uma rede antes que o acesso total à internet seja concedido. O gateway intercepta a sondagem 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 visitantes, desde lobbies 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 os destinos do walled garden ignora a necessidade de autenticação.
Deve incluir URLs de sondagem do 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 sonda `msftconnecttest.com` para determinar se o dispositivo possui acesso à internet ou se está atrás de um Captive Portal. Definido na documentação de rede da Microsoft.
Se o gateway bloquear essa sondagem, o Windows reportará "Sem acesso à internet" e nunca acionará o WebView do Captive Portal. A correção consiste em 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.
Impede que os gateways interceptem requisições HTTPS para redirecionamento do Captive Portal. Domínios importantes, incluindo google.com, constam 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 em uma URI diferente, fornecida no cabeçalho Location.
O mecanismo que os gateways utilizam para desviar a sondagem 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 de nuvem da Purple atua como o servidor RADIUS. O gateway local (Meraki, Aruba, etc.) envia requisições de autenticação para os servidores RADIUS da Purple e age com base na resposta de Access-Accept ou Access-Reject.
Cache de endereço MAC
O processo de armazenamento do 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 conexões perdidas brevemente 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 analytics são aplicados 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 de 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, consequentemente, alcancem o Captive Portal.
Comum em locais de alta densidade durante períodos de pico. Manifesta-se de forma idêntica a uma falha de Captive Portal - o dispositivo mostra-se conectado 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 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 jardim murado (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 connectivitycheck.gstatic.com e clients3.google.com/generate_204. Esses domínios do Google quase certamente estão ausentes do jardim murado. 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. Após atualizar o jardim murado, 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 visitantes se autenticam na página splash da Purple - o painel da Purple mostra logins bem-sucedidos - mas os visitantes ainda não têm acesso à internet após preencher o formulário. O problema afeta todos os locais simultaneamente.
Como a plataforma de 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 de acordo com a mensagem Access-Accept do RADIUS vinda 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 do 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 de NAT que bloqueia esse tráfego. Como o problema afeta todos os 150 locais simultaneamente, a causa provável é 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 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 de visitantes. 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 correção imediata?
Dica: O problema começou após o início do evento, 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 ficava cheio. Os 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 (liberando 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 DHCP para o número máximo de dispositivos simultâneos no próximo evento, e não pela 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, ao tentarem navegar, ficam sem acesso à internet. O painel do Purple mostra os logins como bem-sucedidos. O que você verifica primeiro?
Dica: A plataforma em 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 de acordo com a mensagem Access-Accept dos servidores RADIUS do Purple. Verifique nesta ordem: (1) se o segredo compartilhado 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á chegando.
Q3. Um gerente de TI de um hotel relata que hóspedes usando VPN em seus dispositivos não conseguem acessar o Captive Portal de forma alguma. Hóspedes sem VPN se conectam normalmente. O hotel usa dispositivos Cisco Meraki MX. A equipe de TI deve alterar a configuração do Captive Portal para acomodar 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 ser alterada. Um cliente VPN criptografa todo o tráfego do dispositivo antes que ele saia do aparelho, incluindo a verificação de conectividade HTTP. O gateway não consegue interceptar o tráfego de VPN criptografado, por isso nunca emite o redirecionamento 302. O hóspede precisa desativar a VPN, concluir a autenticação no Captive Portal e depois reativar a VPN. Esta é 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 orientando os usuários de VPN a desativarem a sua VPN antes de se conectarem.
Continue a ler esta série
Ubiquiti UniFi guest portal not redirecting: causes and fixes
Este guia isola uma falha de redirecionamento do portal de convidados UniFi seguindo a sequência do status do convidado, redirecionamento, rota de pré-autorização e autorização do controlador. Ele oferece às equipes de TI do local um método fundamentado para lidar com a confusão entre rede de convidados e Hotspot, redirecionamentos para portais externos, requisitos atuais de conta do UniFi OS e testes de isolamento de DNS.
Cisco Meraki splash page não está funcionando: um fluxograma de solução de problemas
Este guia prático do dia a dia isola onde um fluxo de splash da Cisco Meraki falhou: autorização do cliente, início de redirecionamento HTTP, acessibilidade do walled-garden ou sign-on RADIUS. Ele oferece às equipes de TI do local um caminho de evidências controlado, para que possam restaurar o Guest WiFi sem fazer alterações amplas em um ambiente ativo.
Guia de Configuração de WiFi para Visitantes Corporativos: Segmentação por VLAN, Segurança e Portais Captivos
Este guia técnico mostra às equipes de TI como configurar o WiFi para Visitantes como um serviço de acesso à internet controlado, usando segmentação por VLAN, política de firewall e um Captive Portal. Ele também explica como os formulários de registro e controles de integração do Purple oferecem suporte a uma experiência de visitante proporcional, sem enfraquecer o limite em torno dos sistemas operacionais, de pagamento e da equipe.
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 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.