SonicWall e guest WiFi: configuração de captive portal com Purple

INTEGRAÇÃO DO SONICWALL TZ E SONICWAVE COM O PURPLE WIFI Série de Briefings Técnicos da Plataforma de Inteligência Purple WiFi Duração: Aproximadamente 10 minutos Voz: Inglês britânico, tom de consultor sénior - confiante, conversacional, autoritário --- SEGMENTO 1: INTRODUÇÃO E ENQUADRAMENTO (aproximadamente 1 minuto) Bem-vindo à Série de Briefings Técnicos da Purple. Hoje vamos abordar uma das integrações tecnicamente mais complexas no espaço de WiFi empresarial: as firewalls SonicWall TZ e os pontos de acesso SonicWave, implementados em conjunto com o Purple para autenticação de convidados, controlo de acessos de funcionários e isolamento de redes multi-tenant. Se é um engenheiro de segurança de TI ou um MSP a gerir locais - hotéis, cadeias de retalho, centros de conferências ou empreendimentos de uso misto - este briefing é para si. Vamos avançar rapidamente pela arquitetura, pelos passos de configuração e pelos pontos onde as implementações costumam falhar. A SonicWall é uma escolha sólida no mercado de PMEs e empresas de média dimensão. As firewalls da série TZ estão amplamente implementadas e os APs SonicWave integram-se nativamente através do SonicOS e do Wireless Network Manager. Quando adiciona o Purple por cima, obtém uma camada de WiFi para convidados gerida na cloud com splash pages personalizadas, autenticação baseada em RADIUS e captura de dados primários - tudo isto sem substituir a sua infraestrutura SonicWall existente. Vamos entrar na arquitetura. --- SEGMENTO 2: ANÁLISE TÉCNICA DETALHADA (aproximadamente 5 minutos) Há quatro casos de utilização distintos para abordar aqui e cada um tem um caminho de configuração diferente. WiFi de Convidados com redirecionamento de Captive Portal. Exceções de Walled Garden. WiFi Seguro de Funcionários utilizando 802.1X. E isolamento multi-tenant utilizando chaves pré-partilhadas privadas (PPSK) da SonicWall com direcionamento dinâmico de VLAN. Vamos começar com o WiFi de Convidados e o Captive Portal da SonicWall. O SonicOS utiliza um mecanismo chamado Lightweight Hotspot Messaging - LHM - para lidar com redirecionamentos de Captive Portal externos. Quando um convidado se liga ao seu SSID de convidados e abre um navegador, o SonicWall intercepta esse pedido HTTP e redireciona-o para o URL da splash page da Purple. O convidado autentica-se na plataforma da Purple - através de login social, e-mail ou um clique de aceitação - e a Purple envia uma autorização LHM de volta para o SonicWall na porta TCP 4043. O SonicWall abre então o acesso à internet para o endereço MAC desse dispositivo. A configuração no SonicOS 7.x funciona da seguinte forma. Primeiro, navegue até Object, depois Match Objects e a seguir Zones. Edite a zona atribuída ao seu WiFi de convidados - normalmente uma WLAN ou zona personalizada. Em Guest Services, ative tanto "Enable Guest Services" como "External Guest Authentication". Depois vá a Configure, Guest Services, General. Defina o Client Redirect Protocol para HTTP. Introduza o hostname do portal da Purple como o endereço do servidor web - que é portal.purple.ai. Defina o caminho de redirecionamento para o URL específico da splash page do seu local, que a Purple fornece no dashboard do local. A porta é 4043.No separador Auth Pages, configure o URL de início de sessão para o URL do portal externo do Purple. Configure o URL de fim de sessão se desejar gerir a terminação da sessão. No separador Advanced, ative "Allow unauthenticated users to access HTTPS sites" apenas se precisar de suportar dispositivos que priorizam HTTPS - mas tenha em atenção que isto enfraquece a imposição de redirecionamento. Uma vez guardado, o SonicOS cria automaticamente uma política de NAT e uma regra de acesso WAN-to-WAN permitindo TCP 4043. Não elimine estas regras geradas automaticamente. Elas são o que permite a conclusão do handshake LHM. Agora, a configuração do Walled Garden. Antes de um convidado se autenticar, o seu dispositivo precisa de aceder a determinados domínios para que a splash page funcione. A plataforma do Purple depende da sua própria CDN e endpoints de API. As sondas de deteção do Captive Portal do sistema operativo - captive.apple.com para dispositivos iOS, connectivitycheck.gstatic.com para Android e msftconnecttest.com para Windows - devem todas ser incluídas na whitelist. Se estiver a oferecer início de sessão social, adicione accounts.google.com, oauth2.googleapis.com, apis.google.com e gstatic.com para o Google. Adicione www.facebook.com, graph.facebook.com, connect.facebook.net e o domínio de CDN fbcdn.net se estiver a oferecer início de sessão com o Facebook. No SonicOS, adicione-os como objetos de endereço FQDN em Object, Match Objects, Addresses. Em seguida, crie regras de acesso na zona de convidados que permitam que dispositivos não autenticados acedam a estes FQDNs. Utilize a resolução de DNS dinâmico - o SonicOS resolve objetos FQDN em intervalos regulares - em vez de entradas de IP estáticas, que irão variar à medida que as gamas de IP das CDN mudam. Passando para o WiFi seguro para colaboradores com 802.1X. É aqui que os APs SonicWave e o servidor RADIUS do Purple trabalham em conjunto. O AP SonicWave atua como o autenticador na troca 802.1X. O suplicante é o dispositivo do colaborador. O servidor RADIUS do Purple é o servidor de autenticação. O método EAP que escolher depende do seu fornecedor de identidade. Se estiver a utilizar o Microsoft Entra ID ou o Okta, o PEAP-MSCHAPv2 é a escolha mais comum porque funciona com credenciais de nome de utilizador e palavra-passe. Se tiver implementado certificados de dispositivo - que é a abordagem recomendada para dispositivos geridos - utilize EAP-TLS. No Wireless Network Manager, navegue até Policies, Policy Hierarchy, selecione a sua política de AP e clique no separador 802.1X. Introduza o endereço IP do servidor RADIUS do Purple - disponível no painel de controlo do seu espaço Purple na secção de definições de RADIUS. O segredo partilhado é gerado pelo Purple e deve coincidir exatamente em ambos os lados. Configure a porta de autenticação para 1812 e a porta de accounting para 1813. Para as definições de EAP, selecione o método que corresponde à configuração do seu fornecedor de identidade. Do lado do Purple, crie uma política RADIUS para a autenticação de funcionários. Mapeie o SSID de funcionários para uma VLAN específica - por exemplo, VLAN 200 para funcionários. O servidor RADIUS do Purple devolve a atribuição de VLAN utilizando três atributos padrão: Tunnel-Type definido para VLAN, Tunnel-Medium-Type definido para 802 e Tunnel-Private-Group-ID definido para o ID da VLAN como uma string - ou seja, "200" para a VLAN 200. A firewall SonicWall e o AP SonicWave respeitam estes atributos e colocam o dispositivo autenticado do funcionário na VLAN correta de forma automática. Agora, o caso de uso mais interessante do ponto de vista arquitetónico: PPSK e isolamento multi-tenant. As Private Pre-Shared Keys permitem-lhe executar um único SSID e atribuir a cada inquilino, residente ou grupo de utilizadores uma frase de passe única. Quando um dispositivo se liga utilizando uma PPSK específica, o AP SonicWave envia essa chave para o servidor RADIUS do Purple para validação. O Purple consulta a chave, identifica o inquilino ou grupo de utilizadores associado e devolve a atribuição de VLAN apropriada através do atributo Tunnel-Private-Group-ID. O SonicWall encaminha então esse dispositivo para a VLAN correta - completamente isolado de outros inquilinos no mesmo SSID. Isto é Identity-Based Networking na prática. Não está a gerir SSIDs por inquilino. Está a gerir identidades por inquilino. Num empreendimento de uso misto com dez unidades comerciais, um único SSID transmite para todo o edifício. Cada inquilino recebe a sua própria PPSK. Cada PPSK mapeia para uma VLAN e sub-rede dedicadas. Os dispositivos do Inquilino A nunca veem o tráfego do Inquilino B, mesmo partilhando os mesmos pontos de acesso físicos. A configuração de PPSK no SonicOS requer o modo PPSK baseado em RADIUS no SSID. No Wireless Network Manager, edite o SSID, defina o modo de segurança para WPA2-Enterprise com PPSK e aponte o servidor RADIUS para o Purple. O Purple autoriza centralmente a tabela de mapeamento de PPSK para VLAN. Quando adiciona um novo inquilino, cria uma nova PPSK no Purple, atribui-lhe uma VLAN e a alteração propaga-se para todos os APs SonicWave nesse local sem tocar na configuração da firewall. - SEGMENTO 3: RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS (aproximadamente 2 minutos) Deixe-me apresentar-lhe as três coisas que mais frequentemente correm mal nas implementações de SonicWall e Purple. Primeiro: a porta LHM. A porta TCP 4043 deve estar aberta da WAN para a interface WAN do SonicWall. Se o seu ISP ou firewall a montante bloquear esta porta, o handshake de autorização LHM nunca é concluído e os convidados ficam retidos na página de portal (splash page) após a autenticação. Eles veem um início de sessão bem-sucedido do lado do Purple, mas o SonicWall nunca recebe o sinal de autorização. Teste isto com uma verificação por telnet ou curl para a porta 4043 a partir de um IP externo antes do lançamento. Segundo: o tempo de resolução do objeto FQDN. O SonicOS resolve os objetos de endereço FQDN no arranque e, depois, num intervalo configurável. Se adicionar um novo domínio ao walled garden e a resolução ainda não tiver sido atualizada, os dispositivos não autenticados não conseguirão aceder ao mesmo. Force uma atualização manual após adicionar novos objetos FQDN, ou defina o intervalo de atualização de DNS para 60 segundos em implementações de tráfego elevado. Terceiro: configuração de subinterface VLAN. A atribuição dinâmica de VLAN via RADIUS só funciona se as VLANs de destino existirem como subinterfaces no SonicWall antes de o primeiro dispositivo se autenticar. Se uma resposta RADIUS retornar Tunnel-Private-Group-ID 110 mas a VLAN 110 não existir como uma subinterface no SonicWall, o dispositivo é ignorado ou reverte para a VLAN predefinida. Aloque e teste todas as subinterfaces VLAN antes de ativar a atribuição de VLAN por RADIUS. Para os MSPs que gerem múltiplos locais, o painel na nuvem do Purple permite gerir políticas RADIUS, tabelas PPSK e configurações de splash page de forma centralizada. Pode aplicar alterações de configuração a todos os locais a partir de uma única interface. Essa é a vantagem operacional de uma abordagem de sobreposição na nuvem - o hardware SonicWall permanece no local e o Purple trata da camada de identidade e política acima dele. - SEGMENTO 4: PERGUNTAS E RESPOSTAS RÁPIDAS (aproximadamente 1 minuto) Algumas perguntas que surgem regularmente. "Posso usar APs SonicWave em modo autónomo com o Purple?" Sim, mas perde algumas funcionalidades. No modo autónomo, os APs SonicWave gerem a sua própria configuração RADIUS localmente. Ainda pode apontá-los para o servidor RADIUS do Purple para 802.1X. Mas para PPSK com atribuição dinâmica de VLAN, precisa do SonicWall TZ como proxy RADIUS ou do Wireless Network Manager a gerir a política de AP de forma centralizada. "O Purple suporta WPA3 no SonicWave?" O suporte WPA3 no SonicWave depende da versão do firmware e do modelo do AP. Os APs da série SonicWave 600 suportam WPA3. Para casos de uso de Captive Portal, o WPA3 com Opportunistic Wireless Encryption é compatível com o fluxo de redirecionamento LHM do Purple, mas teste na sua versão de firmware específica antes de implementar em larga escala. "Como é que o Purple lida com o GDPR para os dados de convidados recolhidos através da splash page?" O Purple tem certificação ISO 27001, está em conformidade com o GDPR e possui a certificação Cyber Essentials. O consentimento é recolhido na splash page com caixas de seleção de autoexclusão configuráveis. O Purple armazena dados primários de acordo com a sua política de retenção de dados. Os convidados podem aceder e eliminar os seus dados através do portal de self-service do Purple. "Que atributos RADIUS é que o Purple retorna para a atribuição dinâmica de VLAN?" Três atributos: Tunnel-Type com o valor VLAN, Tunnel-Medium-Type com o valor 802 e Tunnel-Private-Group-ID com o ID da VLAN como uma string. Estes são os atributos padrão RFC 2868 suportados pelo SonicOS e SonicWave. - SEGMENTO 5: RESUMO E PRÓXIMOS PASSOS (aproximadamente 1 minuto) Para resumir. Os firewalls SonicWall TZ e os APs SonicWave integram-se com o Purple através de dois mecanismos principais: LHM para redirecionamento de Captive Portal de convidados, e RADIUS para autenticação de funcionários 802.1X e isolamento multi-inquilino baseado em PPSK. Os principais passos de configuração são: ativar a Autenticação Externa de Convidados na zona de convidados, configurar o URL do portal Purple na porta 4043, criar os seus objetos FQDN de walled garden, configurar o RADIUS na política de AP SonicWave no Wireless Network Manager e criar as suas subinterfaces VLAN no SonicWall antes de ativar a atribuição dinâmica de VLAN. Para implementações multi-tenant, o PPSK com direcionamento de VLAN baseado em RADIUS é a arquitetura a utilizar. Um SSID, um conjunto de APs, isolamento total de inquilinos através de atribuição de VLAN baseada em identidade. Se está a planear uma implementação ou a rever uma existente, a equipa técnica da Purple pode fornecer ficheiros de configuração RADIUS específicos do local e listas de domínios para o walled garden. A plataforma Purple suporta 80 000 locais ativos e processou 440 milhões de inícios de sessão em 2024 - os padrões de integração que abordámos hoje estão comprovados à escala. Obrigado pela vossa atenção. O guia escrito completo, com tabelas de configuração passo a passo e diagramas de arquitetura Mermaid, está disponível no website da Purple. --- FIM DO GUIÃO