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. Sou o seu anfitrião e hoje vamos abordar um dos problemas mais persistentes e frustrantes nas redes de grandes locais corporativos: 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, já deve ter visto isso. O dispositivo do visitante mostra barras de sinal cheias, 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 carrega. O visitante liga para a recepção. Sua equipe de suporte executa um teste de ping, tudo parece bem 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 do firewall e não é um problema de largura de banda no sentido tradicional. É um problema de tempo limite de DNS - e quase sempre é desencadeado por congestionamento na rede. Hoje, quero explicar exatamente por que isso acontece, como diagnosticar isso de forma confiável e como a implantação de um filtro de DNS corporativo resolve esse gargalo permanentemente. [APROFUNDAMENTO TÉCNICO - aproximadamente 5 minutos] Vamos começar com os fundamentos. 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 seu 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, celulares Android, notebooks Windows - possui um mecanismo integrado chamado sonda de detecção de Captive Portal. No iOS, por exemplo, o dispositivo envia uma requisição HTTP para um endpoint conhecido da Apple, algo como captive.apple.com. No Android, ele acessa connectivitycheck.gstatic.com. No Windows, ele sonda msftconnecttest.com. Essas sondas são projetadas para detectar se a rede exige uma página de login antes de conceder acesso à internet. O ponto crítico é este: essas sondas são dependentes de DNS. O dispositivo precisa primeiro resolver o nome de domínio do endpoint da sonda antes de enviar a requisição HTTP. E essa consulta DNS tem um tempo limite - normalmente entre um e cinco segundos, dependendo do sistema operacional. Se o resolvedor DNS na sua rede não responder dentro dessa janela, o dispositivo conclui que a rede não tem conectividade com a internet, mesmo que esteja totalmente associado e tenha um endereço IP válido. Esse é o erro de "conectado, sem internet". Não é uma falha de conectividade - é uma falha de resposta de DNS. Por que o DNS falha em uma rede congestionada? Essa é a parte que pega muitas equipes de surpresa. As consultas de DNS são enviadas por UDP por padrão, 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 for descartado devido ao congestionamento da rede, o cliente simplesmente aguarda até que o tempo limite expire e, em seguida, tenta novamente ou desiste. Em uma rede WiFi de convidados 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 conferências durante uma palestra de abertura - o link de upload e o resolvedor DNS podem ficar saturados muito rapidamente. O problema é agravado pelo fato de que as redes de convidados normalmente compartilham um único resolvedor DNS de upload, muitas vezes o resolvedor padrão do provedor de internet ou um resolvedor público como o 8.8.8.8. Quando cada dispositivo na rede está simultaneamente sondando a detecção de Captive Portal, executando atualizações de aplicativos em segundo plano e fazendo consultas DNS para redes sociais e serviços de streaming, esse resolvedor único se torna um gargalo. Os tempos de resposta das consultas sobem da faixa normal de sub - 50 milissegundos para centenas ou até milhares de milissegundos. Os tempos limites começam a ocorrer. Os erros de "conectado, sem internet" começam a inundar o sistema. Há também um mecanismo secundário que vale a pena entender: a exaustão de TTL. As respostas de 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 de DNS não está otimizado para ambientes de convidados de alta densidade. E é exatamente isso que um filtro DNS corporativo resolve. Um filtro DNS corporativo - como a capacidade de filtragem de DNS na plataforma de WiFi de convidados 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 complacentes antes que eles cheguem ao resolvedor de upload. O resultado é uma redução drástica na latência das consultas DNS - normalmente de tempos limites de dois a três segundos para respostas inferiores a 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, esta arquitetura se alinha com as recomendações do IEEE 802.11 para implantações de alta densidade e oferece suporte à 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 PCI-DSS, garantindo que o tráfego DNS de visitantes seja isolado de sua infraestrutura de resolução corporativa. [RECOMENDAÇÕES DE IMPLANTAÇÃO E ARMADILHAS - aproximadamente 2 minutos] Deixe-me dar as orientações práticas de implantação. Quando você estiver implantando um filtro DNS corporativo em uma rede WiFi de visitantes, existem três decisões de configuração que determinarão o seu sucesso ou fracasso. Primeiro, a localização do resolvedor. Seu filtro DNS deve ser implantado o mais próximo possível da rede de visitantes - de preferência na mesma VLAN ou sub-rede que seus pontos de acesso de visitantes. Cada salto entre o dispositivo do visitante e o resolvedor adiciona latência. Se o seu filtro DNS estiver localizado em um data center remoto e a sua rede de visitantes estiver em um hotel em Manchester, você estará adicionando um tempo de ida e volta que anula o propósito. Use um dispositivo local ou um filtro DNS baseado em nuvem com um ponto de presença regional. Segundo, 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 visitantes são redirecionados para autenticação - esteja na lista de permissões 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 DNS. Terceiro, 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 consultem novamente com frequência e sempre obtenham uma resposta local rápida, em vez de esperar que uma entrada em cache expire e 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 acidentalmente domínios usados por aplicativos legítimos de visitantes - serviços de streaming, endpoints de VPN corporativos, armazenamento em nuvem. Isso gera uma classe diferente de ticket de suporte, mas é igualmente prejudicial para a experiência do visitante. Comece com uma política conservadora, monitore os logs de consultas DNS em busca de domínios bloqueados e refine-os 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 passar pelas perguntas que recebo com mais frequência sobre este assunto. "Posso simplesmente usar 8.8.8.8 como meu resolvedor DNS de visitantes?" Você pode, mas sob carga ele sofrerá 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 de autenticação, mas não altera o caminho de resolução 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 convidados durante o pico de carga. Filtre pelo tráfego da porta UDP 53. Se você vir consultas DNS sem a resposta correspondente em dois segundos, o timeout de DNS é o culpado. "Um filtro DNS corporativo ajuda na conformidade?" Sim - o registro de consultas 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 convidados é, 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 DNS corporativo local de alto desempenho que resolve 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 DNS durante o pico de carga para confirmar o diagnóstico; revise a localização atual do seu resolvedor DNS e identifique se ele é local ou remoto; e avalie a implantação de um filtro DNS corporativo na sua VLAN de convidados. Se você quiser se aprofundar em qualquer um desses pontos, a documentação da plataforma Purple aborda a configuração do filtro DNS em detalhes, e os guias de otimização de WiFi de convidados em purple.ai valem a pena ser revisados junto com este resumo. Obrigado por ouvir - nos vemos no próximo episódio. [FIM DO EPISÓDIO]