Im Weimarnetz wird VPN für zwei Zwecke genutzt: Die Verbindung von Meshwolken, die sich durch die Luft nicht sehen können und um die DSL-Betreiber aus dem Fokus der Abmahnanwälte zu nehmen. Sollte die Störerhaftung fallen, geht es nur noch um die Verbindung der Wolken untereinander. Jahrelang haben wir das gesamte Netz mit einem (zentralen) Server betrieben. Ergebnis langer Überlegungen ist ein dynamischeres, offeneres Konzept, das wir nun umzusetzen wollen.
Was möchten wir erreichen?
- Jede_r soll einen Server im Netz bereitstellen können, ohne die Konfiguration anderer Server oder Router ändern zu müssen.
- Server sollen dezentral und organisatorisch unabhängig voneinander arbeiten. Wir wollen nicht von Einzelnen abhängig sein.
- Lastverteilung und Ausfallsicherheit über mehrere Server
- die Bereitstellung eines VPN-Servers soll im besten Fall scriptbasiert möglich sein
- das Hinzufügen oder Austauschen von Servern funktioniert ohne, dass wir die Firmware auf den Routern anpassen müssen. Das Konzept soll möglichst wenig Dienste auf Server und Router erfordern (idealerweise nichts, was über OLSR und VPN hinausgeht, Internet setzen wir mal voraus)
Wie funktioniert es?
Server
Auf Serverseite benötigen wir vtun als VPN-Software und OLSR als Routing Daemon. Beides kompilieren wir selbst, da die Pakete in den Linuxdistributionen hoffnungslos veraltet sind (insbesondere OLSR) oder nicht zu unseren Anforderungen passen (vtun). VTUN kann in verschiedenen Varianten angeboten werden, die Parameter sind (de)aktivierte Verschlüsselung oder Kompression. Die unterschiedlichen Ausprägungen von VTUN müssen auf verschiedenen TCP-Ports lauschen. Weimarnetzrouter laufen standardmäßig ohne Verschlüsselung und ohne Kompression.
VTUN wird auf einem Server so vorkonfiguriert, dass sich jeder Knotennummer (=Abstraktion der IP-Konfiguration) aus dem Weimarnetz mit dem Server verbinden kann. Der OLSR-Dienst startet bei einem noch unbekannten Router kurz neu, um diesen in die Konfiguration aufzunehmen. Der Clou ist, dass sich der VPN-Server – selbst ein Knotenpunkt im Mesh – per OLSR-Service-Plugin im Netzwerk als Dienst ankündigt und so auch andere Router von diesem Dienst erfahren. In dieser Meldung teilt der Server Verbindungsdaten mit, z.B. die Ports, die MTU oder die Anzahl der bereits verbundenen Router.
Untereinander können sich die Server ebenfalls verbinden und das Mesh erweitern. So wird vermieden, dass Inseln entstehen.
Router
Jeder Router pflegt eine aktuelle Liste angekündigter VPN-Dienste. Die ist fest gespeichert, um einen Neustart zu überleben. Auch im Fall, dass andere Meshnachbarn fehlen, sind trotzdem Informationen zu verfügbaren Diensten da und eine Verbindung kann initiiert werden.
Stellt der Router fest, dass er selbst über Zugang zum Internet verfügt wird versucht, eine VPN-Verbindung zu starten. In einem kurzen Test wird der am besten erreichbare Server ausgewählt (z.B. Ping-Zeit, Anzahl Clients) und eine Verbindung mit diesem gestartet. Fertig.
Wie sieht es heute aus?
Wir haben inzwschen 3 laufende Server. Einen stellt uns Ufo aus Leipzig zur Verfügung, Basti betreibt einen in Chicago und einen in Düsseldorf. Einer unserer Mitstreiter baut gerade einen Server in der Schweiz auf, den wir dafür auch nutzen dürfen.
Aktuell laufen die Arbeiten an der Integration der Funktionen in unsere Firmware, die ersten Tests sehen vielversprechend aus.