Configurando o Redirecionamento do Captive Portal em Controladores de Rede Empresariais

Bem-vindo ao Purple Technical Briefing. Eu sou o vosso anfitrião e, nos próximos dez minutos, vamos entrar diretamente num dos temas mais pesquisados e menos documentados em WiFi empresarial: a configuração do redirecionamento do Captive Portal em controladores de rede. Se alguma vez pesquisou por "configurar controlador portal cautivo" e não obteve resultados, este é o briefing de que precisava. Vamos cobrir o panorama completo - a arquitetura técnica, os passos de configuração controlador por controlador, os requisitos de conformidade e as armadilhas do mundo real que atrapalham até as equipas de rede mais experientes. Vamos a isto. Um Captive Portal é o mecanismo que intercepta o primeiro pedido HTTP ou HTTPS do dispositivo de um convidado após a ligação à sua rede WiFi, redirecionando-o para uma splash page personalizada antes de conceder acesso à Internet. Essa splash page pode solicitar um login social, o preenchimento de um formulário, uma aceitação simples dos termos ou uma verificação de credenciais suportada por RADIUS. O redirecionamento em si é gerido ao nível do controlador - não no ponto de acesso, nem na firewall. O controlador intercepta o tráfego do cliente não autenticado, aplica uma lista de controlo de acesso pré-autenticação - o que chamamos de walled garden - e direciona o browser do cliente para o URL do seu portal. Porque é que isto é importante a nível comercial? Por três razões. Primeiro, a conformidade. Ao abrigo do GDPR, é obrigado a obter consentimento explícito e informado antes de recolher dados pessoais dos visitantes. Um Captive Portal configurado corretamente é o seu mecanismo de consentimento. Sem ele, estará a recolher dados sem uma base jurídica - e isso é uma exposição regulamentar. Segundo, a segurança. Um SSID aberto sem autenticação é uma responsabilidade. O redirecionamento do Captive Portal, combinado com a segmentação por VLAN e um servidor RADIUS, oferece-lhe responsabilidade por sessão. Sabe quem se ligou, quando e a partir de que dispositivo. Terceiro, a inteligência de negócio. Cada sessão autenticada é um ponto de dados primário (first-party data). A Purple processa 440 milhões de logins anualmente em 80.000 locais. Esses dados - tempo de permanência, frequência de visitas, sinais demográficos - só estão disponíveis se o seu Captive Portal estiver configurado corretamente para os recolher e transmitir. Agora, deixe-me guiar-vos pelo fluxo de redirecionamento, passo a passo. Passo um: o dispositivo do convidado associa-se ao seu SSID de convidados. O controlador atribui-lhe um endereço IP via DHCP, mas coloca-o num estado restrito de pré-autenticação. Todo o tráfego é bloqueado, exceto o DNS e os domínios de walled garden que permitiu explicitamente. Passo dois: o convidado abre um browser. O seu pedido HTTP atinge o controlador. O controlador intercepta-o e emite um redirecionamento 302 para o URL do seu portal. Este é o mecanismo central de redirecionamento. Passo três: o browser do convidado carrega a sua splash page, alojada no próprio controlador ou, mais frequentemente em implementações empresariais, numa plataforma de nuvem externa como a Purple. Passo quatro: o convidado autentica-se - via login social, formulário ou credenciais. O portal envia um sinal de autorização de volta ao controlador, tipicamente via uma mensagem RADIUS Access-Accept ou um bypass de autorização MAC. Passo cinco: o controlador move o cliente da VLAN de pré-autenticação para a VLAN de pós-autenticação, remove a regra de redirecionamento e concede acesso à internet. Esse fluxo de cinco passos é consistente em todas as principais plataformas de controladores. O que difere é como configura cada passo em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi e outras. Vamos analisar as principais plataformas. Cisco Meraki. A Meraki utiliza uma página splash personalizada configurada inteiramente através do Meraki Dashboard - não existe CLI. Navegue até Wireless, depois Access Control, selecione o seu SSID de convidados, defina a página splash para "Sign-on with my RADIUS server" ou "Click-through", e depois introduza o URL do seu portal externo no campo Custom Splash URL. O walled garden é configurado na secção Advanced Splash Settings - adiciona os endereços IP do servidor do seu portal para que o convidado possa aceder à página splash antes da autenticação. Os detalhes do servidor RADIUS são inseridos na secção RADIUS: autenticação na porta 1812, accounting na porta 1813. HPE Aruba. No ArubaOS, configura um perfil de Captive Portal sob a secção AAA, especificando o URL de login, o grupo de servidores que aponta para o seu servidor RADIUS e o URL de redirecionamento. Em seguida, aplica esse perfil ao seu SSID através do perfil de AP virtual. A função de pré-autenticação - o que a Aruba chama de função "logon" - contém a ACL que permite DNS, DHCP e acesso ao intervalo de IP do servidor do seu portal. Pós-autenticação, o controlador atribui a função "authenticated", que permite o acesso total à internet. O Ruckus SmartZone utiliza um tipo de WLAN Hotspot para implementações de Captive Portal. Na configuração de WLAN, defina o tipo de WLAN para Hotspot, depois configure o URL do portal, o servidor RADIUS para autenticação e accounting, e as entradas de walled garden. A Northbound Portal Interface lida com o fluxo de autorização MAC entre o portal e o controlador. A Juniper Mist utiliza uma abordagem cloud-native. Em Network, depois WLANs, crie uma WLAN de convidados e defina o tipo de portal para "External Captive Portal". Introduza o URL do seu portal e configure os detalhes do servidor RADIUS. A Mist passa o MAC do cliente, o MAC do AP e o nome do SSID como parâmetros de URL para o portal. Ubiquiti UniFi. No UniFi Network Controller, navegue até Settings, depois WiFi, selecione a sua rede de convidados e, em Advanced Options, ative o Guest Policy para habilitar o portal hotspot. Defina o tipo de portal para "External" e introduza o URL do seu portal. Configure o servidor RADIUS em Profiles, depois RADIUS. O walled garden é o elemento configurado incorretamente com mais frequência em implementações de Captive Portal. Se errar aqui, os seus convidados verão um erro no navegador em vez da sua página splash. O walled garden deve permitir, no mínimo: os endereços IP ou domínio do seu servidor de portal, os endereços IP do seu servidor RADIUS, a resolução de DNS na porta 53 e DHCP nas portas 67 e 68. Se o seu portal carregar recursos de uma CDN - fontes, imagens, JavaScript - esses domínios de CDN também devem estar no walled garden. Para implementações da Purple, fornecemos os intervalos de IP e domínios específicos para colocar na lista de permissões durante a integração. O modo de falha mais comum é um portal que carrega a estrutura HTML, mas não consegue renderizar imagens ou executar JavaScript porque os domínios da CDN estão em falta no walled garden. Dois padrões de conformidade dominam aqui: GDPR e PCI DSS. Sob o GDPR, o seu captive portal deve apresentar um mecanismo de consentimento claro e específico antes de recolher dados pessoais. Isto significa caixas de seleção separadas e desmarcadas para acesso WiFi e consentimento de marketing. Não pode agregá-los. O registo de consentimento deve ser armazenado e recuperável para fins de auditoria. A plataforma da Purple lida com isto automaticamente, armazenando os registos de consentimento associados a cada sessão autenticada. Sob o PCI DSS, se o seu estabelecimento processar pagamentos com cartão, a sua rede WiFi de convidados deve estar isolada do seu ambiente de cartões de pagamento. Isto significa uma VLAN de convidados dedicada com regras de firewall que impedem qualquer encaminhamento entre o segmento de convidados e a sua rede POS. A versão 4.0 do PCI DSS, que se tornou obrigatória em março de 2024, exige testes de segmentação de rede pelo menos a cada seis meses. Permita-me dar-lhe dois cenários concretos. Cenário um: um hotel de 350 quartos a correr Cisco Meraki. O hotel pretende substituir um portal básico de clique simples por uma experiência de convidado personalizada que recolhe endereços de email para o seu programa de fidelização. A configuração: criar um SSID de convidados dedicado numa VLAN separada apenas com acesso à internet. Configurar a splash page da Meraki para apontar para o URL do portal da Purple. Configurar a autenticação RADIUS utilizando os detalhes do servidor RADIUS da Purple. Configurar o walled garden com os intervalos de IP da Purple. No painel da Purple, criar uma splash page personalizada com um formulário que recolhe nome, email e número de quarto, com caixas de seleção explícitas de consentimento do GDPR. Ligar o conector de CRM da Purple à plataforma de marketing do hotel. A Premier Inn implementou este modelo em toda a sua propriedade e registou aumentos mensuráveis nas taxas de reserva direta de convidados angariados através do WiFi. Cenário dois: uma cadeia de retalho regional com 40 lojas a utilizar HPE Aruba. O retalhista necessita de uma experiência de WiFi de convidados consistente em todos os locais, com análises de tráfego pedonal para comparar o desempenho das lojas. Implemente o Aruba Central para gerir todos os 40 locais a partir de um único painel. Configure um modelo de WLAN de convidados com um Captive Portal externo a apontar para a Purple. Aplique o modelo em todos os locais utilizando a funcionalidade de política de grupo do Aruba Central. Na Purple, configure um único modelo de portal que se aplica a todos os locais, com painéis de análise por local. O walled garden e a configuração RADIUS são definidos uma vez no modelo e propagados automaticamente. Resultado: a equipa de TI gere 40 locais a partir de uma única consola. A equipa de marketing obtém dados de tráfego pedonal por loja, análise do tempo de permanência e taxas de visitas repetidas - tudo a partir de um único painel da Purple. Quatro armadilhas que vejo repetidamente. Uma: falhas na interceção de HTTPS. Os browsers modernos e os sistemas operativos móveis utilizam sondas HTTPS para detetar captive portals. Se o seu controlador não conseguir intercetar o tráfego HTTPS - o que requer um certificado válido para o domínio de redirecionamento - a sonda falha silenciosamente e o convidado não vê qualquer redirecionamento. A solução: configure a interface virtual do seu controlador com um certificado fidedigno ou utilize sondas apenas de HTTP no seu SSID de convidados. Duas: fuga de DNS. Se a sua ACL de pré-autenticação permitir DNS sem restrições, os convidados podem utilizar túneis de DNS para contornar completamente o Captive Portal. Restrinja o DNS apenas ao seu resolvedor designado. Três: incompatibilidades no tempo limite da sessão. Se o tempo limite da sessão do seu controlador for inferior à validade do token de sessão do seu portal, os convidados são redirecionados de volta para o portal a meio da sessão. Alinhe estes valores - normalmente 24 horas para hotelaria, oito horas para retalho. Quatro: falta de faturação. A faturação RADIUS - as mensagens Accounting-Start e Accounting-Stop - é a forma como o seu portal sabe que uma sessão terminou. Sem a faturação configurada, os registos de sessão do seu portal serão imprecisos e as suas análises serão pouco fiáveis. Perguntas rápidas, respostas rápidas. Posso utilizar um portal externo com qualquer controlador? Sim, desde que o controlador suporte o redirecionamento para um Captive Portal externo - o que todas as plataformas que discutimos fazem. Preciso de um servidor RADIUS para executar um Captive Portal? Nem sempre. Portais simples de clique único podem utilizar a desclassificação de autorização MAC sem um servidor RADIUS completo. Mas para portais baseados em credenciais ou início de sessão social, o RADIUS é o mecanismo padrão. O Captive Portal funciona com WPA3? Sim. O WPA3 lida com a camada de encriptação sem fios. O Captive Portal lida com a camada de autenticação. Operam de forma independente e são totalmente compatíveis. Como é que a Purple se integra com o meu controlador existente? A Purple funciona como o servidor de portal externo. Aponta o URL de splash do seu controlador para o endpoint de portal da Purple, configura o walled garden com as gamas de IP da Purple e configura o RADIUS utilizando os detalhes do servidor da Purple. A integração segue o mesmo processo, independentemente de utilizar Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist ou Ubiquiti UniFi. Em resumo. O redirecionamento de Captive Portal é configurado ao nível do controlador, não do ponto de acesso. Os componentes principais são: o URL de splash que aponta para o seu portal, o walled garden que permite o acesso ao seu servidor de portal, o RADIUS para autenticação e contabilização (accounting), e a segmentação de VLAN para isolamento de rede. Os passos de configuração variam consoante o fabricante, mas a arquitetura é consistente. Para fins de conformidade, o seu portal deve implementar a recolha de consentimento em conformidade com o GDPR e a segmentação de rede em conformidade com o PCI DSS. O WPA3 é o padrão atual para encriptação sem fios e deve ser a sua especificação de base em qualquer nova implementação. A Purple integra-se nativamente com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Em 80.000 locais e 440 milhões de inícios de sessão em 2024, a plataforma é independente de hardware por conceção - a sua escolha de controlador não limita a sua capacidade de capturar dados de convidados primários (first-party) ou de executar análises. O seu próximo passo: reveja a configuração atual do seu controlador em relação à checklist de walled garden e de contabilização RADIUS neste guia. Se estiver a implementar uma nova rede WiFi de convidados, comece com os passos de configuração específicos do fabricante para a sua plataforma de controlador e ligue a Purple como o seu portal externo. Obrigado por ouvir. Esta foi a Apresentação Técnica da Purple.