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

Gestão de Largura de Banda para WiFi de Funcionários: Shaping, QoS e Redução de Tráfego. Um Briefing Técnico Purple. Bem-vindo. Se está a ouvir isto, provavelmente está a lidar com uma das queixas mais comuns no departamento de TI das empresas: os funcionários queixam-se de que o WiFi está lento. Talvez seja a equipa de back-of-house de um hotel com dificuldades em processar check-ins. Talvez seja uma cadeia de retalho onde os terminais de POS estão a esgotar o tempo de resposta (timeout). 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. Independentemente do contexto, a causa raiz é quase sempre a mesma — tem mais tráfego do que aquele para o qual a sua rede foi concebida, e o tráfego errado está a ter prioridade. Neste briefing, vamos abordar três aspetos: como o traffic shaping e o QoS funcionam realmente num ambiente de WiFi de funcionários, como se caracteriza uma implementação prática em diferentes tipos de espaços, e como a implementação do Purple Shield para bloqueio de anúncios pode reduzir a carga global da sua rede de forma significativa — sem alterar a velocidade da sua linha ou investir em atualizações de infraestrutura. Vamos começar. Secção um: Compreender o problema. A maioria dos espaços empresariais partilha a mesma ligação à Internet. O WiFi de funcionários, o WiFi de convidados, os sistemas de back-office, o CCTV, os sistemas de gestão técnica centralizada — todos partilham o mesmo canal de upstream. Quando esse canal fica congestionado, tudo degrada. Mas nem todo o tráfego é igual. Uma chamada VoIP que vai abaixo a meio de uma frase é catastrófica. Uma atualização de software que demora mais dois minutos é irrelevante. O problema é que, sem uma gestão ativa, a sua rede não sabe distinguir as duas situações. O traffic shaping é o mecanismo que utiliza para indicar à rede qual é o tráfego que importa. O Quality of Service, ou QoS, é a estrutura que define as regras. Em conjunto, 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, best effort (melhor esforço) e background (fundo). 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 da rede 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 background — atualizações de software, transferências em massa, tudo o que possa esperar. Quando mapeia o tráfego das suas aplicações 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 ficar num VLAN próprio - uma Virtual Local Area Network - completamente isolado do WiFi de convidados e dos dispositivos IoT. Este não é apenas um requisito de segurança sob o PCI DSS e o GDPR; é um pré-requisito para uma QoS eficaz, porque pode aplicar políticas diferentes a VLANs diferentes. Uma arquitetura típica de um espaço empresarial é assim. Tem um switch central ligado ao seu gateway de internet. A partir desse switch, tem múltiplos VLANs: um para dispositivos da equipa, um para acesso de convidados, um para POS e sistemas de pagamento, e um para a gestão do edifício. Cada VLAN tem a sua própria política de QoS. Ao VLAN da equipa é atribuída a maior largura de banda garantida. O VLAN de convidados recebe um limite de taxa por utilizador - tipicamente de dois a cinco megabits por segundo de downstream - para que nenhum visitante individual consiga saturar a ligação. No próprio 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 geral na web recebe o melhor esforço (best effort). As atualizações de software e os downloads de patches de SO recebem DSCP CS1 - são executados em segundo plano e não competem com o tráfego operacional. Para a autenticação, os dispositivos da equipa devem autenticar-se usando 802.1X com EAP-TLS - baseado em certificados - ou PEAP com MSCHAPv2 contra o seu servidor RADIUS. Se utiliza o Microsoft Entra ID, Okta ou Google Workspace, a Purple integra-se diretamente com os três via 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 oculto de largura de banda - e como o 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 monitorização, scripts de analítica e endpoints de telemetria. Estudos da Ghostery e de analíticas semelhantes de bloqueio de anúncios 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 consultas 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 monitorização são vetores de ataque reais. O Purple Shield resolve 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 Shield opera como um filtro ao nível do DNS. Cada consulta DNS do VLAN da equipa passa pela lista de bloqueio do Shield antes de ser resolvida. Os domínios de redes de anúncios, endpoints de rastreadores conhecidos e domínios maliciosos são bloqueados antes de um único byte de conteúdo ser descarregado. O dispositivo nunca chega a estabelecer 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 trackers, agora disponível para o seu sistema ERP, as suas videochamadas, os seus terminais POS. Obtém o equivalente a um upgrade 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 os antivírus de endpoint muitas vezes não detetam - particularmente em dispositivos IoT e terminais partilhados que não executam software de segurança tradicional. Secção quatro: Implementação no mundo real. Deixe-me apresentar-lhe dois cenários. Primeiro: um hotel de 200 quartos. A equipa de back-of-house executa o software de gestão hoteleira, um sistema de telefonia VoIP e uma plataforma de videovigilância na mesma rede. O WiFi de clientes 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 hoteleira fica extremamente lento porque os funcionários estão a ouvir música em streaming e o sistema de vigilância está a fazer o upload de filmagens. A solução: aplicar DSCP EF ao tráfego do sistema de gestão hoteleira e ao sistema VoIP. Aplicar DSCP AF41 ao tráfego de upload da vigilância - é importante, mas não é sensível à latência. Aplicar DSCP CS1 a tudo o resto. Implementar o Shield na VLAN dos funcionários para eliminar o tráfego de anúncios e trackers. Resultado: os tempos de resposta do sistema de gestão hoteleira 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 avaliar 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 dos funcionários, o WiFi de clientes e os terminais POS. Durante os períodos de maior atividade comercial, a navegação dos funcionários em dispositivos pessoais satura a ligação e as transações de POS começam a falhar por timeout. A cadeia está a ponderar atualizar para linhas de 200 megabits, com um custo de cerca de 18.000 libras por ano em todo o portefólio. A solução: segmentar os terminais POS para uma VLAN dedicada com largura de banda garantida. Aplicar limites de largura de banda por utilizador na VLAN de WiFi dos funcionários - 10 megabits de download por utilizador, 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%, os timeouts de POS caem para zero e a atualização de linha é adiada indefinidamente. A poupança anual apenas em custos de linha é de 18.000 libras. A configuração do Shield e do QoS custa uma fração desse valor. Secção cinco: Erros comuns na implementação. Alguns aspetos a ter em conta. Remarcação de DSCP. Muitos ISPs e alguns switches empresariais removem ou remarcam os valores de DSCP no limite 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 - particularmente terminais partilhados e sensores IoT - não suportam o WMM corretamente. Podem ignorar marcações 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 estrito de largura de banda de 10 megabits por utilizador parece razoável, mas se 20 funcionários iniciarem atualizações de software em simultâneo, irá atingir o limite global. Utilize o escalonamento token bucket com tolerância a rajadas em vez de um policiamento rígido. Isto permite rajadas curtas enquanto limita 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. Precisa de bloquear o DNS-over-HTTPS na firewall ou de 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 fornecer uma qualidade VoIP fraca 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 de imediato. Funciona com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet - sem necessidade de alterações de hardware. Como meço o impacto? Monitorize três métricas antes e depois da implementação: percentagem de utilização de pico no seu uplink, volume de consultas DNS por hora e tempos de resposta das aplicações para os seus sistemas críticos. O painel da Purple apresenta as três em tempo real. Secção sete: Resumo e próximos passos. Para resumir. Gerir a largura de banda para o WiFi dos 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. O controlo 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 gastos em infraestrutura. Os seus próximos passos: audite a sua estrutura atual de VLAN e confirme que o WiFi dos funcionários está isolado do tráfego de convidados e de IoT. Mapeie as suas aplicações críticas para classes DSCP. Implemente o Shield na VLAN dos funcionários e meça a redução de consultas DNS. Reveja os seus limites de largura de banda por utilizador trimestralmente à medida que o número de dispositivos muda. Se quiser aprofundar qualquer um destes pontos, o guia escrito completo está disponível em purple.ai. Abrange a arquitetura técnica em detalhe, 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 nos ouvir. Esta foi uma sessão técnica da Purple.