Resolver o Erro Ligado mas Sem Internet no WiFi de Convidados

Resolução do Erro "Ligado, mas sem Internet" no WiFi de Convidados — Um Briefing Técnico da Purple [INTRODUÇÃO & CONTEXTO — aproximadamente 1 minuto] Bem-vindo à série de Briefings Técnicos da Purple. Eu sou o seu anfitrião e hoje vamos abordar um dos problemas mais persistentes e frustrantes nas redes corporativas de recintos: 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 as barras de 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 apresenta nada. O Captive Portal nunca carrega. 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 ocorrer. A questão é esta: na vasta maioria dos casos com que me deparo 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 na rede. Hoje quero explicar-lhe exatamente por que razão isso acontece, como diagnosticá-lo de forma fiável e como a implementação de um filtro de DNS empresarial resolve este estrangulamento de forma permanente. [ANÁLISE TÉCNICA DETALHADA — aproximadamente 5 minutos] Vamos começar pelos aspetos fundamentais. Quando o dispositivo de um convidado se liga à sua rede WiFi, a primeira 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 o 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 dependem do DNS. O dispositivo tem primeiro de resolver o nome de domínio do endpoint da sonda antes de poder enviar o pedido HTTP. E essa consulta de 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 dessa janela, 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 se trata de uma falha de conectividade — trata-se de uma falha de resposta de DNS.Então, porque é 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 de upstream e o resolvedor DNS podem ficar saturados muito rapidamente. O problema é agravado pelo facto de as redes de convidados partilharem normalmente um único resolvedor DNS de 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 para deteção de Captive Portal, a executar atualizações de aplicações em segundo plano e a efetuar 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 as centenas ou mesmo milhares de milissegundos. Começam a ocorrer tempos limite. Os erros de "ligado, sem internet" começam a inundar o sistema. 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 guardar 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 têm de 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 de 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 na plataforma de WiFi de convidados da Purple - funciona como um resolvedor DNS local de alto desempenho que se situa entre os seus dispositivos de convidados e a internet upstream. Em vez de reencaminhar cada consulta para um resolvedor público remoto, 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 de upstream. O resultado é uma latência de consulta DNS drasticamente reduzida - normalmente 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 "ligado, sem internet" desaparece e o tempo de integração dos convidados diminui significativamente. Do ponto de vista das normas, esta arquitetura está alinhada 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 da 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] Deixe-me dar-lhe a orientação prática de implementação. Quando está a implementar um filtro DNS empresarial numa rede WiFi de convidados, há 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. Quando implementa 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 a implementação de qualquer política de filtragem DNS. Terceiro, o ajuste do TTL. Configure o seu resolvedor DNS local para fornecer TTLs curtos para domínios de sondagem 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 a montante 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, terminais de VPN corporativas, armazenamento na nuvem. Isto gera um tipo diferente de pedido 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-a 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 analisar as 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 por limite de tempo. Um resolvedor local ou regional terá sempre um desempenho superior ao de um resolvedor público numa rede congestionada. "Isto afeta as implementações 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 tempo limite de DNS ocorre independentemente do padrão de encriptação em utilização. "Como posso saber se o DNS é a verdadeira causa dos meus erros '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 prazo de dois segundos, o tempo limite de DNS é o culpado. "Um filtro de DNS empresarial ajuda com a 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] Em resumo: 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 e 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 - encontramo-nos no próximo. [FIM DO EPISÓDIO]