Cisco Meraki e guest WiFi: configuração do captive portal com a Purple

Integração Cisco Meraki com Purple WiFi - Breve Apresentação para Consultores Seniores Tempo de leitura: aproximadamente 10 minutos INTRODUÇÃO E CONTEXTO (aproximadamente 1 minuto) Bem-vindo. Se é responsável por uma implementação Cisco Meraki e está a tentar decidir se o Purple WiFi é a camada de inteligência de convidados correta para complementar a sua infraestrutura, esta apresentação é para si. Vou explicar-lhe exatamente como funciona a integração, o que precisa de configurar, quais são as armadilhas comuns e que tipo de retorno deve realisticamente esperar. Deixe-me enquadrar a situação. A Cisco Meraki é, por uma margem significativa, a infraestrutura sem fios gerida na cloud mais amplamente implementada no espaço empresarial de hotelaria, retalho e setor público. É fiável, escalável e o seu painel de controlo na cloud é genuinamente excelente. Mas a questão é esta - as capacidades nativas de WiFi para convidados da Meraki são funcionais, não estratégicas. Pode colocar um convidado online, mas não consegue recolher dados primários (first-party data) significativos, não consegue criar um funil de marketing a partir daí e, certamente, não consegue demonstrar o ROI à sua administração. É precisamente essa a lacuna que o Purple preenche. DETALHES TÉCNICOS PROFUNDOS (aproximadamente 5 minutos) Falemos sobre arquitetura. A integração entre o Purple e a Meraki opera em duas camadas técnicas distintas, e compreender ambas é essencial antes de alterar uma única definição de configuração. A primeira camada é a API do Meraki Dashboard - esta é a camada de aprovisionamento. O Purple utiliza a API REST da Meraki para importar todo o seu parque de pontos de acesso para o Purple Hub numa única operação em lote. Autentica-se com a sua chave de API Meraki, que gera na secção Organização do painel de controlo Meraki em API e Webhooks. Assim que o Purple tiver essa chave, pode obter cada ponto de acesso, cada rede e cada configuração de SSID diretamente da sua cloud Meraki. Para um parque de, por exemplo, trezentos pontos de acesso num grupo hoteleiro, isto reduz o que seria um exercício de configuração manual de vários dias para algo que pode concluir em menos de uma hora. Isso não é uma poupança operacional insignificante. A segunda camada é a camada de autenticação e Captive Portal - é aqui que reside efetivamente a experiência do convidado. O Purple funciona como um fornecedor externo de splash page, utilizando a Captive Portal API da Meraki. Quando um convidado se liga ao seu SSID de convidados, a Meraki intercetará o seu tráfego HTTP e redireciona-o para a splash page alojada do Purple - o seu Captive Portal personalizado com a sua marca. O convidado autentica-se através do método que configurou: login social, formulário de email, verificação por SMS ou uma combinação destes. O Purple comunica de volta com a Meraki via RADIUS - Remote Authentication Dial-In User Service - operando na porta 1812 para autenticação e na porta 1813 para contabilidade (accounting). Assim que o RADIUS confirma a autenticação, a Meraki concede ao convidado acesso total à rede. Agora, permita-me guiá-lo pela configuração específica do painel de controlo Meraki, porque os detalhes aqui são importantes. No painel de controlo Meraki, navegue até Wireless e, em seguida, Access Control. Selecione o seu SSID de convidados no menu suspenso. Defina a segurança como Open - sim, aberta, porque a autenticação é gerida pela camada RADIUS e de Captive Portal, e não ao nível de associação 802.11. Defina o tipo de splash page para Sign-on with my RADIUS server. Esta é a seleção crítica - diz à Meraki para utilizar um servidor RADIUS externo para autenticação em vez das suas próprias opções integradas. Em Advanced Splash Settings, defina a força do Captive Portal para Block all access until sign-on is complete. Ative o walled garden - esta é a lista de domínios que os convidados podem aceder antes de serem autenticados, que deve incluir os domínios da plataforma da Purple para que a própria splash page possa carregar. A Purple fornece uma lista branca atualizada destes domínios na sua documentação de suporte. Para a configuração do servidor RADIUS, terá de adicionar dois servidores - a Purple fornece endpoints primários e secundários para redundância. A porta de autenticação é 1812, e utilizará o segredo RADIUS fornecido no seu Purple Portal. Adicione as entradas correspondentes para a monitorização de utilização de RADIUS (accounting) na porta 1813. Defina o intervalo provisório de accounting para quatro minutos - isto é importante para uma monitorização precisa das sessões e análise de dados. Defina o tempo limite do servidor para cinco segundos com uma contagem de repetição de três. Em Advanced RADIUS Settings, configure o Called-Station-ID e o NAS-ID para utilizar o endereço MAC do AP. Isto é fundamental para as análises de localização da Purple - sem isso, a Purple não consegue atribuir com precisão as sessões a pontos de acesso específicos e, portanto, não consegue gerar análises de dados significativas ao nível do piso. Depois navegue até Wireless, Splash Page. Introduza o URL personalizado da splash page fornecido pelo seu Purple Portal - este é o URL do seu Captive Portal de marca. Configure o URL de redirecionamento pós-autenticação - normalmente o website do seu espaço ou uma página de destino específica. Agora, existe um segundo componente que vale a pena discutir em detalhe: PurpleConnex, que é a solução SecurePass da Purple. Esta cria um segundo SSID - normalmente chamado PurpleConnex - configurado como uma rede WPA2 Enterprise utilizando os servidores RADIUS RadSec da Purple. O RadSec é RADIUS sobre TLS, que fornece transporte encriptado para o tráfego de autenticação. Este SSID, combinado com a configuração Hotspot 2.0 - também conhecida como Passpoint, a norma IEEE 802.11u - permite que os convidados habituais se voltem a ligar automaticamente sem verem o Captive Portal novamente. O dispositivo deles reconhece o perfil Passpoint e liga-se perfeitamente. Isto é particularmente valioso em ambientes onde deseja eliminar a fricção de autenticações repetidas, como um hotel onde um hóspede fica por três noites, ou um membro de fidelidade de retalho que visita semanalmente. A configuração de Hotspot 2.0 no Meraki exige que defina o nome do operador como PURPLE de dois pontos GB, configure a lista de domínios para securewifi.purple.ai e adicione os OIs do Roaming Consortium que a Purple especifica. O NAI Realm é configurado com EAP-TTLS e o método de autenticação PAP. Isto está tudo documentado no portal de suporte da Purple, e é simples assim que compreender o que cada campo faz. RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS (aproximadamente 2 minutos) Deixe-me apresentar os três modos de falha mais comuns que vejo nas implementações Meraki e Purple, e como evitá-los. Primeiro: má configuração do walled garden. Se a sua lista de walled garden estiver incompleta, os convidados verão uma página de splash quebrada - o CSS não será carregado, as imagens não serão renderizadas e a autenticação falhará silenciosamente. A Purple mantém uma lista de permissões atualizada dos domínios obrigatórios. Trate esta lista como um documento vivo e reveja-a sempre que a Purple lançar uma atualização da plataforma. Recomendo testar a experiência do Captive Portal a partir de um dispositivo de convidado num segmento de rede separado antes de entrar em funcionamento. Segundo: definições de timeout do RADIUS. O timeout padrão do RADIUS no Meraki é frequentemente definido com um valor demasiado baixo para servidores RADIUS alojados na nuvem. Cinco segundos com três tentativas é a configuração correta. Se mantiver o valor padrão de dois segundos, verá falhas de autenticação intermitentes durante os picos de carga - exatamente a pior altura para a sua experiência de convidado degradar-se. Terceiro: má configuração de NAS-ID e Called-Station-ID. Este é o ponto que mais vezes apanha os engenheiros de surpresa. Se configurar estes campos incorretamente - ou se os deixar com os valores padrão - o motor de analytics da Purple não conseguirá mapear as sessões para pontos de acesso específicos. Obterá dados agregados, mas nenhuma inteligência ao nível do piso. O valor deve ser definido para o endereço MAC do AP, e não para o nome do SSID ou qualquer outra opção. Do lado da conformidade: a recolha de dados da Purple é em conformidade com o GDPR e CCPA por conceção. O Captive Portal apresenta um mecanismo de consentimento que cumpre os requisitos de ambos os regulamentos. Se estiver a operar num ambiente sob o âmbito do PCI-DSS - por exemplo, um hotel com um terminal de pagamento no mesmo segmento de rede - certifique-se de que o seu SSID de convidados está numa VLAN separada com as regras de firewall adequadas. O modo NAT do Meraki para atribuição de IP de cliente, que é a definição recomendada, fornece um certo grau de isolamento, mas a sua arquitetura de segmentação de rede precisa de ser revista pela sua equipa de segurança de forma independente. PERGUNTAS E RESPOSTAS RÁPIDAS (aproximadamente 1 minuto) Pergunta: A Purple pode integrar-se com dispositivos de segurança Meraki MX, bem como com APs sem fios? Resposta: Sim. O processo de configuração é essencialmente idêntico - o MX suporta a mesma página de splash e configuração RADIUS que os APs sem fios. O artigo de suporte abrange as configurações de AP, MX e gateway de teletrabalhador Z1. Pergunta: Quanto tempo demora uma implementação completa para um grupo hoteleiro de 50 locais? Resposta: Com o aprovisionamento automatizado através da API Meraki, a importação do ponto de acesso é uma operação única por organização. A configuração de SSID e RADIUS pode ser aplicada como modelo em várias redes. Uma implementação em 50 locais, com um engenheiro de redes competente, deverá ser exequível em dois a três dias de trabalho de configuração, acrescidos do tempo de testes. Pergunta: A Purple suporta os pontos de acesso mais recentes Wi-Fi 6 e Wi-Fi 6E da Meraki? Resposta: Sim. A integração opera na camada de aplicação - redirecionamento RADIUS e HTTP - pelo que é agnóstica em termos de geração de hardware. A Purple funciona com qualquer AP Meraki que suporte o splash page e a configuração RADIUS descrita. RESUMO E PRÓXIMOS PASSOS (aproximadamente 1 minuto) Em resumo: a integração entre a Cisco Meraki e a Purple WiFi é uma implementação madura e bem documentada que combina a excelente infraestrutura gerida na nuvem da Meraki com as capacidades de inteligência de convidados e captura de dados da Purple. A integração utiliza dois mecanismos principais - a API do Meraki Dashboard para aprovisionamento automatizado e a API de Captive Portal com autenticação RADIUS para a camada de experiência de convidados. As três coisas a acertar são: a sua configuração de walled garden, as suas definições de timeout e repetição de RADIUS e a sua configuração de NAS-ID para análises de localização precisas. O caso de negócio é convincente. McDonald's Belgium, Walmart Canada e Harrods são todas implementações ativas da Purple e Cisco. A AGS Airports obteve um retorno do investimento de 842 por cento. A Harrods transformou 600.000 inícios de sessão de WiFi num retorno do investimento de 57 vezes. Se está pronto para avançar, o próximo passo é gerar a sua chave de API Meraki, iniciar sessão no Purple Portal e utilizar o Assistente de Importação de Hardware para importar o seu parque de pontos de acesso. A partir daí, a sua equipa de conta Purple pode acompanhá-lo na configuração do SSID e RADIUS numa única sessão. Obrigado pelo seu tempo.