Gateways beim Freifunk Stuttgart

Gateways sind in Freifunknetzen die eigentlichen Router, während die Freifunk-Router (Nodes) für die Clients als Switches erscheinen.

Über die Gateways laufen alle Verbindungen, die nicht über direkte Mesh-Beziehungen zwischen benachbarten Nodes abgewickelt werden können, egal ob zu anderen Zielen innerhalb des Freifunknetzes oder ins Internet (Ausleitung). Alle Verbindungen zwischen Nodes und Gateways sowie zwischen den Gateways sind verschlüsselt (VPN).

gw

Beim Freifunk Stuttgart werden die Gateways nicht zentral betrieben und verwaltet, sondern unterschiedliche Personen oder/und Vereine können Gateways betreiben. Deshalb benutzen wir Gateway-Gruppen für die einzelnen Betreiber, die ihrerseits mehrere Instanzen (Maschinen), also die eigentlichen Gateways, in der jeweiligen Gruppe einrichten können. Ein einzelnes Gateway hat deshalb z.B. den Namen

• „gw01n03“ = Gateway-Gruppe 01 (entspricht Gateway des Betreibers 01) und dort die Instanz 03
• „gw05n02“ = Gateway-Gruppe 05 (entspricht Gateway des Betreibers 05) und dort die Instanz 02
• „gw08n01“ = Gateway-Gruppe 08 (entspricht Gateway des Betreibers 08) und dort die Instanz 01

Durch die Aufteilung des Freifunk-Netzes in mehrere Segmente (Subnets), kann ein Gateway (GW) bei uns mehrere Segmente bedienen. Im ersten Schritt halten alle GWs alle Segmente, im zweiten Schritt wird ein Routing-Protokoll implementiert, das die dynamische Zuordnung von Gateways zu einzelnen Segmenten ermöglicht.

Pro Segment läuft auf einem GW

• eine Fastd-Instanz für die VPN-Verbindungen von den Nodes mit MTU 1340 (seit Firmware v1.3)
• eine Fastd-Instanz für die VPN-Verbindungen von den Nodes mit MTU 1406 (bis Firmware v1.1)
• eine Fastd-Instanz für die Verbindungen der Gateways untereinander im selben Segment (Segment-Backbone).
• eine batman-adv Instanz zur Ein- und Auskopplung des Client-Traffic sowie Weiterleitung des Mesh-Traffic von/zu Nodes und anderen GWs im selben Segment

Um die notwendige Zeit zum Aufbau der Verbindung des VPN-Tunnels (fastd) zwischen Node und Gateway möglichst klein zu halten, ist im Node keine vollständige Liste aller möglichen Ziele enthalten, sondern nur eine Liste der GW-Gruppen. Das zugehörige Segment erfährt der Node per DNS-Abfrage auf seine eigene erweiterte Node-ID, woraus er die GW-Gruppenliste im RAM so modifiziert, dass nur Verbindungen zu den Gateways im eigenen Segment aufgebaut werden.

Die DNS-Namen für fastd sehen auf den Nodes im RAM dann z.B. so aus:

• „gw01s03.gw.freifunk-stuttgart.de“ = GW-Gruppe 01 im Segment 03
• „gw04s11.gw.freifunk-stuttgart.de“ = GW-Gruppe 04 im Segment 11
• „gw08s18.gw.freifunk-stuttgart.de“ = GW-Gruppe 08 im Segment 18

Welches konkrete GW (GW-Instanz) aus der GW-Gruppe ausgewählt wird, hängt von der DNS-Antwort auf diese URLs ab. Ein Node weiß von sich aus also weder, zu welchem Segment er gehört, noch welches GW ihn tatsächlich bedienen wird.

Ohne Modifikation der internen GW-Gruppenliste zeigen die URLs auf Onboarder, die für die automatische Registrierung neuer oder geänderter Nodes zuständig sind. Aktuell (Stand 18.02.2018) gibt es zwei Onboarder (gw04 und gw07), die sich gegenüber den Nodes zunächst als GWs ausgeben, die jeden beliebigen Node akzeptieren, aber tatsächlich dann nur die für die Registrierung notwendigen Daten abfragen und die Verbindung wieder trennen. Danach ist eine normale Verbindung zu richtigen GWs möglich.

Für die VPN-Verbindung zwischen Node und Gateway werden je nach Segment und MTU unterschiedliche UDP-Ports benutzt:

Jedes Segment soll aus Performance Gründen maximal 800 Clients beinhalten. Durch den Verschnitt bei der IPv4-Adressvergabe per DHCP-Server (lease time) und Reserve für statische IP-Adressen werden die Segmente jeweils für 2048 IPv4-Adressen ausgelegt, das entspricht einem /21 Netz. Für die automatische IP-Vergabe stehen die drei DHCP-Server dhcp01, dhcp02 und dhcp03 zur Verfügung, jeweils mit einem Pool von 512 IP-Adressen pro Segment. Somit kann einer der DHCP-Server ausfallen, ohne dass das Netz beeinträchtigt wird.

Alle Gateways sind per tinc (ffsl3) am zentralen Backbone 10.191.255.0/24 angeschlossen, an dem auch die drei DHCP-Server angeschlossen sind, und über den auch das Routing zwischen den Segmenten abgewickelt wird. Die DHCP Server haben dabei die IPv4 10.191.255.251 .. 253

Die einzelnen Gateways verteilen die IPv4-Adressen per DHCP-Relays an die Clients, haben also keine eigenen Adresspools. Lediglich Standardgateway und DNS-Server wird von den Gateways auf das Segment des anfragenden Clients angepasst.

IPv4-Range der Client-Netze = 10.190.0.0/21 bis 10.191.250.0/21

Für IPv6 senden die Gateways nur Router Advertisements (RA) mit den IPv6-Routen zu den anderen Segmenten, um das jeweilige Subnet und dessen Übergänge zu definieren. Die Adressvergabe als solche übernehmen die Nodes selbst. Es wird kein IPv6-Standardgateway gesetzt, da das Freifunknetz derzeit noch keine IPv6-Anbindung an das Internet hat.

IPv6-Range der Client-Netze = fd21:b4dc:4b01::/64 bis fd21:b4dc:4b60::/64

Jedes GW belegt pro Segment eine IPv6-Adresse fd21:b4dc:4bxx::a38:ggg und eine IPv4-Adresse 10.19x.y.g

Schema: 02:00:ii:ss:gg:nn

Definierte Werte für ii

Verbotene Werte für ii:

4c .. 4f
58 .. 5b
70 .. 73
8d .. 90
c8 .. cb