Solucionando o erro "Conectado, mas sem internet" no WiFi para visitantes

O erro de conectado, mas sem internet no WiFi de visitantes ocorre quando as verificações de conectividade falham antes que o Captive Portal seja carregado. Em locais de grande movimento, as consultas DNS na porta UDP 53 (RFC 1035) sofrem tempo limite esgotado durante o congestionamento. Para resolver isso, é necessário apontar os escopos DHCP de visitantes para um filtro DNS de cache, preencher os domínios do walled garden em controladores como Cisco Meraki e revisar as regras de modelagem de tráfego.

Como é o erro "conectado, sem internet" no WiFi de visitantes?

O visitante vê todas as barras de sinal e uma rede conectada, mas nada carrega. A página de login nunca aparece, impedindo que os termos sejam aceitos ou o acesso seja feito. Em seguida, ele se dirige à recepção, ao ponto de suporte ou ao balcão de atendimento.

Cada sistema operacional exibe essa mensagem de forma diferente. Sua equipe de suporte do local deve reconhecer todas elas:

• O Windows exibe "Sem internet" abaixo do nome da rede.
• O Android exibe "Conectado sem internet" ou "A internet pode não estar disponível".
• O iPhone e iPad exibem "Sem Conexão com a Internet" abaixo do nome da rede.

Todas as três mensagens vêm do mesmo mecanismo. Após a conexão, o dispositivo solicita um endereço web conhecido para testar a conexão. Se esse teste retornar a página esperada, o dispositivo considera a conexão funcional. Se retornar uma página de login, o dispositivo abre o Captive Portal. Se não obtiver nenhuma resposta, o dispositivo informa "sem internet".

Antes que o dispositivo possa solicitar qualquer uma dessas páginas, ele precisa consultar o hostname por meio do DNS. Essa consulta é onde a maioria das falhas em locais de alta densidade começa.

O que geralmente causa erros de conectado sem internet no WiFi de visitantes?

Tempos limite de DNS em uma rede congestionada

O DNS (Domain Name System) converte um hostname em um endereço IP. A maioria das consultas DNS trafega pela porta UDP 53, conforme definido na RFC 1035. O UDP não possui retransmissão embutida, portanto, uma consulta perdida simplesmente aguarda o temporizador de tentativa do próprio dispositivo.

O congestionamento ocorre em picos. Pense no intervalo de um jogo em um estádio, no check-out do café da manhã em um hotel ou em um trem chegando à estação. Centenas de dispositivos se conectam em segundos, e cada um envia uma consulta ao mesmo tempo. Se o resolvedor estiver a vários saltos de distância em um link WAN sobrecarregado, as consultas serão atrasadas ou descartadas. O dispositivo desiste, o portal nunca abre e o visitante vê a mensagem "sem internet".

Outros motivos comuns

O DNS é a causa mais comum em locais movimentados, mas não é a única. Verifique também estes pontos:

• Entradas ausentes no walled garden. O walled garden é a lista de domínios que um dispositivo pode acessar antes do login. Se o seu portal ou seus recursos estiverem ausentes, a página não poderá carregar.
• Esgotamento do pool DHCP. Se o pool de endereços acabar, os dispositivos atribuirão a si mesmos um endereço 169.254.x.x e não conseguirão acessar nada.
• Limites de taxa ou limitação de QoS na porta UDP 53. Um limite por cliente ou por SSID configurado de forma muito rígida pode esgotar o DNS durante um pico de tráfego.
• DNS criptografado. O DNS sobre HTTPS (DoH, RFC 8484) e o DNS sobre TLS (DoT, RFC 7858) enviam consultas para resolvedores externos. Um walled garden que bloqueia esses resolvedores interrompe a consulta antes do login.
• Uma interrupção na conexão de saída. Se o próprio link WAN estiver fora do ar, todos os dispositivos falham e todas as portas cabeadas também falham.

Como identificar qual é a causa?

Comece pelo padrão, não pelo hardware. Use esta matriz para delimitar a causa antes de alterar qualquer coisa.

Três verificações que sua equipe de suporte pode executar

1. Verifique o endereço IP do dispositivo. Um endereço 169.254.x.x indica um problema no DHCP, não no DNS. Um endereço normal da faixa de visitantes significa que o dispositivo se conectou corretamente.
2. Cronometre uma consulta a partir de um dispositivo de teste. Execute nslookup captive.apple.com a partir de um notebook na rede de visitantes. Uma resposta lenta ou uma falha durante um período de pico confirma um gargalo no DNS.
3. Capture pacotes na VLAN de visitantes. Uma VLAN (LAN virtual) separa o tráfego de visitantes das suas outras redes. Filtre a captura na porta udp port 53 e procure por consultas sem a resposta correspondente.

Em seguida, verifique quando os erros ocorrem. No WiFi Analytics, compare os volumes de conexão e login com os horários em que os visitantes relatam problemas. Falhas que acompanham seus horários de maior movimento indicam claramente congestionamento.

Como um filtro DNS enterprise resolve o gargalo?

Um filtro DNS enterprise é um resolvedor sob seu controle, instalado próximo à rede de visitantes. Ele substitui o resolvedor público ou do provedor de internet distante que o DHCP distribui atualmente. Ele realiza três tarefas que eliminam o tempo limite excedido.

Ele responde a partir do cache. Hostnames de verificação de conectividade são solicitados milhares de vezes por hora em um local movimentado. Um filtro próximo responde a consultas repetidas a partir do seu cache, evitando que elas cruzem o link WAN congestionado.

Ele descarta tráfego indesejado antecipadamente. Consultas para categorias maliciosas ou bloqueadas são recusadas diretamente no filtro. Isso libera capacidade da WAN para consultas que realmente importam.

Ele registra todas as consultas. Você obtém um histórico de quais domínios falharam, quando e com que frequência. Isso transforma adivinhações em evidências na próxima vez que um gerente relatar um problema.

Onde instalá-lo

Para uma infraestrutura distribuída, como uma rede de varejo com centenas de locais pequenos, um filtro fornecido na nuvem com locais de borda próximos costuma ser a opção mais prática. Para um único local grande, como um estádio ou centro de convenções, um resolvedor hospedado no próprio local mantém as consultas totalmente fora da WAN. Em ambos os casos, forneça dois endereços de resolvedor no DHCP para que uma única falha não derrube a rede.

Duas configurações que determinam o sucesso

Primeiro, permita os domínios do seu portal cativo no filtro. Um filtro que bloqueia ou atrasa o portal recria exatamente o erro que você pretendia corrigir. Segundo, mantenha o DNS de convidados separado do DNS corporativo. O PCI DSS trata a segmentação de rede como a forma de manter uma rede de convidados fora do escopo do seu ambiente de dados de titulares de cartão.

Como corrigir isso em cada fabricante e sistema operacional?

Nos seus pontos de acesso e controlador

O Purple é agnóstico em relação ao hardware e roda como uma sobreposição em nuvem no Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A correção segue os mesmos três passos em cada um deles:

1. Atualize os servidores DNS no escopo DHCP de convidados para o seu filtro DNS empresarial.
2. Conclua o walled garden. O Cisco Meraki, o HPE Aruba e o Ruckus usam o termo "walled garden". Siga o artigo de configuração do Purple referente ao seu fabricante, que lista os domínios exatos a serem permitidos.
3. Verifique o controle de tráfego de convidados para que os limites por cliente não limitem a porta UDP 53 durante um pico de acesso.

Não copie configurações entre fabricantes diferentes. Os nomes dos menus e os padrões variam, portanto, use a documentação do próprio fabricante junto com o artigo de configuração do Purple.

No dispositivo do convidado

Quando apenas um único convidado for afetado e todos os outros estiverem navegando normalmente, sua equipe de suporte pode tentar as seguintes etapas:

• Esquecer a rede e reconectar para disparar uma nova verificação de conectividade.
• Abrir um endereço http:// simples no navegador para forçar a exibição do portal.
• No Android, defina o DNS Privado como Automático. Um provedor de DNS Privado fixo pode bloquear a consulta antes do login.
• Pausar qualquer aplicativo de VPN até que o convidado tenha efetuado o login.

Cenários práticos

As estatísticas abaixo são ilustrativas e não foram retiradas de uma implantação específica. Use-as como modelo para o que medir no seu próprio local.

Um hotel de 200 quartos durante o café da manhã

Situação. Reclamações na recepção sobre "sem internet" concentram-se entre 7h e 9h, quando os hóspedes checam seus e-mails antes do checkout. Os pontos de acesso mostram um sinal saudável e tempo de transmissão disponível. O DHCP de convidados fornece o resolvedor do provedor de internet, situado a vários saltos de distância em uma linha congestionada.

O que foi feito. O gerente de TI executou o nslookup durante o horário de pico e viu que as consultas estavam falhando totalmente. A equipe apontou o DHCP de convidados para um filtro DNS em nuvem, adicionou os domínios do portal ao walled garden e manteve o DNS de convidados separado da rede do sistema de gestão hoteleira.

Resultado. Medido no WiFi Analytics e no registro da recepção, as conclusões de cadastro no portal nos horários de pico subiram de 81% para 97%. As reclamações sobre WiFi na recepção caíram de cerca de 15 por manhã para duas. Para saber mais sobre redes de hóspedes em hotéis, visite nossas páginas sobre hotelaria.

Um estádio para 30.000 pessoas no intervalo do jogo

Situação. Os torcedores relatavam "conectado sem internet" a cada intervalo, enquanto os primeiros dez minutos de cada tempo funcionavam perfeitamente. A captura de pacotes na VLAN de convidados mostrou consultas de DNS sem resposta durante o pico de acesso.

O que foi feito. O arquiteto de rede implantou um resolvedor local com um fallback na nuvem. A equipe removeu um limite de taxa por cliente que throttlava a porta UDP 53 e migrou o escopo DHCP para o novo resolvedor.

Resultado. As consultas de DNS não respondidas no intervalo caíram de 12% para menos de 1% nas capturas de acompanhamento. Os logins de torcedores durante o intervalo aumentaram 40% em relação ao jogo anterior.

Como evitar que erros de conectado sem internet aconteçam novamente?

• Nunca confie apenas em um resolvedor público distante. O DNS público geralmente tem um bom desempenho, mas um resolvedor a vários saltos de distância adiciona um atraso que você não pode controlar durante um pico de tráfego.
• Crie alertas para consultas DNS não respondidas. Configure seu firewall ou switch central para sinalizar o aumento de descartes na porta UDP 53 na rede de convidados, o que indica tempos de limite esgotados (timeouts) antes mesmo que os visitantes percebam.
• Revise as listas de bloqueio do filtro DNS todos os meses. Categorias excessivamente agressivas bloqueiam aplicativos legítimos e geram novos chamados de suporte.
• Defina um período de retenção de logs. Os logs de DNS vinculam endereços IP aos domínios visitados, portanto, trate-os como dados pessoais de acordo com a GDPR.
• Adote o RFC 8910 se o seu hardware for compatível. Ele permite que o DHCP informe ao dispositivo onde está o Captive Portal, fazendo com que o dispositivo dependa menos de uma verificação de conectividade por busca.
• Considere o Passpoint para visitantes recorrentes. O Passpoint (também chamado de Hotspot 2.0) e o OpenRoaming permitem que os dispositivos se conectem com segurança sem um Captive Portal, eliminando completamente esse tipo de falha para eles.

A Purple opera o Guest WiFi em mais de 80.000 locais ativos em mais de 90 países, com 500 milhões de usuários e logins por ano. De salas de espera na área de saúde a trens, o padrão se mantém: corrija o DNS antes de comprar mais largura de banda.

Perguntas frequentes

Precisamos de novos pontos de acesso para corrigir erros de conectado sem internet?

Na maioria dos casos, não. Quando o erro ocorre em horários de pico, a causa geralmente é a resolução de DNS, não o hardware dos pontos de acesso. A solução é uma alteração de configuração: aponte o DHCP de convidados para um filtro DNS corporativo próximo, complete o walled garden e revise as regras de modelagem de tráfego (traffic shaping). Substitua o hardware apenas depois que as capturas de pacotes mostrarem que os próprios pontos de acesso estão descartando tráfego sob cargas normais, e após ter descartado problemas de DHCP e DNS.

A Purple funciona com o hardware que já possuímos?

Sim, o Purple é executado nos pontos de acesso que você já possui. O Purple é agnóstico em relação ao hardware e é implantado como uma sobreposição em nuvem no Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Não é necessário substituir a infraestrutura existente. O Purple publica um artigo de configuração para cada fornecedor, listando os domínios do walled garden de que seu controlador precisa para que o portal cativo seja carregado antes de os visitantes fazerem login.

Um filtro de DNS empresarial reduzirá a velocidade do nosso WiFi para visitantes?

Não, um filtro de DNS bem localizado geralmente torna as consultas mais rápidas. Ele fica mais próximo da rede de visitantes do que um provedor de Internet ou um resolvedor público e responde a consultas repetidas a partir do seu cache. O risco está na localização e na configuração, não na filtragem em si. Forneça dois endereços de resolvedor para redundância e permita os domínios do seu portal cativo para que o filtro nunca atrase a página de login.

Por que não fornecer aos visitantes apenas um resolvedor público, como o 8.8.8.8?

Você pode fazer isso, mas essa medida não soluciona os timeouts causados por congestionamento. Um resolvedor público ainda fica localizado do outro lado da sua conexão WAN, portanto, cada consulta compete com o aumento de tráfego que causa a falha. Além disso, ele não oferece filtragem nem registros de consultas para solução de problemas. Um filtro empresarial próximo responde a partir do cache, recusa categorias indesejadas e registra todas as consultas com falha, algo que o DNS público não pode fazer por você.

Como devemos gerenciar os registros de consultas de DNS de acordo com o GDPR?

Trate os registros de DNS como dados pessoais, pois eles vinculam endereços IP aos domínios que um dispositivo visitou. Defina um período de retenção determinado, restrinja o acesso à sua equipe de rede e segurança e registre a finalidade no seu aviso de privacidade. O Purple possui certificação ISO 27001 e está em conformidade com o GDPR, e o seu fornecedor de filtro de DNS deve demonstrar certificação equivalente antes de você rotear o tráfego de visitantes por ele.

Quanto esforço a implantação exige?

A alteração em si é simples; o teste consome a maior parte do esforço. Você atualiza os servidores DNS no escopo DHCP de visitantes, adiciona os domínios do portal à lista de permissões do filtro e verifica o walled garden. Planeje testar durante um pico real, como o horário do café da manhã ou o intervalo de um evento, pois uma tarde tranquila não reproduzirá o congestionamento que causou o erro.

O Passpoint ou o OpenRoaming eliminarão o erro?

Sim, para os dispositivos que os utilizam. O Passpoint e o OpenRoaming permitem que os dispositivos se conectem com segurança sem um portal cativo, portanto, não há portal para apresentar falhas. Os visitantes de primeira viagem e os dispositivos sem um perfil Passpoint ainda usam o portal cativo, por isso você ainda precisa de um DNS rápido e de um walled garden completo. Execute ambos juntos: o Passpoint para visitantes recorrentes e um portal ajustado para todos os outros.