Aruba Central e Purple WiFi: Integração Gerida na Nuvem

Aruba Central e Purple WiFi: Integração Gerida na Nuvem. Um briefing para líderes de TI. Bem-vindos. Se gerem WiFi de convidados em múltiplos locais e utilizam o Aruba Central, este episódio é diretamente relevante para vocês. Vou explicar-vos exatamente como a Purple se integra com o Aruba Central — a arquitetura, os passos de configuração, os padrões de implementação multi-site e as armadilhas que costumam apanhar as equipas de surpresa. Este é um briefing prático, não uma apresentação de vendas. Vamos a isso. Secção um: Contexto e por que razão isto é importante. O Aruba Central é a plataforma de gestão de rede na nuvem da HPE. É o plano de controlo para dezenas de milhares de Aruba Instant Access Points implementados em hotéis, cadeias de retalho, estádios, centros de conferências e edifícios do setor público. Se migraram de controladores Aruba locais — os Mobility Controllers ou Mobility Conductors — para o Central, já experimentaram a transição de uma configuração pesada em CLI e específica de cada site para uma gestão de políticas baseada em grupos e enviada a partir da nuvem. Essa mudança altera fundamentalmente a forma como integram uma plataforma de WiFi de convidados como a Purple. Num controlador Aruba local tradicional, configurariam o redirecionamento do portal cativo e a autenticação RADIUS diretamente no próprio controlador. O controlador era o ponto de aplicação de políticas e residia no vosso centro de dados ou sala de comunicações. Com o Aruba Central, a aplicação de políticas ainda acontece no Access Point — mas a configuração é enviada a partir da nuvem. Isso significa que os vossos pontos de contacto de integração são diferentes. Estão a trabalhar com templates de grupo, perfis de SSID e objetos de perfil de portal cativo externo que vivem na hierarquia de configuração do Central, e não numa caixa num bastidor. A Purple posiciona-se acima de tudo isto como uma plataforma de inteligência de WiFi de convidados alojada na nuvem. Fornece o portal cativo — a página de splash que os convidados veem —, lida com a lógica de autenticação, recolhe dados primários com consentimento e envia análises de volta para as vossas equipas de marketing e operações. A questão é: como interligar estas duas plataformas de nuvem de forma limpa, à escala, em potencialmente centenas de sites? Secção dois: A arquitetura técnica. Deixem-me descrever o fluxo de dados quando um convidado se liga. O dispositivo de um convidado associa-se ao vosso SSID de convidados — vamos chamar-lhe Hotel-Guest — que é transmitido por um AP Aruba Instant. O AP foi configurado, através do Aruba Central, com um perfil de Captive Portal externo. Esse perfil contém duas informações críticas: o URL de redirecionamento, que aponta para o servidor de portal cativo da Purple, e os detalhes do servidor RADIUS, que apontam para o endpoint RADIUS-as-a-Service da Purple. Quando o convidado abre um navegador, o AP intercepta o pedido HTTP e redireciona-o para a página de splash da Purple. O convidado autentica-se — via login social, e-mail, SMS ou um formulário personalizado, dependendo da vossa configuração da Purple. O backend da Purple envia então uma mensagem RADIUS Access-Accept de volta para o AP, que concede ao convidado acesso à internet e o move da função de pré-autenticação para a função de convidado autenticado. Os pacotes de contabilização RADIUS fluem ao longo da sessão, dando à Purple visibilidade sobre a duração da sessão e a utilização de dados. Agora, a principal diferença em relação ao modelo local: no Aruba Central, configuram o perfil de Captive Portal externo uma vez, ao nível do grupo, e este propaga-se para todos os APs nesse grupo. Não tocam em APs individuais. Isto é incrivelmente poderoso para implementações multi-site, mas exige que definam a estrutura de grupos corretamente antes de começar. O Aruba Central organiza os dispositivos em Grupos e, dentro dos grupos, podem ter Sites. Um Grupo é a unidade de configuração — SSIDs, perfis de rádio, políticas de segurança vivem todos ao nível do grupo. Os Sites são a unidade de localização e monitorização. Para uma cadeia de hotéis, uma estrutura sensata é um grupo por tipo de propriedade — por exemplo, Hotéis de Serviço Completo e Propriedades Económicas — com cada hotel físico como um site separado dentro do grupo apropriado. A configuração da Purple mapeia-se então para os grupos: um perfil de Captive Portal externo por grupo, apontando para o mesmo endpoint RADIUS da Purple, mas potencialmente com diferentes temas de página de splash por site utilizando a personalização ao nível do local da Purple. O walled garden é um elemento de configuração crítico que as equipas frequentemente erram. Antes de um convidado se autenticar, o AP apenas permite tráfego de DNS e DHCP, além de quaisquer domínios que coloquem explicitamente na lista de permissões. Para que a Purple funcione, devem incluir na lista de permissões o domínio do portal cativo da Purple, quaisquer domínios de CDN que a Purple utilize para recursos e quaisquer domínios de fornecedores de login social se estiverem a utilizar autenticação social — Facebook, Google, Apple. Se faltar um domínio, a página de splash carregará parcialmente ou a autenticação falhará silenciosamente. A documentação de suporte da Purple fornece a lista atual do walled garden, e vale a pena tratar essa lista como um documento vivo que reveem sempre que a Purple atualiza a sua plataforma. Secção três: A superfície da API do Aruba Central para automação. Se estão a fazer a implementação em mais de vinte sites, a configuração manual através da UI do Central torna-se um obstáculo. O Aruba Central expõe uma API REST abrangente — a API do Central — que permite automatizar a criação de SSIDs, a atribuição de perfis de portal cativo e a configuração do walled garden. A API é autenticada via OAuth 2.0 e precisarão de gerar credenciais de API a partir do portal do Central. Os principais endpoints de API para uma integração com a Purple são: o endpoint de configuração de WLAN, que permite criar e atualizar perfis de SSID; o endpoint de perfil de portal cativo externo, que é onde definem o URL de redirecionamento da Purple e os detalhes do servidor RADIUS; e os endpoints de gestão de sites e grupos, que permitem atribuir dispositivos a sites e grupos de forma programática. Se estiverem a integrar um novo local, podem escrever um script que cria o site no Central, atribui os APs ao site, aplica o template de grupo correto e configura o perfil de portal cativo específico da Purple — tudo sem tocar na UI. A Purple também expõe a sua própria API, que permite criar registos de locais, configurar temas de páginas de splash e extrair dados analíticos. Uma integração madura utilizará ambas as APIs em conjunto: a API do Central para gerir a camada de rede e a API da Purple para gerir a camada de experiência do convidado. Este é o padrão que as grandes cadeias de retalho e grupos hoteleiros utilizam quando integram dezenas de novos sites por trimestre. Secção quatro: Configuração passo a passo. Deixem-me guiar-vos pela sequência de configuração para um único site, que depois automatizariam para escala. Primeiro, no Aruba Central, naveguem até ao vosso grupo-alvo e abram a configuração de WLAN. Criem um novo SSID — por exemplo, Venue-Guest — e definam o nível de segurança para Visitors. Esta é a terminologia da Aruba para uma rede aberta ou autenticada por portal cativo. Segundo, no separador Security, definam o tipo de Splash Page para External Captive Portal. Criem um novo perfil de Captive Portal externo. Atribuam-lhe um nome descritivo — Purple-Guest-Portal funciona bem. Definam o Tipo de Autenticação para RADIUS Authentication. Introduzam o hostname do servidor de portal cativo da Purple no campo IP ou Hostname. Introduzam o URL de redirecionamento. Ativem o HTTPS. Definam o comportamento de Captive Portal Failure para Deny Internet, que é o padrão mais seguro. Terceiro, configurem o servidor RADIUS. No Central, acedam às definições do servidor de autenticação e adicionem o servidor RADIUS-as-a-Service da Purple. Precisarão do IP ou hostname do servidor, do segredo partilhado — que geram na plataforma da Purple — e da porta de autenticação, que é a padrão 1812, com contabilização na 1813. Adicionem este servidor como o Servidor Primário para o vosso SSID de convidados. Quarto, configurem o walled garden. Nas regras de acesso do SSID, adicionem o domínio do portal cativo da Purple e quaisquer domínios de login social à lista de permissões. Testem isto cuidadosamente — um domínio em falta é a causa mais comum de falhas na página de splash. Quinto, guardem e enviem a configuração. O Central enviará a configuração para todos os APs no grupo. Verifiquem num dispositivo de teste se o redirecionamento funciona corretamente e se a autenticação é concluída. Secção cinco: Padrões de implementação multi-site. Para uma implementação em cinquenta ou mais sites, precisam de uma abordagem disciplinada. O padrão que recomendo é: piloto, template, automação, validação. Façam um piloto num único site. Obtenham a configuração exatamente correta — walled garden completo, RADIUS a funcionar, página de splash a carregar de forma limpa, contabilização a fluir. Documentem o valor de cada parâmetro. Em seguida, construam essa configuração num template de grupo do Central. O template torna-se a vossa fonte de verdade. Para a implementação, utilizem a API do Central para enviar o template para novos grupos à medida que integram os sites. Se a vossa implementação da Purple utilizar diferentes temas de página de splash por marca ou região, parametrizem o perfil de portal cativo — o URL de redirecionamento pode incluir parâmetros de consulta que a Purple utiliza para servir o tema correto. Isto significa que podem ter um único endpoint RADIUS mas múltiplas experiências de página de splash, tudo gerido centralmente. Validem cada site após a integração. Um script de validação simples que associe um dispositivo de teste, verifique o redirecionamento, autentique e confirme o acesso à internet detetará desvios de configuração antes que os convidados os experimentem. O painel de análise da Purple também mostrará se as sessões estão a ser registadas — se um site ficar sem atividade nos relatórios da Purple, esse é o vosso sinal de que algo está partido na camada de rede. Secção seis: Armadilhas de implementação. O walled garden é o ponto de falha número um. Testem com um dispositivo que não tenha sessões de portal ou DNS em cache. Utilizem um perfil de navegador limpo ou o modo de navegação anónima. A segunda armadilha é a incompatibilidade do segredo partilhado do RADIUS. O segredo que configuram no Central deve corresponder exatamente ao segredo na plataforma da Purple. Uma diferença de um único caráter causará falhas de autenticação silenciosas — o AP não receberá resposta do servidor RADIUS e rejeitará o convidado ou, se tiverem definido o modo de falha do portal cativo para Allow Internet, concederá acesso sem autenticação, o que representa um risco de conformidade. A terceira armadilha é a configuração incorreta de VLAN. O tráfego de convidados deve estar numa VLAN dedicada, isolada da vossa rede corporativa. No Aruba Central, isto é configurado nas definições de VLAN do perfil de SSID. Se a vossa VLAN de convidados não estiver corretamente configurada em trunk na porta do switch de uplink, os APs iniciarão mas os convidados não obterão endereços DHCP. A quarta armadilha é a confiança no certificado no redirecionamento do portal cativo. Os navegadores e sistemas operativos modernos são cada vez mais agressivos em relação à aplicação de HTTPS. O servidor de portal cativo da Purple utiliza um certificado TLS válido, mas se o vosso walled garden bloquear os endpoints OCSP ou CRL que o cliente utiliza para validar o certificado, verão erros de certificado na página de splash. Adicionem esses endpoints ao vosso walled garden. Secção sete: Perguntas rápidas. A Purple funciona com a arquitetura AOS-10 do Aruba Central, bem como com a AOS-8? Sim. O mecanismo de portal cativo externo é consistente em ambas as versões de firmware. O caminho na UI difere ligeiramente, mas os objetos de configuração subjacentes são os mesmos. Posso utilizar o RADIUS-as-a-Service da Purple sem gerir a minha própria infraestrutura RADIUS? Sim, esse é o objetivo. O RADIUS-as-a-Service da Purple é um servidor RADIUS alojado na nuvem para o qual apontam os vossos APs Aruba. Não precisam de FreeRADIUS ou Cisco ISE localmente. Esta integração suporta WPA3? O Aruba Central suporta WPA3 em APs compatíveis e podem ativar o modo de transição WPA3 no vosso SSID de convidados. O mecanismo de portal cativo da Purple é agnóstico em relação à camada de encriptação — opera ao nível do redirecionamento HTTP, não ao nível da associação 802.11. Os dados que a Purple recolhe estão em conformidade com o GDPR? A Purple foi concebida tendo a conformidade com o GDPR como um requisito central. A página de splash apresenta um mecanismo de consentimento e o processamento de dados da Purple é regido pelo vosso acordo de processamento de dados com eles. Para locais na UE, garantam que a vossa configuração da Purple inclui o texto de consentimento apropriado e que o vosso DPA está em vigor antes do lançamento. Secção oito: Resumo e próximos passos. Para resumir: o Aruba Central e a Purple integram-se através do mecanismo de Captive Portal externo, com a autenticação RADIUS gerida pelo serviço RADIUS na nuvem da Purple. A configuração vive ao nível do grupo no Central e propaga-se para todos os APs no grupo — que é a principal diferença arquitetural em relação ao modelo Aruba local. Para implementações multi-site, utilizem a API do Central para automatizar o aprovisionamento e tratem a configuração do vosso site piloto como o template para tudo o que se segue. Os vossos próximos passos imediatos: primeiro, confirmem que a vossa estrutura de grupos do Aruba Central mapeia para a vossa hierarquia de locais da Purple. Segundo, obtenham a lista atual de domínios do walled garden da Purple e os detalhes do endpoint RADIUS no portal de suporte da Purple. Terceiro, realizem um piloto num único site e validem o fluxo completo de autenticação antes de escalar. Quarto, construam os vossos scripts de automação utilizando a API do Central e a API da Purple em paralelo. Se estão a avaliar a Purple pela primeira vez, as páginas de WiFi de convidados e de plataforma de análise em purple ponto ai dão-vos uma imagem clara do que obtêm além do portal cativo — a recolha de dados primários, a automação de marketing, a análise de tráfego de visitantes. Esse é o caso de negócio que garante o financiamento deste projeto. Obrigado por ouvirem. Se tiverem dúvidas sobre esta integração, a equipa de soluções da Purple pode guiar-vos através de uma prova de conceito adaptada ao vosso ambiente específico do Aruba Central.