Estou tentando configurar um sistema de autenticação para WiFi doméstico que seja independente de qual ponto de acesso/roteador está sendo usado. Este sistema de autenticação seguirá de perto o modelo de portal cativo, mas não acredito que os detalhes do portal cativo (personalizado) sejam importantes.
Para conseguir isso, gostaria de hospedar o portal cativo e a autenticação em um dispositivo barato (como um Raspberry Pi). No entanto, depois de se autenticarem, gostaria que os usuários se reconectassem a um ponto de acesso diferente. Ou seja, o Raspberry Piapenasexecutaria a etapa de autenticação, mas não atuaria como ponto de acesso de uso normal para usuários autenticados. Novamente, isso funcionaria idealmente com qualquer ponto de acesso/roteador que tenha uma rede WiFi normal protegida por senha.
Aqui está o fluxo de login desejado para este projeto:
- O usuário se conecta ao Raspberry Pi habilitado para WiFi
- O usuário é direcionado para um site de portal cativo hospedado no Pi e faz login
- (Assumindo que a autenticação foi bem-sucedida) O usuário está desconectado do Pi e conectado ao ponto de acesso principal
- 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 comoamboso ponto de acesso e o portal cativo, mas não apenas como portal cativo.
Responder1
Não é realmente viável fazer isso com segurança, embora possa ser possível usar um arranjo do tipo 'Rube Goldberg'.
Eu acho que isso poderia ser feito - grosseiramente - personalizando um roteador DHCP no PI e fornecendo um curto tempo de concessão até o lançamento - e modificando o endereço IP distribuído (e não habilitando o DHCP no roteador) - mas então você teria um enorme batalha para garantir que isso não possa ser contornado com algum endereçamento estático simples.
Você pode conseguir algo semelhante com a cooperação do roteador para proibir o DNS da porta (solicitações da porta 53) na WAN a partir de qualquer dispositivo que não seja o portal cativo - e distribuir o DNS do portal cativo com DHCP, e ter o portal cativo fornece respostas DNS para si mesmo até que o usuário seja liberado. No entanto, isso poderia ser subvertido com uma simples VPN ou túnel.
É muito mais difícil do que parece (algo com o qual estou brincando no meu tempo livre - então não muito!), mas dependendo do seu roteador, seria algo como "Wild Dog" - que está integrado nas versões modernas do DD-WRT - funciona para você - parece que o roteador faz a captura subjacente e transfere o trabalho do portal para outro dispositivo.
Responder2
Dado que o OpenBSD é executado no Raspberry Pi, você pode usar o authpf para permitir que cada usuário autentique sua sessão com pubkey/senha e permitir que esses clientes autenticados passem pelo firewall - no entanto, ele realmente funciona melhor diretamente no roteador responsável pela filtragem. Verhttps://www.openbsd.org/faq/pf/authpf.htmle google para obter exemplos de implementações.
Uma opção mais amigável é algo comohttps://coova.github.io/CoovaChilli/ Parece ser mantido ativamente e tem suporte RADIUS.
Responder3
Novamente, idealmente isso funcionaria com qualquer ponto de acesso/roteador
Os pontos de acesso lidam com Wi-Fi (camada de link), os roteadores lidam com IP (camada de rede). Embora muitas vezes sejam combinados em uma única caixa de plástico, eles ainda desempenham duas funções distintas.
Portanto, a ideia dos portais cativos é que um dispositivo ao longo do caminho regular dos pacotes os intercepte e gere uma resposta falsa de “redirecionamento”, que informa ao usuário que ele deve visitar a página de login. O redirecionamento pode ser feito por:
- o gateway padrão (roteador), interceptando toda a conexão TCP usando iptables (o método mais comum);
- o servidor DNS, retornando respostas falsas de pesquisa de DNS que apontam para o servidor "cativo" (não confiável e muito fácil de contornar);
- ponto de acesso ou switch, reescrevendo os cabeçalhos dos pacotes para que o pacote chegue a um gateway diferente (muito raromas tecnicamente possível)…
Em qualquer caso, porém, o seu "portal cativo" Raspberrytema ser inserido no caminho regular. 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 de ignorar),no mínimovocê precisaria reconfigurar o roteador principal para fornecer o endereço IP do Raspberry via DHCP.
(E muitos roteadores sem fio baratos não permitem que vocêconfigurarisso - acho que você teria que desligar o serviço DHCP normal e servir o DHCP inteiramente a partir do Raspberry também.)
Resumindo, não, não acredito que seja possível implementar um dispositivo de portal cativo "plug and play" dessa maneira.
Na verdade, tem grandes problemas do ponto de vista da segurança. Se issoerampossí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 não autorizado com malware simplesmente se conectar e interceptar o tráfego de todos.