Captive Portal para Cisco Meraki

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 de convidados empresariais em que trabalhamos: configurar um Captive Portal em pontos de acesso Cisco Meraki MR e, especificamente, como integrar isso com a plataforma na 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 dar-lhe-á os passos de configuração precisos e a lógica por trás de cada um deles. Vamos contextualizar. Tem um espaço — pode ser um hotel, um centro de conferências, um estádio ou um parque de retalho — equipado com pontos de acesso Cisco Meraki MR geridos através do Meraki Dashboard. O objetivo é implementar uma experiência de WiFi de convidados personalizada que recolha dados primários (first-party data), imponha 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 alterar qualquer 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 provém da nuvem da Meraki — da infraestrutura do Dashboard — e não do AP na sua LAN. Esta é uma distinção crítica que surpreende muitos engenheiros 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 dos intervalos de IP do Meraki Dashboard, e não apenas da sub-rede do seu AP local. Encontrará os intervalos de IP atuais do Dashboard em Help e, depois, em Firewall Info no seu Meraki Dashboard. Muito bem, vamos entrar na configuração. Vou guiar-vos por este processo na ordem em que o faria numa implementação real. Passo um: configuração do SSID. No Meraki Dashboard, navegue até Wireless, depois Configure e, em seguida, SSIDs. Selecione o slot de SSID que pretende utilizar para o acesso de convidados. Dê-lhe um nome claro — algo como GuestWiFi ou NomeDoEspaço_Guest. Nas condições de associação (Association requirements), defina a Segurança (Security) para Aberta (Open), sem encriptação. Isto está correto e é intencional — a camada de segurança para os convidados é gerida pelo Captive Portal e pela autenticação RADIUS, e não pela encriptação WPA. Se estiver a implementar num ambiente PCI DSS, vai querer garantir que o tráfego de convidados está 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 (Access Control) do seu SSID, desça até à secção Splash page. Defina-a para 'Sign-on with' e, no menu suspenso, selecione 'my RADIUS server'. Esta é a definição crítica que indica à Meraki para autenticar os utilizadores num servidor RADIUS externo antes de conceder acesso à rede. Abaixo disso, verá a opção de força do Captive Portal (Captive portal strength). Defina-a para 'Block all access until sign-on is complete'. Isto é o que impõe o walled garden — sem isso, os convidados poderiam contornar o portal por completo. Passo três: configuração do servidor RADIUS. Na secção RADIUS, clique em Add server. 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 de espaços do 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 análise da Purple, o que recomendo vivamente para qualquer espaço onde o tempo de permanência e a duração da sessão sejam métricas significativas. Uma nota rápida sobre os atributos RADIUS. A 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 seja necessária uma nova autenticação. Para um hotel, pode definir isto para 86.400 segundos — ou seja, 24 horas. Para um café, algo como 3.600 segundos (uma hora) é mais apropriado. O atributo Idle-Timeout também é respeitado, mas apenas se o accounting de RADIUS estiver ativado. Isto desliga as sessões inativas, o que é importante para a gestão de capacidade em espaços de alta densidade. Passo quatro: URL da splash page. Navegue até Wireless, depois Configure e, em seguida, Splash page. Selecione o seu SSID de convidados no menu suspenso. Defina o URL de splash personalizado (Custom splash URL) para o URL do portal da Purple para o seu espaço. Este é o URL para o qual a Meraki irá redirecionar os clientes não autenticados. A 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: o walled garden. É aqui que a maioria das implementações encontra problemas. O 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 irá carregar, porque o navegador será bloqueado de aceder à CDN da Purple e aos fornecedores de início de sessão social. Navegue de volta para Access Control para o seu SSID de convidados. Defina o Walled garden para 'Walled garden is enabled'. No campo de intervalos do Walled garden, 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 de CDN que a Purple utiliza para disponibilizar os recursos do portal: star ponto cloudfront ponto net e star ponto akamaihd ponto net. Terceiro, a infraestrutura de redirecionamento da Meraki: star ponto network-auth ponto com. Quarto, se estiver a oferecer opções de início de sessão social, precisa dos domínios 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 gere 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 a Akamai, onde os IPs resolvidos podem mudar frequentemente, deve utilizar o wildcard de domínio em vez de intervalos de IP estáticos. As entradas de IP estático são adequadas para os endpoints de 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 tinha pontos de acesso Meraki MR46 em três edifícios, com cerca de 400 dispositivos de convidados simultâneos no pico. A implementação inicial utilizava uma splash page de clique simples — sem RADIUS, apenas aceitação de termos. O problema era que tinham zero visibilidade sobre quem se estava a ligar, nenhuma recolha de e-mails 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 obstáculo foi que a firewall a montante 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 os intervalos de IP do Meraki Dashboard à lista de permissões da firewall, a autenticação funcionou imediatamente. Após a implementação, o hotel recolheu endereços de e-mail de aproximadamente 68% dos convidados que se ligaram no primeiro mês, e a sua equipa de marketing realizou uma campanha de reativação que gerou um aumento mensurável nas reservas diretas. O segundo cenário é uma cadeia de retalho com 45 lojas, cada uma equipada com pontos de acesso Meraki MR33. O desafio aqui era a escala e a consistência. Configurar manualmente 45 SSIDs com as definições de RADIUS e listas de walled garden corretas seria propício a erros e demorado. A solução foi utilizar a configuração baseada em modelos da Meraki. Criámos um único modelo de rede com as definições corretas de SSID, RADIUS e walled garden e, em seguida, vinculámos todas as 45 redes de lojas a esse modelo. Qualquer alteração — por exemplo, adicionar um novo fornecedor de início de sessão social ao walled garden — é feita uma vez no modelo e propaga-se automaticamente para todas as lojas. As análises da Purple agregaram depois os dados de afluência e tempo de permanência de todas as lojas, oferecendo à equipa de operações de retalho uma visão única em dashboard do comportamento dos convidados por loja, por região e por hora do dia. Permita-me partilhar três regras práticas que lhe pouparão tempo em todas as implementações de Captive Portal Meraki. Regra um: Verifique sempre os intervalos de IP do Meraki Dashboard antes de configurar o RADIUS. Os intervalos mudam ocasionalmente e, se a sua firewall os estiver a bloquear, a autenticação falhará silenciosamente do ponto de vista do utilizador — este verá apenas a página do portal ficar bloqueada. Utilize a ferramenta de teste de RADIUS integrada no Dashboard, em Access Control, para verificar a conectividade antes de avançar para o ambiente de produção. Regra dois: Utilize wildcards de domínio no walled garden, e não intervalos de IP, para qualquer conteúdo alojado em CDN. Os intervalos de IP de CDN são extensos e mudam frequentemente. Uma entrada de domínio wildcard é mais fácil de manter e mais fiável. Regra três: Ative o accounting de RADIUS 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 desligamento e para fornecer 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, as análises, a automação de marketing e a gestão de consentimento em conformidade com o GDPR. A splash integrada é adequada para um clique simples básico, mas não é uma plataforma de inteligência de convidados. Esta configuração funciona em firewalls Meraki MX tão bem como em pontos de acesso MR? A configuração de splash page RADIUS é suportada em pontos de acesso MR. Os dispositivos MX gerem a autenticação de VPN de cliente de forma diferente. Especificamente para WiFi de convidados, está a configurar os SSIDs dos MR. E quanto ao WPA3? Os pontos de acesso Meraki MR suportam WPA3 em SSIDs empresariais. Para implementações de Captive Portal de convidados, o SSID é normalmente Aberto (Open), pelo que o WPA3 não se aplica diretamente. No entanto, se estiver a implementar um SSID Passpoint ou OpenRoaming em conjunto 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 concluir: a integração entre a Cisco Meraki e a Purple está amplamente testada e é fiável, mas requer atenção a três aspetos: encaminhamento de IP de origem do RADIUS, integridade do walled garden e configuração do limite de tempo de sessão. Acerte nestes três pontos e a implementação será simples. O caso de negócio é claro — os espaços que implementam uma plataforma de WiFi de convidados devidamente configurada com recolha de dados obtêm consistentemente retornos mensuráveis no envolvimento de marketing e na visão operacional. Se quiser aprofundar o assunto, consulte o guia da Purple sobre a implementação de autenticação 802.1X com Cloud RADIUS e o nosso guia de implementação de APs sem fios Cisco no blogue da Purple. Ambos estão ligados nas notas do episódio. Obrigado por 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. Vemo-nos no próximo episódio.