Captive Portal for Cisco Meraki

Bem-vindo à Série de Briefing Técnico da Purple. Eu sou o seu anfitrião e hoje vamos abordar algo que surge em quase todas as implantações de WiFi corporativo para convidados em que trabalhamos: a configuração de um Captive Portal nos pontos de acesso Cisco Meraki MR e, especificamente, como integrar isso com a plataforma de nuvem da Purple usando autenticação RADIUS. Quer você seja um MSP integrando um novo cliente do setor de hospitalidade ou um arquiteto de rede interno em uma rede de varejo, este episódio fornecerá as etapas de configuração precisas e a justificativa por trás de cada uma delas. Vamos contextualizar. Você tem um local — que pode ser um hotel, um centro de conferências, um estádio ou um parque comercial — executando pontos de acesso Cisco Meraki MR gerenciados por meio do Meraki Dashboard. O objetivo é implantar uma experiência de WiFi para convidados personalizada com a marca que capture dados primários, imponha a aceitação dos termos de serviço e envie análises de volta para uma plataforma de marketing. É exatamente para isso que a Purple foi criada, e a Meraki é uma das nossas implantações de hardware mais comuns globalmente. Agora, o ponto arquitetônico fundamental a ser compreendido antes de tocar em uma única configuração é este: no Cisco Meraki, a autenticação RADIUS para uma splash page não é processada localmente pelo ponto de acesso. O RADIUS Access-Request é originado da nuvem Meraki — da infraestrutura do Dashboard — e não do AP na sua LAN. Essa é uma distinção crítica que confunde muitos engenheiros em sua primeira implantação Meraki. Isso significa que seu servidor RADIUS, neste caso o endpoint RADIUS na nuvem da Purple, precisa estar acessível a partir da internet, e suas regras de firewall precisam permitir o tráfego das faixas de IP do Meraki Dashboard, não apenas da sub-rede local do seu AP. Você encontrará as faixas de IP atuais do Dashboard em Help e, em seguida, em Firewall Info no seu Meraki Dashboard. Certo, vamos para a configuração. Vou guiar você por isso na ordem em que você realmente faria em uma implantação real. Etapa um: configuração do SSID. No Meraki Dashboard, navegue até Wireless, depois Configure e, em seguida, SSIDs. Selecione o slot de SSID que deseja usar para o acesso de convidados. Dê a ele um nome claro — algo como GuestWiFi ou NomeDoLocal underline Guest. Em Association requirements, defina Security como Open, no encryption. Isso está correto e é intencional — a camada de segurança para convidados é tratada pelo Captive Portal e pela autenticação RADIUS, não pela criptografia WPA. Se você estiver implantando em um ambiente PCI DSS, precisará garantir que o tráfego de convidados esteja isolado em sua própria VLAN, o que abordaremos em breve. Passo dois: Splash page e autenticação. Ainda na página de Controle de Acesso do seu SSID, role até a seção Splash page. Defina-a como Sign-on com e, no menu suspenso, selecione meu servidor RADIUS. Esta é a configuração crítica que diz ao Meraki para autenticar os usuários em um servidor RADIUS externo antes de conceder acesso à rede. Abaixo disso, você verá a opção Força do Captive Portal. Defina-a como Bloquear todo o acesso até que o login seja concluído. É isso que impõe o walled garden — sem isso, os visitantes poderiam ignorar o portal completamente. Passo três: Configuração do servidor RADIUS. Na seção RADIUS, clique em Adicionar servidor. Você 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 compartilhado. A Purple fornece essas informações na seção de configuração de local do portal. Para redundância em implantações de produção, você deve adicionar um servidor RADIUS secundário — a Purple fornece um endpoint de failover. Defina a porta de tarifação (accounting) como UDP 1813 se quiser que os dados da sessão sejam enviados de volta ao mecanismo de análise da Purple, o que eu recomendo fortemente para qualquer local 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. O Meraki respeita o atributo Session-Timeout retornado na resposta RADIUS Access-Accept. A Purple usa isso para controlar quanto tempo dura a sessão de um visitante antes que a autenticação seja necessária novamente. Para um hotel, você pode definir isso como 86.400 segundos — ou seja, 24 horas. Para uma cafeteria, algo como 3.600 segundos, uma hora, é mais apropriado. O atributo Idle-Timeout também é respeitado, mas apenas se a tarifação RADIUS estiver ativada. Isso desconecta sessões inativas, o que é importante para o gerenciamento de capacidade em locais de alta densidade. Passo quatro: URL da Splash page. Navegue até Wireless, depois Configurar e, em seguida, Splash page. Selecione o seu SSID de visitantes no menu suspenso. Defina a URL de splash personalizada para a URL do portal Purple do seu local. Esta é a URL para a qual o Meraki redirecionará os clientes não autenticados. O Meraki anexa parâmetros de consulta a esta URL — incluindo um parâmetro login_url — que a Purple usa para concluir o handshake de autenticação. Não modifique ou remova esses parâmetros. Passo cinco: o walled garden. É aqui que a maioria das implantações enfrenta problemas. O walled garden é a lista de domínios e faixas de IP que um dispositivo de visitante pode acessar antes de ser autenticado. Sem as entradas corretas, a própria página do Captive Portal não será carregada, pois o navegador será impedido de acessar a CDN da Purple e os provedores de login social. Navegue de volta para Controle de Acesso (Access Control) do seu SSID de visitantes. Defina Walled garden para Walled garden is enabled. No campo Walled garden ranges, você precisa 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 usa para servir 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 você estiver oferecendo opções de login social, precisará dos domínios OAuth relevantes. Para o 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 observação importante sobre como a Meraki lida com domínios curinga (wildcard) no walled garden. A Meraki suporta entradas curinga usando o prefixo de asterisco, por exemplo, star ponto cloudfront ponto net. No entanto, essa é uma correspondência baseada em DNS — a Meraki resolve o domínio e permite os endereços IP resultantes. Isso significa que para provedores de CDN como CloudFront ou Akamai, onde os IPs resolvidos podem mudar frequentemente, você deve usar o domínio curinga em vez de intervalos de IP estáticos. Entradas de IP estático funcionam bem 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 nos quais trabalhei diretamente. O primeiro é um hotel de 350 quartos no Reino Unido. O cliente estava operando pontos de acesso Meraki MR46 em três edifícios, com cerca de 400 dispositivos de visitantes simultâneos no horário de pico. A implantação inicial usava uma splash page de clique único — sem RADIUS, apenas aceitação dos termos. O problema era que eles tinham zero visibilidade sobre quem estava se conectando, nenhuma captura de e-mail e nenhuma maneira de executar campanhas de marketing pós-estadia. Nós os migramos para a Purple com login baseado em RADIUS. A configuração foi simples, mas o detalhe foi que o firewall upstream deles estava bloqueando o tráfego UDP de saída na porta 1812 para qualquer coisa fora da sub-rede local. Assim que adicionamos os intervalos de IP do Meraki Dashboard à lista de permissões do firewall, a autenticação funcionou imediatamente. Após a implantação, o hotel capturou endereços de e-mail de aproximadamente 68 por cento dos visitantes conectados no primeiro mês, e sua equipe de marketing executou uma campanha de engajamento que gerou um aumento mensurável nas reservas diretas. O segundo cenário é uma rede de varejo com 45 lojas, cada uma operando com pontos de acesso Meraki MR33. O desafio aqui era escala e consistência. Configurar manualmente 45 SSIDs com as configurações de RADIUS corretas e listas de walled garden seria propenso a erros e demorado. A solução foi usar a configuração baseada em templates da Meraki. Criamos um único template de rede com as configurações corretas de SSID, RADIUS e walled garden, e depois vinculamos todas as 45 redes de lojas a esse template. Qualquer alteração — por exemplo, adicionar um novo provedor de login social ao walled garden — é feita uma única vez no template e se propaga para todas as lojas automaticamente. A análise da Purple então agregou os dados de fluxo de pessoas e tempo de permanência em todas as lojas, oferecendo à equipe de operações de varejo uma visão única em um painel do comportamento dos visitantes por loja, por região e por hora do dia. Deixe-me dar três regras práticas que economizarão seu tempo em cada implantação de Captive Portal Meraki. Regra um: Sempre verifique as faixas de IP do Meraki Dashboard antes de configurar o RADIUS. As faixas mudam ocasionalmente e, se o seu firewall as estiver bloqueando, a autenticação falhará silenciosamente do ponto de vista do usuário — ele apenas verá a página do portal travar. Use a ferramenta de teste de RADIUS integrada no Dashboard em Controle de Acesso para verificar a conectividade antes de entrar em operação. Regra dois: Use curingas de domínio no walled garden, não faixas de IP, para qualquer conteúdo hospedado em CDN. As faixas de IP de CDN são grandes e mudam com frequência. Uma entrada de domínio com caractere curinga é mais fácil de manter e mais confiável. Regra três: Ative a tarifação RADIUS na porta 1813, mesmo que você ache que ainda não precisa dela. Os dados de sessão são valiosos para solucionar problemas de desconexão e para alimentar métricas precisas de tempo de permanência em sua plataforma de analytics. Não custa nada ativar e é muito difícil adaptar depois do fato. Agora, algumas perguntas rápidas que recebo regularmente. Posso usar a splash page integrada da Meraki em vez da Purple? Sim, mas você perde a captura de dados, o analytics, a automação de marketing e o gerenciamento de consentimento em conformidade com a GDPR. A splash integrada é adequada para um clique básico de transição, mas não é uma plataforma de inteligência de visitantes. Essa configuração funciona em firewalls Meraki MX, bem como em pontos de acesso MR? A configuração de splash page RADIUS é suportada em pontos de acesso MR. Os appliances MX lidam com a autenticação de VPN de cliente de forma diferente. Para WiFi de visitantes especificamente, você configura os SSIDs dos MR. E quanto ao WPA3? Os pontos de acesso Meraki MR suportam WPA3 em SSIDs corporativos. Para implantações de Captive Portal de visitantes, o SSID normalmente é Open, então o WPA3 não se aplica diretamente. No entanto, se você estiver implantando um SSID Passpoint ou OpenRoaming junto com seu SSID de Captive Portal — o que a Purple suporta —, esse SSID usa WPA3-Enterprise com 802.1X, e é aí que o WPA3 se torna relevante. Para resumir: a integração entre Cisco Meraki e Purple é amplamente testada e confiável, mas exige atenção a três pontos: roteamento de IP de origem RADIUS, integridade do walled garden e configuração de tempo limite de sessão (session timeout). Acerte esses três pontos e a implantação será simples. O caso de negócio é claro — locais que implantam uma plataforma de guest WiFi configurada corretamente com captura de dados veem consistentemente retornos mensuráveis em engajamento de marketing e insights operacionais. Se quiser se aprofundar, confira o guia da Purple sobre a implementação de autenticação 802.1X com cloud RADIUS e nosso guia de implantação de Cisco Wireless AP no blog da Purple. Ambos estão vinculados nas notas do episódio. Obrigado por ouvir. Se você tiver um cenário de implantação específico que gostaria que cobríssemos, entre em contato com a equipe técnica da Purple. Nos vemos no próximo episódio.