Ich versuche, ein Authentifizierungssystem für WLAN zu Hause einzurichten, das unabhängig davon ist, welcher Access Point/Router verwendet wird. Dieses Authentifizierungssystem wird sich eng am Captive-Portal-Modell orientieren, aber ich glaube nicht, dass die Details des (benutzerdefinierten) Captive-Portals wichtig sind.
Um dies zu erreichen, möchte ich das Captive Portal und die Authentifizierung auf einem kostengünstigen Gerät (wie einem Raspberry Pi) hosten. Nachdem sie sich jedoch authentifiziert haben, möchte ich, dass die Benutzer erneut mit einem anderen Zugangspunkt verbunden werden. Das heißt, der Raspberry Pi würdenurführt den Authentifizierungsschritt aus, fungiert aber nicht als normaler Zugriffspunkt für authentifizierte Benutzer. Auch hier gilt, dass dies optimalerweise mit jedem Zugriffspunkt/Router funktionieren würde, der über ein normales, passwortgeschütztes WLAN-Netzwerk verfügt.
Hier ist der gewünschte Anmeldeablauf für dieses Projekt:
- Der Benutzer stellt eine Verbindung zum WLAN-fähigen Raspberry Pi her
- Der Benutzer wird zu einer Captive-Portal-Site weitergeleitet, die auf dem Pi gehostet wird, und meldet sich an
- (Vorausgesetzt, die Authentifizierung ist erfolgreich) Der Benutzer wird vom Pi getrennt und mit dem Hauptzugangspunkt verbunden.
- Der Benutzer kann nun wie gewohnt im Internet surfen
Gibt es Methoden, um so etwas zu erreichen? Ich weiß, wie man einen Raspberry Pi so einrichtet, dass er alsbeideder Access Point und das Captive Portal, aber nicht nur als Captive Portal.
Antwort1
Dies kann nicht wirklich auf sichere Art und Weise durchgeführt werden, obwohl es mit einer Anordnung vom Typ „Rube Goldberg“ möglich sein könnte.
Ich schätze, dass man das – grob gesagt – dadurch machen könnte, dass man einen DHCP-Router auf dem PI anpasst, eine kurze Leasingdauer bis zur Freigabe bereitstellt und die ausgegebene IP-Adresse ändert (und DHCP auf dem Router nicht aktiviert). Dann wäre es allerdings ein großer Kampf, sicherzustellen, dass dies nicht mit einer einfachen statischen Adressierung umgangen werden kann.
Möglicherweise können Sie weitgehend etwas Ähnliches erreichen, indem Sie mit dem Router zusammenarbeiten, um Port-DNS (Port 53-Anfragen) auf das WAN von jedem anderen Gerät als dem Captive Portal aus zu untersagen – und indem Sie den DNS des Captive Portals mit DHCP verteilen und das Captive Portal DNS-Antworten für sich selbst bereitstellen lassen, bis der Benutzer freigegeben wird. Dies könnte jedoch mit einem einfachen VPN oder Tunnel umgangen werden.
Es ist viel schwieriger, als es aussieht (etwas, womit ich in meiner Freizeit spiele – also nicht viel!), aber abhängig von Ihrem Router, würde etwas wie „Wild Dog“ – das in moderne Versionen von DD-WRT integriert ist – für Sie funktionieren? Es scheint, dass der Router die zugrunde liegende Erfassung durchführt und die Portalarbeit an ein anderes Gerät übergibt.
Antwort2
Da OpenBSD auf Raspberry Pi läuft, können Sie authpf verwenden, damit jeder Benutzer seine Sitzung mit öffentlichem Schlüssel/Passwort authentifizieren kann und diese authentifizierten Clients die Firewall passieren können. Am besten funktioniert es jedoch direkt auf dem Router, der für die Filterung zuständig ist. Siehehttps://www.openbsd.org/faq/pf/authpf.html, und googeln Sie nach Implementierungsbeispielen.
Eine benutzerfreundlichere Option ist so etwas wiehttps://coova.github.io/CoovaChilli/ Es scheint aktiv gepflegt zu werden und verfügt über RADIUS-Unterstützung.
Antwort3
Auch hier gilt, dass dies optimalerweise mit jedem Access Point/Router funktioniert.
Access Points kümmern sich um WLAN (Verbindungsschicht), Router kümmern sich um IP (Netzwerkschicht). Obwohl sie oft in einer einzigen Kunststoffbox zusammengefasst sind, erfüllen sie dennoch zwei unterschiedliche Funktionen.
Die Idee hinter Captive Portals besteht darin, dass ein Gerät entlang des regulären Paketpfads diese abfängt und eine gefälschte „Umleitungs“-Antwort generiert, die dem Benutzer mitteilt, dass er die Anmeldeseite besuchen muss. Die Umleitung könnte folgendermaßen erfolgen:
- das Standard-Gateway (Router), indem die gesamte TCP-Verbindung mit iptables abgefangen wird (die gängigste Methode);
- der DNS-Server, indem er gefälschte DNS-Lookup-Antworten zurücksendet, die auf den „Captive“-Server verweisen (unzuverlässig und sehr leicht zu umgehen);
- den Access Point oder Switch, indem die Paketheader so umgeschrieben werden, dass das Paket ein anderes Gateway erreicht (sehr seltenaber technisch möglich)…
In jedem Fall aber Ihr "Captive Portal" Raspberryhatin den regulären Pfad eingefügt werden. Selbst wenn Sie es mit der Methode „Fake-DNS-Server“ erstellen (die sehr wenig Datenverkehr verarbeitet, aber auch sehr leicht zu umgehen ist),mindestensSie müssten den Hauptrouter neu konfigurieren, um die IP-Adresse Ihres Raspberry über DHCP bereitzustellen.
(Und viele billige WLAN-Router erlauben es Ihnen nicht,konfigurierendas – ich schätze, Sie müssten den normalen DHCP-Dienst abschalten und DHCP auch vollständig vom Raspberry aus bereitstellen.)
Kurz gesagt: Nein, ich glaube nicht, dass ein „Plug-and-Play“-Captive-Portal-Gerät auf diese Weise implementiert werden kann.
Tatsächlich gibt es aus Sicherheitsgründen große Probleme. Wenn eswarEs ist möglich, dass ein Raspberry Pi einfach eine Verbindung herstellt und irgendwie den gesamten Datenverkehr abfängt, ohne dass eine Routerkonfiguration erforderlich ist. Dann wäre es auch für jeden betrügerischen Client mit Malware möglich, einfach eine Verbindung herzustellen und den gesamten Datenverkehr abzufangen.