Um convidado chega a um hotel, seleciona o WiFi da propriedade, aguarda por um Captive Portal, aceita os termos, insere um endereço de email e repete o processo no centro de conferências ao lado. Num hospital, o iPad gerido de um clínico e o telemóvel VoWiFi podem mover-se entre pontos de acesso enquanto transportam perfis diferentes. Num estádio, milhares de dispositivos competem por tempo de antena enquanto a página de início de sessão se torna mais um ponto de falha.
A configuração de Passpoint WiFi resolve essa fricção ao mover as decisões de acesso para a camada de identidade. Os dispositivos compatíveis descobrem a rede, avaliam as credenciais anunciadas e as informações de roaming, e depois autenticam-se através da segurança de WiFi empresarial em vez de dependerem de uma palavra-passe partilhada ou de uma página de splash. O resultado pode ser a integração automática e o roaming entre múltiplos locais que confiam no mesmo fornecedor de identidade.
Este resultado não se obtém simplesmente ao ativar uma caixa de verificação do Hotspot 2.0. Depende do firmware dos APs, dos anúncios 802.11u e ANQP, dos métodos EAP, dos certificados, dos domínios NAI, da capacidade de RADIUS, do suporte dos dispositivos e do planeamento de contingência. A abordagem prática consiste em auditar a infraestrutura, testar uma amostra controlada, registar as falhas e expandir apenas quando as evidências o sustentarem.
Por que Razão a Configuração de WiFi Passpoint é Importante para Redes Empresariais
Hotéis, hospitais e estádios expõem rapidamente as fraquezas do WiFi de convidados convencional. Um hotel pode necessitar de suportar centenas de dispositivos diferentes em visitas repetidas, enquanto um hospital tem dispositivos clínicos partilhados, telemóveis do pessoal e visitantes com fornecedores de identidade não relacionados. Um estádio tem uma procura densa e imprevisível e pouca tolerância para um fluxo de início de sessão que falha quando os utilizadores se deslocam pelas entradas ou mudam de bancada.
Os portais cativos são úteis quando um operador necessita de consentimento ou dados de marketing, mas criam uma carga operacional adicional. Os SSIDs por local obrigam os utilizadores a escolher redes manualmente, as palavras-passe partilhadas espalham-se além do público-alvo e os redirecionamentos de portais podem falhar devido ao comportamento do navegador, avisos de certificado ou más condições de rádio. A reautenticação torna-se especialmente disruptiva quando um utilizador passa de um controlador ou edifício para outro.
O que uma implementação funcional substitui
O Passpoint utiliza a descoberta 802.11u, informações de rede ANQP e autenticação baseada em EAP para permitir que um dispositivo determine se possui um perfil válido antes de se associar. Com as credenciais corretas, o dispositivo pode ligar-se sem a introdução repetida de uma palavra-passe. O WPA2 ou WPA3 fornece depois o modelo de segurança esperado para o acesso baseado em identidade.
Os benefícios operacionais são práticos em vez de cosméticos:
- Menos administração de credenciais: A equipa não precisa de redefinir uma palavra-passe de convidado partilhada sempre que esta aparece num aviso público.
- Menos dependências de portais: Um dispositivo suportado não precisa de carregar uma splash page antes de obter acesso à rede.
- Melhor continuidade multi-site: Um perfil pode reconhecer redes fidedignas associadas ao mesmo domínio ou relação de roaming.
- Controlo de acesso mais limpo: As políticas RADIUS podem distinguir utilizadores, dispositivos e fornecedores de identidade em vez de tratarem cada cliente como um membro anónimo de um único SSID.
O Reino Unido já tem uma referência relevante no setor público. O serviço oficial GovWifi fornece um nome de utilizador e palavra-passe para funcionários e visitantes em todo o setor público, e a Government Property Agency afirma que atende mais de 850.000 pessoas em todo o Reino Unido. O GovWifi também liga os utilizadores automaticamente em milhares de edifícios que oferecem o serviço. Não é a mesma implementação que o Passpoint, mas demonstra que a autenticação centralizada e o acesso multi-site são práticas operacionais estabelecidas, e não ideias de laboratório.
Trate o projeto como engenharia de identidade
A primeira decisão de design é se o Passpoint serve dispositivos de funcionários geridos, acesso público de convidados, offload de operadoras ou uma federação como o OpenRoaming. Cada caso de utilização altera a fonte de credenciais, o método EAP, o modelo de políticas e a experiência de contingência (fallback).
O relatório da Wireless Broadband Alliance coberto pela Comms Business concluiu que 81% dos inquiridos planeavam implementações de OpenRoaming, com motivações que incluem o acesso a WiFi e redes móveis, segurança melhorada, acesso sem fricção e continuidade entre redes. Estes números não eliminam o trabalho de engenharia. Mostram sim a razão pela qual os operadores estão a investir nesta tecnologia, enquanto a implementação continua a depender da configuração exata de identidade e confiança.
Compreender a Stack do Passpoint
O Passpoint é um sistema de camada de identidade, não uma caixa de verificação no controlador sem fios. A resolução de problemas torna-se muito mais rápida quando cada camada tem uma função definida. O ponto de acesso anuncia informações suficientes para que um dispositivo decida se a rede corresponde a um perfil instalado. O dispositivo seleciona uma credencial compatível e inicia a autenticação empresarial. O RADIUS toma a decisão de autorização, enquanto os certificados e os domínios determinam se o cliente e o servidor confiam um no outro.
Na camada de rádio e descoberta, o IEEE 802.11u fornece a descoberta da rede antes da associação normal. O ponto de acesso utiliza GAS para transportar consultas e respostas ANQP. O ANQP pode publicar o tipo de acesso da rede, nomes de domínio, domínios NAI, identificadores de roaming, informações do local, dados relacionados com a rede móvel e métricas de WAN. O cliente compara esses valores com os perfis já instalados no dispositivo.
O caminho prático é:
- Beacon e indicação 802.11u: O AP sinaliza que a informação de Hotspot 2.0 está disponível.
- Troca GAS e ANQP: O cliente pergunta quais as identidades, realms, parceiros de roaming e serviços que a rede suporta.
- Correspondência de perfil: O dispositivo compara os valores anunciados com o seu perfil Passpoint.
- Autenticação EAP: O dispositivo autentica-se através de 802.1X, utilizando frequentemente EAP-TLS, EAP-TTLS, EAP-SIM ou EAP-AKA, dependendo da implementação.
- Autorização RADIUS: O AP ou controlador encaminha o pedido e aplica a política devolvida.
- Associação encriptada: O cliente junta-se através de WPA2-Enterprise ou WPA3-Enterprise, sem depender de um Captive Portal.
As orientações de implementação da WiFi Alliance identificam a indicação HS2.0 no beacon do AP como um pré-requisito. Se um cliente não conseguir detetar essa indicação, não iniciará a deteção Passpoint, independentemente do rigor com que o RADIUS tenha sido configurado.
O EAP-TLS utiliza certificados de cliente e adequa-se geralmente a frotas geridas porque a organização pode emitir, rodar e revogar credenciais de dispositivos. O EAP-TTLS suporta fluxos de trabalho de utilizador e palavra-passe, mas a identidade interna e o certificado de servidor ainda requerem uma proteção cuidadosa. Os métodos EAP baseados em SIM adequam-se a implementações de operadoras ou federadas onde a subscrição móvel fornece a credencial.
O domínio NAI identifica o domínio de identidade responsável por um pedido. Os RCOIs identificam consórcios de roaming e ajudam os clientes a decidir se uma rede pertence a uma relação de serviço fidedigna. Um servidor OSU pode aprovisionar credenciais para fluxos de registo suportados, enquanto um servidor de políticas pode ligar o local a uma federação e aplicar regras de parceiros.
Os lançamentos do Passpoint vão além da descoberta. O Hotspot 2.0 Release 2 e Release 3 suportam o registo online e o provisionamento de políticas, mas cada funcionalidade adicionada cria outro ponto de configuração. Um URI de OSU malformado, uma cadeia de certificados incompleta ou um domínio que difira por um único carácter podem impedir a associação. As definições do Captive Portal também podem entrar em conflito com um fluxo de identidade que espera um acesso empresarial encriptado.
Regra de engenharia: Desenhe o caminho desde o beacon até ao ANQP, perfil, EAP, RADIUS e decisão de política antes de configurar o SSID de produção. Se uma transferência não for clara, execute o piloto aí primeiro.
Verificações Preliminares Antes de Tocar no Controlador
Um projeto-piloto de Passpoint pode falhar antes mesmo de se abrir o controlador. Comece pela cadeia de dependências: firmware do AP, versão do controlador, serviços de identidade, certificados, perfis de cliente e capacidade operacional. Confirme se o modelo exato do AP e o ramo de software suportam Hotspot 2.0, ANQP, o modo WPA selecionado e todos os campos obrigatórios do Passpoint. A compatibilidade da família de produtos não é suficiente.
Crie uma pequena base de referência escrita em vez de copiar configurações entre locais. Confirme se a plataforma AAA suporta os métodos EAP escolhidos, atributos Passpoint, faturação (accounting) e respostas de política. Teste a acessibilidade a partir de cada origem de AP ou controlador que participará no piloto. Dimensione o RADIUS para picos de autenticação e faturação, e não apenas para o tráfego médio. Uma incompatibilidade de domínio (realm) continuará a falhar numa plataforma sobredimensionada, enquanto um serviço sobredimensionado pode ocultar uma configuração que, de outra forma, estaria correta.
O plano de certificados necessita do mesmo tratamento. Registe a CA emissora, as âncoras de confiança, o proprietário da renovação e o caminho de revogação. Certifique-se de que o certificado do servidor é confiável para todos os dispositivos de teste. Se a organização controlar os certificados dos dispositivos e pretender um acesso sem palavra-passe, o EAP-TLS é normalmente a escolha adequada. O EAP-TTLS adequa-se a um processo controlado de utilizador e palavra-passe. O EAP-SIM ou EAP-AKA pertencem a designs de federação suportados por operadora ou SIM, em vez de substituírem uma estratégia de certificados empresariais.
Utilize um grupo de clientes de teste conhecido e representativo do local, incluindo sistemas operativos, fabricantes de telemóveis e perfis geridos. Adicione dispositivos não geridos ou não suportados para verificar o que os utilizadores veem quando a autenticação automática não está disponível. O comportamento do Captive Portal deve fazer parte deste teste, uma vez que uma política de portal pode interferir com um fluxo de identidade destinado a utilizar acesso empresarial encriptado.
Antes da configuração, congele os valores de identidade. Escreva o domínio NAI exatamente como o fornecedor de identidade o espera, incluindo maiúsculas, minúsculas, pontuação e sufixos. Registe a decisão do servidor OSU, a relação de federação, os requisitos de RCOI, o proprietário do certificado e o SSID de contingência numa única lista de verificação. Estes valores não devem constar apenas nas notas de um engenheiro.
Planeie a infraestrutura de rádio a partir do local real e, em seguida, valide a contagem de APs e o design com uma calculadora de pontos de acesso. O planeamento de capacidade expõe um design sobrecarregado antes da transição, mas não consegue corrigir um realm incompatível ou um certificado inválido.
Desative o WEP e o TKIP. Mantenha o design Passpoint em WPA2-Enterprise ou WPA3-Enterprise, excluindo os modos de segurança legados.
Configuração Específica do Fabricante para Meraki, Aruba, Ruckus, Mist e UniFi
Os padrões são partilhados, mas a experiência administrativa não. Os fabricantes expõem as mesmas primitivas em perfis diferentes, e algumas plataformas ocultam a validação atrás de configurações genéricas de WLAN. Trate a configuração abaixo como um mapa de onde procurar e, em seguida, confirme cada campo com a documentação exata da versão em utilização.
| Fabricante | Suporte Nativo Passpoint | Local de Upload do Certificado | OSU / Integração | Erro Comum |
|---|---|---|---|---|
| Meraki | Definições de Hotspot 2.0 no SSID | Área de certificados de toda a rede | Campos do fornecedor OSU no perfil do SSID | Um perfil pode parecer completo enquanto os valores de realm ou de rede de acesso permanecem inconsistentes |
| Aruba | Perfil Hotspot 2.0 associado a um SSID 802.1X | Armazenamento de certificados do controlador ou de mobilidade | Perfil e integração AAA | Os valores de realm derivados de AAA necessitam de verificação, não de suposição |
| Ruckus | Definições Passpoint na WLAN | Configuração de certificados do SmartZone | Campos de local e OSU nas definições de WLAN | O firmware de APs mais antigos pode omitir silenciosamente elementos ANQP |
| Juniper Mist | Passpoint através de templates de WLAN | Configuração de identidade e certificado da organização | Fornecedor de identidade e fluxo de trabalho de template | Um URI de OSU malformado pode criar anomalias de ANQP |
| UniFi | Suporte nativo a objetos limitado | RADIUS externo e processamento de certificados específico da plataforma | Geralmente externo ou improvisado | Soluções personalizadas são difíceis de governar como federação de produção |
Onde as implementações divergem
O Meraki é comparativamente direto para uma implementação gerida na nuvem. Ative o Hotspot 2.0 no SSID, defina o tipo de rede de acesso, o domínio, o realm e o método EAP e, em seguida, preencha as informações do fornecedor de OSU onde for necessário. Transfira o certificado através do fluxo de trabalho de certificado de rede e inspecione o anúncio ANQP resultante em vez de confiar no resumo do painel. As organizações que se padronizam no Meraki também devem analisar a gama de pontos de acesso Cisco Meraki em relação aos requisitos planeados de firmware e perfil de cliente.
A Aruba começa normalmente com uma WLAN 802.1X, um perfil Hotspot 2.0 e uma cadeia CA importada. A verificação importante é a relação entre o domínio derivado do servidor AAA e o domínio anunciado através do perfil. Os Mobility Conductors e os controladores distribuídos adicionam outro local onde a herança de configuração pode falhar.
O Ruckus SmartZone exige uma atenção redobrada ao alinhamento do firmware da WLAN e dos APs. Adicione o perfil Passpoint, o certificado assinado e os detalhes do local, e depois capture as respostas ANQP de um AP atual. Um painel que mostra as configurações ativadas não prova que um AP mais antigo está a transmitir os mesmos elementos.
O Juniper Mist foca o trabalho em modelos de WLAN e na configuração de identidade ao nível da organização. Pode ser simples quando o fornecedor de identidade e os valores OSU são válidos, mas os URIs de inscrição malformados tendem a surgir como anomalias de deteção, em vez de um erro de configuração claro.
A UniFi é o caso difícil. Sem um objeto Passpoint nativo completo, as equipas recorrem frequentemente à montagem de RADIUS externo, nomes de anfitrião personalizados e soluções parciais de políticas. Isso pode ser aceitável para experimentação, mas cria demasiados limites de propriedade para um hospital regulamentado, um grande grupo hoteleiro ou uma federação de roaming.
Realidade do fabricante: Um estado de configuração verde significa que o objeto foi aceite pelo controlador. Não prova que um cliente consiga descobrir, confiar, autenticar e fazer roaming através dele.
Certificados, RADIUS e Configuração da Camada de Identidade
Uma implementação de Passpoint pode associar-se com sucesso mas falhar na camada de identidade. Comece pela identidade do servidor que os dispositivos cliente irão validar. Gere um CSR com os nomes alternativos do requerente necessários para o domínio de serviço e o espaço de nomes de identidade. Utilize uma CA pública que já seja confiável para a população de dispositivos ou distribua uma cadeia de confiança privada através de ferramentas de gestão de dispositivos.
Importe o certificado e a cadeia intermédia na sequência exigida pelo controlador. A ausência de uma intermédia aparece frequentemente ao utilizador como uma palavra-passe incorreta. Após cada alteração de certificado, teste a partir de um dispositivo cliente real, inspecione a cadeia apresentada e correlacione o resultado com os registos de autenticação do controlador. Uma verificação no browser do laboratório não é suficiente.
Construa o caminho RADIUS
O RADIUS é o ponto de decisão de política para a identidade Passpoint, e não apenas um validador de palavras-passe. O FreeRADIUS, Cisco ISE, ClearPass e Microsoft NPS diferem no suporte EAP e na sintaxe de políticas. Registe o método selecionado, as verificações de certificados, o tratamento de realms e o mapeamento de atributos antes da implementação.
- EAP-TLS: Mapeie o assunto do certificado do cliente ou SAN para o registo do dispositivo ou utilizador, imponha a confiança do emissor e defina o tratamento de revogação.
- EAP-TTLS: Proteja a troca externa com o certificado do servidor e, em seguida, mapeie a identidade interna para o domínio e política corretos.
- EAP baseado em SIM: Confirme se a operadora ou federação fornece a validação do assinante e se o nível RADIUS a pode processar.
- Política de domínio: Certifique-se de que um valor como
@corp.example.comchega ao fornecedor de identidade pretendido sem desvios de maiúsculas/minúsculas ou de formatação.
A capacidade de RADIUS necessita de uma revisão separada. A autenticação por certificado e a faturação produzem padrões de pedido diferentes do 802.1X normal. Os picos de integração e de religação podem expor problemas de latência, filas de espera e de limite de tempo, especialmente num hotel, hospital ou estádio. Utilize servidores redundantes, meça a latência de resposta e teste o comportamento em caso de falha em vez de assumir que o escalão de WLAN de pessoal existente tem capacidade livre.
Um modelo gerido de RADIUS-as-a-Service pode reduzir a responsabilidade operacional, mas verifique o suporte para os métodos EAP necessários, controlos de política, registo de logs e ciclo de vida dos certificados antes de o escolher.
Adicione detalhes de federação deliberadamente
O OpenRoaming exige que o local, a identidade do fornecedor de serviços e os identificadores de federação coincidam no perfil, no sistema de políticas e na relação de roaming. As diretrizes de implementação e instalação de Passpoint cobrem domínios NAI, implementação de certificados e registo RCOI como tarefas de camada de identidade. Os identificadores de roaming comuns incluem o RCOI sem liquidação financeira 5A-03-BA e o RCOI legado da Cisco 00-40-96 quando é necessária uma compatibilidade mais ampla.
Depois de carregar o perfil, recarregue os componentes relevantes do controlador e inspecione as respostas de beacon e ANQP em tempo real. Confirme se o domínio anunciado, as informações do local, o RCOI e o NAI de OSU estão corretos. Verifique também se existe um Captive Portal associado ao mesmo caminho de serviço, pois este pode intercetar a integração ou entrar em conflito com um perfil que espera autenticação direta.
O ficheiro de configuração é apenas uma entrada. O pacote transmitido pelo ar é a verificação final.
Piloto, Validação e Limites de Entrada em Funcionamento
Execute o piloto como um exercício de medição. Selecione um piso, departamento ou átrio, mantenha um caminho 802.1X legado disponível e utilize um grupo fixo de dispositivos cuja propriedade e versões de sistema operativo sejam conhecidas. Inclua tanto clientes geridos por certificado como os dispositivos de visitantes que têm maior probabilidade de expor problemas de perfil e de contingência.
Antes de ativar o SSID, defina os critérios de aceitação por escrito:
- Descoberta: Cada AP de teste deve anunciar a indicação HS2.0 e os elementos ANQP necessários.
- Associação: As credenciais em cache devem associar-se em menos de três segundos durante o teste controlado.
- Autenticação: A camada RADIUS não deve apresentar tempos limites esgotados (timeouts) na procura máxima esperada.
- Alternativa: Os dispositivos que não possuem um perfil compatível devem receber uma alternativa documentada, em vez de ficarem num ciclo infinito através de um portal com falhas.
- Roaming: Teste o movimento de AP para AP em intervalos regulares e, em seguida, repita entre controladores com o domínio de mobilidade configurado.
Capture evidências em três pontos. Utilize um AP em modo de monitorização ou uma captura de pacotes equivalente para inspecionar o tráfego beacon, GAS e ANQP. Exporte os registos do RADIUS com identificadores de pedidos e atributos de resposta. Recolha registos do sistema operativo de cada dispositivo de teste, especialmente nos casos em que um fornecedor de telemóveis tem sucesso e outro recusa o mesmo perfil.
As orientações da WiFi Alliance apoiam a verificação da capacidade de AP e controladores, prontidão do RADIUS e compatibilidade EAP antes da implementação. Um guia prático especializado recomenda um piloto em 10% a 20% dos APs, com mais de 98% de sucesso na ligação e latência de autenticação inferior a 300 milissegundos como indicadores de decisão de avanço. Estes limiares devem ser testados contra a tolerância ao risco da própria organização, mas fornecem uma disciplina concreta para a expansão.
Não expanda apenas porque a primeira manhã correu bem. Mantenha o piloto a funcionar durante os períodos normais de maior movimento, reveja os registos de roaming e de falhas e, em seguida, aplique as correções documentadas no local seguinte.
Resolução de Problemas e Modos de Falha de Última Milha
As falhas mais difíceis surgem após a configuração parecer concluída. O Passpoint depende de o cliente, AP, perfil, cadeia de confiança e política RADIUS estarem em sintonia no mesmo instante. Um Captive Portal não consegue reparar uma troca de Passpoint falhada porque os SSIDs compatíveis com Passpoint não suportam redirecionamentos de portal como o seu mecanismo de autenticação.
| Modo de Falha | Sintoma | Sinal de Diagnóstico | Remediação |
|---|---|---|---|
| Incompatibilidade de realm | O cliente ignora a rede ou reverte para outro SSID | Compare o realm NAI anunciado no ANQP com o realm no pedido RADIUS | Normalize as strings de realm e os valores de perfil, incluindo maiúsculas/minúsculas e sufixos |
| Cadeia de certificação corrompida | O EAP-TLS falha apesar de um certificado de cliente válido | Os logs de RADIUS EAP mostram erros de fidedignidade ou de validação de cadeia | Reconstrua a cadeia fornecida, confirme os certificados intermédios e teste a partir do OS do cliente |
| Elementos ANQP em falta | Os dispositivos não reconhecem o SSID como uma rede Passpoint adequada | A captura de pacotes mostra ausência de indicação HS2.0 ou resposta ANQP incompleta | Verifique o firmware do AP, a herança do controlador e o beacon em direto |
| Saturação de RADIUS | A autenticação abranda ou falha durante picos de integração | Aumento da latência de pedidos, retransmissões ou profundidade da fila nos logs de RADIUS | Adicione capacidade e redundância, depois teste novamente a carga de certificados e accounting |
| Conflito de Captive Portal | Os clientes compatíveis ligam-se de forma inconsistente ou nunca concluem o acesso | A depuração do controlador mostra a política de portal associada ao SSID do Passpoint | Separe as políticas do Passpoint e do portal, com um SSID herdado explícito |
| Variação de dispositivos | Uma família de telemóveis faz roaming enquanto outra permanece associada ou recusa | Compare os logs do OS, o suporte de perfil e o processamento de RCOI por tipo de dispositivo | Mantenha uma matriz de dispositivos testados e publique instruções de recurso |
Verifique primeiro o anúncio de rádio em direto, depois o perfil do cliente, a confiança no certificado, o pedido RADIUS e a resposta de política. Esta ordem evita passar horas a alterar regras de servidor quando o AP nunca anunciou a indicação HS2.0 necessária.
As frotas mistas precisam de uma transição intencional. Mantenha o acesso legado WPA2-Enterprise ou EAP-TTLS disponível para dispositivos que não conseguem consumir o perfil Passpoint, mas não coloque lógica de portal cativo no SSID de Passpoint. O DSIT public engagement survey for 2025 to 2026 relata que 31% dos adultos utilizam dados móveis ou um hotspot em casa, enquanto 3% dependem disso como o seu método principal de acesso doméstico. Isso sugere que os utilizadores estão familiarizados com a conectividade assistida por telemóvel, mas os operadores de locais ainda precisam de uma alternativa simples para clientes cujo telemóvel, identificador de operadora ou sistema operativo não suporta o perfil pretendido de forma consistente.
Os dispositivos Apple e Android também podem interpretar as indicações de roaming de forma diferente. Teste cada família suportada, não infira a compatibilidade a partir da presença de uma configuração Passpoint. Quando uma implementação anteriormente estável falhar, compare as últimas alterações de certificado, perfil, firmware, realm e política RADIUS antes de reconstruir a WLAN.
A Purple disponibiliza o Passpoint WiFi através da sua plataforma SecurePass, utilizando a integração baseada em perfis e certificados para autenticação automática em todas as redes suportadas. Se deseja avaliar esta abordagem de camada de identidade juntamente com o seu design de AP e RADIUS existente, visite a Purple e discuta o âmbito do projeto-piloto, a combinação de dispositivos e os requisitos de contingência com a sua equipa.
