Gestão de Largura de Banda para WiFi de Colaboradores: Shaping, QoS e Redução de Tráfego

Gestão de Largura de Banda para WiFi de Funcionários: Modulação de Tráfego, QoS e Redução de Tráfego. Um Briefing Técnico da Purple. Bem-vindo. Se está a ouvir isto, provavelmente está a lidar com uma das reclamações mais comuns nas TI empresariais: os funcionários a dizer que o WiFi está lento. Talvez seja a equipa de apoio de um hotel com dificuldades em processar check-ins. Talvez seja uma cadeia de lojas onde os terminais POS estão a expirar o tempo limite. Ou talvez seja um centro de conferências onde a equipa de AV não consegue uma ligação estável durante um evento ao vivo. Qualquer que seja o contexto, a causa raiz é quase sempre a mesma - tem mais tráfego do que a sua rede foi concebida para suportar, e o tráfego errado está a ter prioridade. Neste briefing, vamos abordar três pontos: como a modulação de tráfego e o QoS realmente funcionam num ambiente de WiFi de funcionários, como é uma implementação prática em diferentes tipos de locais e como a implementação do Purple Shield para bloqueio de anúncios pode reduzir a carga geral da sua rede de forma significativa - sem alterar a velocidade da sua linha ou gastar em atualizações de infraestrutura. Vamos começar. Secção um: Compreender o problema. A maioria dos locais empresariais funciona com uma ligação à internet partilhada. O WiFi de funcionários, o WiFi de convidados, os sistemas administrativos, o CCTV, os sistemas de gestão do edifício - todos partilham a mesma largura de banda de subida. Quando essa ligação fica congestionada, tudo degrada. Mas nem todo o tráfego é igual. Uma chamada VoIP cair a meio de uma frase é catastrófico. Uma atualização de software demorar mais dois minutos é irrelevante. O problema é que, sem uma gestão ativa, a sua rede não sabe a diferença. A modulação de tráfego é o mecanismo que utiliza para dizer à rede qual é o tráfego que importa. O Quality of Service, ou QoS, é a estrutura que define as regras. Juntos, permitem-lhe garantir largura de banda para aplicações críticas e limitar tudo o resto. O padrão IEEE 802.11e introduziu o QoS nas redes sem fios através de um mecanismo chamado WMM - Wireless Multimedia. O WMM define quatro categorias de acesso: voz, vídeo, melhor esforço (best effort) e segundo plano. Todos os pontos de acesso modernos da Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e Ubiquiti UniFi suportam WMM. A questão é saber se o está a utilizar corretamente. Do lado com fios, o QoS é implementado utilizando marcações DSCP - Differentiated Services Code Point - no cabeçalho IP. O DSCP EF, que significa Expedited Forwarding, é utilizado para tráfego de voz. O DSCP AF41 é utilizado para videoconferência. O DSCP CS1 é a classe de segundo plano - atualizações de software, transferências em massa, quaisquer transações que possam aguardar. Quando mapeia o tráfego da sua aplicação para as marcações DSCP corretas e configura os seus switches e pontos de acesso para as respeitarem, obtém um desempenho previsível para as aplicações que importam. Secção dois: Arquitetura e segmentação. Antes de configurar a QoS, precisa de segmentar a sua rede corretamente. O WiFi da equipa deve estar na sua própria VLAN - uma Virtual Local Area Network - completamente isolada do WiFi de convidados e dos dispositivos IoT. Isto não é apenas um requisito de segurança sob a PCI-DSS e o GDPR; é um pré-requisito para uma QoS eficaz, porque pode aplicar políticas diferentes a diferentes VLANs. Uma arquitetura típica de espaço empresarial assemelha-se a isto. Tem um switch principal ligado ao seu gateway de internet. A partir desse switch, tem múltiplas VLANs: uma para dispositivos da equipa, uma para acesso de convidados, uma para sistemas POS e de pagamento, e uma para a gestão do edifício. Cada VLAN tem a sua própria política de QoS. A VLAN da equipa recebe a maior alocação de largura de banda garantida. A VLAN de convidados recebe um limite de taxa por utilizador - normalmente de dois a cinco megabits por segundo de downstream - para que nenhum visitante individual consiga saturar a ligação. Na própria VLAN da equipa, aplica QoS sensível a aplicações. As transações de POS e o tráfego de autenticação RADIUS recebem DSCP EF - a prioridade mais alta. O seu sistema ERP e as ferramentas de videoconferência recebem DSCP AF41. A navegação web geral recebe o melhor esforço. As atualizações de software e as transferências de patches de SO recebem DSCP CS1 - são executadas em segundo plano e não competem com o tráfego operacional. Para a autenticação, os dispositivos da equipa devem autenticar-se utilizando 802.1X com EAP-TLS - baseado em certificados - ou PEAP com MSCHAPv2 no seu servidor RADIUS. Se utiliza o Microsoft Entra ID, o Okta ou o Google Workspace, a Purple integra-se diretamente com os três através de SAML e SCIM, pelo que o seu fornecedor de identidade se torna a fonte de verdade para o acesso à rede. Quando um membro da equipa sai, revoga o seu acesso no Entra ID e o acesso à rede desaparece automaticamente. Secção três: O dreno de largura de banda oculto - e como o Purple Shield o resolve. Eis algo em que a maioria das equipas de TI não pensa. Uma parte significativa do tráfego no seu WiFi de equipa não tem nada a ver com o seu negócio. Cada página web que um membro da equipa visita carrega dezenas de redes de anúncios de terceiros, pixéis de rastreio, scripts de analítica e endpoints de telemetria. Estudos da Ghostery e analíticas de bloqueio de anúncios semelhantes mostram consistentemente que os pedidos de anúncios e rastreadores representam entre 25% e 40% do total de pedidos HTTP numa sessão de navegação típica. Esse tráfego consome largura de banda real. Consome capacidade de consulta de DNS. Adiciona latência a cada carregamento de página. E introduz riscos de segurança - malvertising, downloads automáticos não autorizados (drive-by downloads) e exfiltração de dados através de pixéis de rastreio são todos vetores de ataque reais. O Purple Shield aborda isto ao nível da rede. Em vez de depender de extensões de navegador que a equipa pode ou não ter instalado, o Purple Shield funciona como um filtro ao nível do DNS. Cada consulta de DNS da VLAN da equipa passa pela lista de bloqueio do Purple Shield antes de ser resolvida. Os domínios de redes de anúncios, os endpoints de rastreadores conhecidos e os domínios maliciosos são bloqueados antes que um único byte de conteúdo seja descarregado. O dispositivo nunca estabelece a ligação. A largura de banda nunca é consumida. Na prática, os locais que implementam o Shield no seu WiFi de funcionários reportam uma redução no volume total de consultas DNS de cerca de 30%. Trata-se de largura de banda que era anteriormente desperdiçada em anúncios e rastreadores, agora disponível para o seu sistema ERP, as suas videochamadas, os seus terminais POS. Obtém o equivalente a uma atualização de 30% na largura de banda sem pagar por uma linha mais rápida. O Shield também reduz a sua exposição de segurança. Ao bloquear domínios maliciosos conhecidos na camada DNS, elimina uma categoria de ameaça que o antivírus de endpoint muitas vezes não deteta - particularmente em dispositivos IoT e terminais partilhados que não executam software de segurança tradicional. Secção quatro: Implementação no mundo real. Permita-me orientá-lo através de dois cenários. Primeiro: um hotel de 200 quartos. A equipa de back-office executa software de gestão de propriedade, um sistema telefónico VoIP e uma plataforma de videovigilância na mesma rede. O WiFi de convidados está numa VLAN separada com um limite de cinco megabits por utilizador, mas a VLAN dos funcionários não tem política de QoS. Durante os períodos de pico de check-in, o sistema de gestão de propriedade abranda drasticamente porque os funcionários estão a transmitir música e o sistema de vigilância está a carregar imagens. A solução: aplicar DSCP EF ao tráfego do sistema de gestão de propriedade e ao sistema VoIP. Aplicar DSCP AF41 ao tráfego de carregamento de vigilância - é importante, mas não sensível à latência. Aplicar DSCP CS1 a tudo o resto. Implementar o Shield na VLAN de funcionários para eliminar o tráfego de anúncios e rastreadores. Resultado: os tempos de resposta do sistema de gestão de propriedade diminuem mais de 40% durante os períodos de pico. A qualidade das chamadas VoIP melhora de forma mensurável na escala Mean Opinion Score utilizada para classificar a qualidade de voz. Segundo: uma cadeia de retalho com 50 lojas. Cada loja tem uma única ligação de banda larga de 100 megabits partilhada entre o WiFi de funcionários, o WiFi de convidados e os terminais POS. Durante os períodos de maior atividade comercial, a navegação dos funcionários nos seus dispositivos pessoais satura a ligação e as transações de POS começam a expirar. A cadeia está a ponderar a atualização para linhas de 200 megabits com um custo de cerca de 18.000 libras por ano em todo o parque de lojas. A solução: segmentar os terminais POS numa VLAN dedicada com largura de banda garantida. Aplicar limites de largura de banda por utilizador na VLAN do WiFi de funcionários - 10 megabits por utilizador de download, dois megabits de upload. Implementar o Shield para eliminar o tráfego de anúncios. A combinação reduz a utilização de pico em 35%, as falhas por limite de tempo nos POS descem para zero e a atualização de linha é adiada indefinidamente. A poupança anual apenas nos custos de linha é de 18.000 libras. A configuração do Shield e do QoS custou uma fração desse valor. Secção cinco: Armadilhas na implementação. Alguns aspetos a ter em conta. Remarcação de DSCP. Muitos ISPs e alguns switches empresariais removem ou remarcam os valores DSCP na fronteira da rede. Verifique se as suas marcações de QoS sobrevivem a todo o percurso desde o dispositivo até à aplicação. Utilize uma captura de pacotes no gateway para verificar. WMM e dispositivos antigos. Alguns dispositivos mais antigos - especialmente terminais partilhados e sensores de IoT - não suportam o WMM corretamente. Podem ignorar as marcações de QoS ou gerar tráfego com valores DSCP incorretos. Audite o seu inventário de dispositivos antes de implementar políticas de QoS. Limitação de largura de banda e tráfego de rajada. Um limite rígido de taxa de 10 megabits por utilizador parece razoável, mas se 20 funcionários iniciarem atualizações de software em simultâneo, atingirá o limite agregado. Utilize a modelação por balde de fichas (token bucket shaping) com uma tolerância de rajada em vez de uma política rígida. Isto permite rajadas curtas ao mesmo tempo que restringe a utilização sustentada de elevada largura de banda. Shield e DNS-over-HTTPS. Se os dispositivos dos funcionários utilizarem DNS-over-HTTPS para contornar o seu resolvedor de DNS, a filtragem do Shield não será aplicada. Terá de bloquear o DNS-over-HTTPS na firewall ou configurar os seus dispositivos através de MDM para utilizarem o seu resolvedor de DNS interno. Este é um passo de configuração único e não um fardo de gestão contínuo. Secção seis: Perguntas rápidas. Preciso de QoS se tiver muita largura de banda? Sim. Largura de banda não é o mesmo que desempenho. Uma ligação de 1 gigabit sem QoS continuará a apresentar uma fraca qualidade de VoIP se um único dispositivo estiver a realizar uma transferência de ficheiros em massa. O QoS garante que o tráfego sensível à latência obtém a prioridade de fila de que necessita, independentemente do débito total. Posso implementar o Shield sem alterar o meu hardware existente? Sim. O Shield funciona como uma sobreposição de DNS. Aponta o seu servidor DHCP para os resolvedores de DNS da Purple e o Shield é aplicado imediatamente. Funciona com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet - não são necessárias alterações de hardware. Como meço o impacto? Monitorize três métricas antes e depois da implementação: percentagem de utilização máxima na sua ligação ascendente (uplink), volume de consultas DNS por hora e tempos de resposta de aplicações para os seus sistemas críticos. O dashboard da Purple apresenta as três em tempo real. Secção sete: Resumo e próximos passos. Em resumo. Gerir a largura de banda para o WiFi de funcionários não se trata de comprar mais largura de banda. Trata-se de garantir que a largura de banda que tem vai para os locais certos. A modelação de tráfego e o QoS dão-lhe o controlo. O Purple Shield dá-lhe a redução. Juntos, proporcionam melhorias mensuráveis no desempenho das aplicações sem despesas em infraestrutura. Os seus próximos passos: audite a sua estrutura atual de VLAN e confirme que o WiFi de funcionários está isolado do tráfego de convidados e de IoT. Mapeie as suas aplicações críticas para as classes DSCP. Implemente o Shield na sua VLAN de funcionários e meça a redução de consultas DNS. Reveja os seus limites de taxa por utilizador trimestralmente à medida que o número de dispositivos muda. Se quiser aprofundar qualquer um destes aspetos, o guia escrito completo está disponível em purple.ai. Abrange detalhadamente a arquitetura técnica, inclui exemplos de configuração para as principais plataformas de hardware e orienta-o no cálculo do ROI para a implementação do Shield. Obrigado por ouvir. Esta foi uma apresentação técnica da Purple.