FOSSGIS 2017/OSM-Events/Freifunk
Freifunk Hands on
Am OSM-Samstag haben wir erfolgreich ein kleines Freifunk Netz an der Uni Passau aufgebaut. Problematisch dabei war eigentlich nicht das Anstecken und Einschalten des FF Routers (denn das war's nämlich eigentlich schon), sondern das Uni Netzwerk mit Benutzername, Passwort, begrenzter Ticket-Lebenszeit und HTTPS Authentifizierung.
Diese Art der Anmeldung ist leider immer noch üblich; an öffentlichen Einrichtungen, Hotels, Cafes etc: der erste Zugriff auf 'das Internet' wird von einer Vorschaltseite blockiert, die die Eingabe der Nutzerdaten erfordert. Dabei gibt es - je nach Aufbau der Infrastruktur - einiges zu beachten und wissen. Deshalb hier eine kurze Zusammenfassung was alles passieren kann. Hat also wenig mit FOSSGIS oder OSM zu tun, betrifft aber beinahe jeden in dieser Situation.
Technischer Hintergrund
Meldet man sich mit seinem Laptop oder Smartphone in einem WLAN an, so ist dieses entweder direkt verschlüsselt (per WPA2 beispielsweise) oder offen. Ein verschlüsseltes WLAN bietet in der Regel nach erfolgreicher Anmeldung sofort direkten Internetzugriff. Ein Passwort wird vom Betriebssystem nach der ersten Eingabe gemerkt, so dass eine wiederholte Eingabe entfällt. Das ist die Lösung die man aus Privathaushalten kennt.
Ein scheinbar offenes WLAN wie hier das Gastnetz der Uni Passau macht das ein wenig anders:
Nach der Einbuchung in das WLAN bekommt das Endgerät (Laptop/Handy) zwar eine IP-Adresse und einen Nameserver zugewiesen (die beiden Grundvoraussetzungen für Internetzugang), jedoch lügen beide: Nach der Eingabe einer URL im Browser wie www.google.de erscheint nicht die Google-Seite, sondern eine Vorladeseite der Universität mit der Bitte um Authentifizierung. Damit wird das Endgerät mit seiner MAC-Adresse an den Benutzernamen (Zettel vom Welcomedesk) gekoppelt um den Datenverkehr rückverfolgen zu können.
Erst nach erfolgreicher Anmeldung lügt der Nameserver nicht mehr sondern liefert die korrekte Antwort auf Anfrage nach www.google.de.
Technisch wird das so gelöst, dass der Client eine IP-Adresse des lokalen Subnetzes erhält (192.168.*.*) und einen Nameserver, der alle Anfragen mit der Anmeldeseite der Uni beantwortet. www.google.de liefert also genauso wie www.amazon.de die Antwort der Anmeldeseite.
Schlimmer noch ist, dass dies nur bei HTTP funktioniert und nicht beim sicheren HTTPS, das den Datenstrom für Mitleser unverständlich macht. Die Katastrophe setzt sich fort, weil nämlich Google und Co inzwischen alles auf HTTPS umleiten. Das ist absolut korrekt. Und wer im Browser 'www.google.de' eingibt, wird - ohne es großartig zu merken - gleich auf https://www.google.de weitergeleiget (HTTP redirect nennt man das).
Nur: wer ein Bookmark auf google gesetzt hat und meint, damit das Internet 'ausprobieren' zu können, hat sich geschnitten, denn das Bookmark weist dann auf https://www.google.de und nicht auf http://www.google.de (bemerke das 's'!). Die Infrastrktur der Uni kann aber nur HTTP verbiegen, nicht HTTPS, denn genau dafür wurde HTTPS geschaffen. Es wird also eine Schein-Sicherheit erzeugt, indem man gezwungen wird, ein unsicheres Protokoll zur Authentifierung zu verwenden.
Schritt 1 - Anmeldung
Schritt 1 besteht also darin, sich erstmal per unsicherem HTTP://irgendwas anzumelden, damit man Zugriff auf das Internet hat.
Manche WLAN Anbieter beschränken den Internet Zugriff auf bestimmte Dienste, so dass zwar HTTP, HTTPS und email funktionieren, andere Dienste wie SSH aber blockiert werden, obwohl sie die gleiche Existenzberechtigung haben.
Schritt 2 - network-manager konfigurieren
Das eigentliche Ziel ist es ja, den Freifunk-Router ans Netz zu bekommen. Der braucht allerdings einen drahtgebundenen Uplink. Diesen soll der Laptop liefern, der ja jetzt im Uni-WLAN erfolgreich mit Internetzugriff eingebucht ist.
Die drahtgebundene Schnittstelle kann der Laptop zur Verfügung stellen, wenn man die Netzwerkkonfiguration gewaltig umkrempelt. Das ist vergleichbar mit dem Tethering, das die meisten Handys anbieten, nur eben auf einem anderen Medium und nicht als single-Klick Lösung.
Die Beschreibung bezieht sich hier auf ein Linux Laptop (mit Ubuntu, die Distribution sollte aber keine große Rolle spielen). Dort ist in der Regel der 'network-manager' zu Gange, der dafür sorgt, dass man sorgenfrei WLAN oder drahtgebunden arbeiten kann. Der network-manager sucht sich die beste Verbindung aus und routet den Verkehr darüber.
Schritt 2 besteht darin, den network-manager dazu zu bewegen, dass er einerseits das WLAN Interface weiterhin korrekt bedient, aber das drahtgebundene Interface in Ruhe lässt. Das geht mit der grafischen Oberfläche zur Netzwerkkonfiguration, dort das eth0 auf 'manuell' stellen und eine fixe IP-Adresse hinterlegen, hier die 192.168.0.2. Warum genau diese IP Adresse wird gleich erklärt.
Schritt 3 - DHCP Server
Der Freifunk-Router wiederum verhält sich genauso wie ein Endgerät. D.h. er braucht einen DHCP-Server um eine IP Adresse und einen Nameserver zu erhalten. Diese beiden Dienste müssen wir also auf dem Laptop zur Verfügung stellen, damit der Freifunk-Router überhaupt kommunizieren kann. Hier wurde der isc-dhcp Server installiert (aus der Paketverwaltung von Ubuntu). Ich erkläre das nicht im Detail; es geht darum, dass der DHCP Server so konfiguriert wird, dass er an Clients, die sich anmelden wollen, IP Adressen im Bereich 192.168.0.20 - 102.168.0.40 vergibt. (apt-get install isc-dhcp-server, /etc/dhcp/dhcpd.conf editieren). Damit ist die Frage geklärt, warum der Laptop vorher die feste IP Adresse 192.168.0.2 bekommt, weil die ausserhalb des DHCP Bereichs liegt.
Schritt 4 - iptables
iptables ist der Begriff für das Linux-interne Netzwerk Routing. Das kann als Firewall, Port-Forwarding und für weitere komplexe Aufgaben verwendet werden. iptables entscheidet anhand von Regeln, was mit Netzwerkpaketen passiert (selber interpretieren, weiterleiten, wegwerfen, zurückschicken). Dieses Verfahren war Standard zu Zeiten, als man noch per ISDN ins Internet ging und mehrere Rechner im Heimnetz ans Internet anschliessen wollte (OHNE Fritzbox). Folgende Zeilen erledigen das:
sudo sysctl -w net.ipv4.ip_forward=1 sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE sudo iptables -A FORWARD -i wlan0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT sudo iptables -A FORWARD -i eth0 -o wlan0 -j ACCEPT
Schliessen wir also nun den Freifunk-Router an das Laptop an, sollte der Router eine von DHCP vergebene IP-Adresse erhalten, wahrscheinlich die 192.168.0.20. Man muss das aber ausprobieren oder in logfiles suchen, welche tatsächlich vergeben wurde.
Achtung: Der network-manager (von ubuntu) ist ziemlich kaputt. Mir ist aufgefallen, dass beim An/Abstecken des drahtgebundenen Ethernets immer wieder die default Route auf dem Laptop verstellt wurde. Man kann das kontrollieren und richten mit:
# auf dem Laptop: route -n
zeigt die aktuelle Routing Tabelle an. Die Default-Route (0.0.0.0 als Ziel) MUSS auf das wlan0 Interface zeigen. Tut sie das nicht, hilft:
# auf dem Laptop: route del default route add default gw 192.168.19.251 dev wlan0
Wobei 192.168.19.251 die IP Adresse des Uni-Gateways ist, welche das erste 'route -n' Kommando ausgespuckt hat.
Schritt 5 - Router konfigurieren
Nun können wir uns auf den Freifunk-Router einloggen. Das geht mit ssh. Vorher muss man den ssh Key auf dem Router hinterlegen. Wie das geht steht auf diversen Freifunk HowTo's (üblicherweise per Webinterface). Also:
# auf dem Laptop: ssh -l root 192.168.0.20
Der Router braucht dann weitere Informationen, wie er ins Internet kommt. Weil er mehrere drahtgebundene und WLAN Interfaces hat, muss man ihm sagen, wohin der Weg ins Internet führt:
# auf dem Router: route del default route add default gw 192.168.0.2
und im /etc/resolv.conf muss man den nameserver austauschen:
# auf dem Router: vi /etc/resolv.conf nameserver 127.0.0.1 -> ändern in nameserver 8.8.8.8
8.8.8.8 ist der Google-Namserver, das ist an dieser Stelle einfach nur praktisch, ganz korrekt ist das eigentlich nicht...
Schritt 6 - Testen
Stand jetzt ist, dass der Freifunk-Router den Verkehr nach aussen an den Laptop weiterleitet (192.168.0.2) und das Laptop über iptables den Verkehr weiterleitet an den Uni-Router.
Wenn diese Weiterleitung auf IP-Adress-Basis funktioniert, sollte auch die Namensauflösung funktionieren. Testen kann man das (auf dem Freifunk-Router eingelogged per ssh) mit
# auf dem Router: nslookup www.google.de
und
# auf dem Router: wget www.google.de
Das Kommando 'ping' empfehle ich an dieser Stelle explizit NICHT, es benutzt das ICMP Protokoll (das ist parallel zu TCP oder UDP anzusehen) und wird gerne von Infrastrukturen wie Uni- oder Hotelnetzen unterbunden.
Fertig?!
Das war's eigentlich. Ziemlich kompliziert und mit Sicherheit hat man sich die Laptop-Konfiguration so zerschossen, dass man den nächsten Tag damit beschäftigt ist, das wieder aufzuräumen.
Der Freifunk Router sollte aber an dieser Stelle seinen Dienst nun zur Verfügung stellen und die ganze Anmelde-Orgie überflüssig machen.
Political correctness
Meiner Auffassung nach ist es legitim, so eine Installation zu betreiben. Im Fall der Uni oder auch an Hotels haftet man theorerisch mit seinem temporären Account für den Datenstrom, der darüber fließt. Andererseits wird der Freifunk-Datenstrom per VPN verschlüsselt übertragen und es haftet der Freifunk-Verein als Besitzer des VPN Exit-Nodes (ein angemieteter Server bei Hetzner oder anderen).
Problematisch sehe ich eher das Betreiben eines DHCP-Servers im Uni-Netzwerk. Das könnte unter Umständen andere Clients aus dem Tritt bringen. Gehört schöner gelöst.
Ausblick
Weil mich diese Art der Internet-Anbindung unglaublich nervt, und für Reisende immer wieder das gleiche unnötige Problem darstellt, überlege ich mir, das ganze als Hardwarepaket in Form eines Raspberry-Pi oder so zu verpacken. Die Anleitung hier ist nur eine Zusammenfassung und erfordert schon ziemlich viel Hintergrundwissen. Eine Pushbutton Lösung ist das gewiss nicht. Details muss man sich aus dem Internet zusammensuchen.
Schreibt mich an für Anregungen unter
fossgis2017@edv-buero-lehner.de - Alexander Lehner - OSM ID blutsauger