Resolvendo o Erro de Conectado, mas Sem Internet no WiFi de Visitantes

Resolvendo o Erro de Conectado, mas Sem Internet no WiFi de Visitantes — Um Informativo Técnico da Purple [INTRODUÇÃO E CONTEXTO — aproximadamente 1 minuto] Bem-vindo à série de Informativos Técnicos da Purple. Eu sou o seu anfitrião e hoje vamos abordar um dos problemas mais persistentes e frustrantes na infraestrutura de rede de grandes empreendimentos: o erro de "conectado, sem internet" no WiFi de visitantes. Se você gerencia a infraestrutura de WiFi em um hotel, rede de varejo, estádio ou centro de convenções, com certeza já se deparou com isso. O dispositivo do visitante mostra sinal cheio, está associado ao seu ponto de acesso, recebeu um endereço IP — e, no entanto, o navegador não carrega nada. O Captive Portal nunca inicia. O visitante liga para a recepção. Sua equipe de suporte executa um teste de ping, tudo parece perfeito no papel, mas o problema continua ocorrendo. O ponto principal é este: na grande maioria dos casos que encontro em implantações corporativas, isso não é uma falha de hardware, não é uma configuração incorreta de firewall e não é um problema de largura de banda no sentido tradicional. Trata-se de um problema de tempo limite de DNS — e quase sempre é desencadeado por congestionamento de rede. Hoje, quero explicar exatamente por que isso acontece, como diagnosticar o problema com segurança e como a implantação de um filtro de DNS corporativo resolve esse gargalo de forma definitiva. [APROFUNDAMENTO TÉCNICO — aproximadamente 5 minutos] Vamos começar pelo básico. Quando o dispositivo de um visitante se conecta à sua rede WiFi, a primeira coisa que ele precisa fazer — antes de carregar uma única página da web, antes que seu Captive Portal possa redirecioná-lo, antes que qualquer autenticação ocorra — é resolver um nome de domínio para um endereço IP via DNS. O Domain Name System é a lista telefônica da internet. Sem ele, o dispositivo não tem como saber para onde enviar o tráfego. Agora, é aqui que o problema começa. A maioria dos dispositivos de consumo — iPhones, aparelhos Android, notebooks Windows — possui um mecanismo integrado chamado sonda de detecção de Captive Portal. No iOS, por exemplo, o dispositivo envia uma solicitação HTTP para um endpoint conhecido da Apple, algo como captive.apple.com. No Android, ele acessa connectivitycheck.gstatic.com. No Windows, ele consulta msftconnecttest.com. Essas sondas são projetadas para detectar se a rede exige uma página de login antes de liberar o acesso à internet. O ponto crítico é o seguinte: essas sondas dependem do DNS. O dispositivo precisa primeiro resolver o nome de domínio do endpoint da sonda antes de enviar a solicitação HTTP. E essa consulta DNS tem um tempo limite (timeout) — normalmente entre um e cinco segundos, dependendo do sistema operacional. Se o resolvedor de DNS da sua rede não responder dentro desse intervalo, o dispositivo conclui que a rede não tem conectividade com a internet, mesmo estando totalmente associado e com um IP válido. Esse é o erro de "conectado, sem internet". Não se trata de uma falha de conectividade — é uma falha de resposta do DNS.Então, por que o DNS falha em uma rede congestionada? Esta é a parte que pega muitas equipes de surpresa. As consultas DNS são enviadas por padrão via UDP, na porta 53. O UDP é um protocolo sem conexão — não há handshake, nem confirmação, nem retransmissão na camada de transporte. Se um pacote DNS é descartado devido ao congestionamento da rede, o cliente simplesmente espera até que o tempo limite expire e, em seguida, tenta novamente ou desiste. Em uma rede guest WiFi com centenas ou milhares de dispositivos simultâneos — pense em um estádio durante uma partida, um hotel com ocupação máxima, um centro de convenções durante uma palestra principal — o link de upload e o resolvedor DNS podem ficar saturados muito rapidamente. O problema é agravado pelo fato de que as redes guest normalmente compartilham um único resolvedor DNS de upload, muitas vezes o resolvedor padrão do ISP ou um resolvedor público como o 8.8.8.8. Quando todos os dispositivos na rede estão simultaneamente sondando para a detecção de Captive Portal, executando atualizações de aplicativos em segundo plano e fazendo consultas DNS para mídias sociais e serviços de streaming, esse único resolvedor se torna um gargalo. Os tempos de resposta das consultas sobem da faixa normal de menos de 50 milissegundos para centenas ou até milhares de milissegundos. Os timeouts começam a ocorrer. Os erros de "conectado, sem internet" começam a inundar o suporte. Há também um mecanismo secundário que vale a pena entender: a exaustão do TTL. As respostas DNS incluem um valor de Time To Live que informa ao dispositivo receptor por quanto tempo armazenar em cache o endereço IP resolvido. Em uma rede congestionada onde os dispositivos estão constantemente se associando e desassociando — o que é comum em locais de alta densidade — as entradas em cache expiram e devem ser resolvidas novamente com frequência. Isso aumenta a carga de consultas DNS no resolvedor precisamente quando a rede está sob maior estresse. Agora, a resposta tradicional a esse problema é injetar largura de banda — atualizar o link de upload, adicionar mais pontos de acesso, implementar políticas de QoS. Todas essas são medidas válidas, mas não abordam a causa raiz. A causa raiz é que o seu caminho de resolução DNS não está otimizado para ambientes guest de alta densidade. E é exatamente isso que um filtro DNS corporativo resolve. Um filtro DNS corporativo — como a capacidade de filtragem de DNS dentro da plataforma de guest WiFi da Purple — opera como um resolvedor DNS local de alto desempenho que fica entre os dispositivos dos seus convidados e a internet de upload. Em vez de encaminhar cada consulta para um resolvedor público remoto, ele mantém um cache local de domínios resolvidos com frequência, lida com sondagens de detecção de Captive Portal nativamente e aplica filtragem baseada em políticas para bloquear domínios maliciosos ou não conformes antes que eles cheguem ao resolvedor de upload. O resultado é uma redução drástica na latência das consultas DNS — normalmente de timeouts de dois a três segundos para respostas abaixo de 200 milissegundos — o que significa que as sondagens de detecção de Captive Portal têm sucesso na primeira tentativa, o erro "conectado, sem internet" desaparece e o tempo de integração do convidado cai significativamente. Do ponto de vista de padrões, essa arquitetura se alinha com as recomendações do IEEE 802.11 para implantações de alta densidade e apoia a conformidade com os requisitos de tratamento de dados do GDPR, permitindo que você registre e audite consultas DNS — o que é relevante se você estiver operando sob uma licença do setor público ou de hospitalidade. Ela também apoia os requisitos de segmentação de rede do PCI DSS, garantindo que o tráfego DNS de convidados seja isolado da sua infraestrutura de resolução corporativa. [RECOMENDAÇÕES DE IMPLANTAÇÃO E ARMADILHAS — aproximadamente 2 minutos] Deixe-me fornecer as orientações práticas de implantação. Ao implementar um filtro DNS corporativo em uma rede WiFi de convidados, existem três decisões de configuração que determinarão o seu sucesso ou fracasso. Primeiro, o posicionamento do resolvedor. Seu filtro DNS deve ser implantado o mais próximo possível da rede de convidados — idealmente na mesma VLAN ou sub-rede que seus pontos de acesso de convidados. Cada salto entre o dispositivo do convidado e o resolvedor adiciona latência. Se o seu filtro DNS estiver em um data center remoto e sua rede de convidados estiver em um hotel em Manchester, você estará adicionando um tempo de ida e volta que anula o propósito. Use um appliance local ou um filtro DNS fornecido na nuvem com um ponto de presença regional. Segundo, a passagem de DNS do Captive Portal. Esta é a configuração incorreta mais comum que vejo. Ao implantar um filtro DNS, você deve garantir que o próprio domínio do Captive Portal — a URL para a qual os convidados são redirecionados para autenticação — esteja na lista de permissões (whitelist) do filtro. Se o filtro bloquear ou atrasar a resolução do domínio do seu Captive Portal, você recriará exatamente o problema que estava tentando resolver. Sempre teste explicitamente a resolução do Captive Portal após implantar qualquer política de filtragem de DNS. Terceiro, o ajuste de TTL. Configure seu resolvedor DNS local para fornecer TTLs curtos para domínios de sondagem de detecção de Captive Portal — Apple, Google, Microsoft — para que os dispositivos refaçam as consultas com frequência e sempre obtenham uma resposta local rápida, em vez de esperar que uma entrada em cache expire para depois atingir um resolvedor upstream congestionado. Um TTL de 30 a 60 segundos para esses domínios específicos é um ponto de partida razoável. A armadilha a ser evitada é a filtragem excessiva. Algumas equipes implantam listas de bloqueio de DNS agressivas que bloqueiam inadvertidamente domínios usados por aplicativos legítimos de convidados — serviços de streaming, endpoints de VPN corporativa, armazenamento em nuvem. Isso gera uma classe diferente de chamados de suporte, mas é igualmente prejudicial para a experiência do convidado. Comece com uma política conservadora, monitore os logs de consultas DNS em busca de domínios bloqueados e faça ajustes finos ao longo de um período de duas semanas antes de fechar a configuração. [PERGUNTAS E RESPOSTAS RÁPIDAS — aproximadamente 1 minuto] Deixe-me responder às perguntas que recebo com mais frequência sobre este assunto. "Posso usar apenas o 8.8.8.8 como meu resolvedor DNS de convidados?" Você pode, mas sob carga ele apresentará timeout. Um resolvedor local ou regional sempre superará o desempenho de um resolvedor público em uma rede congestionada. "Isso afeta implantações WPA3?" Não — o WPA3 melhora a segurança da autenticação, mas não altera o caminho de resolução do DNS. O mesmo problema de timeout de DNS ocorre independentemente do padrão de criptografia em uso. "Como posso saber se o DNS é a causa real dos meus erros de 'conectado, sem internet'?" Execute uma captura de pacotes na VLAN de visitantes durante o pico de carga. Filtre pelo tráfego da porta UDP 53. Se você observar consultas de DNS sem resposta correspondente em dois segundos, o timeout de DNS é o culpado. "Um filtro de DNS corporativo ajuda na conformidade?" Sim — o registro de consultas de DNS fornece uma trilha de auditoria que apoia as obrigações de responsabilidade do GDPR e pode auxiliar na resposta a incidentes. A plataforma da Purple inclui esse registro nativamente. [RESUMO E PRÓXIMOS PASSOS — aproximadamente 1 minuto] Para resumir: o erro "conectado, sem internet" no WiFi de visitantes é, em sua grande maioria, um problema de tempo de DNS causado pelo congestionamento da rede que sobrecarrega um caminho de resolução não otimizado. A solução não é mais largura de banda — é um filtro de DNS corporativo local de alto desempenho que resolve as sondagens de detecção de Captive Portal rapidamente, mantém um cache local e aplica filtragem baseada em políticas para reduzir a carga de consultas upstream. As três coisas a fazer esta semana: execute uma captura de pacotes de DNS durante o pico de carga para confirmar o diagnóstico; revise a localização atual do seu resolvedor de DNS e identifique se ele é local ou remoto; e avalie a implantação de um filtro de DNS corporativo na sua VLAN de visitantes. Se você quiser se aprofundar em qualquer um desses pontos, a documentação da plataforma Purple aborda a configuração do filtro de DNS em detalhes, e os guias de otimização de WiFi de visitantes em purple.ai valem a pena ser revisados junto com este briefing. Obrigado por ouvir — nos vemos no próximo. [FIM DO EPISÓDIO]