Resolução de problemas de redirecionamento do portal cativo: Resolver falhas de ligação de WiFi para visitantes

Quando a rede WiFi mostra que está ligada mas sem internet, o dispositivo associou-se à rede, mas o redirecionamento do portal cativo falhou. As causas habituais são o bloqueio da verificação do sistema operativo, a falta de entradas no walled garden ou falhas no DNS. Outras causas incluem o esgotamento do conjunto de endereços DHCP ou uma resposta Access-Accept do RADIUS que nunca chega ao gateway. Qualquer uma destas situações pode ser corrigida na configuração.

Qual é o aspeto de "WiFi ligada mas sem internet"?

O dispositivo associa-se ao nome da rede (SSID) e apresenta sinal no máximo, mas nada carrega. Cada plataforma reporta a situação de forma diferente:

• O iOS apresenta "Sem Ligação à Internet" sob o nome da rede.
• O Android apresenta "Ligado, sem internet" ou a indicação "Iniciar sessão na rede" que não leva a lado nenhum.
• O Windows marca a rede como "Sem internet".

O visitante vê um ícone de WiFi a funcionar e um navegador inativo, pelo que atribui a culpa ao local.

Um sintoma pode ocultar várias falhas distintas. Normalmente, verá um destes padrões:

• A página de início de sessão nunca aparece em nenhum dispositivo.
• A página de início de sessão aparece em iPhones mas não em telemóveis Android, ou vice-versa.
• O navegador apresenta um aviso de certificado ou de privacidade em vez da página de início de sessão.
• O visitante preenche o formulário, vê uma mensagem de sucesso e continua sem internet.
• Tudo funciona em períodos de pouco tráfego e falha nas horas de ponta.

Cada padrão aponta para uma camada diferente da rede. Comece por analisar o padrão, em vez de reiniciar os pontos de acesso.

Como funciona a deteção do portal cativo

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

Todos os principais sistemas operativos verificam a existência de um portal cativo assim que se associam a uma rede. Enviam um pedido HTTP simples para um endereço conhecido e comparam a resposta com o resultado esperado. Cada resultado tem um significado diferente:

• A resposta corresponde. O dispositivo assume que tem acesso aberto à internet.
• O gateway devolve um redirecionamento HTTP 302. O dispositivo deteta que está atrás de um portal. Abre uma janela simplificada do navegador, frequentemente chamada assistente de rede cativa, e carrega a sua página de início de sessão.
• O pedido não obtém resposta. O dispositivo reporta que não tem internet e não abre nada.

A Microsoft documenta que o seu Network Connectivity Status Indicator (NCSI) também resolve dns.msftncsi.com como uma verificação de DNS. Por conseguinte, um portátil Windows pode reportar que não tem internet quando o DNS pré-autenticação está com falhas, mesmo que o HTTP funcione.

O que faz normalmente falhar o redirecionamento do portal cativo?

Sete causas são responsáveis pela maioria dos casos. Estão localizadas em diferentes camadas, desde o endereçamento até à autenticação.

O teste do sistema operativo está bloqueado

A lista de controlo de acessos (ACL) pré-autenticação do gateway rejeita o teste em vez de o redirecionar. O dispositivo não recebe resposta e conclui que não há internet. Por isso, nunca abre o portal.

Um serviço de filtragem de DNS que bloqueie os nomes de host do teste produz o mesmo efeito. Esta é a razão mais comum para um portal nunca aparecer.

O HTTPS e o HSTS interrompem a interceção

O HTTP Strict Transport Security (HSTS), definido na RFC 6797, indica aos navegadores para acederem a um domínio apenas via HTTPS. Os navegadores incluem uma lista pré-carregada de domínios HSTS, incluindo os da Google e a maioria dos bancos. Quando um visitante digita google.com, o navegador atualiza para HTTPS antes de o pedido sair do dispositivo.

O gateway não pode redirecionar esse pedido sem apresentar um certificado para google.com, o qual não possui. O navegador exibe um aviso de segurança grave sem opção de prosseguir.

A solução consiste em redirecionar apenas os testes HTTP simples apresentados na tabela acima, que existem exatamente para este propósito. Nunca intercepte HTTPS para redirecionamento de portal.

O jardim murado é demasiado restrito

O jardim murado é a lista de domínios e endereços IP que um dispositivo pode aceder antes de se autenticar. Se faltar uma entrada, a página de início de sessão carrega parcialmente ou a etapa de início de sessão falha. As lacunas habituais são:

• Pontos finais do fornecedor de identidade para início de sessão social ou autenticação única (SSO), como Microsoft Entra ID, Okta ou Google Workspace.
• Domínios da rede de distribuição de conteúdos (CDN) que fornecem os tipos de letra, scripts e folhas de estilo da sua página de início de sessão.
• Domínios do processador de pagamentos, caso cobre pelo acesso.
• Pontos finais do portal cativo da Purple e do RADIUS, listados no guia de integração da Purple para o seu hardware.

O DNS falha antes da autenticação

O dispositivo tem de resolver o nome de host do portal antes de poder carregar a página. O redirecionamento não leva a lado nenhum em dois casos:

• O gateway bloqueia o DNS no estado de pré-autenticação.
• O DHCP atribui um servidor DNS a que o dispositivo não consegue aceder.

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

O conjunto de endereços DHCP está esgotado

Quando o conjunto de endereços se esgota, um novo dispositivo associa-se ao ponto de acesso, mas não obtém endereço IP. O Windows atribui a si próprio um endereço de ligação local 169.254.x.x, e outros sistemas apresentam um estado de autoatribuição semelhante.

Sem um endereço válido, o dispositivo não consegue enviar um teste. Parece ligado, mas não tem internet. Esta é a falha clássica em horas de ponta em estádios, centros de conferências e interfaces de transporte.

O RADIUS nunca entrega o Access-Accept

O RADIUS (Remote Authentication Dial-In User Service) transporta a decisão de início de sessão 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 abre então o acesso ou mantém-no fechado.

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

• Um segredo partilhado incorreto.
• Um firewall a bloquear a porta UDP 1812 (autenticação) ou UDP 1813 (accounting). As RFC 2865 e RFC 2866 definem estas portas.
• O endereço de servidor errado no controlador.

O próprio certificado do portal expirou

A sua página de início de sessão é disponibilizada via HTTPS. Se o respetivo certificado TLS expirar, qualquer navegador moderno bloqueia a página com um aviso de segurança. O redirecionamento funciona perfeitamente, mas o visitante continua sem conseguir iniciar sessão.

Como determinar qual é a causa?

Verifique a pilha por ordem. Cada verificação exclui uma camada, por isso pare na primeira falha.

1. O dispositivo tem um endereço IP válido? Execute ipconfig /all no Windows ou verifique os detalhes da rede num telemóvel. Um endereço 169.254.x.x, ou a ausência de endereço, aponta para o DHCP. Verifique a utilização do pool no servidor DHCP. Acima de 90%, está perto da exaustão.
2. O DNS resolve? A partir de um dispositivo na LAN virtual de convidados (VLAN), um segmento de rede logicamente separado, pesquise o hostname do portal. Se a pesquisa falhar, o DNS pré-autenticação está bloqueado ou o servidor DNS atribuído pelo DHCP está errado.
3. O teste recebe um 302? Realize uma captura de pacotes na VLAN de convidados ou navegue para um dos URL de teste HTTP. Deverá ver o teste e, em seguida, um HTTP 302 a apontar para o portal. Um teste sem resposta significa que a ACL o está a descartar. Nenhum teste significa que o dispositivo considera que já está online, frequentemente devido a um estado em cache. Esqueça a rede e volte a ligar-se.
4. A página de início de sessão carrega completamente? Abra as ferramentas de programador do navegador (F12) e monitorize o separador de rede. Pedidos bloqueados para domínios de terceiros apontam para lacunas no walled garden.
5. O gateway recebe um Access-Accept? Verifique os registos de RADIUS do controlador. Um início de sessão bem-sucedido é seguido por um Accounting-Request com o estado Start. Se não surgir qualquer registo de accounting após o início de sessão, o caminho de RADIUS está interrompido.

Em seguida, compare o que observa com esta tabela.

Cenário prático: um centro de conferências de 1.500 lugares em hora de ponta

Situação. Um centro de conferências operava a sua rede de participantes numa única sub-rede /24 com uma concessão DHCP de oito horas. As palestras da manhã decorreram sem problemas. Após o almoço, os participantes que chegavam para as sessões da tarde viam a mensagem "ligado, sem internet". O suporte técnico tratou o problema como uma falha do portal e reiniciou o controlador duas vezes.

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

Resultado. Os endereços utilizáveis subiram de 254 para 2.046, cerca de oito vezes a capacidade anterior. Um endereço deixado por um participante que saía voltava para o intervalo dentro de 30 minutos, e não de 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 iniciar sessão

Situação. Após um redesign da página de início de sessão, um hotel de 200 quartos recebeu reclamações na receção da parte de hóspedes com Android. A maioria optava pelo início de sessão com o Google. O portal aparecia, mas o botão não fazia nada.

O que foi feito. O gestor de TI testou o fluxo num iPhone, num telemóvel Android e num portátil Windows. As ferramentas de programador no portátil mostraram pedidos bloqueados a uma rede de distribuição de fontes e aos domínios de início de sessão da Google. O redesign tinha adicionado ambos. A equipa adicionou-os à walled garden.

Resultado. O início de sessão com o Google foi concluído nos três dispositivos de teste na primeira tentativa. A correção exigiu duas entradas na walled garden e nenhuma alteração de hardware.

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

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

O que foi feito. O Passo 5 não encontrou registos de accounting das lojas atualizadas. O novo modelo de firewall negava UDP de saída por predefinição, bloqueando as portas 1812 e 1813. A equipa adicionou regras explícitas de saída ao modelo e aplicou-o a todas as 40 lojas.

Resultado. Os registos de accounting voltaram a surgir em todas as lojas após a aplicação. Como apenas as lojas atualizadas falhavam, o padrão apontou diretamente para o modelo e não para o WiFi WiFi.

Como resolver o problema em cada sistema operativo e controlador?

A resolução no controlador segue o mesmo padrão em todas as plataformas. As correções no sistema operativo dizem respeito, sobretudo, a saber como cada um se comporta.

No seu controlador

O Purple funciona como um overlay na nuvem em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. O padrão de resolução é o mesmo em todos os oito:

1. Aponte a WiFi para visitantes SSID para o URL do portal cativo externo do seu guia de integração da Purple e desative qualquer página de boas-vindas local.
2. Redirecione o tráfego HTTP não autenticado, incluindo as sondagens, para esse URL. Não altere o HTTPS.
3. Permita DNS e DHCP antes da autenticação.
4. Adicione as entradas do walled garden: pontos de extremidade da Purple, pontos de extremidade do fornecedor de identidade e domínios de recursos da página de início de sessão.
5. Introduza os endereços de servidor RADIUS e o segredo partilhado a partir do seu painel da Purple. Em seguida, confirme que a firewall permite UDP de saída 1812 e 1813.

Os nomes dos menus variam consoante o fornecedor e a versão do firmware, pelo que deve seguir o guia de integração da Purple para a sua plataforma. A documentação da comunidade da Fortinet sobre o fluxo do portal cativo no FortiGate é uma referência útil do lado do fornecedor para a sequência de redirecionamento.

No iOS e macOS

Se o assistente de rede cativa não abrir, esqueça a rede nas Definições e volte a ligar-se. Isto força uma nova sondagem.

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

No Android

O Android apresenta uma notificação "Iniciar sessão na rede" quando deteta um portal. Se a notificação nunca aparecer, confirme que o gateway redireciona connectivitycheck.gstatic.com em vez de o descartar.

Se um visitante vir "Não é possível aceder ao servidor DNS privado", o seu telemóvel tem um nome de anfitrião de DNS privado estrito configurado. Tem duas opções:

• Permitir DNS sobre TLS na porta 853 antes da autenticação.
• Pedir ao visitante para alterar o DNS privado para automático.

No Windows

O Windows depende da sondagem HTTP do NCSI e da sua verificação de DNS. Se o portal não abrir automaticamente, navegue para qualquer site HTTP simples para acionar o redirecionamento manualmente. Se a mensagem "Sem internet" persistir após a introdução das credenciais, isso significa geralmente que o gateway ainda está a redirecionar a sondagem. Nesse caso, o gateway não aplicou o Access-Accept.

No navegador

Instrua a equipa de apoio de primeira linha a encaminhar os visitantes para um endereço HTTP, nunca para um domínio HSTS como google.com. O Firefox executa a sua própria sondagem em detectportal.firefox.com, por isso inclua esse anfitrião nos seus testes de redirecionamento.

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

A maioria dos incidentes recorrentes resulta de alterações e não da configuração original. Uma atualização de firmware, um novo modelo de firewall, um redesenho da página de início de sessão ou um certificado prestes a expirar passam despercebidos nos testes. Integre estes controlos no seu processo de gestão de alterações:

• Testar em três plataformas após cada alteração. Utilize um iPhone, um telemóvel Android e um portátil Windows. Se uma plataforma falhar enquanto as outras passam, procure primeiro por falhas no walled garden.
• Dimensionar 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. As redes temporárias de visitantes utilizam habitualmente concessões de 15 a 30 minutos.
• Defina sessões adequadas à visita. Os espaços de hotelaria e retalho costumam definir sessões de 24 horas, para que um visitante inicie sessão apenas uma vez por estadia ou visita.
• Acompanhe os volumes de início de sessão diariamente. Os WiFi Analytics da Purple reportam os inícios de sessão por local. Uma queda súbita num local alerta-o para uma falha no RADIUS ou no jardim murado (walled garden), por vezes antes de os visitantes se queixarem.
• Coloque certificados e segredos partilhados sob controlo de alterações. Agende a data de expiração do certificado do portal. Armazene o segredo partilhado do RADIUS num local onde as equipas de firewall e de controladores o possam consultar.
• Segmente o tráfego de visitantes. Coloque os visitantes na sua própria VLAN. O PCI DSS considera a segmentação como a forma de manter uma rede de visitantes fora do âmbito do seu ambiente de dados de detentores de cartões.
• Planeie para a aleatorização de MAC. As versões recentes do iOS e do Android utilizam um endereço MAC aleatório para cada rede, e alguns modos alternam-no ao longo do tempo. O armazenamento em cache da sessão baseado no endereço MAC solicitará aos visitantes recorrentes que iniciem sessão novamente.
• Recolha o consentimento de forma adequada. O GDPR exige um consentimento informado e afirmativo para dados de marketing. As opções de subscrição de escolha consciente da Purple apresentam uma escolha separada para cada finalidade.

Remova os visitantes recorrentes do portal cativo

A solução mais duradoura remove completamente o redirecionamento em visitas repetidas.

• O Passpoint é a certificação do setor desenvolvida com base na especificação Hotspot 2.0. Permite que um dispositivo se junte a uma rede automaticamente utilizando um perfil armazenado.
• O OpenRoaming, gerido pela Wireless Broadband Alliance, federa fornecedores de identidade. As credenciais existentes de um visitante funcionam, assim, entre os espaços participantes.

Ambos utilizam o IEEE 802.1X, o padrão para controlo de acesso à rede baseado em portas, pelo que não existe qualquer portal suscetível de falhar.

Onde a Purple se enquadra

O Guest WiFi da Purple funciona como uma sobreposição na nuvem agnóstica em termos de hardware, permitindo-lhe corrigir falhas de redirecionamento na configuração e não com hardware novo. A Purple serve mais de 80 000 espaços ativos em mais de 90 países e suporta 500 milhões de utilizadores e inícios de sessão por ano. A plataforma opera com uma disponibilidade de 99,999% e possui as certificações ISO 27001, Cyber Essentials e B Corp. Está também em conformidade com o GDPR e a CCPA.

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

Os padrões repetem-se nos vários setores:

• Os Hotéis sentem falhas de redirecionamento nos picos de check-in.
• Os espaços de Comércio sentem-nas após alterações de firewall em toda a rede de lojas.
• Os Comboios e estações enfrentam pressão de DHCP à medida que os passageiros embarcam em vagas.
• Os locais de Saúde precisam de WiFi para doentes e visitantes que funcione sem arrastar a equipa clínica para chamadas de suporte.

Perguntas frequentes

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

Sim. O Purple é independente de hardware e é executado como uma sobreposição na nuvem no Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Mantém os seus pontos de acesso e controladores existentes. Basta apontar o seu SSID para visitantes para o portal cativo do Purple, adicionar as entradas de "walled garden" e os detalhes de RADIUS do guia de integração do Purple e, em seguida, testar. Não há substituição integral de equipamento.

Precisamos de hardware novo para corrigir o problema de WiFi para visitantes ligado mas sem internet?

Não. Em quase todos os casos, a falha é de configuração: uma sonda bloqueada, uma lacuna no "walled garden", DNS de pré-autenticação, um pool DHCP esgotado ou uma regra de firewall de RADIUS. Corrige cada um deles no controlador, firewall ou servidor DHCP que já utiliza. O hardware só se torna um problema quando a densidade de pontos de acesso não consegue responder ao seu número máximo de dispositivos, o que será demonstrado por um estudo de cobertura do local.

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

A migração para o Purple é um projeto de configuração, não um projeto de instalação. Em cada controlador, define o SSID para visitantes para o portal externo do Purple e adiciona as definições de "walled garden" e de RADIUS. Em seguida, confirma as regras de firewall para UDP 1812 e 1813. Depois, cria a sua página de início de sessão e as opções de consentimento no Purple e testa no iOS, Android e Windows. Os edifícios e redes multilocalização podem criar modelos das definições do controlador.

Um portal cativo está em conformidade com o GDPR?

Sim, desde que o consentimento seja informado, específico e livremente dado. O GDPR exige uma opção afirmativa separada para cada finalidade, como e-mails de marketing, e exclui caixas pré-selecionadas. As opções de adesão por escolha consciente do Purple apresentam cada escolha separadamente. O Purple tem certificação ISO 27001, possui a certificação Cyber Essentials e está em conformidade com o GDPR e o CCPA. Isso fornece ao seu encarregado da proteção de dados as normas sobre as quais ele irá questionar.

Os visitantes recorrentes podem ignorar a página de início de sessão?

Sim. O Passpoint e o OpenRoaming permitem que um dispositivo se ligue automaticamente através de um perfil armazenado ou de uma identidade federada. Ambos utilizam autenticação IEEE 802.1X com encriptação WPA2 ou WPA3-Enterprise, pelo que não há redirecionamento de portal cativo que possa falhar em visitas repetidas. Muitos locais utilizam ambos: um portal cativo para visitantes pela primeira vez e recolha de dados, e o OpenRoaming para visitantes recorrentes, passageiros e estudantes.

Como saberemos quando os inícios de sessão começarem a falhar?

Acompanhe os volumes de início de sessão por local. Os relatórios de analítica de WiFi da Purple registam os inícios de sessão de cada local, para que uma queda súbita num determinado local se destaque do seu padrão normal e dos outros locais. Essa queda indica, geralmente, uma falha de RADIUS, de portal protegido ou de DHCP introduzida por uma alteração recente. Identificá-la no painel de controlo é mais rápido do que esperar que as reclamações da receção cheguem ao departamento de TI.

Devemos utilizar um portal cativo ou uma palavra-passe de WiFi partilhada?

Utilize um portal cativo se pretender obter dados próprios e consentimento, e uma palavra-passe partilhada apenas se não precisar de nenhum dos dois. Uma chave pré-partilhada encripta o tráfego com WPA2 ou WPA3-Personal. No entanto, não lhe diz nada sobre quem se conetou e a palavra-passe acaba por se espalhar. Um portal cativo recolhe dados próprios com consentimento e o Passpoint ou OpenRoaming adiciona acesso automático e encriptado para visitas repetidas.