Architektur

Hinweis: Jans Seite zur Architektur im FF-Netz - WIP. Bitte NICHT ändern.

Freifunk-KBU verolgt die Komplettes Bridging-Strategie: Fastd-Server verbinden als Super-Nodes WLAN-Mesh-Partionen. IP-Adressen werden per DHCP und radvd vergeben. Ein routed Backbone-VPN (tinc) verbindet die Supernodes und ermöglicht Routing zum Exit.

Einleitung

Dieser Artikel beschreibt die Architektur des in Köln, Bonn und Umgebung verwendeten Freifunk-Netzes. Dabei wird insbesondere auf die Zusammenhänge zwischen Server-Konfiguration und Firmware-Eigeschaften eingegangen. Diese Wiki-Seite beschreibt die Konfigration jedoch nur aus Architektur-Sicht - sie ist nicht nicht Bestandteil der Server-Dokumentation.

Im Rahmen der Einleitung wird die verwendete Stratgie (komplettes Briding) dargelegt. Die folgenden Absätze (OSI-2: Briding, OSI-3: Routing) gehen detailliert auf die verschiedenen Schichten des Netzes ein. Der letzte Absatz gibt einen Ausblick auf mögliche Änderung, die in Zukunft einziehen können.

Strategie

Das Netz wird als hierachisches P2P-Netz betrieben. Es besteht aus Nodes und Super-Nodes. Die verwendete Komplettes Bridging Stratgie sieht vor, dass das komplette Netz ein einziges zusammehängendes OSI-2 Segment bildet. Dieses Segment verbindet alle Klienten, Nodes und Server. Dadurch sind je 2 Klienten in verschiedenen Teilen des Netzes immer über eine zu Grunde liegende Infrastruktur via "Ethernet" (nach IEEE 802-Substandards) miteinander verbunden. Für die Infrastruktur selbst wird batman-adv (http://www.open-mesh.org/) verwendet. Somit:
Daten zwischen Netzteilnehmer werden als Frames switched, das Netz bildet eine große Broadcast-/Link-Local-Multicast-Domäne.

Implementierung: Nodes

Abb. 1

Auf den Nodes existieren verschiedene Netze, die teilweise mit einander verbunden sind (Abb. 1). Jeder Node spannt dabei zwei Wireless-Lan-Netze auf und ggf. eine VPN-Verbindung auf. .

• wlan0 wird als "Master"-Netz mit SSID kbu.freifunk.net betrieben. Für Klienten erscheint es als normaler Accesspoint.
• wlan1 arbeitet als "Ad-Hoc"-Netz mit ESSID und BSSID: 02:d1:11:37:fc:39. Es ermöglicht die direkte Kommunikation zwischen verschiedenen Nodes.
• tap0 ist das VPN-Interface. Verfügt ein Node über einen drahtgebundenen Zugang zum Internet, so baut er eine VPN-Verbindung auf.

wlan1 und tap0 sind hierbei dem bat0 Interface hinzugefügt. Somit werden in beiden Netzen (ad-hoc, VPN) batman-adv-Frames anstelle gewöhnlicher Ethernet-Frames übermittelt. Alle Stationen in diesen Netzen müssen daher die gleiche batman-adv Protokollversion zur Kommunikation verwenden. Ethernet-Frames nach IEEE 802 können nicht verwendet werden. bat0 und wlan0 sind über die Bridge br0 verbunden.

Hinweis: Aus technischen Gründen (u.a. vlan-Fähigkeit einzelner Geräte), weichen Interface-Namen in der Node-Firmware z.T. ab.

Implementierung: Super-Nodes

Super-Nodes (auch: fastd-Server) sind Nodes, die VPN-Verbindungen von Nodes entgegen nehmen. Ein Super-Node ist im Internet erreichbar, d.h. Nodes können VPN-Verbindungen dorthin initiieren, auch wenn sie sich z.B. hinter einem NAT befinden. Super-Nodes verfügen über eine gute Internet-Anbindung (100MBit/s up/down). Jeder Node hält typischerweise VPN-Verbindungen zu zwei verschiedenen Super-Nodes. Adressen und VPN-Schlüssel der Super-Nodes sind fest in der Node-Firmware verdrahtet.

Super-Nodes werden typischerweise auf dedizierten Servern ohne WLAN-Konnektivität betrieben. Abb. 2 zeigt die Kommunikation zwischen Klienten, Nodes und Super-Nodes. Die Nodes A, B und C sind mit den Super-Nodes fastd1 und fastd2 verbunden. Über die eingezeichneten Verbindungen werden batman-adv Frames versendet. Der Klient ist im Infrastrukt-Netz an Node A eingebucht - es werden gewöhnliche Wireless-Lan-Frames verwendet. (kein batman-adv)