Saltar para o conteúdo principal

SonicWall TZ and SonicWave Integration with Purple WiFi

Esta referência técnica detalha a integração de firewalls SonicWall TZ e APs SonicWave com a plataforma Purple WiFi. Fornece passos de configuração práticos para redirecionamento de Captive Portal, exceções de walled garden, autenticação 802.1X e direcionamento dinâmico de VLAN usando Private Pre-Shared Keys (PPSK).

📖 6 min de leitura📝 1,263 palavras🔧 2 exemplos práticos3 perguntas de prática📚 8 definições principais

Ouça este guia

Ver transcrição do podcast
INTEGRAÇÃO DO SONICWALL TZ E SONICWAVE COM A PURPLE WIFI Purple WiFi Intelligence Platform - Série de Briefing Técnico Duração: Aproximadamente 10 minutos Voz: Inglês do Reino Unido, tom de consultor sénior - confiante, conversacional, autoritário --- SEGMENTO 1: INTRODUÇÃO E CONTEXTO (aproximadamente 1 minuto) Bem-vindo à Série de Briefing Técnico da Purple. Hoje estamos a abordar uma das integrações tecnicamente mais complexas no espaço de WiFi empresarial: firewalls SonicWall TZ e pontos de acesso SonicWave, implementados em conjunto com a Purple para autenticação de convidados, controlo de acesso de funcionários e isolamento de rede 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, os passos de configuração e os pontos onde as implementações costumam falhar. A SonicWall é uma escolha forte no segmento das PME e no mercado intermédio. 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 a Purple por cima, obtém uma camada de WiFi de convidados gerida na nuvem com Captive Portals personalizados, autenticação baseada em RADIUS e captura de dados primários - tudo isto sem substituir a sua infraestrutura SonicWall existente. Vamos passar à arquitetura. --- SEGMENTO 2: MERGULHO TÉCNICO PROFUNDO (aproximadamente 5 minutos) Existem quatro casos de uso 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 para funcionários utilizando 802.1X. E isolamento multi-tenant utilizando chaves privadas pré-partilhadas da SonicWall - PPSK - 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 essa requisição HTTP e redireciona-a para o URL do Captive Portal 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 depois Zones. Edite a zona atribuída ao seu WiFi de convidados - normalmente uma WLAN ou uma zona personalizada. Em Guest Services, ative tanto "Enable Guest Services" como "External Guest Authentication." Depois aceda a Configure, Guest Services, General. Defina o Client Redirect Protocol para HTTP. Introduza o hostname do portal da Purple como endereço do servidor web - que é portal.purple.ai. Defina o caminho de redirecionamento para o URL do Captive Portal específico do seu local, que a Purple fornece no painel do local. A porta é a 4043. No separador Auth Pages, configure o URL de login para o URL do portal externo da Purple. Configure o URL de logout se pretender gerir a terminação da sessão. No separador Advanced, ative "Allow unauthenticated users to access HTTPS sites" apenas se precisar de suportar dispositivos HTTPS-first - mas tenha em atenção que isto enfraquece a aplicação do redirecionamento. Depois de guardado, o SonicOS cria automaticamente uma política NAT e uma regra de acesso WAN-to-WAN que permite TCP 4043. Não elimine estas regras geradas automaticamente. São elas que permitem 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 da Purple depende da sua própria CDN e endpoints de API. As sondas de deteção de Captive Portal do sistema operativo - captive.apple.com para dispositivos iOS, connectivitycheck.gstatic.com para Android e msftconnecttest.com para Windows - devem ser todas incluídas na whitelist. Se estiver a disponibilizar o login 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 disponibilizar o login do Facebook. No SonicOS, adicione estes como objetos de endereço FQDN em Object, Match Objects, Addresses. Em seguida, crie regras de acesso na zona de convidados que permitam que os dispositivos não autenticados acedam a estes FQDNs. Utilize a resolução DNS dinâmica - o SonicOS resolve objetos FQDN em intervalos regulares - em vez de entradas de IP estáticas, que irão sofrer desvios à medida que os intervalos de IP da CDN forem alterados. Passando para o WiFi Seguro para Funcionários com 802.1X. É aqui que os APs SonicWave e o servidor RADIUS da Purple funcionam em conjunto. O AP SonicWave atua como o autenticador na troca 802.1X. O suplicante é o dispositivo do funcionário. O servidor RADIUS da 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 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 da Purple - disponível no painel de controlo do seu espaço Purple na secção de definições de RADIUS. O segredo partilhado é gerado pela Purple e deve corresponder 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 dos 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 como VLAN, Tunnel-Medium-Type definido como 802 e Tunnel-Private-Group-ID definido como o ID da VLAN em formato string - ou seja, "200" para a VLAN 200. A firewall SonicWall e o AP SonicWave respeitam estes atributos e colocam automaticamente o dispositivo autenticado do funcionário na VLAN correta. Agora, o caso de utilização mais interessante do ponto de vista arquitetónico: PPSK e isolamento multi-tenant. As Chaves Privadas Partilhadas Previamente (PPSK) permitem executar um único SSID e atribuir a cada inquilino, residente ou grupo de utilizadores uma frase de acesso exclusiva. 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 é Redes Baseadas em Identidade 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 de retalho, um único SSID emite 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, embora partilhem 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 gere a tabela de mapeamento PPSK-para-VLAN de forma centralizada. 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 visitantes ficam presos na 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 da entrada em produção. Segundo: o tempo de resolução de objetos FQDN. O SonicOS resolve objetos de endereço FQDN no arranque e, depois, num intervalo configurável. Se adicionar um novo domínio de 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 elevado tráfego. Terceiro: Configuração de subinterfaces VLAN. A atribuição dinâmica de VLAN via RADIUS só funciona se as VLANs de destino existirem como subinterfaces na SonicWall antes da autenticação do primeiro dispositivo. Se uma resposta RADIUS retornar o Tunnel-Private-Group-ID 110 mas a VLAN 110 não existir como uma subinterface na SonicWall, o dispositivo será desconectado ou reverterá para a VLAN padrão. Crie e teste todas as subinterfaces VLAN antes de ativar a atribuição de VLAN por RADIUS. Para MSPs que gerem múltiplos locais, o painel na nuvem da Purple permite-lhe gerir políticas RADIUS, tabelas PPSK e configurações de splash pages 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 a Purple lida com a 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 a Purple?" Sim, mas perde algumas funcionalidades. No modo autónomo, os APs SonicWave gerem a sua própria configuração RADIUS localmente. Pode continuar a apontá-los para o servidor RADIUS da Purple para 802.1X. Mas para PPSK com atribuição dinâmica de VLAN, precisa da firewall SonicWall TZ como proxy RADIUS ou do Wireless Network Manager a gerir a política dos APs de forma centralizada. "A Purple suporta WPA3 em SonicWave?" O suporte para WPA3 em 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 da Purple, mas teste na sua versão de firmware específica antes de implementar em larga escala. "Como é que a Purple lida com o GDPR para dados de convidados recolhidos através da splash page?" A Purple possui certificação ISO 27001, está em conformidade com o GDPR e tem a certificação Cyber Essentials. O consentimento é capturado na splash page com caixas de seleção de auto-exclusão (opt-in) configuráveis. A 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 da Purple. "Que atributos RADIUS é que a 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) Em resumo. As firewalls SonicWall TZ e os APs SonicWave integram-se com a Purple através de dois mecanismos principais: LHM para redirecionamento do Captive Portal de convidados, e RADIUS para autenticação 802.1X de funcionários e isolamento multi-tenant 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 da Purple na porta 4043, criar os seus objetos FQDN de walled garden, configurar o RADIUS na política do AP SonicWave no Wireless Network Manager, e criar as suas subinterfaces VLAN na 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 completo de tenants 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 para o 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 cobrimos hoje estão comprovados à escala. Obrigado por ouvir. 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

header_image.png

Resumo Executivo

A integração da infraestrutura de rede SonicWall com a sobreposição de nuvem da Purple oferece controlo de acessos de nível empresarial juntamente com uma recolha sofisticada de dados primários. Este guia abrange a implementação técnica de quatro casos de utilização distintos: WiFi de convidados com redirecionamento para Captive Portal, exceções de Walled Garden, WiFi seguro para colaboradores utilizando 802.1X e isolamento Multi-Tenant utilizando Chaves Privadas Pré-Partilhadas (PPSK) da SonicWall com direcionamento dinâmico de VLAN.

Processamos 440 milhões de inícios de sessão anualmente em mais de 80.000 locais ativos. A arquitetura detalhada abaixo está comprovada à escala em ambientes de hotelaria, retalho e setor público. Permite-lhe manter o seu hardware SonicWall existente enquanto delega a gestão de identidades, o alojamento de splash pages e a autenticação RADIUS para a nuvem da Purple.

Análise Técnica Detalhada

A integração baseia-se em dois mecanismos principais: Lightweight Hotspot Messaging (LHM) para redirecionamento do Captive Portal, e RADIUS para autenticação 802.1X e PPSK.

Redirecionamento de Captive Portal via LHM

O SonicOS utiliza o LHM para gerir redirecionamentos externos de Captive Portal. Quando um dispositivo de convidado não autenticado tenta aceder à Internet, a firewall SonicWall TZ intercepta o pedido HTTP e redireciona o cliente para a splash page alojada da Purple. O convidado conclui o fluxo de autenticação (por exemplo, início de sessão social, preenchimento de formulário). A Purple envia então um pacote de autorização LHM de volta para o SonicWall na porta TCP 4043. Ao receber este pacote, o SonicWall atualiza a sua lista interna de controlo de acessos, permitindo que o endereço MAC do dispositivo aceda à Internet.

architecture_overview.png

Arquitetura de Walled Garden

Antes da autenticação, o dispositivo do convidado é mantido numa zona restrita. O Walled Garden é o conjunto específico de Nomes de Domínio Totalmente Qualificados (FQDNs) aos quais o dispositivo tem permissão de aceder para renderizar a splash page e concluir o processo de início de sessão. Isto inclui a CDN da Purple (cdn.purple.ai), a API de autenticação (api.purple.ai) e os domínios exigidos por fornecedores de identidade terceiros, como o Google Workspace, Microsoft Entra ID e Meta.

O SonicOS implementa Walled Gardens utilizando objetos de endereço FQDN. A firewall realiza a resolução de DNS dinâmico nestes objetos, atualizando automaticamente os intervalos de IP permitidos. Isto é fundamental porque os fornecedores de identidade e as CDNs utilizam alocação de IP dinâmico; as listas brancas de IP estático irão inevitavelmente falhar.

WiFi Seguro para Colaboradores e 802.1X

Para redes de colaboradores, os SonicWave APs funcionam como o autenticador 802.1X, encaminhando os pedidos de proxy para o servidor RADIUS do Purple. Recomendamos EAP-TLS para dispositivos geridos que utilizem certificados, ou PEAP-MSCHAPv2 para autenticação de utilizador/palavra-passe em diretórios como o Microsoft Entra ID. Após a autenticação bem-sucedida, o Purple devolve os atributos RADIUS padrão (Tunnel-Type, Tunnel-Medium-Type e Tunnel-Private-Group-ID) para atribuir dinamicamente o dispositivo à VLAN de colaboradores correta.

Isolamento Multi-Tenant com PPSK

As Redes Baseadas em Identidade eliminam a necessidade de implementações complexas de multi-SSID. Utilizando o SonicWall PPSK, um único SSID (ex.: "Multi-Tenant-WiFi") é transmitido em todo o local. Cada inquilino recebe uma frase de acesso única. Quando um dispositivo se associa através de um PPSK específico, o SonicWave AP valida a chave contra o servidor RADIUS do Purple. O Purple identifica o inquilino e devolve o VLAN ID associado. O SonicWall encaminha então o tráfego para a VLAN isolada do inquilino.

ppsk_vlan_diagram.png

Guia de Implementação

1. Configurar o SonicWall Captive Portal (LHM)

Para configurar o Captive Portal externo numa série SonicWall TZ com SonicOS 7.x:

  1. Navegue até Object > Match Objects > Zones. Edite a zona atribuída à sua rede de convidados (ex.: WLAN).
  2. No separador Guest Services, ative Enable Guest Services e External Guest Authentication.
  3. Navegue até Configure > Guest Services > General.
  4. Defina o Client Redirect Protocol para HTTP.
  5. Defina o endereço do Web Server para portal.purple.ai.
  6. Defina a Port para 4043.
  7. No separador Auth Pages, defina o Login URL para o URL da splash page específica fornecido no seu painel de controlo de locais do Purple.
  8. Guarde a configuração. O SonicOS irá gerar automaticamente uma política NAT e uma regra de acesso WAN-to-WAN para permitir a porta TCP 4043. Não modifique estas regras geradas automaticamente.

2. Construir o Walled Garden

Crie objetos de endereço FQDN para os domínios necessários e adicione-os a um grupo de endereços. Aplique este grupo a uma regra de permissão na sua zona de convidados.

Domínios do Purple Obrigatórios:

  • *.purple.ai
  • *.purpleportal.net

Sondas de Captive Portal de SO:

  • captive.apple.com (iOS/macOS)
  • connectivitycheck.gstatic.com (Android)
  • msftconnecttest.com (Windows)

Domínios Comuns de Autenticação Social (Google):

  • accounts.google.com
  • oauth2.googleapis.com
  • apis.google.com
  • *.gstatic.com

3. Configurar RADIUS para SonicWave APs

Para integrar os SonicWave APs com o RADIUS do Purple através do Wireless Network Manager:

  1. Navegue até Policies > Policy Hierarchy e selecione a sua Política de AP.
  2. Selecione o separador 802.1X.
  3. Introduza o endereço IP do servidor RADIUS do Purple (disponível no seu painel de controlo do Purple).
  4. Introduza o segredo partilhado gerado pelo Purple.
  5. Defina a Authentication Port para 1812 e a Accounting Port para 1813.6. Selecione o método EAP apropriado com base no seu fornecedor de identidade.

4. Configurar o Encaminhamento Dinâmico de VLAN (Dynamic VLAN Steering)

Certifique-se de que as VLANs de destino existem como subinterfaces na firewall SonicWall TZ antes de ativar a atribuição dinâmica.

No painel da Purple, mapeie o grupo de utilizadores ou PPSK para o ID da VLAN de destino. A Purple devolverá os seguintes atributos após uma autenticação bem-sucedida:

  • Tunnel-Type = VLAN (13)
  • Tunnel-Medium-Type = 802 (6)
  • Tunnel-Private-Group-ID = [VLAN ID] (ex: "110")

Melhores Práticas

  • Testar a Visibilidade da Porta LHM: A porta TCP 4043 deve estar acessível a partir da Internet para a interface WAN da SonicWall. Teste isto utilizando um scanner de portas externo antes do lançamento. Se o ISP bloquear esta porta, o pacote de autorização falhará e os convidados ficarão retidos no Captive Portal.
  • Pré-Provisionar Subinterfaces VLAN: O encaminhamento dinâmico de VLAN falhará silenciosamente se a subinterface VLAN de destino não estiver configurada no SonicWall antes do evento de autenticação. O dispositivo reverterá para a VLAN predefinida sem etiqueta (untagged).
  • Forçar OAuth Baseado na Web: Certifique-se de que a configuração do seu Captive Portal força fluxos OAuth baseados na Web. A ligação direta (deep-linking) para aplicações de redes sociais nativas (como a aplicação Facebook para iOS) quebra frequentemente a sequência do Captive Portal porque o tráfego da aplicação nativa é bloqueado pelo jardim vedado (walled garden).
  • Otimizar Intervalos de Atualização de DNS: O SonicOS resolve objetos FQDN periodicamente. Em ambientes de elevada rotatividade, como estádios ou interfaces de transporte, defina o intervalo de atualização de DNS para objetos do jardim vedado (walled garden) para 60 segundos para garantir que as alterações de IP de CDN são monitorizadas com precisão.

Resolução de Problemas e Mitigação de Riscos

Sintoma: O convidado conclui o início de sessão no Captive Portal mas não tem acesso à Internet. Causa: O pacote de autorização LHM na porta TCP 4043 não está a chegar ao SonicWall. Resolução: Verifique se a regra de acesso WAN-para-WAN gerada automaticamente existe. Verifique os routers do ISP a montante para identificar bloqueios de portas. Certifique-se de que o IP WAN do SonicWall está corretamente registado no painel da Purple.

Sintoma: O Captive Portal falha ao carregar ou os botões de início de sessão social devolvem erros de CORS. Causa: Configuração incompleta do jardim vedado (walled garden). Resolução: Ligue um dispositivo de teste num estado não autenticado. Utilize as ferramentas de programador do navegador (separador Rede) para identificar pedidos HTTPS bloqueados. Adicione os domínios em falha como objetos de endereço FQDN no SonicOS.

Sintoma: Os dispositivos dos colaboradores autenticam-se via 802.1X, mas recebem um endereço IP da VLAN predefinida em vez da VLAN atribuída. Causa: A subinterface VLAN de destino não existe no SonicWall ou os atributos RADIUS estão malformados. Resolução: Verifique se a subinterface VLAN está ativa. Verifique os registos RADIUS da Purple para confirmar se o Tunnel-Private-Group-ID está a ser enviado como um valor de string correspondente ao ID da VLAN.

ROI e Impacto no Negócio

A implementação da infraestrutura SonicWall com a Purple transforma um centro de custos de rede padrão num ativo de negócio mensurável.

Para uma cadeia de retalho com 200 localizações, a transição de chaves pré-partilhadas genéricas para um Captive Portal com a marca do cliente resulta tipicamente num aumento de 40% nos perfis de clientes conhecidos num prazo de seis meses. Estes dados de primeira parte (first-party data) integram-se diretamente nos sistemas CRM, impulsionando campanhas de marketing direcionadas e aumentando as visitas recorrentes.

Em ambientes multi-tenant, como espaços de coworking ou alojamentos estudantis, o PPSK com direcionamento dinâmico de VLAN elimina a sobrecarga operacional de gerir hardware dedicado por inquilino. Implementa apenas uma rede física e segmenta-a logicamente através de identidade. Isto reduz as despesas de capital em hardware (CapEx) em até 60%, mantendo um isolamento de rede rigoroso em conformidade com a norma ISO 27001.

Definições Principais

Lightweight Hotspot Messaging (LHM)

Um protocolo utilizado pela SonicWall para comunicar com Captive Portals externos. Trata do redirecionamento e do processo de autorização.

Necessário para integrar o SonicOS com plataformas de WiFi de convidados geridas na nuvem, como a Purple.

Walled Garden

Um conjunto específico de domínios ou endereços IP que os dispositivos não autenticados têm permissão para aceder.

Crucial para permitir que os dispositivos dos convidados carreguem a splash page, acedam a CDNs e concluam os fluxos de OAuth de login social antes de obterem acesso total à internet.

Private Pre-Shared Key (PPSK)

Um método de segurança no qual várias palavras-passe exclusivas são válidas num único SSID, estando cada palavra-passe associada a um utilizador ou política específica.

Utilizado em ambientes multi-tenant para isolar o tráfego sem transmitir múltiplos SSIDs.

Captive Network Assistant (CNA)

O mecanismo integrado do SO (em iOS, Android, Windows) que deteta um Captive Portal e abre automaticamente uma janela de navegador limitada para autenticação.

Se os domínios de validação do SO (por exemplo, captive.apple.com) não estiverem no walled garden, o CNA não será ativado e os convidados pensarão que o WiFi não está a funcionar.

Dynamic VLAN Steering

O processo de atribuição de um dispositivo a uma VLAN específica com base na sua identidade ou credenciais, em vez do SSID ao qual se ligou.

Gerido pelo RADIUS da Purple, que devolve o atributo Tunnel-Private-Group-ID à SonicWall.

FQDN Address Object

Um objeto de firewall baseado num Fully Qualified Domain Name (Nome de Domínio Totalmente Qualificado) em vez de num endereço IP estático.

O SonicOS resolve estes objetos de forma dinâmica, tornando-os essenciais para configurações robustas de walled garden.

Identity-Based Network

Uma arquitetura de rede onde as políticas de acesso e a segmentação são aplicadas com base no utilizador ou dispositivo autenticado, em vez de portas físicas ou SSIDs.

Alcançado através da combinação do RADIUS da Purple com PPSK e 802.1X da SonicWall.

Tunnel-Private-Group-ID

O atributo RADIUS padrão da norma RFC 2868 utilizado para especificar o ID da VLAN para um dispositivo em ligação.

Deve ser devolvido pela Purple como um valor de string (por exemplo, '100') para instruir a SonicWall a direcionar o dispositivo.

Exemplos Práticos

Um hotel de 150 quartos (Premier Inn) necessita de disponibilizar WiFi para convidados gratuito através de uma splash page e uma rede Staff WiFi segura para dispositivos de limpeza (housekeeping). Possuem um SonicWall TZ570 e 40 APs SonicWave. Como devem segmentar este tráfego?

Implemente dois SSIDs. SSID 1: "Guest-WiFi" mapeado para a VLAN 100. Configure a zona WLAN do SonicWall para Autenticação Externa de Convidados a apontar para portal.purple.ai em TCP 4043. Configure os FQDNs de walled garden para a Purple e logins sociais. SSID 2: "Staff-WiFi" mapeado para a VLAN 200 usando 802.1X. Aponte a política de AP SonicWave para o servidor RADIUS da Purple. Configure a Purple para autenticar os dispositivos de limpeza via bypass de endereço MAC (MAB) ou PEAP-MSCHAPv2, retornando Tunnel-Private-Group-ID "200".

Comentário do Examinador: Esta abordagem isola rigorosamente o tráfego não confiável de convidados dos sistemas operacionais. Usar a Purple tanto para o Captive Portal como para a autenticação RADIUS centraliza a gestão de identidades. O MAB é apropriado para dispositivos headless (como carrinhos de limpeza), enquanto o 802.1X protege os telemóveis do pessoal.

Um espaço de coworking gere 15 empresas diferentes que partilham um escritório em plano aberto. Querem fornecer redes seguras e isoladas para cada empresa sem transmitir 15 SSIDs diferentes a partir dos seus APs SonicWave.

Implemente um único SSID chamado "Workspace-Secure" usando WPA2-Enterprise com PPSK. Crie 15 subinterfaces VLAN no firewall SonicWall TZ (ex. VLANs 101-115). No painel da Purple, gere um PPSK exclusivo para cada empresa e mapeie-o para o respetivo ID de VLAN. Quando um utilizador se liga utilizando o PPSK da sua empresa, o RADIUS da Purple retorna o Tunnel-Private-Group-ID correspondente, e o SonicWall direciona o dispositivo para a VLAN isolada.

Comentário do Examinador: Este design de rede baseada em identidade escala de forma limpa. A transmissão de 15 SSIDs causaria uma sobrecarga severa de tráfego de gestão e degradaria o desempenho do WiFi. O PPSK oferece a segurança de credenciais exclusivas e o isolamento de VLANs dedicadas sem o impacto de RF de múltiplos SSIDs.

Perguntas de Prática

Q1. Configurou a zona de convidados do SonicWall para Autenticação Externa de Convidados e definiu o servidor web para portal.purple.ai. Os convidados são redirecionados para a splash page e conseguem iniciar sessão com sucesso, mas nunca obtêm acesso à internet. Qual é a causa mais provável?

Dica: Pense em como a Purple informa o SonicWall de que a autenticação foi bem-sucedida.

Ver resposta modelo

O pacote de autorização LHM está a ser bloqueado. A porta TCP 4043 deve estar aberta na interface WAN do SonicWall para receber o sinal de sucesso da Purple. Verifique as firewalls a montante ou as configurações do ISP quanto ao bloqueio de portas.

Q2. Um espaço pretende disponibilizar o início de sessão do Facebook na sua splash page. Adiciona o endereço www.facebook.com ao grupo de endereços FQDN do walled garden. Os convidados relatam que a página de início de sessão do Facebook carrega, mas a formatação está incorreta e o botão de login não funciona.

Dica: As aplicações web modernas carregam recursos de múltiplos domínios.

Ver resposta modelo

O walled garden está incompleto. Deve também incluir na lista de permissões os domínios que fornecem o CSS, JavaScript e as chamadas de API do Facebook, especificamente graph.facebook.com, connect.facebook.net e o domínio CDN (por exemplo, *.fbcdn.net).

Q3. Está a implementar PPSK para um escritório partilhado com várias empresas. Configura o SSID para WPA2-Enterprise com PPSK e aponta o servidor RADIUS para a Purple. Cria uma PPSK na Purple associada à VLAN 50. Quando um utilizador se liga com essa PPSK, recebe um endereço IP da VLAN 10. Porquê?

Dica: O SonicWall precisa de saber para onde enviar o tráfego antes de o pedido RADIUS ser concluído.

Ver resposta modelo

A VLAN 50 não foi criada como uma subinterface na firewall SonicWall TZ. O encaminhamento dinâmico de VLAN requer que a VLAN de destino já exista previamente na firewall; caso contrário, o dispositivo reverte para a VLAN predefinida sem etiqueta (neste caso, a VLAN 10).