https://kbu.freifunk.net/wiki/api.php?action=feedcontributions&user=Zuse&feedformat=atomFreifunk Köln, Bonn und Umgebung - Benutzerbeiträge [de]2024-03-29T06:57:31ZBenutzerbeiträgeMediaWiki 1.38.2https://kbu.freifunk.net/wiki/index.php?title=Architektur&diff=5328Architektur2017-12-27T21:24:44Z<p>Zuse: /* Backbone-VPN / Tinc */ Rechtschreibunk</p>
<hr />
<div>{{TOCright}}<br />
<span style="color: #F00">'''Hinweis'''</span>: Dieser Artikel beschreibt das Freifunk-Netz aus konzeptioneller Sicht und erklärt viele, tiefe Details. Um einfach mitzumachen musst Du nicht alles davon verstehen - wenn Du Interesse hast, lese einfach weiter :-).<br />
<br />
<br />
== Kurzzusammenfassung ==<br />
<br />
Freifunk-KBU verfolgt die [[Netzwerk-Konfiguration#Komplettes_Bridging | Komplettes Bridging]]-Strategie: Das gesamte KBU-Netz bildet eine Broadcast-Domäne. Fastd-Server verbinden als Supernodes WLAN-Mesh-Partionen. IP-Adressen werden an Clients per DHCP und radvd vergeben. Nodes erhalten keine IPv4 aber eine IPv6 Adresse. Ein routed Backbone-VPN (tinc) verbindet die Supernodes und ermöglicht Routing zum Exit.<br />
<br />
== Einleitung ==<br />
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-Eigenschaften eingegangen. Hierbei gibt die Architektur vor, wie Nodes, Supernodes, Server und Klienten konfiguriert werden müssen. <br />
<br />
Im Rahmen der Einleitung wird die verwendete Strategie (''komplettes Bridging'') dargelegt. Die folgenden Absätze (OSI-2: Bridging, 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.<br />
<br />
=== Strategie ===<br />
Das Netz besteht aus Klienten, Nodes und Supernodes. Die verwendete [[Netzwerk-Konfiguration#Komplettes_Bridging | Komplettes Bridging Strategie]] sieht vor, dass das komplette Netz ein einziges zusammenhä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 [[Wikipedia:Peer-to-Peer | P2P-Netz]] realisiert. Somit: <br /><br />
''Daten zwischen Netzteilnehmer werden als Frames switched, das Netz bildet eine große Broadcast-/Link-Local-Multicast-Domäne.''<br />
<br />
=== Supernodes ===<br />
[[Datei:Super-node-overview.png|thumb|300px|right|Abb. 1]]<br />
[[supernode|Supernodes]] (auch: fastd-Server) sind Nodes, die VPN-Verbindungen von Nodes entgegen nehmen. Ein Supernode ist im Internet erreichbar, d.h. Nodes können VPN-Verbindungen dorthin initiieren, auch wenn sie sich z.B. hinter einem [[Wikipedia:Network_Address_Translation | NAT]] befinden. Supernodes verfügen über eine gute Internet-Anbindung (100MBit/s). Jeder Node hält (bis zur KBU-Firmware 1.4) typischerweise VPN-Verbindungen zu zwei verschiedenen Supernodes. Adressen und VPN-Schlüssel der Supernodes sind fest in der Node-Firmware verdrahtet.<br />
<br />
Supernodes werden beispielsweise auf dedizierten Servern ohne WLAN-Konnektivität betrieben.<br />
Abb. 1 zeigt die Kommunikation zwischen Klienten, Nodes und Supernodes. Die Nodes A und B sind mit den Supernodes 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'')<br />
<br />
'''Update:''' seit KBU-Firmware 1.4 (basierend auf Gluonv 2015.1.2) wird von jedem Freifunk-Router (Knoten) nur noch eine Verbindung zu einem (anstatt zwei) Supernodes aufgebaut, um den Hintergrund-Datenverkehr zu halbieren und mehr Nutzdaten zu erlauben. Bei einem Supernode-Ausfall dauert es damit 1-2 Minuten, bis sich ein Knoten mit einem anderen Supernode verbindet und der Dienst wieder zur Verfügung steht. Da Ausfälle selten sind, scheint das ein guter Kompromiss zu sein.<br />
<br />
=== Nodes ===<br />
[[Datei:4.1-All-Bridging.png|thumb|300px|right|Abb. 2]]<br />
Auf den Nodes existieren verschiedene Netze, die teilweise mit einander verbunden sind (Abb. 2). Jeder Node spannt dabei zwei Wireless-Lan-Netze und ggf. eine VPN-Verbindung auf.<br />
<br />
* ''wlan0'' wird als "Master"-Netz betrieben<br />
* ''wlan1'' arbeitet als "Ad-Hoc"-Netz <br />
* ''tap0'' ist das VPN-Interface. <br />
<br />
wlan1 und tap0 sind hierbei dem ''bat0'' Interface hinzugefügt. <br />
<br />
''Hinweis'': Aus technischen Gründen (u.a. vlan-Fähigkeit einzelner Geräte), weichen Interface-Namen in der Node-Firmware z.T. ab.<br />
<br />
== OSI-2: Data-Link-Layer ==<br />
[[Datei:Osi-2.png|thumb|350px|right|Abb. 3]]<br />
<br />
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 Konfiguration der verschiedenen Komponenten des Segements erläutert. Abb. 3 illustriert das Segment. Es besteht aus den Super-Nodes fastd1, fastd2 und fastd3, den Nodes <tt>b0487aaeec16</tt>, <tt>f8d111883fea</tt> und <tt>d85d4cae420c</tt> sowie zwei Klienten. <br />
* Nodes <tt>b0..</tt> und <tt>f8..</tt> sind per Kabel mit dem Internet verbunden und bauen eine VPN-Verbindung zu jeweils zwei Supernodes auf.<br />
* Node <tt>d8..</tt> verfügt über keine kabelgebundene Verbindung zum Internet. Er ist via ad-hoc wlan mit der Wolke verbunden<br />
* Entlang der blau eingezeichneten Verbindungen werden batman-adv Frames ausgetauscht.<br />
Die Klienten werden daher via batman-adv TT-annouces im Mesh bekannt gemacht. Bridge-Loop-Avoidance (BLA) wird nicht verwendet (http://www.open-mesh.org/projects/batman-adv/wiki/Understand-your-batman-adv-network)<br />
<br />
=== Node-IDs ===<br />
Jedem Node wird eine eindeutige ID zugewiesen. Sie entspricht der Hardware-Adresse gemäß Aufkleber - Trennzeichen werden entfernt. (Beispiel: Hardware-Adresse: <tt>F4:EC:38:E9:72:34</tt> => Node-ID: <tt>f4ec38e97234</tt>. Verfügt ein Node über mehrere Interfaces, so wird die des ersten (gemäß Treiber- / Kernel Nummerierung) 2.4 GHz-Interface verwendet.<br />
<br />
=== Wireless LAN ===<br />
Im Freifunk-KBU Netz wird IEEE 802.11g/n verwendet:<br />
* Das Infrastruktur-Netz führt die SSID <tt>kbu.freifunk.net</tt>. Für Klienten erscheint es als normaler Accesspoint.<br />
* Das Ad-Hoc Netz nutzt die ESSID und BSSID: <tt>02:d1:11:37:fc:39</tt>. Es ermöglicht die direkte Kommunikation zwischen verschiedenen Nodes.<br />
<br />
=== VPN ===<br />
==== Verwendung ====<br />
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 Topologie-Ermittlung: Für batman-adv existiert ''nicht'' der transitive Abschluss aller konfigurierten fastd-Links als Broadcast-Medium. Das VPN arbeitet hier als Ersatz für ad-hoc wlan Verbindungen: Teile des Netzes zwischen denen keine Verbindungen bestehen, werden über das VPN zusammen gefasst.<br />
Nodes ohne Verbindung zum VPN-Server bilden eine gemeinsames OSI-2 Segment, wenn eine Ad-Hoc Verbindung besteht oder wenn zwischen ihnen eine VPN-Verbindung manuell konfiguriert wurde<br />
(fastd-Peers per Shell im Dateisystem des Nodes hinterlegt). Eine Verbindung zu Supernodes ist nicht zwingend erforderlich. Somit gilt:<br />
<br />
''Das VPN verbindet Ad-Hoc Mesh-Partitionen - Partitionen ohne VPN-Link zu Supernodes arbeiten autark.<br />
<br />
=== Frame-Typen ===<br />
Für die genutzten Frame-Typen gilt:<br />
* vlan-Tagging wird nicht verwendet.<br />
* VPN und ad-hoc: ''batman-adv''-Frames <br />
* Infrastruktur-Netz: Gewöhnliche Wireless-Lan Frames (IEEE 802.11)<br />
<br />
=== MTU / PMTU ===<br />
* wireless-lan Interfaces verwenden als MTU 1500 Byte<br />
* fastd tap-Interfaces verwenden als MTU 1426 Byte<br />
<br />
''Hinweise: ''<br />
<br />
fastd-Pakete werden per default nicht fragmentiert. Wird eine VPN-Verbindung mit zu kleiner PMTU verwendet, werden die Pakete verworfen. Die MTU 1426 des fastd-Interfaces errechnet sich durch:<br />
* PMTU des Uplinks: 1500 Byte - 8 Byte = 1492 Byte = MTU einer DSL-PPPoE Verbindung<br />
* Overhead fastd: 1492 Byte - 20 Byte (IP) - 8 Byte (UDP) - 24 Byte (fastd) - 14 Byte (Inner Ethernet) = 1426 Byte<br />
<br />
Falls keine fastd-Verschlüsselung verwendet wird (Method: 'null') rediziert sich der fastd-Overhead von 24 Byte auf 1 Byte.<br />
<br />
Problematisch ist, dass Netcologne bei ADSL typischerweise nur eine PMTU von 1442 (d.h. 50 Byte weniger) zur Verfügung stellt. Hiermit ist fraglich, in wie weit 1426 als MTU für fastd-Interfaces sinnvoll ist (alternativ: 1376). Aktuell werden alle Supernodes ohne PMTU-Discovery betrieben (<tt>sysctl -w net.ipv4.ip_no_pmtu_disc=1</tt>), so dass das Don't Fragment (DF)-Bit seitens fastd auf 0 gesetzt wird und keine Probleme durch Paketverlust auftreten. Auf den Nodes ist PMTU-Discovery derzeit aktiv - Probleme sind jedoch nicht erkennbar. Mittelfristig sollte das Fragmentierungsverhalten seitens fastd konfigurierbar sein: https://projects.universe-factory.net/issues/120<br />
<br />
Somit senden radvds eine MTU von 1350 (1376 - batman-adv Overhead) (<tt>AdvLinkMTU 1350</tt>)<br />
<br />
== OSI-3: Network Layer ==<br />
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 Backbone-VPN (Tinc) und auf die Konfiguration der Supernodes eingegangen.<br />
<br />
=== IPv4 ===<br />
[[Datei:Osi-3-v4.png|thumb|400px|right|Abb. 5]]<br />
Abb. 5 illustriert die verwendeten IPv4-Netze. Zur Vereinfachung sind nicht alle Supernodes und Server dargestellt. Von ''oben nach unten'' gesehen werden die Netze wie folgt verwendet (vgl. [[IP Subnetze]]).<br />
<br />
==== Mesh ====<br />
In der Mesh-Wolke (dem OSI-2 Segment) werden Adressen aus dem Bereich <tt>172.27.0.0/18</tt> verwendet. <br />
* Supernodes ist eine statische Adresse fest zugewiesen. fastd3 verwendet die Adresse <tt>172.27.8.1</tt> während fastd4 <tt>172.27.16.1</tt> nutzt. <br />
* Nodes besitzen keine IPv4 Adresse - sie sind nicht Teil des IPv4-Netzes. (Evtl. bald doch - siehe Abschnitt [[Architektur#Anycast | Anycast]])<br />
* Jedem Supernode ist ein /21 Netz zugeteilt. Hier: fastd3: <tt>172.27.8.0/21</tt>, fastd4: <tt>172.27.16.0/21</tt>. Sie verfügen somit über je 2048 Adressen. <br />
** Jeder Supernode betreibt einen DHCP-Server, der Adressen aus dem zugeteilten Bereich in der Mesh-Cloud vergibt. fastd3 vergibt beispielsweise Adressen aus dem Bereich <tt>172.27.8.10</tt> - <tt>172.27.15.255</tt><br />
** Jeder Klient im Mesh-Netz bezieht eine IP von einem Supernode. Er nutzt ihn als ''Default-Router'' und ''DNS-Server''. Die Auswahl des Supernodes erfolgt durch den batman-adv Gateway Mode (Vgl. http://www.open-mesh.org/projects/batman-adv/wiki/Gateways).<br />
<br />
==== Backbone-VPN / Tinc ====<br />
Alle Supernodes und sonstigen Server des Freifunk-KBU-Netztes sind untereinander über ein dezentrales VPN (Tinc - vgl. http://tinc-vpn.org/) verbunden.<br />
* Das Netz verwendet den Adressbereich <tt>172.27.255.0/24</tt>. Bspw. verwendet fastd3 die Adresse <tt>172.27.55.9</tt> -- fastd4 hingegen <tt>172.27.255.10</tt><br />
* Das VPN wird als Transport-Netz benutzt: IP-Pakete mit fremden Quell- und Zieladressen werden darüber transportiert.<br />
* Verfügt ein Supernode über Kontakt zu weiteren Netzten so annonciert er eine entsprechende Route. In der Abbildung kann fastd4 über das Tor-Netzwerk Verbindungen zum WWW aufbauen. Er annonciert daher die Route <tt>0.0.0.0/0</tt> (Default Route). Verfügt ein Node über Kontakt im ChaosVPN (http://wiki.hamburg.ccc.de/ChaosVPN) oder IC-VPN (http://wiki.freifunk.net/IC-VPN) so annonciert er diese Netzbereiche.<br />
* Das VPN ist verschlüsselt. Nutzlast wie z.B. Service-Aufrufe müssen daher nicht zusätzlich per SSL/TLS gesichert werden.<br />
* Jeder Router annonciert zusätzlich das ihm zugeteilte Netz -- fastd3: <tt>172.27.8.0/21</tt>, fastd4: <tt>172.27.16.0/21</tt><br />
* Der Schlüsselaustausch erfolgt via github (https://github.com/ff-kbu/bbkeys).<br />
Paul nimmt hierbei eine Sonderrolle ein: Als einziger, regulärer Router zum Internet kann er als IPv4- und IPv6-Default-Router verwendet werden. Paul ist kein Supernode sondern wickelt lediglich externen Traffic ab.<br />
<br />
==== Anycast ====<br />
<todo nicht implementiert> <br />
Jeder Node ist über das Infrastruktur-Netz auf der IP <tt>172.27.0.1</tt> erreichbar. Hierüber können Klienten Status-Informationen des Nodes beziehen, bei dem sie eingebucht sind.<br />
</todo nicht implementiert><br />
<br />
=== IPv6 ===<br />
[[Datei:Osi-3-v6.png|thumb|450px|right|Abb. 6]]<br />
Abb. 6 illustriert die IPv6 Konfiguration. Wie zuvor bei IPv4 sind zur Vereinfachung nicht alle Supernodes und Server dargestellt. Für IPv6 werden die folgenden Addressbereiche verwendet:<br />
* <tt>fdd3:5d16:b5dd::/48</tt> Unique Local Addresses (ULA)<br />
* <tt>2001:67C:20A0:B100::/56</tt> Global.<br />
Die Verwendung der Public IPv6 Address ermöglicht, dass alle Teilnehmer des Freifunk-Netzes extern erreichbar sind. <br />
<br />
Von ''oben nach unten'' werden die Netze wie folgt verwendet:<br />
<br />
==== Mesh ====<br />
Im Mesh werden ULA und global gültige IPv6-Addressen verwendet. Jedem Supernode ist ein eigenes, globales /64 Subnet zugewiesen. Der Supernode verwendet die Host-ID 1. Hier: fastd3: <tt>2001:67c:20a0:b104::1/6</tt>, fastd4: <tt>2001:67c:20a0:b105::1/64</tt>).<br />
<br />
Supernodes versenden Router Advertisments (RA) im kompletten Segment. Nodes und Klienten erhalten aus jedem Pool eine Addresse (stateless autoconfiguration). Jeder Supernode routed IPv6-Pakete zwischen Mesh-Cloud und Internet.<br />
<br />
Hinweis: Da der Klient das Default-Gateway zufällig wählt, werden Pakete idR auf verschiedenen Routes zugestellt:<br />
* Sendet der Klient ein Paket, so wird der vom Klienten zufällig gewählte Supernode genutzt<br />
* Empfängt der Klient ein Paket, so richtet sich der Supernode nach der verwendeten Public IPv6 Addresse des Klienten: es wird der Supernode verwendet, aus dessem Subnet die Adresse stammt<br />
<br />
==== Backbone-VPN / Tinc ====<br />
Im Backbone-VPN wird IPv6 analog zu IPv4 verwendet (vgl. [[Architektur#Backbone-VPN_.2F_Tinc | Backbone-VPN / Tinc (IPv4)]]. Jedem Teilnehmer ist eine IP aus dem Bereich <tt>fdd3:5d16:b5dd:3::/64</tt> zugewiesen. Die Endziffer entspricht der von IPv4. Bspw. verfügt Paul über die Adressen <tt>172.27.255.3</tt> und <tt>fdd3:5d16:b5dd:3::3</tt><br />
<br />
Supernodes annoncieren fremde Public-V6 Netze des Mesh-Segments mit geringer Priorität im Tinc-Backone. Somit ist sichergestellt, dass bei einem Ausfall eines Supernodes die Addressen weiterhin verwendet werden können. Im kompletten Mesh wird <tt>fdd3:5d16:b5dd::/64</tt> zur internen Adressierung genutzt.<br />
<br />
==== Sonstige Bereiche / ULA ====<br />
Einzelnen Anwendungen stehen komplette /64-Netze zur Verfügung gestellt. Entsprechende Adressen sind in der Firmware fest verdrahtet. Die Nutzung eigener /64 Netze ermöglicht es, Server zu transparent migrieren ohne auf DNS angewiesen zu sein. Beispiel: collectd verwendet <tt>fdd3:5d16:b5dd:2::/64</tt>, der collectd-Server ist unter <tt>fdd3:5d16:b5dd:2::1</tt> erreichbar.<br />
<br />
== OSI-7: Anwendungen ==<br />
TBD - Hier kommen hin:<br />
* Register<br />
* collectd<br />
* DNS<br />
* Ggf. Squid<br />
<br />
== Ausblick / Probleme / TODOs / Offene Punkte ==<br />
# Anycast Info-Page implementieren<br />
# In Tinc 1.0 wird das annoncieren beliebiger Netze hackish, da [http://www.tinc-vpn.org/documentation-1.1/tincctl.8 tincctl] noch nicht nutzbar ist. (Ggf. Scripten)? Alternativ können wir auch OSPF auf allen Tinc-Verbindungen nutzen - Nachteil: Komplexität.<br />
# Wenn Lübeck LFF 0.3.2.1 release hat: Filter für Broadcast / Multicast dokumentieren. -> Weniger Last auf den fastd-Gateways.<br />
# DNS-Caches auf den Supernodes _wirklich_ implementieren - bislang leiten wir ganz "lame" an Paul weiter.<br />
<br />
== Notizblock ==<br />
Nix zu sehen - bitte weitergehen.<br />
<strike> <br />
<br />
Im OSI-2 Segment werden die folgenden Adressen verwendet:<br />
* 2001:67c:20a0:b102::/64<br />
* fdd3:5d16:b5dd::/64<br />
* fdd3:5d16:b5dd:1::/64<br />
<br />
=== Konfiguration Super-Nodes ===<br />
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.<br />
<br />
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.<br />
<br />
=== Konfiguration Nodes ===<br />
''<todo> (TODO: Implementierung in der Firmware ausstehend).''<br />
<br />
Nodes verwenden im Uplink-Netz zusätzlich den ULA-Bereich<br />
*fdd3:5d16:b5dd:1::/64 <br />
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 <br />
<br />
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><br />
<br />
=== IPv6 / RADVD ===<br />
Hinweis: Aktell nicht so umgesetzt - Tinc in Squeeze hat da afair Probleme TODO: Umsetzen.<br />
Super-Nodes betreiben radvd-Server im Adressbereich 2001:67c:20a0:b102::/64 und annoncen sich selbst als Router<br />
</strike><br />
[[Category:Netzdesign]]</div>Zuse