Struktur des Freifunknetzes

Das Freifunknetz ist ein eigenständiges Netzwerk, über das sich deren Nutzer intern miteinander verbinden können, das aber auch die Verbindung ins Internet ermöglicht. Dazu kommen verschiedene Komponenten zum Einsatz, die im Folgenden anhand einer schematischen Übersicht erklärt werden sollen.

Die Nutzer, die sich mit dem Freifunknetz verbinden, nennen wir Clients. Typischerweise verbindet man sich per WLAN mit einem Freifunk-Router, den wir als Node bezeichnen, und der beim Freifunk Stuttgart die SSIDFreifunk“ ausstrahlt. Aus Sicht der Clients ist ein Node gar kein Router, sondern lediglich ein Accesspoint, der den Zugang zum Freifunknetz herstellt.

Da das Freifunknetz als vermaschtes Netzwerk (Mesh) konzipiert ist, um allen aufgeschlossenen Bürgern ein einfaches Mitmachen und Mitbauen am Netzwerk zu ermöglichen, können die Datenpakete von und zu den Clients nicht unmittelbar übertragen werden, sondern müssen in ein Mesh-Protokoll eingebunden werden. Beim Freifunk Stuttgart, wie auch bei vielen anderen Freifunk-Communities, kommt hier batman-adv zum Einsatz.

Nodes können sich untereinander direkt per WLAN verbinden und so miteinander „meshen“. Dazu strahlen sie neben der für die Clients bestimmten SSID „Freifunk“ eine weitere SSID aus, die entweder als ad-hoc-Netz (IBSS mit der hidden SSID 02:04:08:16:32:64) oder seit der Firmware-Version 1.3 als IEEE 802.11s-Netz mit der SSID „ffsmesh_batman“ arbeitet. Man kann aber auch für den Mesh-Traffic Kabel zwischen den Nodes benutzen, was je nach verwendeter Konfiguration als Mesh-on-LAN oder Mesh-on-WAN bezeichnet wird. Eine Gruppe aus miteinander meshenden Nodes nennen wir Mesh-Wolke.

Um Mesh-Wolken untereinander zu verbinden bzw. um Clients im Freifunknetz den Zugang zum Internet zu ermöglichen, muss jede Mesh-Wolke über mindestens einen Node verfügen, der mit einem Freifunk-Gateway verbunden ist. Für diese Verbindung nutzt zwar ein Node einen normalen Internet-Router (DSL- oder Kabel-Router), aber lediglich als Mittel zum Zweck, um eine VPN-Verbindung zum FF-Gateway aufbauen zu können (beim Freifunk Stuttgart per „fastd“). Es wird also keinerlei Mesh-Traffic oder darin eingebettete Datenpakete der Clients unmittelbar am Node ins Internet ausgeleitet, sondern in einem Tunnel zum FF-Gateway geführt. Dieser Umstand sorgt dafür, dass sich ein Node-Betreiber keine Gedanken zur Haftung für mögliche Fehlverhalten der Clients an seinem Node machen muss.

Ein Freifunk-Gateway hat mehrere Aufgaben, die in einem eigenen Beitrag im Detail beschrieben sind. An dieser Stelle ist lediglich von Bedeutung, dass ein Gateway die Verknüpfung zwischen den Mesh-Wolken herstellt, die Clients mit IP-Adressen versorgt und den Clients den Zugang zum Internet bereitstellt.

Bei der Verbindung zwischen Nodes im Freifunknetz bzw. den Clients, die über die Nodes mit dem Freifunknetz verbunden sind, sind mehrere Situationen möglich, die zu unterschiedlichen Datenflüssen führen:

  • Die Nodes/Clients sind mit demselben Gateway verbunden. Hier wickelt dieses Gateway alles ab.
  • Die Nodes/Clients sind mit unterschiedlichen Gateways im selben Segment verbunden. Hier läuft die Querverbindung zwischen den beteiligten Gateways über den Segment-Backbone auf Basis eines fastd-VPN (bbXX), das auf den Gateways in dieselbe batman-adv Instanz eingebunden ist, wie die fastd-VPNs von den Nodes. Damit befinden sich die Nodes/Clients im selben logischen Netz, als wären sie über einen Switch direkt miteinander verbunden.
  • Die Nodes/Clients sind mit unterschiedlichen Gateways in verschiedenen Segmenten verbunden. Hier muss ein Routing stattfinden, das über den zentralen Backbone läuft, der aktuell (01.09.2018) noch als Layer3-tinc-Netz (ffsl3) realisiert ist. Es gibt aber bereits ein Konzept und erste Tests für einen Umbau, der mit dem Routingprotokoll BGP auf Basis expliziter Punkt-zu-Punkt VPN-Verbindungen arbeiten wird.

Am zentralen Backbone werden auch die zentralen Dienste für das Freifunknetz bereitgestellt, insbesondere befinden sich hier die drei DHCP-Server. Die Clients erhalten nämlich ihre IP-Adressen nicht unmittelbar von „ihrem“ Gateway, sondern die Gateways sind lediglich DHCP-Relays, welche ihrerseits die IP-Adressen von den DHCP-Servern anfordern. Dieser Schritt ist notwendig, weil nicht abschätzbar ist, wie viele Clients sich mit welchem Gateway verbinden werden, so dass man den Gateways keine festen Kontingente an IP-Adressen zuweisen kann.

IP-Adressen

Wir haben im Freifunknetz IPv4 und IPv6. IPv6 wird allerdings nur intern genutzt und es besteht keine Möglichkeit über IPv6 ins Internet zu kommen. Deshalb erhalten die Nodes/Clients auch keine IPv6-Default-Route.

Über IPv4 sind alle Clients - aber nicht die Nodes - erreichbar. Über IPv4 gibt es auch Internet.

Beim Freifunk Stuttgart werden interne IP-Adressen aus folgenden Subnetzen verwendet:

  • IPv4 = 10.190.0.0/15 (aktuell genutzt nur 10.190.0.0/18 und 10.191.255.0/24 vom zentralen Backbone)
  • IPv6 = fd21:b4dc:4b00::/40 (aktuell genutzt nur fd21:b4dc:4b00::/42, davon fd21:b4dc:4b00::/64 vom zentralen Backbone)

Die Namensauflösung ist in der Regel über die GWs geregelt. Diese sind Nameserver. Die GWs sind per IPv4 und IPv6 erreichbar. Prinzipiell wäre es denkbar, dass die Namensauflösung auch per IPv6 gemacht wird. Über DHCP bekommen die Clients aber einen IPv4 Nameserver mitgeteilt.

Ein Ping ins Internet kann nur per IPv4 funktionieren. Hier ist IPv6 von vorn herein ausgeschlossen.

PS: Es kann gut sein, dass man einem Windows

ping <addr> -4

sagen muss, dass es IPv4 machen soll, weil es vielleicht per default (trotz fehlender IPv6 default route) IPv6 macht - und für heise.de gibt es eben vom Nameserver IPv4 und IPv6 Adressen zurück.

Segmentierung

Mit zunehmender Anzahl Nodes und Clients im Freifunknetz nimmt auch die Grundlast im Netzwerk zu. Das hängt einerseits mit dem Verhalten des für das Mesh-Konzept benutzten batman-adv zusammen und ist andererseits eine normale Situation innerhalb eines Ethernet-Netzwerks (Layer 2). Während diese Grundlast jedoch bei den verfügbaren Bandbreiten in einem LAN nicht besonders stört, kann es ein auf WLAN basiertes Mesh-Netz und deren VPN-Uplinks zum Erliegen bringen.

Beim Freifunk Stuttgart haben wir uns daher im Jahr 2016 entschieden, das Netzwerk in verschiedene Teilnetze aufzuteilen, die wir Segmente nennen. Jedes Segment hat seinen eigenen IP-Bereich, und die Gateways verknüpfen diese Segmente per Routing (Layer 3), so dass weiterhin alle Nodes und Clients im gesamten Freifunknetz erreichbar sind.

Bei Änderungen der Segmentzuweisung eines Nodes gibt es folgende Punkte zu beachten:

1. FF-Router mit eigenem VPN-Uplink nutzen je nach Segment und Firmwarestand einen unterschiedlichen Port (Details zu diesem Thema siehe hier). Bitte im vorgelagerten Internetrouter am Besten dem FF-Router die Nutzung aller beim Freifunk-Stuttgart in Frage kommenden Ports erlauben, um bei einem Segment- oder Firmwarewechsel nicht versehentlich ausgesperrt zu sein. Typische Fälle mit Einschränkungen sind Gast-Netze (z.B. bei der FritzBox), an denen der FF-Router angeschlossen wird.

Wir verwenden UDP-Ports, und zwar die Ports 10041 - 10139 (bis Firmware v1.1) bzw. 10201 - 10299 (ab Firmware v1.3). Insbesondere wer noch eine ältere Firmware einsetzt, öffnet am Besten den kompletten Bereich von 10041 - 10299, um nicht nur für Segmentwechsel auf der sicheren Seite zu sein, sondern auch problemlos die Firmware aktualisieren zu können.

2. Die IPv6-Adressen der FF-Router beginnen alle mit fd21:b4dc:4b und direkt anschließend die zweistellige Segmentnummer, gefolgt vom individuellen Teil des Geräts, also z.B. fd21:b4dc:4b04:0:32b5:c2ff:febd:da4 bei einem FF-Router im Segment 04. Bei einer Segmentänderung ändern sich die zwei Ziffern des Segments entsprechend. Der Teil ist nur interessant für diejenigen, die per Browser auf die Statusseite des FF-Routers wollen oder sich per SSH verbinden.

3. Neben den Änderungen bei den FF-Routern ändern sich für die Clients auch die zugewiesenen IP-Adressen. Bei IPv6 gilt für die Clients dasselbe, wie für die FF-Router, bei IPv4 ist der Bereich vom Segment abhängig. Wer keine besondere „Bastellösung“ mit fixen IP-Adressen einsetzt, braucht sich um nichts zu kümmern, weil die DHCP-Server automatisch die passenden IP-Adressen verteilen. Und die „Bastler“ wissen sich selbst zu helfen.

Segment-Backbones

Damit Nodes und Clients, die innerhalb eines Segments mit unterschiedlichen Gateways verbunden sind, sich dennoch innerhalb eines großen Layer-2-Netzes befinden, sind die Gateways pro Segment untereinander jeweils über einen Segment-Backbone verbunden. Dieser ist über VPN-Verbindungen auf Basis von eigenen fastd-Instanzen „bbXX“ realisiert, die jeweils an dieselbe Batman-Instanz angekoppelt sind, wie die VPN-Verbindungen von den Nodes.

Zentraler Backbone

Über den zentralen Backbone wird das Routing zwischen unterschiedlichen Segmenten realisiert, und hier sind auch die zentralen Dienste angebunden. Zur Realisierung stehen verschiedene Techniken zur Verfügung, aktuell (19.04.2019) ist der Backbone mit tinc und folgenden Anschlüssen in Betrieb:

ID IPv4 IPv6 Hostname
3003 10.191.255.3 fd21:b4dc:4b00::a38:3 salt-master-01
13 10.191.255.13 fd21:b4dc:4b00::a38:103 gw01n03
41 10.191.255.41 fd21:b4dc:4b00::a38:401 gw04n01
42 10.191.255.42 fd21:b4dc:4b00::a38:402 gw04n02
53 10.191.255.53 fd21:b4dc:4b00::a38:53 gw05n03
71 10.191.255.71 fd21:b4dc:4b00::a38:701 gw07n01
81 10.191.255.81 fd21:b4dc:4b00::a38:801 gw08n01
82 10.191.255.82 fd21:b4dc:4b00::a38:802 gw08n02
3171 10.191.255.171 prometheus-01
3172 10.191.255.172 prometheus-02
3181 10.191.255.181 voip-incoming-01
3191 10.191.255.191 test01
3192. 10.191.255.192 test02
3193 10.191.255.193 test03
3194 10.191.255.194 test04-wiki
3201 10.191.255.201 fd21:b4dc:4b00::a38:201 dns01
3213 10.191.255.213 fd21:b4dc:4b00::a38:213 revproxy-03
3220 10.191.255.220 fd21:b4dc:4b00::a38:220 gitlab
3221 10.191.255.221 fd21:b4dc:4b00::a38:221 wiki
3222 10.191.255.222 fd21:b4dc:4b00::a38:222 unifi
3223 10.191.255.223 fd21:b4dc:4b00::a38:223 unms
3224 10.191.255.224 fd21:b4dc:4b00::a38:224 db-postgres01
3225 10.191.255.225 fd21:b4dc:4b00::a38:225 gitlab-runner02 (VM)
3225 10.191.255.226 fd21:b4dc:4b00::a38:226 www-staging
3230 10.191.255.230 mailrelay intern für FFS-Hosts
3231 10.191.255.231 mailrelay extern spamabwehr
3232 10.191.255.232 mailinglisten
3233 10.191.255.233 mailboxen
3234 10.191.255.234 ticketsystem
3235 10.191.255.235 passbolt
3241 10.191.255.241 monitor02
3242 10.191.255.242 fd21:b4dc:4b00::a38:242 munin02
3243 10.191.255.243 fd21:b4dc:4b00::a38:243 netinfo, karte, firmware
251 10.191.255.251 fd21:b4dc:4b00::a38:501 dhcp01 (gw05n01)
252 10.191.255.252 fd21:b4dc:4b00::a38:252 dhcp02
253 10.191.255.253 fd21:b4dc:4b00::a38:253 dhcp03


  • technik/ip-adressen.txt
  • Zuletzt geändert: vor 6 Wochen
  • von Wilhelm