Solução de problemas em redirecionamentos de portal cativo: Resolvendo falhas de conexão no WiFi para visitantes

Quando o WiFi para visitantes mostra conectado, mas sem internet, o dispositivo se conectou à rede, mas o redirecionamento do portal cativo falhou. As causas mais comuns são a bloqueio da verificação do sistema operacional, entradas ausentes no walled garden ou falha no DNS. Outras causas incluem o esgotamento do pool DHCP ou um Access-Accept do RADIUS que nunca chega ao gateway. Cada um desses problemas pode ser corrigido na configuração.

Como é a aparência do aviso "WiFi para visitantes conectado, mas sem internet"?

O dispositivo se conecta ao nome da rede (SSID) e exibe sinal cheio, mas nada carrega. Cada plataforma exibe essa situação de forma diferente:

• O iOS exibe "Sem Conexão com a Internet" abaixo do nome da rede.
• O Android exibe "Conectado, sem internet" ou uma solicitação para "Fazer login na rede" que não leva a lugar nenhum.
• O Windows marca a rede como "Sem internet".

O visitante vê o ícone do WiFi funcionando e o navegador sem carregar, o que o faz culpar o local.

Um mesmo sintoma pode ocultar falhas diferentes. Geralmente, você verá um destes padrões:

• A página de login nunca é exibida em nenhum dispositivo.
• A página de login aparece em iPhones, mas não em telefones Android, ou vice-versa.
• O navegador exibe um aviso de certificado ou de privacidade em vez da página de login.
• O visitante preenche o formulário, vê uma mensagem de sucesso, mas continua sem internet.
• Tudo funciona em horários de pouco movimento e falha nos horários de pico.

Cada padrão indica um problema em uma camada diferente da rede. Comece analisando o padrão, em vez de reiniciar os pontos de acesso.

Como funciona a detecção do portal cativo

Um portal cativo é a página da web que um gateway exibe antes de liberar o acesso à internet. O gateway é o seu controlador, firewall ou ponto de acesso, dependendo da sua arquitetura.

Todos os principais sistemas operacionais verificam a presença de um portal cativo assim que se conectam a uma rede. O sistema envia uma requisição HTTP simples para um endereço conhecido e compara a resposta com o resultado esperado. Cada resultado tem um significado diferente:

• A resposta corresponde. O dispositivo presume que possui acesso livre à internet.
• O gateway retorna um redirecionamento HTTP 302. O dispositivo identifica que está atrás de um portal. Ele abre uma janela de navegador simples, frequentemente chamada de assistente de rede cativa, e carrega a sua página de login.
• A requisição não recebe resposta. O dispositivo informa que está sem internet e não abre nada.

A Microsoft documenta que o seu Indicador de Status de Conectividade de Rede (NCSI) também resolve dns.msftncsi.com para verificação de DNS. Por isso, um notebook Windows pode informar que está sem internet quando o DNS pré-autenticação está com falha, mesmo que o HTTP esteja funcionando.

O que geralmente faz com que o redirecionamento do portal cativo falhe?

Sete causas respondem pela maioria dos casos. Elas estão em camadas diferentes, do endereçamento até a autenticação.

A sondagem do sistema operacional está bloqueada

A lista de controle de acesso (ACL) pré-autenticação do gateway descarta a sondagem em vez de redirecioná-la. O dispositivo não recebe resposta e decide que não há internet. Ele nunca abre o portal.

Um serviço de filtragem de DNS que bloqueia os hostnames de sondagem causa o mesmo efeito. Este é o motivo mais comum para um portal nunca aparecer.

HTTPS e HSTS quebram a interceptação

O HTTP Strict Transport Security (HSTS), definido na RFC 6797, instrui os navegadores a acessar um domínio apenas via HTTPS. Os navegadores vêm com uma lista de pré-carregamento de domínios HSTS, incluindo os do Google e da maioria dos bancos. Quando um visitante digita google.com, o navegador atualiza para HTTPS antes que a requisição saia do dispositivo.

O gateway não pode redirecionar essa requisição sem apresentar um certificado para google.com, o qual ele não possui. O navegador exibe um aviso de segurança definitivo sem opção de prosseguir.

A solução é redirecionar apenas as sondagens HTTP simples da tabela acima, que existem exatamente para esse propósito. Nunca intercepte HTTPS para redirecionamento de portal.

O jardim murado é muito restrito

O jardim murado é a lista de domínios e endereços IP que um dispositivo pode acessar antes de se autenticar. Se uma entrada estiver faltando, a página de login carrega parcialmente ou a etapa de logon falha. As lacunas comuns são:

• Endpoints de provedores de identidade para login social ou de logon único (SSO), como Microsoft Entra ID, Okta ou Google Workspace.
• Domínios de rede de entrega de conteúdo (CDN) que hospedam as fontes, scripts e folhas de estilo da sua página de login.
• Domínios do processador de pagamento, caso você cobre pelo acesso.
• Endpoints do portal cativo e RADIUS da Purple, listados no guia de integração da Purple para o seu hardware.

O DNS falha antes da autenticação

O dispositivo precisa resolver o hostname do portal antes de conseguir carregar a página. O redirecionamento não leva a lugar nenhum em dois casos:

• O gateway bloqueia o DNS no estado de pré-autenticação.
• O DHCP fornece um servidor DNS que o dispositivo não consegue alcançar.

O Android adiciona uma complicação. Se um visitante definiu um hostname de DNS Privado específico, o Android espera DNS sobre TLS na porta 853. No modo automático, ele recorre ao DNS comum.

O pool de DHCP está esgotado

Quando o pool de endereços se esgota, um novo dispositivo se associa ao ponto de acesso, mas não recebe um endereço IP. O Windows se atribui um endereço link-local 169.254.x.x, e outros sistemas mostram um estado autoatribuído semelhante.

Sem um endereço válido, o dispositivo não consegue enviar uma sondagem. Ele parece conectado, mas não tem internet. Esta é a falha clássica em horários de pico em estádios, centros de convenções e terminais de transporte.

O RADIUS nunca entrega o Access-Accept

O RADIUS (Remote Authentication Dial-In User Service) carrega a decisão de login do servidor de autenticação para o seu gateway. O servidor responde com Access-Accept ou Access-Reject, conforme definido na RFC 2865. O gateway então libera o acesso ou o mantém fechado.

Um visitante que preenche o formulário, mas permanece offline, quase sempre significa que o gateway não recebeu o Access-Accept. As três causas mais comuns são:

• Uma chave secreta compartilhada incompatível.
• Um firewall bloqueando UDP 1812 (autenticação) ou UDP 1813 (accounting). As RFC 2865 e RFC 2866 definem essas portas.
• O endereço de servidor incorreto no controlador.

O próprio certificado do portal expirou

Sua página de login é exibida via HTTPS. Se o certificado TLS expirar, qualquer navegador moderno bloqueará a página com um aviso de segurança. O redirecionamento funciona perfeitamente, mas o visitante ainda não consegue fazer login.

Como identificar qual é a causa?

Avance na pilha em ordem. Cada verificação descarta uma camada, portanto, pare na primeira falha.

1. O dispositivo possui um endereço IP válido? Execute ipconfig /all no Windows ou verifique os detalhes da rede em um telefone. Um endereço 169.254.x.x, ou a ausência de um endereço, indica problemas no DHCP. Verifique a utilização do pool no servidor DHCP. Acima de 90%, você está próximo do esgotamento.
2. O DNS é resolvido? A partir de um dispositivo na LAN virtual de visitantes (VLAN), um segmento de rede logicamente separado, consulte o nome de host do portal. Se a consulta falhar, o DNS de pré-autenticação está bloqueado ou o servidor DNS atribuído pelo DHCP está incorreto.
3. A sonda recebe um 302? Realize uma captura de pacotes na VLAN de visitantes ou navegue até um dos URLs de sonda HTTP. Você deve ver a sonda e, em seguida, um HTTP 302 apontando para o portal. Uma sonda sem resposta significa que a ACL a descartou. A ausência total de sonda significa que o dispositivo considera que já está online, geralmente devido a um estado em cache. Esqueça a rede e reconecte-se.
4. A página de login é carregada completamente? Abra as ferramentas do desenvolvedor do navegador (F12) e observe a guia de rede. Solicitações bloqueadas para domínios de terceiros indicam falhas no walled garden.
5. O gateway recebe um Access-Accept? Verifique os logs de RADIUS do controlador. Um login bem-sucedido é seguido por um Accounting-Request com status Start. Se nenhum registro de accounting aparecer após o login, o caminho do RADIUS está interrompido.

Em seguida, compare o que você vê com esta tabela.

Cenário prático: um centro de convenções de 1.500 lugares no pico

Situação. Um centro de convenções operava sua rede de participantes em uma única sub-rede /24 com lease de DHCP de oito horas. As palestras de abertura da manhã funcionaram sem problemas. Após o almoço, os participantes que chegavam para as sessões da tarde viram a mensagem "conectado, sem internet". O suporte tratou o caso como uma falha no portal e reiniciou o controlador duas vezes.

O que foi feito. A Etapa 1 do diagnóstico identificou que os novos dispositivos estavam com endereços 169.254.x.x. Uma sub-rede /24 oferece 254 endereços utilizáveis, e o lease de oito horas manteve todos os endereços da manhã reservados. A equipe mudou a VLAN dos participantes para uma /21 e reduziu o lease para 30 minutos.

Resultado. Os endereços utilizáveis subiram de 254 para 2.046, aproximadamente oito vezes a capacidade anterior. Um endereço deixado por um participante que foi embora agora retorna ao pool em 30 minutos, e não em oito horas. A correção exigiu apenas uma janela de alteração e nenhum hardware novo.

Cenário prático: um hotel de 200 quartos onde os hóspedes com Android não conseguiam fazer login

Situação. Após a reformulação da página de login, um hotel de 200 quartos recebeu reclamações na recepção de hóspedes com Android. A maioria deles escolheu a opção de login do Google. O portal aparecia, mas o botão não fazia nada.

O que foi feito. O gerente de TI testou o fluxo em um iPhone, um celular Android e um notebook Windows. As ferramentas de desenvolvedor no notebook mostraram solicitações bloqueadas para uma rede de distribuição de fontes e para os domínios de login do Google. A reformulação havia adicionado ambos. A equipe os adicionou ao walled garden.

Resultado. O login do Google foi concluído nos três dispositivos de teste na primeira tentativa. A correção precisou de duas entradas no walled garden e nenhuma alteração de hardware.

Cenário prático: uma rede varejista de 40 lojas após a atualização do firewall

Situação. Um varejista substituiu os firewalls em 40 lojas durante um fim de semana. Na segunda-feira, os clientes de todas as lojas atualizadas conseguiam preencher o formulário de login, mas permaneciam offline. As lojas ainda não atualizadas funcionavam normalmente.

O que foi feito. A Etapa 5 não encontrou registros de contabilização das lojas atualizadas. O novo modelo de firewall bloqueava o UDP de saída por padrão, impedindo as portas 1812 e 1813. A equipe adicionou regras explícitas de saída ao modelo e o aplicou a todas as 40 lojas.

Resultado. Os registros de contabilização reapareceram de todas as lojas após o envio da atualização. Como apenas as lojas atualizadas falhavam, o padrão apontou diretamente para o modelo e descartou problemas na WiFi.

Como corrigir isso em cada sistema operacional e controlador?

A correção no controlador segue o mesmo padrão em todas as plataformas. As correções nos sistemas operacionais consistem principalmente em saber como cada um se comporta.

No seu controlador

O Purple roda como uma sobreposição em nuvem no Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. O padrão de correção é o mesmo em todos os oito:

1. Apontar o SSID para visitantes para a URL do portal cativo externo presente no seu guia de integração da Purple e desativar qualquer página de boas-vindas local.
2. Redirecionar o tráfego HTTP não autenticado, incluindo as sondas (probes), para essa URL. Não alterar o tráfego HTTPS.
3. Permitir DNS e DHCP antes da autenticação.
4. Adicionar as entradas do walled garden: endpoints da Purple, endpoints do provedor de identidade e domínios de ativos da página de login.
5. Inserir os endereços de servidor RADIUS e o segredo compartilhado a partir do seu painel da Purple. Em seguida, confirmar se o firewall permite o tráfego UDP de saída nas portas 1812 e 1813.

Os nomes dos menus variam de acordo com o fabricante e a versão do firmware, portanto, siga o guia de integração da Purple específico para a sua plataforma. A documentação da comunidade do Fortinet sobre o fluxo de portal cativo no FortiGate é uma referência útil do lado do fabricante para a sequência de redirecionamento.

No iOS e no macOS

Se o assistente de rede cativa não abrir, esqueça a rede nas Configurações e conecte-se novamente. Isso força uma nova sonda.

As versões recentes do iOS e do macOS também suportam a API do portal cativo. Ela permite que a rede anuncie seu portal por meio da opção 114 do DHCP, definida na RFC 8910, o que reduz a dependência de interceptação. Se o assistente abrir, mas permanecer em branco, verifique os domínios de ativos no walled garden.

No Android

O Android exibe uma notificação de "Fazer login na rede" quando detecta um portal. Se a notificação nunca aparecer, confirme se o gateway redireciona o endereço connectivitycheck.gstatic.com em vez de descartá-lo.

Se um visitante visualizar a mensagem "Servidor de DNS privado inacessível", significa que o telefone possui um nome de host de DNS privado estrito configurado. Você tem duas opções:

• Permitir DNS sobre TLS na porta 853 antes da autenticação.
• Solicitar ao visitante que altere o DNS privado para o modo automático.

No Windows

O Windows depende da sonda HTTP do NCSI e de sua verificação de DNS. Se o portal não abrir automaticamente, navegue até qualquer site HTTP comum para disparar o redirecionamento manualmente. A mensagem persistente de "Sem conexão com a internet" após o login geralmente significa que o gateway ainda está redirecionando a sonda. Nesse caso, o gateway não aplicou o Access-Accept.

No navegador

Oriente a equipe de linha de frente a direcionar os visitantes para um endereço HTTP, nunca para um domínio HSTS, como google.com. O Firefox executa sua própria sonda em detectportal.firefox.com; portanto, inclua esse host em seus testes de redirecionamento.

Como evitar que falhas de redirecionamento no WiFi para visitantes voltem a acontecer?

A maioria dos incidentes recorrentes resulta de alterações, não da configuração original. Uma atualização de firmware, um novo modelo de firewall, um reformulação da página de login ou um certificado expirado podem passar sem serem testados. Incorpore estes controles ao seu processo de mudança:

• Teste em três plataformas após cada alteração. Utilize um iPhone, um telefone Android e um notebook Windows. Se uma plataforma falhar enquanto as outras funcionarem, verifique primeiro se há lacunas no walled garden.
• Dimensione para o pico, não para a média. Calcule o número máximo de dispositivos simultâneos e adicione uma margem de segurança. Redes temporárias para visitantes costumam utilizar tempos de concessão (leases) de 15 a 30 minutos.
• Configure as sessões para corresponder à visita. Locais de hospitalidade e varejo costumam configurar sessões de 24 horas, para que o visitante faça login apenas uma vez por estadia ou visita.
• Acompanhe os volumes de login diariamente. Os relatórios do WiFi Analytics da Purple exibem logins por local. Uma queda repentina em um local alerta você sobre uma falha de RADIUS ou de jardim murado, geralmente antes que os visitantes se queixem.
• Coloque certificados e segredos compartilhados sob controle de alterações. Agende a data de expiração do certificado do portal. Armazene o segredo compartilhado de RADIUS onde as equipes de firewall e de controladores possam verificar.
• Segmente o tráfego de visitantes. Coloque os visitantes em sua própria VLAN. O PCI DSS considera a segmentação como a forma de manter uma rede de visitantes fora do escopo do seu ambiente de dados de portadores de cartão.
• Planeje para a randomização de MAC. Versões recentes do iOS e do Android usam um endereço MAC aleatório para cada rede, e alguns modos o alternam com o tempo. O armazenamento em cache de sessão baseado no endereço MAC solicitará que os visitantes recorrentes façam login novamente.
• Colete o consentimento adequadamente. O GDPR exige consentimento informado e afirmativo para dados de marketing. As opções de aceitação por escolha consciente da Purple apresentam uma escolha separada para cada finalidade.

Remova os visitantes recorrentes do portal cativo

A correção mais duradoura remove completamente o redirecionamento para visitas repetidas.

• Passpoint é a certificação do setor desenvolvida com base na especificação Hotspot 2.0. Ela permite que um dispositivo se conecte a uma rede automaticamente usando um perfil armazenado.
• OpenRoaming, administrado pela Wireless Broadband Alliance, federa provedores de identidade. As credenciais existentes de um visitante funcionam em todos os locais participantes.

Ambos usam o IEEE 802.1X, o padrão para controle de acesso à rede baseado em porta, portanto, não há portal para apresentar falhas.

Onde a Purple se encaixa

O WiFi para visitantes da Purple opera como uma sobreposição em nuvem independente de hardware, para que você corrija falhas de redirecionamento na configuração, e não com novos equipamentos. A Purple atende a mais de 80.000 locais ativos em mais de 90 países e suporta 500 milhões de usuários e logins por ano. A plataforma opera com 99,999% de disponibilidade e possui certificações ISO 27001, Cyber Essentials e B Corp. Também está em conformidade com o GDPR e o CCPA.

Quando um portal falha, a causa quase sempre é local: uma regra de sondagem, uma entrada no walled garden, um pool DHCP ou uma regra de firewall.

Os padrões se repetem entre os setores:

• Hotéis sentem falhas de redirecionamento nos picos de check-in.
• Redes de varejo as sentem após alterações de firewall em toda a empresa.
• Trens e estações enfrentam pressão de DHCP à medida que os passageiros embarcam em ondas.
• Locais de saúde precisam de WiFi para visitantes e pacientes WiFi que funcione sem envolver a equipe clínica em chamados de suporte.

Perguntas frequentes

O Purple funciona com os pontos de acesso que já possuímos?

Sim. O Purple independe de hardware e é executado como uma sobreposição em nuvem no Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Você mantém seus pontos de acesso e controladores existentes. Você direciona sua rede WiFi para visitantes SSID para o portal cativo do Purple, adiciona as entradas do walled garden e os detalhes do RADIUS a partir do guia de integração do Purple e realiza os testes. Não há necessidade de substituição completa da infraestrutura.

Precisamos de novos hardwares para corrigir a situação em que o WiFi para visitantes WiFi está conectado, mas não há internet?

Não. Em quase todos os casos, a falha é de configuração: uma sondagem bloqueada, uma lacuna no walled garden, DNS de pré-autenticação, um pool DHCP esgotado ou uma regra de firewall do RADIUS. Você corrige cada um desses itens no controlador, firewall ou servidor DHCP que já utiliza. O hardware só se torna um problema se a densidade de pontos de acesso não puder atender ao seu pico de dispositivos, o que será indicado por uma vistoria no local.

O que é necessário para migrar nosso WiFi para visitantes WiFi para o Purple?

A migração para o Purple é um projeto de configuração, não um projeto de instalação. Em cada controlador, você define a rede WiFi para visitantes SSID para o portal externo do Purple e adiciona as configurações do walled garden e do RADIUS. Em seguida, você confirma as regras de firewall para UDP 1812 e 1813. Depois, cria sua página de login e opções de consentimento no Purple e realiza os testes em dispositivos iOS, Android e Windows. Redes com múltiplos locais podem padronizar as configurações dos controladores em modelos.

O portal cativo está em conformidade com o GDPR?

Sim, desde que o consentimento seja informado, específico e fornecido livremente. O GDPR exige uma escolha afirmativa separada para cada finalidade, como e-mails de marketing, e proíbe caixas pré-marcadas. As opções de adesão baseadas em escolha consciente do Purple apresentam cada opção separadamente. O Purple possui certificação ISO 27001, conta com a Cyber Essentials e está em conformidade com o GDPR e o CCPA. Isso fornece ao seu encarregado de proteção de dados os padrões que ele solicitará.

Os visitantes recorrentes podem ignorar a página de login?

Sim. O Passpoint e o OpenRoaming permitem que um dispositivo se conecte automaticamente usando um perfil armazenado ou uma identidade federada. Ambos usam autenticação IEEE 802.1X com criptografia WPA2 ou WPA3-Enterprise, eliminando falhas de redirecionamento do portal cativo em visitas recorrentes. Muitos locais utilizam ambos: um portal cativo para visitantes de primeira viagem e captura de dados, e o OpenRoaming para visitantes recorrentes, passageiros e estudantes.

Como saberemos quando os logins começarem a falhar?

Acompanhe os volumes de login por local. Os relatórios de análise do WiFi da Purple exibem os logins de cada unidade, permitindo que uma queda repentina em um local se destaque em relação ao padrão normal e aos seus outros estabelecimentos. Essa queda geralmente indica uma falha de RADIUS, walled garden ou DHCP introduzida por uma alteração recente. Identificar o problema no painel é muito mais rápido do que esperar que as reclamações da recepção cheguem ao TI.

Devemos usar um portal cativo ou uma senha de WiFi compartilhada?

Use um portal cativo se você deseja obter dados próprios e consentimento, e use uma senha compartilhada apenas se não precisar de nenhum dos dois. Uma chave pré-compartilhada criptografa o tráfego com WPA2 ou WPA3-Personal. No entanto, ela não fornece informações sobre quem se conectou, e a senha acaba sendo divulgada. Um portal cativo captura dados próprios consentidos, enquanto o Passpoint ou o OpenRoaming adiciona acesso automático e criptografado para visitas recorrentes.