Portal cativo em dispositivo separado do ponto de acesso

Question

Estou tentando configurar um sistema de autenticação para WiFi doméstico que seja agnóstico sobre o ponto de acesso / roteador que está sendo usado. Esse sistema de autenticação seguirá de perto o modelo do portal cativo, mas não acredito que os detalhes do portal cativo (personalizado) sejam importantes.

Para conseguir isso, eu gostaria de hospedar o portal cativo e autenticação em um dispositivo barato (como um Raspberry Pi). No entanto, depois de se autenticarem, gostaria que os usuários fossem reconectados a um ponto de acesso diferente. Ou seja, o Raspberry Pi só executaria a etapa de autenticação, mas não atuaria como o ponto de acesso de uso normal para usuários autenticados. Novamente, otimamente isso funcionaria com qualquer ponto de acesso / roteador que tenha uma rede WiFi protegida por senha normal.

Aqui está o fluxo de login desejado para este projeto:

1. O usuário se conecta ao Raspberry Pi habilitado para Wi-Fi
2. O usuário é direcionado para um site de portal cativo hospedado no Pi e efetua login
3. (Supondo que a autenticação seja bem-sucedida) O usuário está desconectado do Pi e conectado ao ponto de acesso principal
4. O usuário agora pode navegar na web normalmente

Existem métodos para realizar esse tipo de coisa? Estou ciente de como configurar um Raspberry Pi para atuar como ambos o ponto de acesso e o portal cativo, mas não apenas como o portal cativo.

    

Answer 1

Isso não é realmente viável para fazer isso com segurança, embora possa ser possível usando um arranjo do tipo 'Rube Goldberg'.

Acho que isso poderia ser feito - de forma grosseira - personalizando um roteador DHCP no PI e fornecendo um curto período de concessão até que seja liberado - e modificando o endereço IP fornecido (e não habilitando o DHCP no roteador) - mas ter uma batalha enorme, garantindo que isso não seja contornado com um simples endereçamento estático.

Você pode conseguir, em grande parte, algo semelhante com a cooperação do roteador para impedir o DNS (solicitações de porta 53) da porta na WAN de qualquer dispositivo diferente do portal cativo - e distribuir o DNS do portal cativo com o DHCP e faça com que o portal cativo forneça respostas de DNS para si mesmo até que o usuário seja liberado. Isso poderia ser subvertido com uma simples VPN ou túnel.

É muito mais difícil do que parece (algo com que estou jogando no meu tempo livre - então não muito!), mas dependendo do seu roteador, algo como "Wild Dog" - que é construído em versões modernas de DD-WRT - trabalhe para você - parece que o roteador faz a captura subjacente e transfere o trabalho do portal para outro dispositivo.

    

Answer 2

Dado que o OpenBSD roda em Raspberry Pi, você pode usar o authpf para permitir que cada usuário autentique sua sessão com o pubkey / password e deixe que esses clientes autenticados passem pelo firewall - ele realmente funciona melhor diretamente no roteador responsável pela filtragem Contudo. Consulte o link e o Google para obter exemplos de implementações.

Mais opções de fácil utilização é algo como link Parece ser ativamente mantido e tem suporte RADIUS.

    

Answer 3

Again, optimally this would work with any access point/router

Os pontos de acesso lidam com o Wi-Fi (camada de link), os roteadores manipulam o IP (camada de rede). Embora sejam frequentemente combinados em uma única caixa de plástico, eles ainda executam duas funções distintas.

Assim, a ideia dos portais cativos é que um dispositivo ao longo do caminho normal dos pacotes os intercepte e gere uma falsa resposta de "redirecionamento", que informa ao usuário que eles precisam visitar a página de login. O redirecionamento pode ser feito por:

• o gateway padrão (roteador), interceptando toda a conexão TCP usando o iptables (o método mais comum);
• o servidor DNS, retornando falsas respostas de pesquisa de DNS que apontam para o servidor "cativo" (não confiável e muito fácil de contornar);
• o ponto de acesso ou switch, reescrevendo cabeçalhos de pacote para que o pacote atinja um gateway diferente ( muito raro mas tecnicamente possível)…

Em qualquer caso, no entanto, o seu "portal cativo" Raspberry tem para ser inserido no caminho normal. Mesmo se você construí-lo usando o método "servidor DNS falso" (que lida com muito pouco tráfego, mas também é muito fácil ignorar), no mínimo você precisaria reconfigurar o roteador principal para fornecer o seu Raspberry Endereço IP via DHCP.

(E muitos roteadores sem fio baratos na verdade não permitem que você configure isso - eu acho que você teria que desligar o serviço DHCP regular e servir o DHCP inteiramente do Raspberry também. )

Então, em suma, não, eu não acredito que um dispositivo de portal cativo "plug and play" seja possível de implementar dessa maneira.

Na verdade, tem grandes problemas do ponto de vista da segurança. Se fosse possível para um Raspberry Pi simplesmente se conectar e de alguma forma interceptar o tráfego de todos, sem configuração de roteador ... então também seria possível para qualquer cliente desonesto com malware simplesmente conectar e interceptar o tráfego de todos .