Ver transcrição do podcast
Bem-vindo à Série de Briefings Técnicos da Purple. Sou o vosso anfitrião e hoje vamos abordar algo que surge em quase todas as implementações de WiFi para convidados em empresas com as quais trabalhamos: configurar um captive portal em pontos de acesso Cisco Meraki MR e, especificamente, como integrar isso com a plataforma de nuvem da Purple utilizando autenticação RADIUS. Quer seja um MSP a integrar um novo cliente de hotelaria ou um arquiteto de rede interno numa cadeia de retalho, este episódio vai dar-lhe os passos de configuração precisos e a justificação por trás de cada um.
Vamos contextualizar. Tem um espaço - que pode ser um hotel, um centro de conferências, um estádio ou um parque de retalho - a correr pontos de acesso Cisco Meraki MR geridos através do Meraki Dashboard. O objetivo é implementar uma experiência de WiFi para convidados personalizada com a marca que recolha dados em primeira mão, force a aceitação dos termos de serviço e envie análises para uma plataforma de marketing. É exatamente para isso que a Purple foi criada, e a Meraki é uma das nossas implementações de hardware mais comuns a nível global.
Agora, o ponto arquitetónico fundamental a compreender antes de tocar numa única definição é este: na Cisco Meraki, a autenticação RADIUS para uma splash page não é processada localmente pelo ponto de acesso. O RADIUS Access-Request é originado a partir da nuvem Meraki - a partir da infraestrutura do Dashboard - e não a partir do AP na sua LAN. Esta é uma distinção crítica que apanha muitos engenheiros de surpresa na sua primeira implementação Meraki. Significa que o seu servidor RADIUS, neste caso o endpoint de RADIUS na nuvem da Purple, precisa de estar acessível a partir da internet, e as suas regras de firewall precisam de permitir o tráfego proveniente das gamas de IP do Meraki Dashboard, não apenas da sua sub-rede local de APs. Encontrará as gamas de IP atuais do Dashboard em Help, depois Firewall Info no seu Meraki Dashboard.
Muito bem, vamos entrar na configuração. Vou guiar-vos por isto na ordem em que o fariam numa implementação real.
Passo um: configuração do SSID. No Meraki Dashboard, navegue até Wireless, depois Configure, e depois SSIDs. Selecione o slot de SSID que deseja utilizar para o acesso de convidados. Dê-lhe um nome claro - algo como GuestWiFi ou NomeDoEspaco_Guest. Em Association requirements, defina a Security para Open, no encryption. Isto está correto e é intencional - a camada de segurança para os convidados é gerida pelo captive portal e pela autenticação RADIUS, não pela encriptação WPA. Se estiver a implementar num ambiente PCI-DSS, vai querer garantir que o tráfego de convidados é isolado na sua própria VLAN, o que abordaremos em breve.
Passo dois: Splash page e autenticação. Ainda na página de Controlo de Acesso para o seu SSID, deslize até à secção Splash page. Defina para Iniciar sessão com e, no menu suspenso, selecione o meu servidor RADIUS. Esta é a configuração crítica que indica ao Meraki para autenticar utilizadores num servidor RADIUS externo antes de conceder acesso à rede. Abaixo, verá a opção de Força do Captive Portal. Defina para Bloquear todo o acesso até que a sessão seja iniciada. Isto é o que impõe a walled garden - sem isso, os convidados poderiam contornar o portal completamente.
Passo três: Configuração do servidor RADIUS. Na secção RADIUS, clique em Adicionar servidor. Irá precisar de três informações da sua conta Purple: o endereço IP ou FQDN do servidor RADIUS, a porta de autenticação que é UDP 1812 e o segredo partilhado. A Purple fornece estas informações na secção de configuração do local no portal. Para redundância em implementações de produção, deve adicionar um servidor RADIUS secundário - a Purple fornece um endpoint de failover. Defina a porta de accounting para UDP 1813 se pretender que os dados de sessão sejam enviados para o motor de analítica da Purple, o que recomendo vivamente para qualquer local onde o tempo de permanência e a duração da sessão sejam métricas importantes.
Uma breve nota sobre atributos RADIUS. O Meraki respeita o atributo Session-Timeout retornado na resposta RADIUS Access-Accept. A Purple utiliza isto para controlar a duração de uma sessão de convidado antes que a autenticação seja novamente necessária. Para um hotel, pode definir isto para 86.400 segundos - ou seja, 24 horas. Para uma cafetaria, algo como 3.600 segundos, uma hora, é mais apropriado. O atributo Idle-Timeout também é respeitado, mas apenas se o RADIUS accounting estiver ativado. Isto desliga as sessões inativas, o que é importante para a gestão de capacidade em locais de alta densidade.
Passo quatro: URL da splash page. Navegue até Wireless, depois Configurar e depois Splash page. Selecione o seu SSID de convidados no menu suspenso. Defina o URL de splash personalizado para o URL do portal Purple para o seu local. Este é o URL para o qual o Meraki irá redirecionar os clientes não autenticados. O Meraki anexa parâmetros de consulta a este URL - incluindo um parâmetro login_url - que a Purple utiliza para concluir o handshake de autenticação. Não modifique nem remova estes parâmetros.
Passo cinco: a walled garden. É aqui que a maioria das implementações encontra problemas. A walled garden é a lista de domínios e intervalos de IP que um dispositivo de convidado pode aceder antes de se autenticar. Sem as entradas corretas, a própria página do Captive Portal não será carregada, porque o browser será impedido de aceder ao CDN da Purple e aos fornecedores de login social.
Navegue de volta para o Controlo de Acesso (Access Control) para o seu SSID de convidados. Defina Walled garden para Walled garden is enabled. No campo Walled garden ranges, precisa de adicionar o seguinte. Primeiro, os domínios da plataforma Purple: star ponto purple ponto ai, e star ponto venuewifi ponto com. Segundo, os domínios da CDN que a Purple utiliza para disponibilizar recursos do portal: star ponto cloudfront ponto net, e star ponto akamaihd ponto net. Terceiro, a infraestrutura de redirecionamento Meraki: star ponto network-auth ponto com. Quarto, se estiver a oferecer opções de início de sessão social, precisará dos domínios de OAuth relevantes. Para a Google: accounts ponto google ponto com, star ponto googleapis ponto com, star ponto gstatic ponto com. Para o Facebook: star ponto facebook ponto com, star ponto fbcdn ponto net, e connect ponto facebook ponto net. Para o Twitter ou X: star ponto twitter ponto com e star ponto twimg ponto com.
Uma nota importante sobre como a Meraki lida com domínios wildcard no walled garden. A Meraki suporta entradas wildcard utilizando o prefixo de asterisco, por exemplo, star ponto cloudfront ponto net. No entanto, esta é uma correspondência baseada em DNS - a Meraki resolve o domínio e permite os endereços IP resultantes. Isto significa que, para fornecedores de CDN como a CloudFront ou Akamai, onde os IPs resolvidos podem mudar frequentemente, deve utilizar o wildcard do domínio em vez de gamas de IP estáticas. As entradas de IP estático são adequadas para os endpoints RADIUS da Purple, que são estáveis, mas não para o tráfego de CDN.
Agora vamos falar sobre dois cenários do mundo real em que trabalhei diretamente.
O primeiro é um hotel de 350 quartos no Reino Unido. O cliente estava a utilizar pontos de acesso Meraki MR46 em três edifícios, com cerca de 400 dispositivos de convidados concorrentes no pico. A implementação inicial utilizava uma página splash de clique único - sem RADIUS, apenas aceitação de termos. O problema era que tinham zero conhecimento sobre quem se estava a ligar, nenhuma captura de e-mail e nenhuma forma de realizar campanhas de marketing pós-estadia. Migrámo-los para a Purple com início de sessão baseado em RADIUS. A configuração foi simples, mas o detalhe foi que a sua firewall upstream estava a bloquear o tráfego UDP de saída na porta 1812 para qualquer destino fora da sub-rede local. Assim que adicionámos as gamas de IP do Meraki Dashboard à lista de permissões da firewall, a autenticação funcionou imediatamente. Após a implementação, o hotel capturou endereços de e-mail de aproximadamente 68 por cento dos convidados que se ligaram no primeiro mês, e a sua equipa de marketing realizou uma campanha de re-envolvimento que gerou um aumento mensurável nas reservas diretas.
O segundo cenário é uma cadeia de retalho com 45 lojas, cada uma a executar pontos de acesso Meraki MR33. O desafio aqui foi a escala e a consistência. Configurar manualmente 45 SSIDs com as definições RADIUS corretas e as listas de walled garden seria propício a erros e demorado. A solução foi utilizar a configuração baseada em templates da Meraki. Criámos um único template de rede com as definições corretas de SSID, RADIUS e walled garden, e depois associámos todas as 45 redes de lojas a esse template. Qualquer alteração - por exemplo, adicionar um novo fornecedor de login social ao walled garden - é feita uma vez no template e propaga-se a todas as lojas automaticamente. A análise da Purple agregou então os dados de tráfego de visitantes e tempos de permanência em todas as lojas, fornecendo à equipa de operações de retalho uma vista única no painel de controlo sobre o comportamento dos clientes por loja, por região e por hora do dia.
Permita-me partilhar três regras práticas que lhe vão poupar tempo em cada implementação de Captive Portal Meraki.
Regra um: Verifique sempre as gamas de IP do Dashboard Meraki antes de configurar o RADIUS. As gamas mudam ocasionalmente e, se a sua firewall as estiver a bloquear, a autenticação falhará silenciosamente do ponto de vista do utilizador - eles verão apenas a página do portal ficar bloqueada. Utilize a ferramenta de teste RADIUS integrada no Dashboard em Access Control para verificar a conectividade antes de entrar em produção.
Regra dois: Utilize wildcards de domínio no walled garden, e não gamas de IP, para qualquer conteúdo alojado em CDN. As gamas de IP de CDN são extensas e mudam frequentemente. Uma entrada de domínio wildcard é mais fácil de manter e mais fiável.
Regra três: Ative o RADIUS accounting na porta 1813 mesmo que ache que ainda não precisa dele. Os dados de sessão são valiosos para a resolução de problemas de desconexão e para alimentar métricas precisas de tempo de permanência na sua plataforma de análise. Não custa nada ativar e é muito difícil de implementar retroativamente.
Agora, algumas perguntas rápidas que me fazem regularmente.
Posso utilizar a splash page integrada da Meraki em vez da Purple? Sim, mas perde a recolha de dados, a análise, a automatização de marketing e a gestão de consentimento em conformidade com o GDPR. A splash integrada é adequada para um clique simples de acesso, mas não é uma plataforma de inteligência de clientes.
Esta configuração funciona nas firewalls Meraki MX tal como nos pontos de acesso MR? A configuração da splash page RADIUS é suportada nos pontos de acesso MR. Os equipamentos MX gerem a autenticação VPN de clientes de forma diferente. Para WiFi de convidados especificamente, estará a configurar os SSIDs MR.
E em relação ao WPA3? Os pontos de acesso Meraki MR suportam WPA3 em SSIDs empresariais. Para implementações de Captive Portal de convidados, o SSID é tipicamente Open, pelo que o WPA3 não se aplica diretamente. No entanto, se estiver a implementar um SSID Passpoint ou OpenRoaming juntamente com o seu SSID de Captive Portal - o que a Purple suporta - esse SSID utiliza WPA3-Enterprise com 802.1X, e é aí que o WPA3 se torna relevante.
Para resumir: a integração entre a Cisco Meraki e a Purple é amplamente testada e fiável, mas requer atenção a três aspetos: encaminhamento de IP de origem RADIUS, integridade do walled garden e configuração do limite de tempo da sessão. Garanta estes três pontos e a implementação será simples. O caso de negócio é claro - os locais que implementam uma plataforma de WiFi para convidados configurada corretamente com captura de dados obtêm consistentemente retornos mensuráveis no envolvimento de marketing e insights operacionais.
Se quiser aprofundar o assunto, consulte o guia da Purple sobre a implementação de autenticação 802.1X com RADIUS na nuvem, e o nosso guia de implementação de AP Cisco Wireless no blogue da Purple. Ambos estão acessíveis através dos links nas notas do episódio.
Obrigado por nos ouvir. Se tiver um cenário de implementação específico que gostaria que abordássemos, entre em contacto com a equipa técnica da Purple. Encontramo-nos no próximo episódio.
