Captive-Portal auf separatem Gerät vom Zugangspunkt

702
phepp

Ich versuche, ein Authentifizierungssystem für WLAN zu Hause einzurichten, das keine Ahnung davon hat, welcher Zugangspunkt / Router verwendet wird. Dieses Authentifizierungssystem folgt dem Modell des Captive-Portals, 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 preiswerten Gerät (wie einem Raspberry Pi) hosten. Nachdem sie sich jedoch authentifiziert haben, möchte ich, dass die Benutzer wieder mit einem anderen Zugangspunkt verbunden werden. Das heißt, der Raspberry Pi führt nur den Authentifizierungsschritt aus, fungiert jedoch nicht als normal genutzter Zugangspunkt für authentifizierte Benutzer. Optimalerweise würde dies mit jedem Access Point / Router funktionieren, der über ein normales, passwortgeschütztes WLAN-Netzwerk verfügt.

Hier ist der gewünschte Login-Fluss für dieses Projekt:

  1. Der Benutzer stellt eine Verbindung zum WiFi-fähigen Raspberry Pi her
  2. Der Benutzer wird zu einer auf dem Pi gehosteten Captive-Portal-Site geleitet und meldet sich an
  3. (Vorausgesetzt, die Authentifizierung ist erfolgreich) Der Benutzer ist vom Pi getrennt und mit dem Hauptzugangspunkt verbunden
  4. Benutzer können jetzt wie gewohnt im Internet surfen

Gibt es Methoden, um so etwas zu erreichen? Ich bin mir bewusst, wie ein Raspberry Pi einzurichten, um als sowohl die Access Point und Captive Portal, aber nicht nur als Captive Portal.

3

3 Antworten auf die Frage

1
davidgo

Dies ist nicht wirklich möglich, um dies sicher durchzuführen, obwohl es möglich ist, eine Anordnung vom Typ "Rube Goldberg" zu verwenden.

Ich denke, es könnte - grob - durch Anpassen eines DHCP-Routers auf dem PI und eine kurze Lease-Zeit bis zur Freigabe und Änderung der übergebenen IP-Adresse (und nicht das Aktivieren von DHCP auf dem Router) geschehen -, aber dann hätten Sie eine riesige Kampf, der sicherstellt, dass dies mit einer einfachen statischen Adressierung nicht umgangen werden kann.

Möglicherweise können Sie weitgehend etwas Ähnliches mit der Zusammenarbeit des Routers erreichen, um Port-DNS (Port 53-Anfragen) auf das WAN von einem anderen Gerät als dem Captive-Portal zu verbieten - und das Captive-Portal-DNS mit DHCP auszugeben und haben Das Captive-Portal stellt selbst DNS-Antworten bereit, bis der Benutzer freigegeben wird. Dies kann jedoch mit einem einfachen VPN oder Tunnel unterlaufen werden.

Es ist viel schwieriger als es aussieht (Etwas, mit dem ich in meiner Freizeit spiele - also nicht viel!), Aber abhängig von Ihrem Router würde es etwas wie "Wild Dog" geben, das in moderne Versionen von DD-WRT eingebaut ist - Arbeit für Sie - es scheint, dass der Router die zugrunde liegende Erfassung durchführt und die Portalarbeit an ein anderes Gerät übergibt.

Leider sieht es nicht so aus, als ob mein Router DD-WRT unterstützt. Korrigieren Sie mich, wenn ich falsch liege, aber es scheint, als sei die Übergabe die größte Hürde, die auf Ihrer Antwort basiert. Ich bin nicht dagegen, dass die "Übergabe" manuell vom Kunden durchgeführt wird. Im Wesentlichen ist die Fähigkeit, nach der ich hier suche, die Möglichkeit, dem Benutzer Zugriff auf den Hauptrouter zu gewähren, nachdem er ein benutzerdefiniertes Captive-Portal routerunabhängig passiert hat. Das heißt, ich bin damit einverstanden, dass der Benutzer die manuelle Verbindung mit dem Pi und die erneute Verbindung zum Router erzwingt, sofern kein gemeinsames Geheimnis erforderlich ist. phepp vor 6 Jahren 0
Ich verstehe, was Sie versuchen (aber nicht den Anwendungsfall) und höre höflich darauf hin, dass es keinen Sinn macht. Aufgrund Ihrer Netzwerkebene ist es wahrscheinlich die beste Lösung, einen Router mit einem zweiten Portal hinter Ihrem Hauptrouter zu installieren. davidgo vor 6 Jahren 1
0
user2497

Da OpenBSD auf Raspberry Pi ausgeführt wird, können Sie mit authpf jedem Benutzer die Sitzung mit pubkey / password authentifizieren und solche authentifizierten Clients die Firewall passieren lassen. Dies funktioniert jedoch am besten direkt auf dem für die Filterung zuständigen Router. Siehe https://www.openbsd.org/faq/pf/authpf.html und google für Beispiele für Implementierungen.

Eine benutzerfreundlichere Option ist so etwas wie https://coova.github.io/CoovaChilli/ Es scheint aktiv gewartet zu werden und RADIUS-Unterstützung zu bieten .

0
grawity

Optimalerweise würde dies mit jedem Access Point / Router funktionieren

Access Points sind für Wi-Fi (Link Layer) und Router für IP (Network Layer) zuständig. Obwohl sie häufig in einer einzigen Kunststoffbox zusammengefasst sind, erfüllen sie immer noch zwei verschiedene Funktionen.

Die Idee von Captive-Portalen ist also, dass ein Gerät entlang des regulären Pfads der Pakete diese abfängt und eine gefälschte "Weiterleitungsantwort" generiert, die dem Benutzer mitteilt, dass er die Anmeldeseite besuchen muss. Die Umleitung kann durchgeführt werden durch:

  • das Standard-Gateway (Router), indem die gesamte TCP-Verbindung mit iptables abgefangen wird (die häufigste Methode);
  • der DNS-Server durch Rückgabe gefälschter DNS-Lookup-Antworten, die auf den "Captive" -Server verweisen (unzuverlässig und sehr leicht zu umgehen);
  • den Access Point oder Switch, indem Paketheader neu geschrieben werden, sodass das Paket ein anderes Gateway erreicht ( sehr selten, aber technisch möglich)…

Auf jeden Fall aber Ihre „Captive Portal“ Raspberry hat in den regulären Weg eingefügt werden. Selbst wenn Sie es mit der "gefälschten DNS-Server" -Methode erstellen (die sehr wenig Datenverkehr abwickelt, aber auch sehr einfach umgangen werden kann), müssten Sie mindestens den Hauptrouter neu konfigurieren, um die IP-Adresse Ihres Raspberry über DHCP bereitzustellen.

(Und bei vielen billigen WLAN-Routern können Sie das nicht wirklich konfigurieren - ich denke, Sie müssten den regulären DHCP-Dienst ausschalten und DHCP vollständig vom Raspberry aus bereitstellen.)

Kurz gesagt, nein, ich glaube nicht, dass ein "Plug and Play" -Portiv-Gerät auf diese Weise implementiert werden kann.

Aus sicherheitstechnischer Sicht gibt es tatsächlich große Probleme. Wenn es ist möglich, dass ein Raspberry Pi einfach zu verbinden und irgendwie abfangen jeden Verkehr, ohne Router - Konfiguration ... dann wäre es auch möglich sein, für jede Rogue Client mit Malware einfach zu verbinden und jeden Verkehr abfangen.

Verwandte Probleme