Wie funktionieren Captive-Portal-Netzwerkverbindungen?

Der Internetzugang in Hotels und Flughafencafés wird häufig von einem Captive-Portal gesteuert, das Sie bei der ersten Verwendung zu einer bestimmten Webseite zwingt, z. B. einer Zahlungsseite oder einer Seite, auf der Sie Nutzungsbedingungen oder eine Authentifizierungs- / Autorisierungsseite akzeptieren. Sie sehen dies sowohl bei drahtlosen als auch bei kabelgebundenen Verbindungen.

Wie funktioniert das?

Es variiert sicherlich je nach Anbieter des drahtlosen Produkts, aber meiner Erfahrung nach funktioniert es normalerweise ungefähr so:

1. Ihr Laptop stellt eine drahtlose Verbindung zu einem intelligenten Zugangspunkt her, der möglicherweise mit einer zentralen Verwaltungsstation verbunden ist.
2. Ihre erste Webanforderung wird abgefangen und mit einem Location:Header beantwortet, der Sie zu einer Anmelde- / Richtlinienseite (z . B. http://hotelwireless.net/login ) weiterleitet . Dies kann direkt auf dem intelligenten Zugangspunkt oder auf einer zentralen Verwaltungsstation erfolgen.
3. Sobald Sie die Authentifizierung abgeschlossen haben, wird Ihre MAC-Adresse zu einer Liste zulässiger Clients hinzugefügt, wodurch zukünftige Anforderungen korrekt an das Internet weitergeleitet werden oder auf Intranet-Ressourcen zugegriffen werden kann.

Ich habe gehört, dass es am häufigsten als "Captive Portal" oder "Wireless Access Portal" bezeichnet wird.

Um die Umleitung zu erreichen, benötigen Sie zunächst einen Inline-Authentifikator (Access Controller). Im Kontext Ihres Themas benötigen Sie einen Wireless Lan Controller, wenn Sie sich für die zentrale Verwaltung von AP entscheiden. ODER Sie können auch einen Netzwerkzugriffscontroller mit Captive-Portal und Wall Garden-Funktionen platzieren.

NAS überwacht den in den Downlink (Client-Seite) eintretenden Datenverkehr über den Raw-Socket im Promiscuous-Modus. Wenn der vom Browser initiierte Datenverkehr für einen nicht authentifizierten Client erkannt wird, wird ihm als Antwort eine HTTP-Umleitung zugewiesen. So wird der Browser beim Empfang auf unsere CAPTIVE-Portal-Homepage umgeleitet, die inline auf dem Authentifikator oder out-of-box auf einem externen Webserver gehostet werden kann.

Die einzige Aufgabe dieser Seite besteht darin, dem Benutzer eine Benutzeroberfläche zur Eingabe von Anmeldeinformationen bereitzustellen. Die eingegebenen Anmeldeinformationen werden wie Chili im Falle von Coova-Chili an den Authentifizierungs-Daemon zurückgeleitet. Anschließend werden diese Anmeldeinformationen als Radiusanforderung an den RADIUS-Server übergeben oder können lokal überprüft werden. Nach erfolgreicher Authentifizierung wird der Status des Clients am Authentifikator als autorisiert markiert und dem Client wird Zugriff gewährt.

Wie die Umleitung erreicht wird

Der am weitesten verbreitete Ansatz besteht darin, die vom Benutzer initiierte HTTP-Anforderung und den 302-Code als Antwort auf den Client abzufangen. Bei Chili erfolgt dies über die unten stehende Funktion

http_redirect2() {

cat < <  EOF
HTTP/1.1 302 Redirect 

Location: $1

Set-Cookie: PORTAL_SESSIONID=$PORTAL_SESSIONID

Set-Cookie: COOVA_USERURL=$COOVA_USERURL

Connection: close

EOF
    exit

}

Diese Umleitung kann leicht durch eine pragmatisch gesteuerte Tun-Tap-Schnittstelle zur clientseitigen Schnittstelle erreicht werden, die den Client-Verkehr abfängt. Eine weitere Umleitung kann auch über eine DNS-Vergiftung erreicht werden, kann jedoch manchmal zu Problemen führen, wenn die Antworten im Client-Browser zwischengespeichert wurden. Weitere Dinge können spezifischer entsprechend der Problemdomäne getan werden. Ich kann Ihnen dabei helfen, wenn Sie wollen.

Eine ausführliche Beschreibung hierzu finden Sie unter https://www.arubanetworks.com/vrd/GuestAccessAppNote/wwhelp/wwhimpl/js/html/wwhelp.htm .

Hier ist ein Teil davon:

Captive Portal-Authentifizierungsprozess

Das Captive-Portal ist eine Layer 3-Authentifizierung, bei der die Geräte eine Verbindung zum Netzwerk herstellen und eine IP-Adresse und zugehörige DNS-Informationen erhalten müssen, bevor sie sich über das Captive-Portal authentifizieren. In den folgenden Schritten wird der gesamte Prozess des Captive-Portals erläutert, wenn das native ArubaOS für die Authentifizierung des Captive-Portals verwendet wird:

1. Dem Gerät, das der Gast-SSID zugeordnet ist, wird eine Anfangsrolle zugewiesen (Gastanmelderolle in der Beispielkonfiguration). Diese anfängliche Rolle ermöglicht DHCP, sodass der Benutzer eine IP-Adresse erhält.

2. Der Benutzer öffnet einen Browser und sendet eine HTTP- (oder HTTPS-) Anforderung an ein bestimmtes Ziel (z. B. www.bbc.com).

3. Der Resolver im Gerät sendet eine DNS-Anfrage zum Auflösen von www.bbc.com. Die anfängliche Rolle (Gastanmelderolle) ermöglicht DNS-Dienste, sodass der Resolver mit dem DNS-Server kommunizieren kann.

4. Der DNS-Server antwortet mit der richtigen Adresse auf www.bbc.com.

5. Der Resolver teilt dem Browser anhand der DNS-Antwort mit, welche IP-Adresse verwendet werden soll.

6. Der Browser initiiert eine TCP-Verbindung zu Port 80 der Adresse www.bbc.com.

7. Der Controller fängt die Verbindung ab und fälscht die anfänglichen TCP-Handshakes des HTTP-Prozesses. In diesem Moment glaubt der Client-Browser, dass er mit dem bbc.com-Server kommuniziert.

8. Wenn der Browser die HTTP-GET-Anforderung für die Webseite sendet, antwortet der Controller, dass bbc.com "vorübergehend verschoben" wurde.

9. Der Browser schließt die Verbindung.

10. Der Browser versucht, eine Verbindung herzustellen, muss jedoch zuerst eine DNS-Anfrage für die Adresse senden.

11. Der tatsächliche DNS-Server antwortet, dass er https://securelogin.arubanetworks.com nicht auflösen kann. Der Controller fängt diese Antwort jedoch ab und ändert das Paket so, dass sich securelogin.arubanetworks.com an der IP-Adresse des Controllers befindet. Denken Sie daran, dass es wichtig ist, dass der DNS-Server eine Antwort auf die Abfrage zurücksendet. Erst dann kann der Controller die Antwort vom DNS-Server fälschen. Das Senden einer DNS-Anfrage ohne Erhalt einer Antwort reicht nicht aus, da der Controller dem Client ohne Antwort niemals hilft, securelogin.arubanetworks.com aufzulösen.

12. Der Browser initiiert eine HTTPS-Verbindung zur Adresse des Controllers, die mit der Anmeldeseite des Captive-Portals antwortet, auf der sich der Gast authentifiziert.

13. Nach erfolgreicher Authentifizierung wird dem Benutzer die Nachauthentifizierungsrolle zugewiesen (Auth-Guest-Rolle in der Beispielkonfiguration). Dies ist die Standardrolle im Captive-Portal-Profil.

14. Nach der Authentifizierung wird der Browser unter der ursprünglich vom DNS aufgelösten Adresse zu bbc.com umgeleitet. Wenn eine Begrüßungsseite konfiguriert ist, wird der Browser alternativ zur Begrüßungsseite umgeleitet.

15. Um erfolgreich zur ursprünglichen Webseite umzuleiten, fälscht der Controller eine Antwort von bbc.com, um dem Client mitzuteilen, dass bbc.com dauerhaft auf bbc.com verschoben wurde. Dieser Schritt korrigiert den „vorübergehenden Umzug“, der im Rahmen der Anmeldung für das Captive-Portal aufgetreten ist.

16. Dadurch fragt der Client DNS erneut nach der Adresse von www.bbc.com ab.

17. Der Browser beginnt mit der Kommunikation mit dem tatsächlichen bbc.com-Server.