Cisco Meraki e guest WiFi: configuração de Captive Portal com Purple

Integração do Cisco Meraki com o Purple WiFi - Uma Apresentação para Consultores Seniores Tempo de duração: aproximadamente 10 minutos INTRODUÇÃO E CONTEXTO (aproximadamente 1 minuto) Bem-vindo. Se é responsável por uma implementação do Cisco Meraki e está a tentar decidir se o Purple WiFi é a camada certa de inteligência de passageiros/clientes para colocar por cima da mesma, 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 o cenário. O Cisco Meraki é, por uma margem significativa, a infraestrutura sem fios gerida na nuvem 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 nuvem é genuinamente excelente. Mas o problema é este - as capacidades nativas de WiFi para convidados do Meraki são funcionais, não estratégicas. Consegue colocar um convidado online, mas não consegue capturar dados primários significativos, não consegue construir um funil de marketing a partir disso e, certamente, não consegue demonstrar o ROI à sua administração. Essa é precisamente a lacuna que o Purple preenche. MERGULHO TÉCNICO PROFUNDO (aproximadamente 5 minutos) Vamos falar de arquitetura. A integração do Purple e do Meraki opera em duas camadas técnicas distintas, e compreender ambas é essencial antes de tocar numa única definição de configuração. A primeira camada é a Meraki Dashboard API - esta é a camada de aprovisionamento. O Purple utiliza a REST API do Meraki para importar todo o seu parque de pontos de acesso para o Purple Portal numa única operação em lote. Autentica-se com a sua chave de API do Meraki, que gera a partir da secção de Organização do painel de controlo do Meraki em API e Webhooks. Assim que o Purple tem essa chave, consegue obter cada ponto de acesso, cada rede, cada configuração de SSID diretamente da sua nuvem Meraki. Para um parque de, digamos, 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 de Captive Portal - é aqui que a experiência do convidado realmente reside. O Purple funciona como um fornecedor externo de splash page, utilizando a Captive Portal API do Meraki. Quando um convidado se liga ao seu SSID de convidados, o Meraki intercepta 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 tiver configurado: login social, formulário de e-mail, verificação por SMS ou uma combinação destes. O Purple comunica então de volta para o Meraki via RADIUS - Remote Authentication Dial-In User Service - operando na porta 1812 para autenticação e na porta 1813 para contabilidade. Assim que o RADIUS confirma a autenticação, o Meraki concede ao convidado acesso total à rede. Agora, deixe-me guiar-lhe através da configuração específica do painel de controlo do Meraki, porque os detalhes aqui importam. No painel da Meraki, navegue para Wireless e depois para Access Control. Selecione o seu SSID de convidados no menu pendente. Defina a segurança para Open - sim, aberta, porque a autenticação é gerida pela camada RADIUS e de captive portal, e não ao nível da 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 a walled garden - esta é a lista de domínios que os convidados podem aceder antes de se autenticarem, a qual deve incluir os domínios de plataforma da Purple para que a própria splash page possa carregar. A Purple fornece uma whitelist 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 é a 1812, e utilizará o segredo RADIUS fornecido no seu Purple Portal. Adicione as entradas correspondentes para a monitorização RADIUS na porta 1813. Defina o intervalo provisório de monitorização para quatro minutos - isto é importante para a monitorização de sessões e analytics precisos. Defina o tempo limite do servidor para cinco segundos com uma contagem de três tentativas. Em Advanced RADIUS Settings, configure o Called-Station-ID e o NAS-ID para utilizar o endereço MAC do AP. Isto é fundamental para o location analytics da Purple - sem isso, a Purple não consegue atribuir sessões de forma precisa a pontos de acesso específicos e, portanto, não consegue gerar analytics significativos ao nível do piso. Depois navegue para Wireless, Splash Page. Introduza o URL splash personalizado 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 landing page 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 que utiliza os servidores RADIUS RadSec da Purple. O RadSec é RADIUS sobre TLS, o 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 frequentes se voltem a ligar automaticamente sem verem o captive portal novamente. O seu dispositivo 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 hospedado por três noites, ou um membro de fidelidade de retalho que visita o espaço semanalmente. A configuração de Hotspot 2.0 no Meraki exige que defina o nome do operador para PURPLE 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 o método de autenticação EAP-TTLS e PAP. Tudo isto está 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 em implementações Meraki e Purple, e como evitá-los. Primeiro: configuração incorreta 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 necessários. Trate esta lista como um documento vivo e reveja-a sempre que a Purple lançar uma atualização de plataforma. Recomendo testar a experiência do Captive Portal a partir de um dispositivo convidado num segmento de rede separado antes do lançamento oficial. Segundo: definições de timeout do RADIUS. O timeout predefinido do RADIUS no Meraki está frequentemente definido para um valor demasiado baixo para servidores RADIUS alojados na nuvem. Cinco segundos com três tentativas é a configuração correta. Se deixar no valor predefinido de dois segundos, verá falhas de autenticação intermitentes durante picos de carga - precisamente a pior altura para a experiência do utilizador convidado degradar-se. Terceiro: configuração incorreta de NAS-ID e Called-Station-ID. Este é o ponto que mais vezes surpreende os engenheiros. Se configurar estes campos incorretamente - ou se os deixar como predefinidos - 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, não para o nome do SSID ou qualquer outra opção. No que respeita à conformidade: a recolha de dados da Purple é compatível com o GDPR e a CCPA por conceção. O Captive Portal apresenta um mecanismo de consentimento que cumpre os requisitos de ambas as regulamentações. Se estiver a operar num ambiente abrangido pelo PCI-DSS - por exemplo, um hotel com um terminal de pagamento no mesmo segmento de rede - certifique-se de que o seu SSID de convidado está numa VLAN separada com regras de firewall adequadas. O modo NAT do Meraki para atribuição de IP de cliente, que é a definição recomendada, oferece um nível de isolamento, mas a sua arquitetura de segmentação de rede precisa de ser revista de forma independente pela sua equipa de segurança. 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 de RADIUS que os APs sem fios. O artigo de suporte abrange as configurações de AP, MX e do gateway de teletrabalho Z1. Pergunta: Quanto tempo demora uma implementação completa para um grupo hoteleiro de 50 localizações? Resposta: Com o aprovisionamento automatizado através da Meraki API, a importação de pontos de acesso é uma operação única por organização. A configuração de SSID e RADIUS pode ser modelada em várias redes. Uma implementação em 50 locais com um engenheiro de redes competente deve ser realizável em dois a três dias de trabalho de configuração, mais o tempo de testes. Pergunta: A Purple suporta os pontos de acesso Wi-Fi 6 e Wi-Fi 6E mais recentes da Meraki? Resposta: Sim. A integração funciona na camada de aplicação - RADIUS e redirecionamento HTTP - pelo que é agnóstica em termos de geração de hardware. A Purple funciona com qualquer AP Meraki que suporte a página splash e a configuração RADIUS descrita. RESUMO E PASSOS SEGUINTES (aproximadamente 1 minuto) Em resumo: a integração do Cisco Meraki com o 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 Meraki Dashboard API para aprovisionamento automatizado, e a Captive Portal API com autenticação RADIUS para a camada de experiência do convidado. 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. A McDonald's Bélgica, a Walmart Canadá e o Harrods são todos implementações ativas da Purple e Cisco. A AGS Airports obteve um retorno do investimento de 842 por cento. O Harrods transformou 600.000 inícios de sessão WiFi num retorno do investimento de 57 vezes. Se está pronto para avançar, o próximo passo é gerar a sua chave de Meraki API, iniciar sessão no Portal Purple e utilizar o Assistente de Importação de Hardware para importar o seu parque de pontos de acesso. A partir daí, a equipa da sua conta Purple pode acompanhá-lo na configuração do SSID e do RADIUS numa única sessão. Obrigado pelo seu tempo.