Resolver o Erro de Ligado mas Sem Internet no WiFi de Convidados

Resolução do Erro "Ligado, mas Sem Internet" em WiFi de Convidados — Um Briefing Técnico da Purple [INTRODUÇÃO E CONTEXTO — aproximadamente 1 minuto] Bem-vindo à série de Briefings Técnicos da Purple. Sou o vosso anfitrião e hoje vamos abordar um dos problemas mais persistentes e frustrantes nas redes de recintos empresariais: o erro "ligado, sem internet" no WiFi de convidados. Se gere infraestruturas de WiFi num hotel, cadeia de retalho, estádio ou centro de conferências, já se deparou com isto. O dispositivo de um convidado mostra o sinal no máximo, está associado ao seu ponto de acesso, foi-lhe atribuído um endereço IP — e, no entanto, o browser não carrega nada. O Captive Portal nunca abre. O convidado liga para a receção. A sua equipa de suporte executa um teste de ping, tudo parece bem no papel e, no entanto, o problema continua a repetir-se. A questão é esta: na grande maioria dos casos que encontro em implementações empresariais, isto não é uma falha de hardware, não é uma configuração incorreta da firewall e não é um problema de largura de banda no sentido tradicional. É um problema de temporização de DNS — e é quase sempre desencadeado por congestionamento de rede. Hoje quero explicar-lhe exatamente por que razão isto acontece, como diagnosticá-lo de forma fiável e como a implementação de um filtro DNS empresarial resolve este estrangulamento de forma permanente. [MERGULHO TÉCNICO PROFUNDO — aproximadamente 5 minutos] Comecemos pelos fundamentos. Quando o dispositivo de um convidado se liga à sua rede WiFi, a primeiríssima coisa que precisa de fazer — antes de poder carregar uma única página web, antes de o seu Captive Portal o poder redirecionar, antes de qualquer autenticação poder acontecer — é resolver um nome de domínio para um endereço IP através de DNS. O Domain Name System é a lista telefónica da internet. Sem ele, o seu dispositivo não tem forma de saber para onde enviar o tráfego. Agora, é aqui que o problema começa. A maioria dos dispositivos de consumo — iPhones, telemóveis Android, portáteis Windows — tem um mecanismo integrado chamado sonda de deteção de Captive Portal. No iOS, por exemplo, o dispositivo envia um pedido HTTP para um endpoint conhecido da Apple, algo como captive.apple.com. No Android, acede a connectivitycheck.gstatic.com. No Windows, sonda msftconnecttest.com. Estas sondas foram concebidas para detetar se a rede requer uma página de início de sessão antes de conceder acesso à internet. O ponto crítico é este: estas sondas estão dependentes do DNS. O dispositivo deve primeiro resolver o nome de domínio do endpoint da sonda antes de poder enviar o pedido HTTP. E essa consulta DNS tem um limite de tempo (timeout) — normalmente entre um e cinco segundos, dependendo do sistema operativo. Se o resolvedor de DNS na sua rede não responder dentro desse intervalo, o dispositivo conclui que a rede não tem conectividade à internet, embora esteja totalmente associado e tenha um endereço IP válido. Esse é o erro "ligado, sem internet". Não é uma falha de conectividade — é uma falha de resposta de DNS.Então, por que é que o DNS falha numa rede congestionada? Esta é a parte que apanha muitas equipas de surpresa. As consultas DNS são enviadas por UDP por predefinição, na porta 53. O UDP é um protocolo sem ligação — não há handshake, nem confirmação, nem retransmissão na camada de transporte. Se um pacote DNS for descartado devido a congestionamento de rede, o cliente simplesmente aguarda até que o tempo limite expire e, em seguida, tenta novamente ou desiste. Numa rede WiFi de convidados com centenas ou milhares de dispositivos simultâneos — pense num estádio durante um jogo, num hotel com ocupação total, num centro de conferências durante uma palestra — a ligação upstream e o resolvedor DNS podem ficar saturados muito rapidamente. O problema é agravado pelo facto de as redes de convidados partilharem tipicamente um único resolvedor DNS upstream, muitas vezes o resolvedor predefinido do ISP ou um resolvedor público como o 8.8.8.8. Quando todos os dispositivos na rede estão simultaneamente a sondar a deteção de Captive Portal, a executar atualizações de aplicações em segundo plano e a fazer consultas DNS para redes sociais e serviços de streaming, esse resolvedor único torna-se um gargalo. Os tempos de resposta das consultas sobem da gama normal inferior a 50 milissegundos para centenas ou até milhares de milissegundos. Os tempos limite começam a ocorrer. Os erros de "ligado, sem internet" começam a surgir em massa. Existe também um mecanismo secundário que vale a pena compreender: a exaustão do TTL. As respostas DNS incluem um valor de Time To Live que indica ao dispositivo recetor durante quanto tempo deve armazenar em cache o endereço IP resolvido. Numa rede congestionada onde os dispositivos estão constantemente a associar-se e a desassociar-se — o que é comum em locais de alta densidade — as entradas em cache expiram e devem ser resolvidas novamente com frequência. Isto aumenta a carga de consultas DNS no resolvedor precisamente quando a rede está sob maior stress. Ora, a resposta tradicional a este problema é investir em largura de banda — atualizar a ligação upstream, adicionar mais pontos de acesso, implementar políticas de QoS. Estas são todas medidas válidas, mas não resolvem a causa raiz. A causa raiz é que o seu caminho de resolução DNS não está otimizado para ambientes de convidados de alta densidade. E é exatamente isso que um filtro DNS empresarial resolve. Um filtro DNS empresarial — como a capacidade de filtragem DNS dentro da plataforma de WiFi de convidados da Purple — funciona como um resolvedor DNS local de alto desempenho que se posiciona entre os seus dispositivos de convidados e a internet upstream. Em vez de encaminhar cada consulta para um resolvedor público remoto, este mantém uma cache local de domínios frequentemente resolvidos, lida com sondagens de deteção de Captive Portal de forma nativa e aplica filtragem baseada em políticas para bloquear domínios maliciosos ou não conformes antes que estes cheguem ao resolvedor upstream. O resultado é uma redução drástica na latência das consultas DNS — tipicamente de tempos limite de dois a três segundos para respostas inferiores a 200 milissegundos — o que significa que as sondagens de deteção de Captive Portal são bem-sucedidas à primeira tentativa, o erro de "ligado, sem internet" desaparece e o tempo de integração dos convidados diminui significativamente. Do ponto de vista das normas, esta arquitetura alinha-se com as recomendações IEEE 802.11 para implementações de alta densidade e apoia a conformidade com os requisitos de tratamento de dados do GDPR, permitindo-lhe registar e auditar consultas DNS — o que é relevante se estiver a operar sob uma licença do setor público ou de hotelaria. Também apoia os requisitos de segmentação de rede PCI DSS, garantindo que o tráfego DNS de convidados é isolado da sua infraestrutura de resolução corporativa. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS — aproximadamente 2 minutos] Permita-me dar-lhe orientações práticas de implementação. Quando está a implementar um filtro DNS empresarial numa rede WiFi de convidados, existem três decisões de configuração que determinarão o seu sucesso ou fracasso. Primeiro, a localização do resolvedor. O seu filtro DNS deve ser implementado o mais próximo possível da rede de convidados — idealmente na mesma VLAN ou sub-rede que os 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 num centro de dados remoto e a sua rede de convidados estiver num hotel em Manchester, está a adicionar um tempo de ida e volta que anula o objetivo. Utilize um equipamento 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 implementar um filtro DNS, deve garantir que o próprio domínio do Captive Portal — o URL para o qual os convidados são redirecionados para autenticação — está na lista de permissões do filtro. Se o filtro bloquear ou atrasar a resolução do domínio do seu Captive Portal, irá recriar exatamente o problema que estava a tentar resolver. Teste sempre a resolução do Captive Portal explicitamente após implementar qualquer política de filtragem DNS. Terceiro, o ajuste de TTL. Configure o seu resolvedor DNS local para fornecer TTLs curtos para domínios de deteção de Captive Portal — Apple, Google, Microsoft — para que os dispositivos façam novas consultas frequentemente e obtenham sempre uma resposta local rápida, em vez de esperarem que uma entrada em cache expire e depois acederem a um resolvedor upstream congestionado. Um TTL de 30 a 60 segundos para estes domínios específicos é um ponto de partida razoável. O erro a evitar é a filtragem excessiva. Algumas equipas implementam listas de bloqueio DNS agressivas que bloqueiam inadvertidamente domínios utilizados por aplicações legítimas de convidados — serviços de streaming, endpoints de VPN corporativas, armazenamento na nuvem. Isto gera uma classe diferente de pedidos de suporte, mas é igualmente prejudicial para a experiência do convidado. Comece com uma política conservadora, monitorize os registos de consultas DNS para domínios bloqueados e refine ao longo de um período de duas semanas antes de bloquear a configuração. [PERGUNTAS E RESPOSTAS RÁPIDAS — aproximadamente 1 minuto] Deixe-me responder às perguntas que me fazem com mais frequência sobre este tema. "Posso simplesmente usar o 8.8.8.8 como o meu resolvedor DNS de convidados?" Pode, mas sob carga irá expirar o tempo limite. Um resolvedor local ou regional terá sempre um desempenho superior ao de um resolvedor público numa rede congestionada. "Isto afeta as implementações de WPA3?" Não — o WPA3 melhora a segurança da autenticação, mas não altera o caminho de resolução de DNS. O mesmo problema de timeout de DNS ocorre independentemente do padrão de encriptação em utilização. "Como posso saber se o DNS é a causa real dos meus erros de 'ligado, sem internet'?" Execute uma captura de pacotes na VLAN de convidados durante o pico de carga. Filtre pelo tráfego da porta UDP 53. Se vir consultas de DNS sem resposta correspondente no espaço de dois segundos, o timeout de DNS é o culpado. "Um filtro de DNS empresarial ajuda na conformidade?" Sim — o registo de consultas de DNS fornece um registo de auditoria que apoia as obrigações de responsabilidade do GDPR e pode ajudar na resposta a incidentes. A plataforma da Purple inclui este registo de forma nativa. [RESUMO E PRÓXIMOS PASSOS — aproximadamente 1 minuto] Para resumir: o erro "ligado, sem internet" no WiFi de convidados é, na sua grande maioria, um problema de temporização 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 empresarial local de alto desempenho que resolve rapidamente as sondas de deteção do Captive Portal, mantém uma cache local e aplica filtragem baseada em políticas para reduzir a carga de consultas a montante. As três coisas a fazer esta semana: executar uma captura de pacotes de DNS durante o pico de carga para confirmar o diagnóstico; rever a localização atual do seu resolvedor de DNS e identificar se é local ou remoto; e avaliar a implementação de um filtro de DNS empresarial na sua VLAN de convidados. Se quiser aprofundar qualquer um destes pontos, a documentação da plataforma Purple abrange a configuração do filtro de DNS em detalhe, e os guias de otimização de WiFi de convidados em purple.ai merecem ser revistos em conjunto com este briefing. Obrigado por ouvir — vemo-nos no próximo. [FIM DO EPISÓDIO]