VPN zwischen Funkwolken
aus Fuerstenland-Wireless, der freien Wissensdatenbank
Inhaltsverzeichnis |
Aufbauen von VPN-Verbindungen zwischen Funkwolken
Grundideen
Jeder kennt das Problem: WLAN-Verbindungen klappen am besten, wenn man Sichtkontakt hat oder zumindest die Distanz zum Kommunikationspartner nicht zu gross ist. Da leider die an Freifunk interessierten Leute selten nebeneinander oder zumindest mit Sichtkontakt bzw. in WLAN-Reichweite wohnen, kann keine Funkverbindung aufgebaut werden.
Im Moment sieht es so aus, dass die interessierten Leute über die ganze Schweiz verteilt sind: -Im Raum St.Gallen: ich in Zuzwil, Marco in Abtwil -Im Raum Basel: Leute vom Chaostreff Basel -Im Raum Zürich: Leute vom Chaostreff Zürich, Leute von anderen im Dock18 beheimateten Vereinen sowie die Leute von Revamp-It -Im Raum Bern: Die Leute von OpenWireless.ch
Da in der Schweiz Internetzugänge weit verbreitet sind, besteht die Idee nun darin, die einzelnen Funkwolken per VPN-Tunnel über das Internet miteinander zu verbinden. Dabei sollten aber Wireless-Verbindungen bevorzugt genutzt werden, denn man will möglichst die VPN-Tunnel entlasten. Die Idee liegt darin, dass mit der Zeit die Funkwolken grösser werden und einzelne Funkwolken langsam zusammenwachsen. Ein Freifunk-Netzwerk auf reiner Funkbasis über die ganze Schweiz oder noch weiter ist und bleibt eine Vision, die organisatorisch sowie auch technisch nicht realistisch erscheint...
Beispiele von technischen Umsetzungen
In Deutschland sind schon VPNs aktiv: VPN in Leipzig
Artikel über Vernetzung von Berlin, Leipzig und Weimar: Indymedia-Artikel zu Freifunk-VPNs
HOWTO zur praktischen Umsetzung eines TINC-VPNs auf einem WRT54G-Router
Gedanken zur Realisierung mit TINC
(siehe offizielle TINC-VPN-Webseite)
Das VPN sollte einen Netzwerknamen bekommen, so geht die Übersichtlichkeit bei mehreren TINC-VPNs auf dem gleichen Rechner nicht verloren.
Im Sinne eines "Mesh Netzwerks" darf das VPN nicht von einem zentralen Server abhängig sein. TINC kennt keine Server oder Client-Konfiguration, jeder TINC-Knoten ist gleichwertig (Peer-to-Peer). Man könnte auf einer Webseite (einem Wiki) die TINC-Kontaktangaben aller Teilnehmer sammeln; wenn möglichst viele der Teilnehmer diese Angaben als "ConnectTo" abspeichern, so funktioniert das VPN auch bei vielen derzeit nicht übers Internet erreichbare Teilnehmern (siehe "4.3 How connections work" im Handbuch).
Es wäre sinnvoll, wenn viele Einstellungsarbeiten möglichst automatisch passieren. Sonst müsste über eine Webseite (Wiki) eine genaue Anleitung oder gleich ein aktuelles IPKG mit allen Einstellungen aufgebaut werden. Optimal wäre eine Webinterface-Unterseite in der Freifunk-Firmware, mit der man z.B. den Status, die verbundenen TINC-Teilnehmer angezeigt werden und Kontaktangaben von neuen TINC-Teilnehmern importiert werden können.
Praxistests müssen zeigen, wie gut der UDP-Modus von TINC über Firewalls hinweg funktioniert, oder wie empfindlich TINC auf nicht weitergeleitete Ports bei NAT-Umgebungen reagiert.
Sinnvolle Einstellungen bei den wichtigsten Konfigurationsparametern:
Die Hauptkonfiguration des TINC-Programmes:
AddressFamily = <ipv4|ipv6|any> (any) IPv4 würde hier Sinn machen, da IPv6 (zumindest bei mir) noch nicht genutzt wird.
BindToAddress = <address> [experimental] BindToInterface = <interface> [experimental] Hier sollte wohl das Internet-Interface bzw. die IP-Adresse dieses Interfaces (Interface über das die Defaultroute verläuft) angegeben werden, da dieses VPN nur bei Knoten mit direkter Internetverbindung Sinn macht. Entsprechende Firewall-Regeln könnten dies auch so einrichten.
Mode = <router|switch|hub> (router) Es heisst da in der Beschreibung, dass im Router-Modus nur "Unicast"-Pakete transportiert werden. OLSR-Pakete benötigen aber die Broadcast-Verbreitung, um Routinginformationen zwischen den OLSR-Programmen auszutauschen. Falls nun OLSR auch mit Broadcast-Adresse 255.255.255.255 nicht über das TINC-VPN funktionieren will, so muss wohl der Switch-Modus aktiviert werden. In diesem Modus verhält sich das TINC-VPN wie ein Ethernet-Switch. Ein Betrieb im Hub-Modus würde alle VPN-Teilnehmer mit allen Datenpaketen versorgen, dies wäre über das Internet sehr hinderlich, weil Bandbreite verschwendet wird.
Host-abhängige Konfiguration:
Von der Idee einer einfachen Konfiguration, eines freien Netzes sowie Einsparung von Rechenpower (VPN wird auf WRT54G laufen), sollte wohl auf Verschlüsselung verzichtet werden. Falls das Missbrauchsrisiko von unbekannten Nutzern aus dem Internet besteht, so muss die Schwierigkeit von gegenseitigem Vertrauen unter den VPN-Teilnehmern überwunden werden, damit asymetrische Schlüssel ausgetauscht und zum Einsatz kommen.
Cipher = <cipher> (blowfish) Verschlüsselung wird mit "none" abgeschaltet. Vielleicht kann man Platz einsparen, indem man SSL nicht in TINC hineincompiliert, die Verschlüsselung brauchen wir ja nicht...
Compression = <level> (0) Eine geringe Kompression macht Sinn. Es muss ausprobiert werden, mit welcher Kompressionsrate ein Kompromis zwischen CPU-Last und Bandbreiteneinsparung hergestellt ist.
Digest = <digest> (sha1) In einem offenen Netzwerk könnte man AFAIK ohne Probleme auf "none" stellen.
