Como Melhorar a Velocidade do WiFi Sem Comprar Novos Access Points

Como Melhorar a Velocidade do WiFi Sem Comprar Novos Pontos de Acesso Uma Sessão Técnica da Purple — Aproximadamente 10 Minutos --- INTRODUÇÃO E CONTEXTO (aprox. 1 minuto) --- Bem-vindo à série de Sessões Técnicas da Purple. Eu sou o seu anfitrião e hoje vamos abordar uma das conversas mais comuns que tenho com diretores de TI e CTOs em espaços empresariais — o problema da capacidade do WiFi. Tem um hotel, uma rede de retalho, um centro de conferências ou um estádio. Os seus clientes e funcionários queixam-se de um WiFi lento. O seu primeiro instinto — e, francamente, o instinto com que o seu fornecedor de infraestrutura está a contar — é comprar mais pontos de acesso. Novo hardware, maior implementação, fatura mais elevada. Mas a questão é esta. Na maioria dos casos que analisei, o problema não são de todo os pontos de acesso. O problema é o que está a passar por eles. E isso é um problema de software, o que significa que a solução é de software. Hoje vou explicar-lhe exatamente como o filtro de DNS e a otimização ao nível do software podem recuperar trinta por cento ou mais da sua largura de banda existente — sem tocar num único componente de hardware. Vamos abordar a arquitetura técnica, cenários de implementação no mundo real e o caso de negócio que pode apresentar ao seu CFO. Vamos a isso. --- ANÁLISE TÉCNICA DETALHADA (aprox. 5 minutos) --- Primeiro, vamos estabelecer o problema central. Quando olhamos para o que está realmente a consumir largura de banda numa rede WiFi de convidados empresarial típica, a repartição é genuinamente surpreendente para a maioria das pessoas. As redes de publicidade e os rastreadores de terceiros — a telemetria de fundo que cada aplicação em cada dispositivo está constantemente a enviar — representam entre vinte e cinco e quarenta por cento do volume de consultas DNS numa rede de convidados típica. Estes não são pedidos que os seus convidados estejam a fazer conscientemente. São automáticos. Sempre que alguém abre uma aplicação de notícias, uma plataforma de redes sociais ou uma aplicação de retalho no telemóvel, essa aplicação envia dezenas de pesquisas DNS para servidores de publicidade, plataformas de análise e píxeis de monitorização. Nenhum desse tráfego está a trazer valor aos seus convidados. Tudo isso está a consumir a capacidade da sua ligação de uplink. Além disso, temos o tráfego de malware e botnets. Dispositivos comprometidos — e numa grande rede de convidados, haverá sempre dispositivos comprometidos — estão constantemente a tentar comunicar com servidores de comando e controlo. Esse tráfego não só está a desperdiçar largura de banda, como é uma responsabilidade de conformidade e segurança. Portanto, antes que um único byte de tráfego legítimo — uma videochamada, uma página web, uma transação de pagamento — chegue sequer ao seu uplink, já consumiu entre um terço e metade da sua capacidade disponível em ruído. Agora, o filtragem de DNS opera na camada de resolução. Cada pedido de internet começa com uma consulta DNS — uma pesquisa que traduz um nome de domínio num endereço IP. O filtragem de DNS intercepta essa consulta antes mesmo de ela chegar ao seu uplink. Se o domínio se resolver para uma rede de publicidade, um host de malware conhecido ou uma categoria restrita por políticas, a consulta é bloqueada na camada de DNS. O dispositivo recebe uma resposta nula. Nenhum dado é transferido. Nenhuma largura de banda é consumida. Isto é fundamentalmente diferente de uma firewall ou de um proxy. Uma firewall inspeciona os pacotes depois de estes já terem chegado. Um proxy intercepta o tráfego a meio do fluxo. O filtragem de DNS interrompe o pedido antes de este começar — e é por isso que a recuperação de largura de banda é tão significativa. Não está a limpar o tráfego que já chegou; está a evitar que ele seja sequer solicitado. Do ponto de vista da arquitetura, a implementação é simples. Configura o seu servidor DHCP para apontar os dispositivos clientes para o seu resolvedor de filtragem de DNS, em vez do DNS predefinido do seu ISP. Normalmente, trata-se de uma alteração de duas linhas na sua configuração DHCP. As regras de filtragem são mantidas centralmente — na nuvem ou localmente, dependendo dos seus requisitos de conformidade — e aplicadas uniformemente em todos os dispositivos ligados, independentemente do ponto de acesso ao qual estejam associados. Este é um ponto crítico para operadores multi-site. Uma cadeia de retalho com duzentas lojas, ou um grupo hoteleiro com cinquenta propriedades, pode implementar uma política de filtragem de DNS consistente em todo o património a partir de uma única consola de gestão. Sem visitas de engenharia ao local. Sem configuração por local. As alterações de política propagam-se em minutos. Agora, há uma consideração técnica importante aqui que quero destacar para os arquitetos presentes. O aparecimento do DNS over HTTPS — DoH — cria um desafio para o filtragem de DNS tradicional. Quando um dispositivo utiliza DoH, encripta as suas consultas DNS e envia-as diretamente para um resolvedor específico — normalmente um operado por um fornecedor de browser — contornando totalmente o seu DNS ao nível da rede. Isto significa que as suas regras de filtragem são contornadas. A solução é impor a interceção de DoH ao nível da rede. Isto envolve identificar o tráfego DoH — que corre na porta 443 para gamas de IP de resolvedores conhecidos — e bloqueá-lo ou redirecioná-lo para o seu próprio resolvedor de filtragem compatível com DoH. Esta é uma configuração mais avançada, mas é essencial para manter a eficácia da filtragem em redes modernas onde o Chrome, Firefox e iOS estão cada vez mais a definir como padrão o DNS encriptado. A Purple publicou um guia detalhado sobre as implicações do DNS over HTTPS para a filtragem de WiFi público, que recomendo a leitura em conjunto com este briefing. Além do filtragem de DNS, existem várias otimizações complementares ao nível da camada de software que vale a pena implementar em paralelo. O band steering é uma das medidas com maior impacto. A maioria dos pontos de acesso modernos suporta as bandas de 2.4 gigahertz e 5 gigahertz. A banda de 5 gigahertz oferece um débito significativamente superior, mas um alcance menor. Sem um band steering ativo, os dispositivos associam-se frequentemente à banda de 2.4 gigahertz por predefinição — particularmente os dispositivos mais antigos e o hardware IoT — criando congestionamento numa banda que já está sobrecarregada com tráfego legado. Ativar o band steering no seu controlador sem fios direciona os dispositivos compatíveis para os 5 gigahertz, libertando os 2.4 gigahertz para os dispositivos que realmente precisam. A consolidação de SSIDs é outra vitória rápida. Cada SSID que transmite consome tempo de antena através de tramas beacon — tráfego de gestão que todos os dispositivos ao alcance têm de processar. Um espaço que execute oito ou dez SSIDs para diferentes departamentos, prestadores de serviços e níveis de convidados está a desperdiçar uma percentagem mensurável de tempo de antena em custos de gestão. Consolidar para três ou quatro SSIDs — guest, staff, IoT e gestão — e utilizar a etiquetagem VLAN para segmentação em vez de SSIDs separados pode recuperar esse tempo de antena imediatamente. A aplicação de políticas de QoS — Quality of Service — é a terceira alavanca. Sem QoS, um único convidado a transmitir vídeo em 4K pode saturar uma célula de rádio, degradando a experiência de todos os outros dispositivos nesse ponto de acesso. Implementar a limitação de largura de banda por cliente e a priorização de tráfego — elevando o tráfego de VoIP e de transações POS acima do streaming em massa — garante que o tráfego crítico para o negócio seja protegido mesmo sob carga máxima. Finalmente, o planeamento de canais e a otimização da potência de transmissão. Estes são frequentemente configurados e esquecidos durante a implementação inicial e nunca mais são revistos. À medida que o ambiente de RF muda — novos edifícios, novas fontes de interferência, alterações na densidade de dispositivos — as suas atribuições de canais podem estar a criar interferência de cocanal que degrada significativamente o débito. Realizar um levantamento passivo de RF e reotimizar as atribuições de canais é uma intervenção de custo zero que pode gerar melhorias substanciais de débito. --- RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS (aprox. 2 minutos) --- Permita-me apresentar-lhe uma sequência prática de implementação para um espaço de média dimensão — por exemplo, um hotel de duzentos quartos ou um centro de distribuição de retalho regional. Comece com uma medição de referência. Antes de alterar qualquer coisa, prepare a sua rede para capturar o volume de consultas DNS por categoria, o consumo de largura de banda por cliente e a utilização da ligação ascendente por hora do dia. Isto fornece-lhe o estado inicial para o seu cálculo de ROI. A maioria das plataformas de análise de WiFi empresariais apresenta estes dados de forma nativa — a plataforma de análise da Purple, por exemplo, fornece visibilidade ao nível do dispositivo que torna este exercício de referência simples. Passo dois: implemente a filtragem de DNS em modo de monitorização. A maioria das soluções empresariais de filtragem de DNS suporta um modo passivo onde as consultas são registadas e categorizadas, mas não bloqueadas. Execute isto durante quarenta e oito a setenta e duas horas para compreender a composição do seu tráfego antes de aplicar qualquer política. Isto evita que falsos positivos perturbem o tráfego legítimo no primeiro dia. Passo três: ative o bloqueio por fases. Comece com as categorias de maior confiança — domínios de malware conhecidos, comando e controlo de botnets e redes de publicidade. Estes são bloqueios de baixo risco com elevado impacto na largura de banda. Reveja os registos diariamente durante a primeira semana para detetar quaisquer bloqueios inesperados. Passo quatro: adicione camadas de QoS e band steering. Assim que a filtragem de DNS estiver estável, implemente a limitação de taxa por cliente e o band steering. Teste estas alterações fora das horas de ponta e valide se os terminais POS, telefones VoIP e outros dispositivos críticos para o negócio estão a funcionar corretamente. Passo cinco: documente e meça. Após trinta dias, extraia as suas métricas de utilização de largura de banda e compare-as com a sua linha de base. Na maioria das implementações, verá uma redução de vinte a quarenta por cento na utilização do uplink. Esse é o seu valor de ROI. Agora, as armadilhas. A mais comum que vejo é o excesso de bloqueio. Se ativar categorias agressivas de filtragem de conteúdos sem rever os registos primeiro, irá bloquear serviços legítimos. O armazenamento em nuvem, as aplicações SaaS empresariais e até alguns domínios de processamento de pagamentos podem aparecer em bloqueios de categorias amplas. Comece sempre de forma conservadora e expanda. A segunda armadilha é ignorar o desvio de DoH. Se implementar a filtragem de DNS sem abordar o DoH, verá a eficácia da sua filtragem diminuir ao longo do tempo, à medida que mais dispositivos passam a utilizar DNS encriptado por predefinição. Aborde isto ao nível da política de rede desde o primeiro dia. A terceira armadilha é não segmentar o tráfego de IoT. Os dispositivos IoT — smart TVs, sistemas de gestão de edifícios, sinalização digital — geram frequentemente um tráfego de DNS significativo para os servidores de telemetria do fabricante. Se não estiver a segmentar a IoT numa VLAN separada com a sua própria política de filtragem, poderá bloquear inadvertidamente a funcionalidade dos dispositivos quando apertar as suas regras de filtragem. --- PERGUNTAS E RESPOSTAS RÁPIDAS (aprox. 1 minuto) --- Deixe-me passar pelas perguntas que recebo com mais frequência. "A filtragem de DNS afetará a experiência dos convidados?" Na prática, os convidados nunca notam. Os domínios que estão a ser bloqueados são telemetria de fundo, não conteúdos que estejam ativamente a solicitar. Se houver alguma alteração, a sua experiência melhora porque há mais largura de banda disponível para as coisas que estão realmente a tentar fazer. "Isto requer alterações nos nossos pontos de acesso?" Não. A filtragem de DNS é configurada na camada do DHCP e do resolvedor de DNS. Os seus pontos de acesso não são alterados. "Isto está em conformidade com o GDPR?" O filtro de DNS regista consultas de domínio, não o conteúdo. Não está a realizar uma inspeção profunda de pacotes. Desde que tenha políticas de retenção de dados adequadas e o seu aviso de privacidade cubra a monitorização de rede — o que deve acontecer de qualquer forma — o filtro de DNS é totalmente compatível com o GDPR. Para implementações no setor público e na saúde, é frequentemente um requisito de conformidade e não uma escolha. "E quanto ao PCI DSS?" O filtro de DNS, na verdade, reforça a sua postura de PCI DSS ao impedir que os ambientes de dados de titulares de cartões comuniquem com domínios maliciosos conhecidos. É um controlo positivo, não um risco. --- RESUMO E PRÓXIMOS PASSOS (aprox. 1 minuto) --- Para resumir: a maioria dos problemas de desempenho de WiFi empresarial não são problemas de hardware. São problemas de software — especificamente, a ausência de uma gestão inteligente de tráfego na camada de DNS. Ao implementar o filtro de DNS, pode recuperar trinta por cento ou mais da sua largura de banda existente, prolongar a vida útil operacional da sua infraestrutura atual de pontos de acesso em dois a quatro anos e, simultaneamente, melhorar a sua postura de segurança e conformidade. O cronograma de implementação é medido em horas, não em meses. O investimento de capital é uma fração de uma renovação de hardware. Os próximos passos práticos são simples. Execute uma auditoria de tráfego de DNS na sua rede esta semana — a maioria das plataformas empresariais fornecerá estes dados sem qualquer ferramenta adicional. Identifique as suas principais categorias de domínios que consomem largura de banda. Em seguida, avalie uma solução de filtro de DNS em relação a essas categorias. Se opera uma rede WiFi de convidados em grande escala — hotelaria, retalho, eventos, setor público — a plataforma da Purple integra o filtro de DNS com a gestão e análise de WiFi de convidados numa única implementação. Isso significa que obtém a recuperação de largura de banda, os controlos de conformidade e as informações de dados de convidados a partir de uma única plataforma, em vez de três. Obrigado por ouvir o Purple Technical Briefing. O guia de implementação completo, diagramas de arquitetura e exemplos práticos estão disponíveis no guia escrito que acompanha esta apresentação. Até à próxima.