Ver transcrição do podcast
Bem-vindo à série Purple Technical Briefing. Eu sou o seu apresentador 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 em pontos de acesso Cisco Meraki MR e, especificamente, como integrar isso com a plataforma de nuvem da Purple usando a autenticação RADIUS. Seja você um MSP integrando um novo cliente de hotelaria ou um arquiteto de rede interno em uma rede de varejo, este episódio fornecerá as etapas exatas de configuração e a lógica 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 de compras - 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 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 alterar qualquer configuração é o seguinte: no Cisco Meraki, a autenticação RADIUS para uma página de splash 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. Esta é uma distinção crítica que confunde muitos engenheiros em sua primeira implantação Meraki. Isso significa que o seu servidor RADIUS, neste caso o endpoint de nuvem RADIUS da Purple, precisa estar acessível pela internet, e suas regras de firewall precisam permitir o tráfego dos intervalos de IP do Meraki Dashboard, e não apenas da sub-rede do seu AP local. Você encontrará os intervalos de IP atuais do Dashboard em Help e, depois, em Firewall Info no seu Meraki Dashboard.
Certo, vamos para a configuração. Vou orientar você na ordem em que faria isso em uma implantaçã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 deseja usar para o acesso de convidados. Dê a ele um nome claro - algo como GuestWiFi ou NomeDoLocal_Guest. Em Association requirements, defina Security como Open, no encryption. Isso está correto e é intencional - a camada de segurança para convidados é gerenciada pelo Captive Portal e pela autenticação RADIUS, não pela criptografia WPA. Se você estiver fazendo a implantação em um ambiente PCI-DSS, precisará garantir que o tráfego de convidados seja 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 como Sign-on com e, no menu suspenso, selecione meu servidor RADIUS. Esta é a configuração crítica que informa 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 como Bloquear todo o acesso até que o login seja concluído. É isso que impõe o walled garden - sem isso, os convidados 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 do servidor RADIUS ou FQDN, 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 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 recomendaria 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 honra o atributo Session-Timeout retornado na resposta RADIUS Access-Accept. A Purple usa isso para controlar quanto tempo dura a sessão de um convidado antes que a autenticação seja exigida novamente. Para um hotel, você pode definir isso para 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 é honrado, mas apenas se o RADIUS accounting estiver ativado. 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 Configure e depois Splash page. Selecione o seu SSID de convidado 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 intervalos de IP que um dispositivo de convidado 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 para o seu SSID de convidados. Defina Walled garden como Walled garden está ativado. No campo de intervalos do Walled garden, você precisa adicionar o seguinte. Primeiro, os domínios da plataforma Purple: estrela ponto purple ponto ai, e estrela ponto venuewifi ponto com. Segundo, os domínios de CDN que a Purple usa para servir ativos do portal: estrela ponto cloudfront ponto net, e estrela ponto akamaihd ponto net. Terceiro, a infraestrutura de redirecionamento Meraki: estrela ponto network-auth ponto com. Quarto, se você estiver oferecendo opções de login social, precisará dos domínios OAuth relevantes. Para Google: accounts ponto google ponto com, estrela ponto googleapis ponto com, estrela ponto gstatic ponto com. Para Facebook: estrela ponto facebook ponto com, estrela ponto fbcdn ponto net, e connect ponto facebook ponto net. Para Twitter ou X: estrela ponto twitter ponto com e estrela ponto twimg ponto com.
Uma observação importante sobre como a Meraki lida com domínios curinga no walled garden. A Meraki suporta entradas curinga usando o prefixo asterisco, por exemplo, estrela 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 com frequência, 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 convidados simultâneos no horário de pico. A implantação inicial usava uma página de splash do tipo clique e acesse - sem RADIUS, apenas aceitação de termos. O problema era que eles tinham zero visibilidade sobre quem estava se conectando, nenhuma captura de e-mail e nenhuma maneira de realizar 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 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 convidados conectados no primeiro mês, e sua equipe de marketing realizou uma campanha de reengajamento que gerou um aumento mensurável nas reservas diretas.
O segundo cenário é uma rede de varejo com 45 lojas, cada uma operando pontos de acesso Meraki MR33. O desafio aqui era escala e consistência. Configurar manualmente 45 SSIDs com as configurações RADIUS corretas e listas de walled garden seria propício a erros e consumiria muito tempo. A solução foi usar a configuração baseada em templates da Meraki. Criamos um único template de rede com o SSID, RADIUS e configurações de walled garden corretas e, em seguida, 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. As análises do Purple agregaram os dados de tráfego de pedestres e tempo de permanência de todas as lojas, oferecendo à equipe de operações de varejo uma visão única em um painel sobre o 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 painel da Meraki antes de configurar o RADIUS. As faixas mudam ocasionalmente e, se o seu firewall as estiver bloqueando, a autenticação falhará silenciosamente sob a perspectiva do usuário - eles apenas verão a página do portal travar. Use a ferramenta de teste RADIUS integrada no painel 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 curinga é mais fácil de manter e mais confiável.
Regra três: habilite a contabilidade RADIUS na porta 1813, mesmo que você ache que não precisa dela ainda. 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 análise. Não custa nada habilitar e é muito difícil readaptar depois.
Agora, algumas perguntas rápidas que recebo regularmente.
Posso usar a página de splash integrada da Meraki em vez do Purple? Sim, mas você perde a captura de dados, as análises, a automação de marketing e o gerenciamento de consentimento em conformidade com o GDPR. A página de splash integrada é adequada para um clique básico, mas não é uma plataforma de inteligência de visitantes.
Esta configuração funciona em firewalls Meraki MX, bem como em pontos de acesso MR? A configuração da página de splash RADIUS é compatível com pontos de acesso MR. Os appliances MX lidam com a autenticação de VPN de cliente de maneira diferente. Especificamente para WiFi de visitantes, você configura os SSIDs MR.
E quanto ao WPA3? Os pontos de acesso Meraki MR oferecem suporte a WPA3 em SSIDs corporativos. Para implantações de Captive Portal de visitantes, o SSID normalmente é Open, portanto 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 o Purple suporta - esse SSID usa WPA3-Enterprise com 802.1X, e é aí que o WPA3 se torna relevante.
Para concluir: 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 session timeout. Acerte esses três pontos e a implementação será simples. O caso de negócios é claro - locais que implementam uma plataforma de WiFi de visitantes configurada corretamente com captura de dados observam consistentemente retornos mensuráveis no 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 RADIUS em nuvem e nosso guia de implementação de AP Cisco Wireless no blog da Purple. Ambos estão linkados nas notas do episódio.
Obrigado por ouvir. Se você tiver um cenário de implementaçã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.
