Architektur: Unterschied zwischen den Versionen
Yanosz (Diskussion | Beiträge) |
Yanosz (Diskussion | Beiträge) (→VPN) |
||
Zeile 49: | Zeile 49: | ||
=== VPN === | === VPN === | ||
==== Verwendung ==== | ==== Verwendung ==== | ||
Verfügt ein Node über einen drahtgebundenen Zugang zum Internet, so baut er eine VPN-Verbindung auf. Als VPN wird fastd (https://projects.universe-factory.net/projects/fastd) verwendet. Fastd baut - ähnlich zu l2tp - per Default Verbindungen nur zwischen zu definierten Links auf. Somit ergibt sich keine Redundanz zur batman-adv Topoligie-Ermittlung: Für batman-adv erscheint nicht der transitive Abschluss aller VPN-Verbindungen. | Verfügt ein Node über einen drahtgebundenen Zugang zum Internet, so baut er eine VPN-Verbindung auf. Als VPN wird fastd (https://projects.universe-factory.net/projects/fastd) verwendet. Fastd baut - ähnlich zu l2tp - per Default Verbindungen nur zwischen zu definierten Links auf. Somit ergibt sich keine Redundanz zur batman-adv Topoligie-Ermittlung: Für batman-adv erscheint nicht der transitive Abschluss aller VPN-Verbindungen. Das VPN arbeitet hier als Ersatz für ad-hoc wlan Verbindungen: Teile des Netzes zwischen denen keine Verbindung besteht, werden über das VPN zusammen gefasst. Somit: | ||
Das VPN | ''Das VPN verbindet Ad-Hoc Mesh-Partionen.'' | ||
==== Schlüsselaustausch ==== | ==== Schlüsselaustausch ==== |
Version vom 24. März 2013, 18:41 Uhr
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. Hierbei gibt die Architektur vor, wie Nodes, Super-Nodes, Server und Klienten konfiguriert werden müssen.
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 besteht aus Klienten, 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 Teilnehmer. Dadurch sind je 2 Klienten in verschiedenen Teilen des Netzes immer über eine zu Grunde liegende Infrastruktur via "Ethernet" (WLAN / LAN) miteinander verbunden. Für die Infrastruktur wird batman-adv (http://www.open-mesh.org/) verwendet - sie wird als hierachisches P2P-Netz realisiert. Somit:
Daten zwischen Netzteilnehmer werden als Frames switched, das Netz bildet eine große Broadcast-/Link-Local-Multicast-Domäne.
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). 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 beispielsweise auf dedizierten Servern ohne WLAN-Konnektivität betrieben. Abb. 1 zeigt die Kommunikation zwischen Klienten, Nodes und Super-Nodes. Die Nodes A und B sind mit den Super-Nodes fastd1 und fastd2 verbunden. Über die eingezeichneten Verbindungen werden batman-adv Frames versendet. Der Klient ist im Infrastruktur-Netz an Node A eingebucht - es werden gewöhnliche Wireless-Lan-Frames verwendet. (kein batman-adv)
Nodes
Auf den Nodes existieren verschiedene Netze, die teilweise mit einander verbunden sind (Abb. 2). Jeder Node spannt dabei zwei Wireless-Lan-Netze auf und ggf. eine VPN-Verbindung auf. .
- wlan0 wird als "Master"-Netz betrieben
- wlan1 arbeitet als "Ad-Hoc"-Netz
- tap0 ist das VPN-Interface.
wlan1 und tap0 sind hierbei dem bat0 Interface hinzugefügt.
Hinweis: Aus technischen Gründen (u.a. vlan-Fähigkeit einzelner Geräte), weichen Interface-Namen in der Node-Firmware z.T. ab.
OSI-2: Data-Link-Layer
Die komplettes Bridging Strategie sieht vor, dass alle Stationen zu einem OSI-2 Segment zusammen gefasst werden. Hierbei werden LAN, WLAN und VPN-Verbindungen via bridging verbunden. In diesem Absatz wird die Konfigration der verschiedenen Komponenten des Segements erläutert. Abb. 3 illustiert das Segment. Es besteht aus den Super-Nodes fastd1, fastd2 und fastd3, den Nodes A, B, C und D sowie zwei Klienten.
- Nodes A, B und C sind per Kabel mit dem Internet verbunden und bauen eine VPN-Verbindung zu jeweils zwei Super-Nodes auf.
- Node D verfügt über keine kabelgebundene Verbindung zum Internet. Er ist vua ad-hoc wlan mit der Wolke verbunden
- Entlang der blau eingezeichneten Verbindungen werden batman-adv Frames ausgetauscht.
Node-IDs
Jedem Node wird eine eindeutige ID zugewiesen. Sie entspricht der Hardware-Adresse gemäß Aufkleber - Trennzeichen werden entfernt. (Beispiel: Hardware-Adresse: F4:EC:38:E9:72:34 => Node-ID: f4ec38e97234. Verfügt ein Node über mehrere Interfaces, so wird die des ersten (gemäß Treiber- / Kernel Numerierung) 2.4 GHz-Interface verwendet.
Wireless LAN =
Im Freifunk-KBU Netz wird IEEE 802.11g/n mit Datenraten verwendet.
- Das Infrastruktur-Netz für die SSID kbu.freifunk.net. Für Klienten erscheint es als normaler Accesspoint.
- Das Ad-Hoc Netz nutzt die ESSID und BSSID: 02:d1:11:37:fc:39. Es ermöglicht die direkte Kommunikation zwischen verschiedenen Nodes.
VPN
Verwendung
Verfügt ein Node über einen drahtgebundenen Zugang zum Internet, so baut er eine VPN-Verbindung auf. Als VPN wird fastd (https://projects.universe-factory.net/projects/fastd) verwendet. Fastd baut - ähnlich zu l2tp - per Default Verbindungen nur zwischen zu definierten Links auf. Somit ergibt sich keine Redundanz zur batman-adv Topoligie-Ermittlung: Für batman-adv erscheint nicht der transitive Abschluss aller VPN-Verbindungen. Das VPN arbeitet hier als Ersatz für ad-hoc wlan Verbindungen: Teile des Netzes zwischen denen keine Verbindung besteht, werden über das VPN zusammen gefasst. Somit:
Das VPN verbindet Ad-Hoc Mesh-Partionen.
Schlüsselaustausch
Der Schlüsselaustausch erfolgt dabei über die Super-Nodes. Jeder Super-Node betreibt einen RESTful-Webservice über den er Schlüssel entgegen nimmt (https://github.com/ff-kbu/fastd-service): Initiiert ein Node eine VPN-Verbindung zu einem Super-Node zu übermittelt er im Vorfeld seinen Public-Key. Durch die Verwendung Elliptischer Kurven sind die Schlüssel hinreichend klein und können urlencoded übermittelt werden. Abb. 4 zeigt den Schlüsselaustausch zwischen Node und Super-Node. Zusätzlich ist das Node-Register am Austausch beteiligt, dass den Schlüssel ablehen kann (bspw. wenn er bereits im Netz verwendet wird).
Frame-Typen
Für die genutzten Frame-Typen gilt:
- vlan-Tagging wird nicht verwendet.
- VPN und ad-hoc: batman-adv-Frames verwendet
- Infrastruktur-Netz: Gewöhnliche Wireless-Lan Frames (IEEE 802.11)
OSI-3: IP-Adressierung / Routing
Zur Kommunikation im Freifunk-Netz und mit weiteren Netzen ist es erforderlich, IP-Adressen zu Vergeben und Pakete in andere Netze zu routen. Dieser Absatz beschreibt die verwendete Adressierungs und Routing-Strategien im Freifunk-Netz. Hierbei wird insbesondere auf das Backbon-VPN (Tinc) und auf die Konfigration der Super-Nodes eingangen.
Adressbereiche
Im OSI-2 Segment werden die folgenden Adressen verwendet:
- 172.27.0.0/18 - 172.27.0.0 bis 172.63.255.255, Subnet-Mask: 255.255.192.0
- 2001:67c:20a0:b102::/64
- fdd3:5d16:b5dd::/64
- fdd3:5d16:b5dd:1::/64
Konfiguration Super-Nodes
Jeder Super-Node betreibt einen DHCPv4-Server, mit dem er die Konfiguration für die Klienten ausliefert. Gleichzeitig betreibt er einen DNS-Cache - optional ist der Betrieb eines transparenten HTTP-Proxies denkbar.
Die aktuelle Planung sieht 8 Super-Nodes für das FF-KBU vor, auf denen DHCP-Server betrieben werden. Keys und DNS-Namen sind in der Firmware hinterlegt. Bei Bedarf können weitere Super-Nodes hinzugefügt werden.
IPv4 / DHCP
IPv4-Adressen und DHCP-Ranges können wie folgt aufgeteilt werden.
Name | Zugewiesenes Subnet | IP | DHCP-Range |
---|---|---|---|
fastd1 | 172.27.0.0/21 | 172.27.0.3 | 172.27.0.10 - 172.27.7.254 |
fastd3 | 172.27.8.0/21 | 172.27.8.1 | 172.27.8.10 - 172.27.15.254 |
fastd4 | 172.27.16.0/21 | 172.27.16.1 | 172.27.16.10 - 172.27.23.254 |
fastd5 | 172.27.24.0/21 | 172.27.24.1 | 172.27.24.10 - 172.27.31.254 |
fastd6 | 172.27.32.0/21 | 172.27.32.1 | 172.27.32.10 - 172.27.39.254 |
fastd7 | 172.27.40.0/21 | 172.27.40.1 | 172.27.40.10 - 172.27.47.254 |
fastd8 | 172.27.48.0/21 | 172.27.48.1 | 172.27.48.10 - 172.27.55.254 |
fastd2 | 172.27.56.0/21 | 172.27.56.1 | 172.27.56.10 - 172.27.63.254 |
Hinweis: Werden weitere Super-Nodes benötigt, so müssen die zugewiesenen subnets aufgeteilt werden.
Konfiguration Nodes
<todo> (TODO: Implementierung in der Firmware ausstehend).
Nodes verwenden im Uplink-Netz zusätzlich den ULA-Bereich
- fdd3:5d16:b5dd:1::/64
Jeder Node kann über seine Public-IPv6, ULA-IPv6, Link-Local-IPv6 Adressen und die IPv4-Adresse seines WAN-Uplink-Netzes erreicht werden. Jedem Node wird dadurch eine eindeutige Adresse aus fdd3:5d16:b5dd::/64 zugewiesen, die aus allen Netzen - mit denen er verbunden ist erreicht werden kann
Gleichzeitig verwendet jeder Node die anycast-Adresse 172.27.0.255, die nur aus dem Infrastruktur-Netz erreichbar ist. Hierdurch kann ein Client explizit abfragen, mit welchem Node er verbunden ist. </todo>
IPv6 / RADVD
Hinweis: Aktell nicht so umgesetzt - Tinc in Squeeze hat da afair Probleme TODO: Umsetzen. Super-Nodes betreiben radvd-Server im Adressbereich 2001:67c:20a0:b102::/64 und annoncen sich selbst als Router