Freifunk Köln, Bonn und Umgebung - Benutzerbeiträge [de]

Router auswählen

2017-02-10T11:16:42Z

Globalhawk: /* Informationen zu einigen unterstützten Geräten */

<noinclude>
<div style="text-align: center;">
[[Mitmachen|Übersicht]]         [[Firmware herunterladen]] >
</div>
</noinclude>

Als Einstieg bietet sich der recht kostengünstige Router TP-Link TL-WR841N an, der für ca. 20 € erhältlich ist. Dieser funkt im weit verbreiteten 2.4 GHz-Frequenzband.

Wer neuere Geräte im 5 GHz-Frequenzband via Freifunk versorgen möchte, kann hierzu zum Beispiel der Archer C5 oder C7 einsetzen. Allerdings nur innerhalb von Gebäuden, da die Freifunk-Firmware derzeit nicht die gesetzlichen Anforderungen für 5 GHz-Outdoor-Betrieb erfüllt.

Die Freifunk-Firmware gibt es auch für weitere Router-Modelle, schau einfach mal auf dem Images-Server, welche Images bereitstehen: https://images.ffkbu.de/

== Informationen zu einigen unterstützten Geräten ==

Diese Geräte werden unter anderem in aktuellen Versionen von der Freifunk-Firmware unterstützt.

{|class="wikitable sortable"
|-
|Gerät
|Preis<br>(lt. Amazon,<br>Feb. 2017)
|Eigenschaften
|Links
|-
|[[File:Tplink_wr841n_b.jpg|center|thumb|200px|TP-Link '''TL-WR841N''', '''TL-WR841ND''']]
| 17 €
| 2 x 2.4 GHz Antennen, 5 LAN-Ports <br> Modell mit '''D''' am Ende hat abnehmbare Antennen und ist etwas teurer.
| [https://wiki.openwrt.org/toh/tp-link/tl-wr841nd OpenWRT] [http://www.tp-link.de/products/details/TL-WR841N.html Hersteller]
|-
|[[File:Tplink_archer-c7_b.jpg|center|thumb|200px|TP-Link '''Archer C7''']]
| 82 €
| 3 x 2.4 GHz Antennen (intern), 3 x 5 GHz Antennen, 5 LAN-Ports
| [http://www.tp-link.de/products/details/cat-9_Archer-C7.html Hersteller]
|-
|[[File:Tplink_wa860re_b.jpg|center|thumb|200px|TP-Link '''TL-WA860RE''']]
| 25 €
| 2 x 2.4 GHz Antennen, LAN-Anschluss, Frontsteckdose
| [http://www.tp-link.de/products/details/cat-10_TL-WA860RE.html Hersteller]
|-
|[[File:Tplink_wa850re_b.jpg|center|thumb|200px|TP-Link '''TL-WA850RE''']]
| 16 €
| 2 x 2.4 GHz Antennen (intern), LAN-Anschluss
| [http://www.tp-link.de/products/details/cat-10_TL-WA850RE.html Hersteller]
|-
|[[File:Tplink_cpe210_b.jpg|center|thumb|200px|TP-Link '''TL-CPE210''']]
| 48 €
| 2 x 2.4 GHz Richtfunk-Antennen (intern), 2 LAN-Ports, PoE, Öffnungswinkel 65°, Sendeleistung 27dBm (500 mW)
| [http://www.tp-link.de/products/details/cat-37_CPE210.html Hersteller]
|-
|[[File:Tplink_cpe510_b.jpg|center|thumb|200px|TP-Link '''TL-CPE510''']]
| 62 €
| 2 x 5 GHz Richtfunk-Antennen (intern), 2 LAN-Ports, PoE, Öffnungswinkel 45°, Sendeleistung 27dBm (500 mW)
| [http://www.tp-link.de/products/details/cat-37_CPE510.html Hersteller]
|-
|[[File:Ubiquity_ns_loco.jpg|center|thumb|200px|Ubiquity '''Nanostation Loco M2''']]
| 54 €
| Sendeleistung: 23 dBm (200 mW)
| [https://www.ubnt.com/airmax/nanostationm/ Hersteller]
|-
|[[File:Ubiquity_ns_loco.jpg|center|thumb|200px|Ubiquity '''Nanostation Loco M5''']]
| 71 €
| Sendeleistung: 23 dBm (200 mW)
| [https://www.ubnt.com/airmax/nanostationm/ Hersteller]
|-
|[[File:Ubiquity_ns.jpg|center|thumb|200px|Ubiquity '''Nanostation M2''']]
| 94 €
| Sendeleistung: 28 dBm (> 1 W)
| [https://www.ubnt.com/airmax/nanostationm/ Hersteller]
|-
|[[File:Ubiquity_ns.jpg|center|thumb|200px|Ubiquity '''Nanostation M5''']]
| 82 €
| Sendeleistung: 27 dBm (1 W)
| [https://www.ubnt.com/airmax/nanostationm/ Hersteller]
|-
|[[File:Tplink_archer-c5_b.jpg|center|thumb|200px|TP-Link '''Archer C5''']]
| 76 €
| 2 x 2.4 GHz Antennen (intern), 2 x 5 GHz Antennen, 5 LAN-Ports
| [http://www.tp-link.de/products/details/cat-9_Archer-C5.html Hersteller]
|-
|D-Link '''DIR-505'''
| 28€
|
| [http://www.dlink.com/de/de/products/dir-505-shareport-mobile-companion Hersteller]
|-
|[[File:DIR615H2ImageLFrontGB.png|center|thumb|200px|DLink '''DIR-615''']]
| 29€
|
| [http://www.dlink.com/de/de/support/product/dir-615-wireless-n-300-router Hersteller]
|}

== Hinweis zur Sendeleistung ==
Die Sendeleistung darf in Deutschland ohne Genehmigung nicht mehr als 100 mW (2.4 GHz) bzw. 200 mW (5 GHz) betragen. Das entspricht 20 dBm, bzw 23 dBm. [https://wiki.freifunk.net/WLAN-Antennen Siehe auch: FF-Wiki]

Die Firmware regelt die Leistung von selbst auf den erlaubten Wert herunter.

<noinclude>
<div style="text-align: center;">
[[Mitmachen|Übersicht]]         [[Firmware herunterladen]] >
</div>
</noinclude>

Datei:DIR615H2ImageLFrontGB.png

2017-02-10T11:15:19Z

Globalhawk:

Architektur

2017-02-10T10:59:34Z

Globalhawk: /* OSI-3: Network Layer */

{{TOCright}}
<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 :-).

== Kurzzusammenfassung ==

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.

== 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-Eigenschaften eingegangen. Hierbei gibt die Architektur vor, wie Nodes, Supernodes, Server und Klienten konfiguriert werden müssen.

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.

=== Strategie ===
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 />
''Daten zwischen Netzteilnehmer werden als Frames switched, das Netz bildet eine große Broadcast-/Link-Local-Multicast-Domäne.''

=== Supernodes ===
[[Datei:Super-node-overview.png|thumb|300px|right|Abb. 1]]
[[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.

Supernodes werden beispielsweise auf dedizierten Servern ohne WLAN-Konnektivität betrieben.
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'')

'''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.

=== Nodes ===
[[Datei:4.1-All-Bridging.png|thumb|300px|right|Abb. 2]]
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.

* ''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 ==
[[Datei:Osi-2.png|thumb|350px|right|Abb. 3]]

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.
* 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.
* Node <tt>d8..</tt> verfügt über keine kabelgebundene Verbindung zum Internet. Er ist via ad-hoc wlan mit der Wolke verbunden
* Entlang der blau eingezeichneten Verbindungen werden batman-adv Frames ausgetauscht.
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)

=== Node-IDs ===
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.

=== Wireless LAN ===
Im Freifunk-KBU Netz wird IEEE 802.11g/n verwendet:
* Das Infrastruktur-Netz führt die SSID <tt>kbu.freifunk.net</tt>. Für Klienten erscheint es als normaler Accesspoint.
* 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.

=== 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 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.
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
(fastd-Peers per Shell im Dateisystem des Nodes hinterlegt). Eine Verbindung zu Supernodes ist nicht zwingend erforderlich. Somit gilt:

''Das VPN verbindet Ad-Hoc Mesh-Partitionen - Partitionen ohne VPN-Link zu Supernodes arbeiten autark.

=== Frame-Typen ===
Für die genutzten Frame-Typen gilt:
* vlan-Tagging wird nicht verwendet.
* VPN und ad-hoc: ''batman-adv''-Frames
* Infrastruktur-Netz: Gewöhnliche Wireless-Lan Frames (IEEE 802.11)

=== MTU / PMTU ===
* wireless-lan Interfaces verwenden als MTU 1500 Byte
* fastd tap-Interfaces verwenden als MTU 1426 Byte

''Hinweise: ''

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:
* PMTU des Uplinks: 1500 Byte - 8 Byte = 1492 Byte = MTU einer DSL-PPPoE Verbindung
* Overhead fastd: 1492 Byte - 20 Byte (IP) - 8 Byte (UDP) - 24 Byte (fastd) - 14 Byte (Inner Ethernet) = 1426 Byte

Falls keine fastd-Verschlüsselung verwendet wird (Method: 'null') rediziert sich der fastd-Overhead von 24 Byte auf 1 Byte.

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

Somit senden radvds eine MTU von 1350 (1376 - batman-adv Overhead) (<tt>AdvLinkMTU 1350</tt>)

== OSI-3: Network Layer ==
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.

=== IPv4 ===
[[Datei:Osi-3-v4.png|thumb|400px|right|Abb. 5]]
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]]).

==== Mesh ====
In der Mesh-Wolke (dem OSI-2 Segment) werden Adressen aus dem Bereich <tt>172.27.0.0/18</tt> verwendet.
* 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.
* Nodes besitzen keine IPv4 Adresse - sie sind nicht Teil des IPv4-Netzes. (Evtl. bald doch - siehe Abschnitt [[Architektur#Anycast | Anycast]])
* 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.
** 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>
** 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).

==== Backbone-VPN / Tinc ====
Alle Supernodes und sonstigen Server des Freifunk-KBU-Netztes sind untereinander über ein dezentrales VPN (Tinc - vgl. http://tinc-vpn.org/) verbunden.
* 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>
* Das VPN wird als Transport-Netz benutzt: IP-Pakete mit fremden Quell- und Zieladressen werden darüber transportiert.
* 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.
* Das VPN ist verschlüsselt. Nutzlast wie z.B. Service-Aufrufe müssen daher nicht zusätzlich per SSL/TLS gesichert werden.
* Jeder Router annonciert zusätzlich das im zugeteilte Netz -- fastd3: <tt>172.27.8.0/21</tt>, fastd4: <tt>172.27.16.0/21</tt>
* Der Schlüsselaustausch erfolgt via github (https://github.com/ff-kbu/bbkeys).
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.

==== Anycast ====
<todo nicht implementiert>
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.
</todo nicht implementiert>

=== IPv6 ===
[[Datei:Osi-3-v6.png|thumb|450px|right|Abb. 6]]
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:
* <tt>fdd3:5d16:b5dd::/48</tt> Unique Local Addresses (ULA)
* <tt>2001:67C:20A0:B100::/56</tt> Global.
Die Verwendung der Public IPv6 Address ermöglicht, dass alle Teilnehmer des Freifunk-Netzes extern erreichbar sind.

Von ''oben nach unten'' werden die Netze wie folgt verwendet:

==== Mesh ====
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>).

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.

Hinweis: Da der Klient das Default-Gateway zufällig wählt, werden Pakete idR auf verschiedenen Routes zugestellt:
* Sendet der Klient ein Paket, so wird der vom Klienten zufällig gewählte Supernode genutzt
* 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

==== Backbone-VPN / Tinc ====
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>

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.

==== Sonstige Bereiche / ULA ====
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.

== OSI-7: Anwendungen ==
TBD - Hier kommen hin:
* Register
* collectd
* DNS
* Ggf. Squid

== Ausblick / Probleme / TODOs / Offene Punkte ==
# Anycast Info-Page implementieren
# 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.
# Wenn Lübeck LFF 0.3.2.1 release hat: Filter für Broadcast / Multicast dokumentieren. -> Weniger Last auf den fastd-Gateways.
# DNS-Caches auf den Supernodes _wirklich_ implementieren - bislang leiten wir ganz "lame" an Paul weiter.

== Notizblock ==
Nix zu sehen - bitte weitergehen.
<strike>

Im OSI-2 Segment werden die folgenden Adressen verwendet:
* 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.

=== 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
</strike>
[[Category:Netzdesign]]

Architektur

2017-02-10T10:52:28Z

Globalhawk: /* Nodes */

{{TOCright}}
<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 :-).

== Kurzzusammenfassung ==

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.

== 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-Eigenschaften eingegangen. Hierbei gibt die Architektur vor, wie Nodes, Supernodes, Server und Klienten konfiguriert werden müssen.

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.

=== Strategie ===
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 />
''Daten zwischen Netzteilnehmer werden als Frames switched, das Netz bildet eine große Broadcast-/Link-Local-Multicast-Domäne.''

=== Supernodes ===
[[Datei:Super-node-overview.png|thumb|300px|right|Abb. 1]]
[[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.

Supernodes werden beispielsweise auf dedizierten Servern ohne WLAN-Konnektivität betrieben.
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'')

'''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.

=== Nodes ===
[[Datei:4.1-All-Bridging.png|thumb|300px|right|Abb. 2]]
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.

* ''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 ==
[[Datei:Osi-2.png|thumb|350px|right|Abb. 3]]

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.
* 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.
* Node <tt>d8..</tt> verfügt über keine kabelgebundene Verbindung zum Internet. Er ist via ad-hoc wlan mit der Wolke verbunden
* Entlang der blau eingezeichneten Verbindungen werden batman-adv Frames ausgetauscht.
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)

=== Node-IDs ===
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.

=== Wireless LAN ===
Im Freifunk-KBU Netz wird IEEE 802.11g/n verwendet:
* Das Infrastruktur-Netz führt die SSID <tt>kbu.freifunk.net</tt>. Für Klienten erscheint es als normaler Accesspoint.
* 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.

=== 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 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.
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
(fastd-Peers per Shell im Dateisystem des Nodes hinterlegt). Eine Verbindung zu Supernodes ist nicht zwingend erforderlich. Somit gilt:

''Das VPN verbindet Ad-Hoc Mesh-Partitionen - Partitionen ohne VPN-Link zu Supernodes arbeiten autark.

=== Frame-Typen ===
Für die genutzten Frame-Typen gilt:
* vlan-Tagging wird nicht verwendet.
* VPN und ad-hoc: ''batman-adv''-Frames
* Infrastruktur-Netz: Gewöhnliche Wireless-Lan Frames (IEEE 802.11)

=== MTU / PMTU ===
* wireless-lan Interfaces verwenden als MTU 1500 Byte
* fastd tap-Interfaces verwenden als MTU 1426 Byte

''Hinweise: ''

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:
* PMTU des Uplinks: 1500 Byte - 8 Byte = 1492 Byte = MTU einer DSL-PPPoE Verbindung
* Overhead fastd: 1492 Byte - 20 Byte (IP) - 8 Byte (UDP) - 24 Byte (fastd) - 14 Byte (Inner Ethernet) = 1426 Byte

Falls keine fastd-Verschlüsselung verwendet wird (Method: 'null') rediziert sich der fastd-Overhead von 24 Byte auf 1 Byte.

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

Somit senden radvds eine MTU von 1350 (1376 - batman-adv Overhead) (<tt>AdvLinkMTU 1350</tt>)

== OSI-3: Network Layer ==
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 Konfiguration der Supernodes eingegangen.

=== IPv4 ===
[[Datei:Osi-3-v4.png|thumb|400px|right|Abb. 5]]
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]]).

==== Mesh ====
In der Mesh-Wolke (dem OSI-2 Segment) werden Adressen aus dem Bereich <tt>172.27.0.0/18</tt> verwendet.
* 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.
* Nodes besitzen keine IPv4 Adresse - sie sind nicht Teil des IPv4-Netzes. (Evtl. bald doch - siehe Abschnitt [[Architektur#Anycast | Anycast]])
* 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.
** 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>
** 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).

==== Backbone-VPN / Tinc ====
Alle Supernodes und sonstigen Server des Freifunk-KBU-Netztes sind untereinander über ein dezentrales VPN (Tinc - vgl. http://tinc-vpn.org/) verbunden.
* 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>
* Das VPN wird als Transport-Netz benutzt: IP-Pakete mit fremden Quell- und Zieladressen werden darüber transportiert.
* 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.
* Das VPN ist verschlüsselt. Nutzlast wie z.B. Service-Aufrufe müssen daher nicht zusätzlich per SSL/TLS gesichert werden.
* Jeder Router annonciert zusätzlich das im zugeteilte Netz -- fastd3: <tt>172.27.8.0/21</tt>, fastd4: <tt>172.27.16.0/21</tt>
* Der Schlüsselaustausch erfolgt via github (https://github.com/ff-kbu/bbkeys).
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.

==== Anycast ====
<todo nicht implementiert>
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.
</todo nicht implementiert>

=== IPv6 ===
[[Datei:Osi-3-v6.png|thumb|450px|right|Abb. 6]]
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:
* <tt>fdd3:5d16:b5dd::/48</tt> Unique Local Addresses (ULA)
* <tt>2001:67C:20A0:B100::/56</tt> Global.
Die Verwendung der Public IPv6 Address ermöglicht, dass alle Teilnehmer des Freifunk-Netzes extern erreichbar sind.

Von ''oben nach unten'' werden die Netze wie folgt verwendet:

==== Mesh ====
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>).

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.

Hinweis: Da der Klient das Default-Gateway zufällig wählt, werden Pakete idR auf verschiedenen Routes zugestellt:
* Sendet der Klient ein Paket, so wird der vom Klienten zufällig gewählte Supernode genutzt
* 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

==== Backbone-VPN / Tinc ====
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>

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.

==== Sonstige Bereiche / ULA ====
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.

== OSI-7: Anwendungen ==
TBD - Hier kommen hin:
* Register
* collectd
* DNS
* Ggf. Squid

== Ausblick / Probleme / TODOs / Offene Punkte ==
# Anycast Info-Page implementieren
# 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.
# Wenn Lübeck LFF 0.3.2.1 release hat: Filter für Broadcast / Multicast dokumentieren. -> Weniger Last auf den fastd-Gateways.
# DNS-Caches auf den Supernodes _wirklich_ implementieren - bislang leiten wir ganz "lame" an Paul weiter.

== Notizblock ==
Nix zu sehen - bitte weitergehen.
<strike>

Im OSI-2 Segment werden die folgenden Adressen verwendet:
* 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.

=== 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
</strike>
[[Category:Netzdesign]]