Como Configurar um Captive Portal no Starlink: Um Guia para Locais Remotos e Marítimos

Fale em inglês britânico com um tom confiante, autoritário e de conversação - como um consultor sénior a instruir um cliente. Ritmo medido, articulação clara, caloroso mas profissional. Sem palavras de preenchimento. Breves pausas ocasionais para dar ênfase: Bem-vindo ao Purple Technical Briefing. Vou guiá-lo por tudo o que precisa de saber sobre a configuração de um captive portal no Starlink - especificamente para locais remotos, operadores marítimos e qualquer pessoa que disponibilize WiFi para convidados onde a fibra simplesmente não é uma opção. [pausa média] Comecemos pelo problema. O Starlink mudou genuinamente o cenário da conectividade para locais que anteriormente estavam limitados a ligações de satélite lentas e dispendiosas ou a uma rede 4G instável. Um navio de cruzeiro, um hotel remoto nas montanhas, uma unidade de apoio a estaleiros de construção, o recinto de um festival num campo - todos estes podem agora obter 100 a 220 megabits por segundo a partir de uma antena do tamanho de uma pizza grande. Isso é notável. Mas a questão é esta: a conectividade bruta é apenas metade do trabalho. No momento em que disponibiliza essa ligação a convidados, passageiros ou tripulação, precisa de autenticação, controlo de acessos, consentimento em conformidade com o GDPR e gestão de largura de banda. O Starlink não lhe oferece nada disso de forma nativa. É aí que entra um captive portal. E é isso que vamos construir hoje. [pausa média] Secção um: compreender as restrições de rede do Starlink. Antes de tocar num router, precisa de compreender o que o Starlink realmente lhe oferece na interface WAN. A antena padrão do Starlink liga-se a um router proprietário que gere o DHCP e o NAT. Por predefinição, está atrás de um NAT de classe operadora - o que os engenheiros chamam de CGNAT. Isso significa que o seu endereço IP WAN está na gama de 100.64 a 100.127. Não é um IP público. Não pode receber ligações de entrada a partir da internet. E isso é de extrema importância para a arquitetura do captive portal. A solução é o bypass mode - por vezes chamado de bridge mode. Ative esta opção na aplicação Starlink em Definições e, em seguida, ative "Bypass Starlink WiFi router." Uma vez ativado, a antena do Starlink passa o endereço CGNAT diretamente para a porta WAN do seu router empresarial. O router Starlink deixa de fazer DHCP e NAT. O seu router assume o controlo. Continua atrás de CGNAT, mas agora tem total controlo da camada de encaminhamento. Um ponto crítico: se a antena do Starlink for reposta para as definições de fábrica por qualquer motivo, o bypass mode é desativado. Terá de o reativar. Inclua isso no manual de procedimentos do seu local. [pausa média] Atualmente, o Starlink oferece três níveis de planos relevantes para operadores de locais. O plano Standard oferece até 100 megabits de download, prioridade de melhor esforço e nenhuma opção de IP estático. O plano Business oferece até 220 megabits, atribuição de dados prioritários e um suplemento de IP estático. O plano Maritime oferece as mesmas velocidades com portabilidade global - essencial se a embarcação se mover entre regiões oceânicas. Para qualquer local com vários utilizadores, recomendo o Business ou o Maritime como requisito mínimo. Dados de melhor esforço no plano Standard significam que os seus convidados perdem prioridade sempre que a célula de satélite estiver congestionada. [pausa média] Secção dois: a stack de arquitetura. Aqui está a stack de quatro camadas que está a construir. A camada um é o uplink Starlink em modo bypass. A camada dois é o seu router ou firewall empresarial - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Fortinet - qualquer um destes funciona. A camada três é a segmentação VLAN ao nível do switch ou do ponto de acesso. A camada quatro é o captive portal na cloud, que lida com a autenticação, consentimento e analítica. Permita-me focar um momento na segmentação VLAN porque esta é inegociável. Precisa, no mínimo, de três VLANs. VLAN 10 para funcionários - esta transporta os seus sistemas POS, aplicações de back-office e tráfego de gestão. VLAN 20 para convidados - este é o segmento exclusivo de internet que acede ao captive portal. VLAN 30 para IoT - câmaras, termostatos inteligentes, sistemas de gestão de edifícios. Estas três redes não devem conseguir comunicar entre si. O encaminhamento inter-VLAN deve ser bloqueado na firewall. Um convidado na VLAN 20 nunca deve conseguir aceder ao seu terminal POS na VLAN 10. Isto não é apenas uma boa prática - é um requisito PCI-DSS se estiver a processar pagamentos com cartão em qualquer parte da mesma infraestrutura física. [medium pause] O próprio captive portal reside na cloud. Quando um convidado se liga ao seu SSID de convidados e abre um browser, o router intercepta o pedido HTTP e redireciona-o para a página de login do portal. O convidado autentica-se - via e-mail, login social ou um código de voucher - aceita os seus termos de serviço, e o portal sinaliza ao router para conceder acesso à internet a esse endereço MAC. Todo o fluxo deve ser concluído em menos de 10 segundos num dispositivo móvel. Com a Purple, esse portal de cloud integra-se diretamente com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Configura a integração RADIUS ou API uma vez, e a Purple lida com o handshake de autenticação. Não é necessário nenhum servidor de autenticação no local. Isto é fundamental para locais remotos onde não é possível executar um servidor RADIUS local. [medium pause] Secção três: o problema do CGNAT e como o resolver. Aqui está o desafio que apanha a maioria das equipas de TI de surpresa. As arquiteturas padrão de captive portal assumem que o portal na cloud consegue aceder de volta à sua rede. Com o CGNAT, isso é impossível. As ligações de entrada são bloqueadas. A solução é um túnel reverso. O seu router estabelece uma ligação de saída para o portal na cloud e mantém-na aberta persistentemente. Todo o tráfego de autenticação flui através desse túnel. A cloud nunca precisa de iniciar uma ligação de entrada. A arquitetura de overlay em cloud da Purple lida com isto de forma nativa - não necessita de configurar o WireGuard ou o OpenVPN manualmente, embora ambos sejam alternativas válidas se estiver a executar a sua própria infraestrutura.Se de facto precisar de um IP estático - por exemplo, se estiver a executar um servidor RADIUS no local ou se necessitar de uma lista de permissões de IP consistente - o Starlink Business e o Maritime oferecem um IP estático como um suplemento. À data desta gravação, isso está disponível na maioria das regiões. Verifique as páginas dos planos atuais da Starlink para o seu território específico. [medium pause] Secção quatro: GDPR e conformidade de dados. É aqui que os espaços remotos e marítimos são frequentemente apanhados de surpresa. O facto de o seu espaço se encontrar numa embarcação em águas internacionais, ou num local remoto, não o isenta do GDPR se estiver a recolher dados de residentes da UE. E se estiver a operar em águas do Reino Unido pós-Brexit, o UK GDPR aplica-se. O seu Captive Portal deve apresentar uma caixa de seleção de consentimento específica e não assinalada para comunicações de marketing. Deve indicar claramente quais os dados que está a recolher, porquê e durante quanto tempo os irá reter. Os termos de serviço devem estar acessíveis antes de o convidado se autenticar. E deve ser capaz de demonstrar, a pedido, que um indivíduo específico deu consentimento numa data e hora específicas. O Purple possui certificação ISO 27001, está em conformidade com o GDPR, em conformidade com a CCPA e possui certificação Cyber Essentials. Cada evento de início de sessão é registado com uma marca de tempo, endereço IP e registo de consentimento. Esse registo de auditoria é o que o protege caso um regulador faça perguntas. [medium pause] Secção cinco: gestão de largura de banda. No Starlink, a largura de banda é o seu recurso mais limitado. Um único passageiro a transmitir vídeo em 4K pode consumir 25 megabits por segundo continuamente. Numa embarcação com 50 passageiros e uma ligação de 220 megabits, isto representa uma única pessoa a consumir 11% da capacidade total. Pode resolver isto ao nível do Captive Portal e do router. Defina limites de largura de banda por dispositivo - por exemplo, 5 megabits de download e 2 megabits de upload por dispositivo de convidado. Implemente políticas de utilização responsável que limitem a velocidade após um limite diário de dados. Utilize a modelação de tráfego para priorizar a navegação na web e as mensagens em detrimento da transmissão de vídeo. E considere o acesso em níveis: um nível gratuito para conectividade básica e um nível premium pago para transmissão. Isso converte o seu WiFi de uma linha de custos num fluxo de receita. [medium pause] Agora deixe-me apresentar-lhe dois cenários do mundo real. Cenário um: um navio de cruzeiro de 120 cabines. O operador utiliza o Starlink Maritime a 220 megabits. Implementa pontos de acesso Cisco Meraki em todo o navio com três VLANs - tripulação, passageiros e sistemas do navio. O Captive Portal do Purple trata da autenticação dos passageiros através de e-mail ou de uma pesquisa de número de cabine integrada com o PMS. Cada passageiro recebe um limite diário de 2 gigabytes. Os passageiros do nível premium recebem 10 gigabytes. O portal recolhe dados de e-mail primários para marketing pós-viagem. Resultado: a receita do WiFi cobre o custo da assinatura do Starlink e o operador obtém uma lista de marketing direto em crescimento. Cenário dois: um hotel remoto nas Highlands sem fibra. Utilizam Starlink Business a uma média de 150 megabits. Os pontos de acesso HPE Aruba cobrem o edifício principal e três anexos. Os hóspedes autenticam-se por e-mail no portal da Purple. O hotel utiliza as análises da Purple para compreender as horas de pico de utilização e ajusta as políticas de largura de banda em conformidade. Reduziram as reclamações sobre o WiFi de hóspedes em 60% em comparação com a sua configuração anterior de agregação 4G, de acordo com os seus próprios dados operacionais. [medium pause] Erros comuns. Deixe-me apresentar os cinco que vejo com mais frequência. Um: esquecer de reativar o modo bypass após uma reposição da antena. Documente isto no seu manual de procedimentos e configure um alerta de monitorização na interface WAN do seu router. Dois: não bloquear o encaminhamento inter-VLAN. Todas as implementações que analisei e que tiveram um incidente de segurança tinham isto mal configurado. Verifique duas vezes. Três: utilizar o redirecionamento HTTP para o captive portal numa rede onde os hóspedes utilizam navegadores HTTPS-first. Os navegadores modernos utilizam HTTPS por predefinição. O seu router precisa de processar a interceção HTTPS corretamente ou os hóspedes verão erros de certificado antes de chegarem ao portal. O portal da Purple lida com isto, mas a configuração do seu router precisa de estar correta. Quatro: não testar em iOS e Android separadamente. O Captive Network Assistant da Apple e a sonda de rede do Android comportam-se de forma diferente. Teste ambos antes do lançamento. Cinco: ignorar a latência. A constelação LEO da Starlink proporciona uma latência de 20 a 40 milissegundos - muito melhor do que o satélite geoestacionário tradicional. Mas durante as transições entre satélites, podem ocorrer picos breves. As definições de tempo limite do seu captive portal precisam de ter isto em conta. Defina os intervalos de session keepalive para 60 segundos ou menos. [medium pause] Perguntas rápidas. Preciso de um IP estático para um captive portal na Starlink? Não, se o seu portal utilizar uma arquitetura alojada na nuvem com túnel reverso. Sim, se estiver a executar RADIUS local. Posso executar múltiplos SSIDs na Starlink? Sim - os seus pontos de acesso empresariais tratam da criação de SSIDs. A Starlink em modo bypass apenas fornece a ligação ascendente. Pode executar tantos SSIDs quantos os suportados pelos seus pontos de acesso. A Purple funciona com a Starlink diretamente de origem? Sim. Configura o modo bypass na antena da Starlink, liga os seus pontos de acesso suportados e aponta a integração RADIUS ou API para a nuvem da Purple. O portal fica ativo no espaço de uma hora. O que acontece se a ligação Starlink cair? O portal da Purple armazena em cache as sessões ativas localmente no router por um período configurável - normalmente 24 horas. Os hóspedes que já estão autenticados permanecem online. As novas autenticações ficam em fila de espera até que a conectividade seja restabelecida. [medium pause] Para resumir. A Starlink fornece-lhe o canal. O seu router empresarial em modo bypass dá-lhe o controlo da camada de encaminhamento. A segmentação de VLAN isola o tráfego de convidados, funcionários e IoT. Um Captive Portal na nuvem - o da Purple, neste caso - lida com a autenticação, o consentimento do GDPR, a política de largura de banda e a recolha de dados primários. A restrição de CGNAT é resolvida através de uma arquitetura de túnel reverso, e não por IP estático. E a gestão da largura de banda ao nível do portal é o que mantém a sua ligação Starlink utilizável para todos. Se está a avaliar isto para o seu espaço, o próximo passo é verificar qual o hardware de ponto de acesso que está a utilizar - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks ou Fortinet - e confirmar a documentação de integração da Purple para essa plataforma. Pode encontrar o guia técnico completo em purple.ai, e a equipa da Purple pode orientá-lo através de uma configuração de prova de conceito para o seu site específico. Obrigado por ouvir. Vemo-nos no próximo briefing.