diff --git a/README.md b/README.md index b2636f9..d869dc9 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,10 @@ # server-scripts +## Dokumentation + +Eine Übersicht über die Architektur des Repositories sowie eine Erklärung, wie das +Freifunk-Backbone auf Netzwerkebene funktioniert, findet sich unter [`docs/`](docs/README.md). + ## Skripte installieren ``` diff --git a/docs/README.md b/docs/README.md new file mode 100644 index 0000000..717f1c5 --- /dev/null +++ b/docs/README.md @@ -0,0 +1,17 @@ +# Dokumentation + +Diese Dokumentation ergänzt die Installationsanleitung in der [Haupt-README](../README.md) um +einen Überblick über die Architektur des Repositories und die dahinterliegenden Netzwerkkonzepte. + +- [Architektur](architektur.md) — Kernkomponenten des Repositories, ihre Beziehungen + zueinander und der Start-/Stop-/Watchdog-Ablauf. +- [Komponenten](komponenten.md) — jede einzelne Komponente (Software und eigene Skripte) + im Detail: was sie ist und wozu sie dient. +- [Backbone-Netzwerk](backbone-netzwerk.md) — wie GRE, batman-adv, fastd und BGP (BIRD) + zusammen das Freifunk-Chemnitz-Backbone bilden. +- [IP-Adressplan](ip-adressplan.md) — alle IPv4-/IPv6-Adressbereiche und -Schemata an + einem Ort, inklusive der Aufteilung in die Regionen Chemnitz und Umland. +- [Sicherheitsmodell](sicherheitsmodell.md) — welche Verbindungen verschlüsselt und/oder + zugangskontrolliert sind, und welches Vertrauensmodell sich daraus ergibt. +- [Betrieb](betrieb.md) — Runbook für wiederkehrende Aufgaben: neuen Server hinzufügen, + toten GRE-Tunnel debuggen, fastd-Schlüssel rotieren, Watchdog-Mails einordnen. diff --git a/docs/architektur.md b/docs/architektur.md new file mode 100644 index 0000000..824ab04 --- /dev/null +++ b/docs/architektur.md @@ -0,0 +1,99 @@ +# Architektur + +Dieses Repository konfiguriert und betreibt einen **Freifunk-Chemnitz-Backbone-Server** +(auch **„Uplink-Server“** genannt, siehe [Backbone-Netzwerk](backbone-netzwerk.md)): +einen Server, der als Gateway/Supernode für Freifunk-Router (Mesh-Knoten) dient und +gleichzeitig mit den anderen Backbone-Servern des Netzes verbunden ist. Das Repository ist +als Sammlung von Bash-Skripten aufgebaut, die wie ein SysV-Init-Dienst gestartet, gestoppt +und per Cron überwacht werden. + +## Verzeichnisstruktur + +| Pfad | Zweck | +|---|---| +| `ffc-server.sh` | Zentrales Steuerskript: `start`, `stop`, `watchdog`. Lädt Konfiguration und alle `lib/*.sh`-Module. | +| `initd-ffc.sh` | Dünner Wrapper, der `ffc-server.sh` als `/etc/init.d/ffc` einbindet (SysV-Init). | +| `lib/*.sh` | Ein Modul pro Dienst/Funktion (siehe unten). Jedes Modul stellt `_init`, `_start`, `_stop` und optional `_cron` bereit. | +| `conf/*.conf` | Eingecheckte Vorlagen/Defaults. Pro Server werden daraus `*.local.conf`-Dateien erzeugt bzw. von Hand angelegt (siehe `conf/.gitignore`: `*.local.*` und `bird-routes.country.conf` sind lokal/generiert und nicht versioniert). | + +## Die Module in `lib/` + +Eine ausführlichere Beschreibung jeder einzelnen Komponente (Software und Skript) samt +ihrem Zweck findet sich in [Komponenten](komponenten.md). + +| Modul | Verantwortlich für | +|---|---| +| `log.sh` | Logging nach syslog (`logger`) und optional per Mail (`LOG_TO`), inkl. `log_fatal_error` zum Abbruch bei Fehlkonfiguration. | +| `gre.sh` | Aufbau der GRE-Tunnel (`gretap`) zu allen anderen Backbone-Servern aus `GRE_PEERS`; Watchdog-Check per ICMPv6-Ping auf die Tunnel-Interfaces. | +| `batman.sh` | Initialisiert `batman-adv`, hängt die GRE-Interfaces (aus `BATMAN_IFS`) und später `fastd`-Interfaces als Slaves ein, konfiguriert `bat0` (Service-Adressen, Bridge-Loop-Avoidance, Bonding, Gateway-Modus) und startet `alfred`/`batadv-vis` für die Meshviewer-Daten. | +| `fastd.sh` | Startet das fastd-VPN (einen Prozess pro CPU-Kern, jeweils auf eigenem Port), über das sich Freifunk-Router mit dem Server verbinden. | +| `bird.sh` / `bird6.sh` | Generieren die BIRD-/BIRD6-Konfiguration aus Templates (`conf/bird*.conf`), tragen alle GRE-Peers als BGP-Nachbarn ein, setzen Policy-Routing (`ip rule`/`ip -6 rule`) für das Mesh-Netz und starten die Routing-Daemons. | +| `dnsmasq.sh` | DHCP/DNS für Endgeräte im Mesh (`bat0`), optional, nur auf Servern mit `USE_DNSMASQ=1`. | +| `radvd.sh` | IPv6 Router Advertisements für `bat0`, nur auf IPv6-Gateway-Servern (`USE_RADVD=1`), setzt zusätzlich eine Default-Route in BIRD6. | +| `meshviewer.sh` | Startet `alfred`/`batadv-vis` unabhängig von `batman.sh`, falls der Server primär als Meshviewer-Datenquelle dient. | + +## Ablauf: Start, Stop, Watchdog + +`ffc-server.sh` (siehe dort) lädt zunächst `conf/general.conf` und `conf/general.local.conf` +sowie alle `lib/*.sh`-Module und verzweigt dann anhand des Arguments: + +```mermaid +flowchart TD + conf["conf/general.conf +\nconf/general.local.conf"] --> ffc[ffc-server.sh] + lib["lib/*.sh Module"] --> ffc + + ffc -->|start| gre_i[gre_init] --> bat_i[batman_init] + bat_i --> fastd_i["fastd_init (USE_FASTD)"] + fastd_i --> bird_i["bird_init / bird6_init (USE_BIRD)"] + bird_i --> dns_i["dnsmasq_init (USE_DNSMASQ)"] + dns_i --> radvd_i["radvd_init (USE_RADVD)"] + radvd_i --> mv_i[meshviewer_init] + mv_i --> tunnels[gre_add_all_tunnels] + tunnels --> peers[batman_add_all_peers] + peers --> daemons["fastd_start / bird_start / bird6_start /\ndnsmasq_start / radvd_start"] + daemons --> sysctl[sysctl -p conf/sysctl.conf] + + ffc -->|stop| stop["fastd_stop, gre_stop, batman_stop,\nbird_stop, bird6_stop, dnsmasq_stop,\nradvd_stop, meshviewer_stop"] + stop --> rules[ip rule delete lookup 100] + + ffc -->|watchdog, jedes 1 Min| wd1["meshviewer_cron, radvd_cron,\ndnsmasq_cron (Prozess-Check)"] + ffc -->|watchdog, alle 5 Min| wd2["gre_cron (Tunnel-Ping-Check),\nbird_cron (Länder-Routen nachladen)"] +``` + +Wichtige Details zum Ablauf: + +- **Reihenfolge beim Start:** Erst werden alle Dienste initialisiert (`*_init`, meist reine + Konfigurationsgenerierung/-validierung), dann werden GRE-Tunnel und batman-adv-Peers + aufgebaut, und erst danach die eigentlichen Daemons gestartet. So existieren die + Netzwerk-Interfaces bereits, wenn z. B. BIRD versucht, BGP-Sessions über sie aufzubauen. +- **Feature-Flags:** `USE_FASTD`, `USE_BIRD`, `USE_DNSMASQ`, `USE_RADVD`, `USE_MESHVIEWER` in + `general.local.conf` steuern, welche Module überhaupt aktiv werden — ein Server muss nicht + alle Rollen gleichzeitig übernehmen (z. B. ist `USE_DNSMASQ`/`USE_RADVD` nur auf + ausgewählten Gateway-Servern gesetzt). +- **Watchdog:** `ffc-server.sh watchdog` wird minütlich per Cron aufgerufen (siehe README). + Jede Minute werden laufende Prozesse (dnsmasq, radvd, alfred) geprüft und bei Bedarf neu + gestartet; alle 5 Minuten wird zusätzlich die Erreichbarkeit der GRE-Tunnel per Ping + geprüft und die länderspezifische Routen-Datei von der Freifunk-Chemnitz-API neu geladen. + Fehler werden über `log_error`/`log_fatal_error` sowohl nach syslog als auch (im + Watchdog-Kontext) per Mail an `LOG_TO` gemeldet. +- **Konfigurations-Templating:** `bird.sh`, `bird6.sh` und `dnsmasq.sh` erzeugen aus den + eingecheckten `conf/*.conf`-Vorlagen (Platzhalter wie `__BIRD_ROUTER_ID__`, + `__DNSMASQ_SERVICE_IP__`) bei jedem Start neue `*.local.conf`-Dateien anhand der Werte aus + `general.local.conf` — die eingecheckten Vorlagen sind also keine fertigen Configs, + sondern Templates. + +## Kopplung zwischen den Modulen + +Die Module sind nicht unabhängig, sondern bauen aufeinander auf: + +- `bird.sh`/`bird6.sh` iterieren über dieselbe `GRE_PEERS`-Liste wie `gre.sh`, um pro + GRE-Tunnel eine BGP-Session zum jeweiligen Nachbarserver zu konfigurieren. +- `batman.sh` bindet die von `gre.sh` erzeugten Interfaces (`BATMAN_IFS`) sowie die von + `fastd.sh` erzeugten Client-Tunnel in dieselbe batman-adv-Instanz (`bat0`) ein. +- `radvd.sh` erfordert `USE_BIRD=1` und trägt seine Default-Route direkt in BIRD6 ein + (`bird6_add_route`). +- `dnsmasq.sh` und die BGP-Konfiguration nutzen dieselben `SERVICE_ADDRESSES` (die + Dnsmasq-Gateway-Adresse wird zugleich als Route über BIRD announced). + +Das Zusammenspiel dieser Module ergibt das eigentliche Backbone-Netz — siehe +[Backbone-Netzwerk](backbone-netzwerk.md) für die konzeptionelle Erklärung. diff --git a/docs/backbone-netzwerk.md b/docs/backbone-netzwerk.md new file mode 100644 index 0000000..9b053ec --- /dev/null +++ b/docs/backbone-netzwerk.md @@ -0,0 +1,199 @@ +# Wie funktioniert das Freifunk-Backbone? + +Ein Freifunk-Netz besteht aus zwei Ebenen: den **Mesh-Knoten** (die WLAN-Router, die +Freifunk-Firmware nutzen und sich untereinander sowie über einen VPN-Tunnel mit einem +Server verbinden) und dem **Backbone**: mehreren, geografisch verteilten Servern, die das +Netz mit dem Internet verbinden und untereinander verknüpft sind. Dieses Repository +konfiguriert genau diese Backbone-Server. Alle unten beschriebenen Bausteine entsprechen +konkreten Modulen aus [`lib/`](../lib) (siehe [Architektur](architektur.md)). + +> **Hinweis:** Im Repository (z. B. in der Haupt-README) wird für dieselben Server auch der +> Begriff **„Uplink-Server“** verwendet. Beide Bezeichnungen meinen dasselbe: „Backbone“ +> betont das Server-zu-Server-Netz als Ganzes, „Uplink-Server“ die Rolle des einzelnen +> Servers als Internet-Zugang für die an ihn angeschlossenen Freifunk-Router. + +## Grundlagen: Was ist ein Layer-2-Netz? + +Netzwerke werden häufig nach dem OSI-Modell in Schichten eingeteilt. Für das Verständnis +des Backbones sind vor allem zwei davon relevant: + +- **Schicht 2 (Sicherungsschicht, „Layer 2“):** Hier werden **Ethernet-Frames** anhand von + **MAC-Adressen** zugestellt, nicht anhand von IP-Adressen. Alle Geräte in einem + Layer-2-Netz bilden eine gemeinsame **Broadcast-Domäne** — sie „sehen“ sich gegenseitig + so, als wären sie über einen einzigen Switch verbunden, unabhängig davon, wie sie + tatsächlich physisch verkabelt sind. Geräte können sich z. B. per ARP oder Broadcast + direkt erreichen, ganz ohne Router dazwischen. +- **Schicht 3 (Vermittlungsschicht, „Layer 3“):** Hier werden **Pakete** anhand von + **IP-Adressen** zwischen unterschiedlichen Netzen weitergeleitet (Routing). Ein + Layer-3-Netz besteht typischerweise aus mehreren, durch Router getrennten + Layer-2-Netzen. + +Für das Freifunk-Backbone ist das zentral: **GRE- (`gretap`) und fastd-Tunnel +transportieren rohe Ethernet-Frames**, nicht IP-Pakete. Dadurch lassen sie sich direkt in +`batman-adv` einhängen, das selbst auf Schicht 2 arbeitet. Das Ergebnis ist ein einziges, +großes Layer-2-Netz (eine gemeinsame Broadcast-Domäne), das sich über alle +Backbone-Server und alle daran angeschlossenen Freifunk-Router erstreckt — obwohl die +Server geografisch verteilt und nur über das öffentliche Internet verbunden sind. Erst +darüber legt sich mit BGP/BIRD eine klassische Layer-3-Routingebene (siehe unten). + +## Grundlagen: Was ist eine Vollvermaschung? + +Bei einer **Vollvermaschung** (englisch *full mesh*) hat jeder Teilnehmer eines Netzes eine +direkte Verbindung zu **jedem anderen** Teilnehmer — im Gegensatz zu einer Stern-Topologie +(alle Verbindungen laufen über einen zentralen Knoten) oder einer Teilvermaschung (nur +manche Teilnehmer sind direkt verbunden, der Rest wird über Zwischenstationen erreicht). +Bei `n` Teilnehmern braucht eine Vollvermaschung `n * (n-1) / 2` Verbindungen — bei den +aktuell 8 Servern in `GRE_PEERS` sind das 28 GRE-Tunnel bzw. 28 BGP-Sessions. + +Der Vorteil: Es gibt keinen Single Point of Failure und keinen Server, über den zwangsläufig +aller Verkehr laufen müsste — fällt ein Server aus, bleiben alle übrigen weiterhin direkt +miteinander verbunden. Der Nachteil ist die quadratisch wachsende Anzahl an Verbindungen, +weshalb eine Vollvermaschung nur bei einer überschaubaren Anzahl an Servern praktikabel ist; +bei sehr vielen Teilnehmern würde man stattdessen auf ein hierarchisches oder +teilvermaschtes Modell wechseln. + +Im Backbone gibt es zwei unabhängige Vollvermaschungen übereinander: + +- eine **GRE-Vollvermaschung** auf der Transportebene — jeder Server hat einen `gretap`-Tunnel + zu jedem anderen (siehe „Transport“ unten), und +- eine **BGP-Vollvermaschung** auf der Routingebene — jeder Server hat eine BGP-Session zu + jedem anderen (siehe „Ebene 3“ unten). + +## Die drei Ebenen des Backbones + +```mermaid +flowchart TB + subgraph L3["Ebene 3: Layer-3-Routing zwischen Servern (BIRD / BIRD6, BGP)"] + direction LR + BirdA[BIRD @ Server A] + BirdB[BIRD @ Server B] + BirdC[BIRD @ Server C] + end + + subgraph L2["Ebene 2: Ein gemeinsames Layer-2-Mesh (batman-adv, bat0)"] + direction LR + BatA[batman-adv @ Server A] + BatB[batman-adv @ Server B] + BatC[batman-adv @ Server C] + end + + subgraph Transport["Transport: GRE-Tunnel zwischen Servern + fastd-VPN zu Knoten"] + direction LR + GRE["GRE-Tunnel-Vollvermaschung\n(gretap über das Internet)"] + FASTD["fastd-VPN\n(Freifunk-Router als Clients)"] + end + + L3 -. "läuft über Link-Local-Adressen der GRE-Interfaces" .-> L2 + L2 -. "bat0-Interface läuft über GRE- und fastd-Interfaces" .-> Transport +``` + +### 1. Transport: GRE-Vollvermaschung zwischen Servern + fastd zu den Knoten + +- Jeder Backbone-Server baut zu **jedem anderen** Backbone-Server einen + `gretap`-Tunnel auf — eine [Vollvermaschung](#grundlagen-was-ist-eine-vollvermaschung) + (`lib/gre.sh`, Liste `GRE_PEERS`). Es handelt sich bewusst um + **`gretap`** (GRE mit Ethernet-Framing), nicht um klassisches IP-GRE — dadurch transportiert + der Tunnel [Layer-2](#grundlagen-was-ist-ein-layer-2-netz)-Frames und kann direkt in eine + Bridge/batman-adv-Instanz gehängt werden. + Jeder Server bekommt auf jedem Tunnel-Interface eine Link-Local-artige IPv4-Adresse aus + `169.254.0.0/16` (abgeleitet aus den letzten beiden Oktetten der öffentlichen IP) sowie + eine IPv6-Link-Local-Adresse (`fe80::ffc:…`) — diese Adressen dienen ausschließlich als + Endpunkte für die spätere BGP-Session, nicht dem eigentlichen Mesh-Verkehr. +- Freifunk-Router (Endgeräte) bauen stattdessen ein **fastd**-VPN zum Server auf + (`lib/fastd.sh`). fastd ist ebenfalls ein [Layer-2](#grundlagen-was-ist-ein-layer-2-netz)-VPN + (`mode multitap`); jedes neue + Client-Interface wird beim Verbindungsaufbau automatisch per `batctl interface add` + in batman-adv eingehängt (siehe `on up`-Hook in `conf/fastd.conf`). +- Damit transportieren sowohl GRE- als auch fastd-Tunnel **Ethernet-Frames über das + Internet** — beide sind reine Transportstrecken für die nächste Ebene. Welche der beiden + Strecken verschlüsselt ist und welche nicht, beschreibt das + [Sicherheitsmodell](sicherheitsmodell.md). + +### 2. Ebene 2: Ein einziges großes Mesh über batman-adv + +- `lib/batman.sh` hängt sowohl die GRE-Interfaces zu den anderen Servern + (`BATMAN_IFS`) als auch die dynamisch entstehenden fastd-Client-Interfaces in + **eine gemeinsame batman-adv-Instanz** (`bat0`). +- Das Ergebnis: Alle Freifunk-Router *aller* Server und alle Backbone-Server bilden + gemeinsam **ein einziges flaches [Layer-2](#grundlagen-was-ist-ein-layer-2-netz)-Mesh-Netz**, + unabhängig davon, an welchem + Server ein Knoten gerade per fastd angemeldet ist. batman-adv übernimmt dabei + Pfadwahl, Redundanz und Schleifenvermeidung (`bridge_loop_avoidance`) über die + [vermaschten](#grundlagen-was-ist-eine-vollvermaschung) GRE-Verbindungen der Server. +- `bonding 1` erlaubt es außerdem, dass ein Client, der (theoretisch) über mehrere + Pfade erreichbar ist, den Verkehr über mehrere Uplinks bündelt. +- Auf `bat0` bekommt jeder Server passende Service-Adressen (`SERVICE_ADDRESSES`) sowie ggf. + DHCP (`dnsmasq`, IPv4 `10.149.0.0/16`) und Router Advertisements (`radvd`, IPv6 + `2001:bc8:3f13:ffc2::/64` bzw. `ffc3::/64`) — das ist der Adressraum, den Freifunk-Router + und Endgeräte im Mesh tatsächlich nutzen. +- `alfred` und `batadv-vis` (`lib/meshviewer.sh`/`lib/batman.sh`) sammeln Topologie- und + Knoten-Metadaten aus dem Mesh für die Kartendarstellung (Meshviewer). + +### 3. Ebene 3: Routing zwischen den Servern per BGP (BIRD/BIRD6) + +Ein reines [Layer-2](#grundlagen-was-ist-ein-layer-2-netz)-Mesh reicht nicht aus, um Internet-Zugang, Lastverteilung und +Ausfallsicherheit über mehrere, unterschiedlich angebundene Server hinweg zu organisieren. +Dafür betreibt jeder Server **BIRD** (IPv4) und **BIRD6** (IPv6) — je einen eigenen +BGP-Router: + +- `lib/bird.sh`/`lib/bird6.sh` tragen für **jeden** GRE-Peer eine eigene interne + BGP-Session ein (`template bgp intern`), die genau über die Link-Local-Adressen des + jeweiligen GRE-Tunnels läuft. Damit hat jeder Server eine direkte BGP-Session zu jedem + anderen Server — eine [BGP-Vollvermaschung](#grundlagen-was-ist-eine-vollvermaschung) + passend zur GRE-Vollvermaschung. +- Jeder Server bekommt eine Router-ID/AS-Nummer, die aus seiner öffentlichen IP abgeleitet + wird (`169.254.<3.Oktett>.<4.Oktett>` bzw. AS `<3.Oktett><4.Oktett>`) — ein einfaches, + kollisionsfreies Schema ganz ohne zentrale IP-/AS-Vergabe. +- Über BGP announcen die Server sich gegenseitig Routen: die eigene öffentliche IP + (`__WANIP__/32`), das Mesh-Netz (`10.149.0.0/20`), die konfigurierten Service-Adressen + sowie — nur auf Servern mit `USE_RADVD=1` — eine IPv6-Default-Route über den eigenen + Internet-Uplink (`radvd_add_route "::/0" "$WANGW6" "$WANIF"`). +- Damit ein Server für Mesh-Verkehr eine **eigene Routingtabelle** neben der normalen + Internet-Routingtabelle nutzt, richtet `bird_init`/`bird6_init` Policy-Routing ein + (`ip rule` für `10.149.0.0/16` bzw. `ip -6 rule` für `ffc2::/64`/`ffc3::/64`, + Ziel-Tabelle `100`) und BIRD selbst schreibt seine gelernten Routen in genau diese + Tabelle (`kernel table 100`). So kann Mesh-Verkehr andere Pfade/Gateways nehmen als + regulärer Internet-Verkehr des Servers. +- **Geoblocking/Regionalrouten:** `bird_cron` lädt alle 5 Minuten eine länderspezifische + Routenliste von `api.chemnitz.freifunk.net` (`COUNTRY`, `APIKEY`) nach + `conf/bird-routes.country.conf` und lässt BIRD per `SIGHUP` neu konfigurieren — so lassen + sich z. B. bestimmte Zielnetze nur über Server in einem bestimmten Land routen. +- **NAT/Internet-Zugang:** `iptables -t nat -A POSTROUTING -o $WANIF -j MASQUERADE` sorgt + dafür, dass Mesh-Clients über die öffentliche IP des jeweiligen Servers ins Internet + können, wenn dieser Server als ihr Gateway gewählt wird. + +## Zusammengefasst: Der Weg eines Pakets + +1. Ein Freifunk-Router baut ein **fastd**-VPN zu einem (für ihn erreichbaren) Backbone-Server + auf; sein virtuelles Interface wird automatisch **batman-adv** beigetreten. +2. **batman-adv** lernt über das gesamte, aus GRE- und fastd-Tunneln bestehende Mesh, wie der + Router von jedem anderen Punkt im Mesh aus erreichbar ist — inklusive über andere + Backbone-Server hinweg, mit denen der Router nie direkt verbunden ist. +3. Will der Router ins Internet, wählt er (bzw. das Mesh) einen Gateway-Server; dessen + **BIRD/BIRD6**-Instanz hat über BGP von allen anderen Servern gelernt, welche Netze wie + erreichbar sind, trifft Routingentscheidungen (inkl. Geoblocking-Regeln) und NATet den + Verkehr über die eigene öffentliche IP ins Internet. +4. Für Verkehr zwischen zwei Mesh-Teilnehmern an unterschiedlichen Servern reicht bereits die + batman-adv-Ebene ([Layer 2](#grundlagen-was-ist-ein-layer-2-netz)) — BGP wird hier nur zur Verteilung der Dienst-/Uplink-Routen + und für die Policy-Routing-Tabelle 100 gebraucht, nicht für die reine + Erreichbarkeit im Mesh selbst. + +Diese Trennung — **Transport** (GRE/fastd) → **ein flaches [Layer-2](#grundlagen-was-ist-ein-layer-2-netz)-Mesh** (batman-adv) → +**L3-Routing zwischen Servern** (BGP/BIRD) — ist ein im Freifunk-Umfeld verbreitetes +Architekturprinzip. Auch andere Communities verbinden ihre Gateway-/Supernodes über +GRE-Tunnel und tauschen Routen per BGP (BIRD) aus, etwa +[Freifunk Köln/Bonn](https://kbu.freifunk.net/wiki/index.php?title=Architektur); andere, z. B. +[Freifunk Rheinland](https://wiki.freifunk-rheinland.net/wiki/Backbone), nutzen für die +Transport- und Routingebene zwischen den Supernodes stattdessen tinc-VPN mit OSPF (siehe +auch [Netzwerk/Super-Node Backbone Anbindung](https://wiki.freifunk-rheinland.net/wiki/Netzwerk/Super-Node_Backbone_Anbindung)). +Das grundsätzliche Muster — Zugangs-VPN zu Gateways, ein gemeinsames Mesh, darüberliegendes +L3-Routing — ist aber vergleichbar und erklärt, warum die Module in `lib/` in dieser +Reihenfolge initialisiert werden (siehe [Architektur](architektur.md)). + +## Quellen + +- [batman-adv — The Linux Kernel documentation](https://docs.kernel.org/networking/batman-adv.html) +- [How to Configure a GRETAP Tunnel for Layer 2 Bridging](https://oneuptime.com/blog/post/2026-03-20-gretap-tunnel-layer2-bridging/view) +- [Architektur – Freifunk Köln, Bonn und Umgebung](https://kbu.freifunk.net/wiki/index.php?title=Architektur) +- [Backbone – Freifunk Rheinland e.V.](https://wiki.freifunk-rheinland.net/wiki/Backbone) +- [Netzwerk/Super-Node Backbone Anbindung – Freifunk Rheinland e.V.](https://wiki.freifunk-rheinland.net/wiki/Netzwerk/Super-Node_Backbone_Anbindung) diff --git a/docs/betrieb.md b/docs/betrieb.md new file mode 100644 index 0000000..2cbbe9b --- /dev/null +++ b/docs/betrieb.md @@ -0,0 +1,77 @@ +# Betrieb: Häufige Aufgaben + +Ein kurzes Runbook für wiederkehrende Betriebsaufgaben, die über die reine +Erstinstallation (siehe [Haupt-README](../README.md)) hinausgehen. Hintergrund zu den +verwendeten Befehlen/Dateien steht in [Architektur](architektur.md) und +[Komponenten](komponenten.md). + +## Neuen Backbone-Server hinzufügen + +Die Peer-Liste `GRE_PEERS` ist eine **statische, pro Server gepflegte** Liste in +`general.local.conf` — sie wird nirgends automatisch zwischen den Servern synchronisiert. +Das ist die häufigste Fehlerquelle beim Hinzufügen eines neuen Servers: + +1. Öffentliche IPv4 (`WANIP`) des neuen Servers festlegen und dessen + `general.local.conf`, `bird.local.conf` etc. wie in der README beschrieben einrichten. +2. Den neuen Server **auf jedem bereits bestehenden Backbone-Server** in dessen + `GRE_PEERS` (und ggf. `BATMAN_IFS`, siehe [IP-Adressplan](ip-adressplan.md#regionen-chemnitz-und-umland)) + eintragen — nicht nur in der Konfiguration des neuen Servers selbst. +3. Den neuen Server ebenfalls mit der vollständigen, aktuellen `GRE_PEERS`-Liste aller + anderen Server konfigurieren. +4. `ffc-server.sh` (bzw. den `ffc`-Dienst) auf **allen** betroffenen Servern neu starten, + damit die neuen GRE-Tunnel und BGP-Sessions aufgebaut werden. +5. Prüfen, ob der neue Server angekommen ist: + - `grep gre- /proc/net/dev` — läuft das neue `gre-`-Interface? + - `birdc show protocols` / `birdc6 show protocols` — ist die neue BGP-Session `Established`? + - `batctl o` (Originators) — taucht der neue Server/seine Clients im Mesh auf? + +Ein geändertes `WANIP` eines *bestehenden* Servers erfordert dieselbe Sorgfalt: Es muss +in `GRE_PEERS` auf **allen** anderen Servern nachgezogen werden (siehe z. B. die Commits +„switched noether and kohn“ und „updated IP Adresses of new servers“ in der Historie +dieses Repositories). + +## Toten GRE-Tunnel debuggen + +Der Watchdog (`ffc-server.sh watchdog`, alle 5 Minuten über `gre_cron`) meldet einen +Tunnelausfall per Mail an `LOG_TO` mit der Meldung `GRE tunnel seems down: gre-`. +Das Verfahren dahinter (`gre_check_tunnel` in `lib/gre.sh`): ein ICMPv6-Ping auf +`ff02::2%gre-` (All-Routers-Multicast) muss mindestens eine `DUP`-Antwort liefern. + +Vorgehen bei einer solchen Meldung: + +1. `ip link show gre-` — existiert das Interface überhaupt (lokales Problem, z. B. + Server frisch neu gestartet, Tunnel noch nicht aufgebaut)? +2. `ping6 -c5 -i1 ff02::2%gre-` manuell wiederholen — Bestätigung des Watchdog-Befunds. +3. Erreichbarkeit der `WANIP` des Peers direkt prüfen (`ping`/`traceroute`) — liegt es am + darunterliegenden Internet-Pfad zwischen den beiden Rechenzentren? +4. Beim Betreiber des Peer-Servers nachfragen, ob dort `GRE_PEERS` noch die aktuelle + eigene `WANIP` enthält (siehe „Neuen Backbone-Server hinzufügen“ oben) — eine veraltete + IP auf der Gegenseite ist eine häufige Ursache. + +## fastd-Schlüssel rotieren + +1. Neues Schlüsselpaar erzeugen: `fastd --generate-key`. +2. Den neuen öffentlichen Schlüssel an das Freifunk-Chemnitz-Team melden, damit er in die + `site.conf` der betroffenen Domäne übernommen wird (siehe Haupt-README). +3. Den privaten Schlüssel in `conf/fastd-secret.local.conf` ersetzen + (Format: `secret "000...fff";`). +4. fastd neu starten (z. B. über einen Neustart des `ffc`-Dienstes). Bestehende + Client-Verbindungen werden dabei getrennt und bauen sich mit dem neuen Schlüssel neu + auf — kurzzeitiger Verbindungsabbruch für alle an diesem Server angemeldeten + Freifunk-Router ist zu erwarten. + +## Watchdog-Mails einordnen + +`ffc-server.sh watchdog` läuft minütlich per Cron. Nur ein Teil der dabei aufgerufenen +`*_cron`-Funktionen kann tatsächlich eine Mail auslösen: + +- `gre_cron` (alle 5 Minuten): meldet per `log_error` (→ Mail im Cron-Kontext) einen + scheinbar toten GRE-Tunnel — siehe „Toten GRE-Tunnel debuggen“ oben. **Das ist aktuell + die einzige Quelle für Watchdog-Mails.** +- `dnsmasq_cron`, `radvd_cron` (jede Minute): starten den jeweiligen Dienst still neu, + falls er nicht läuft — ohne Logging oder Mail, auch bei Erfolg oder Misserfolg. +- `bird_cron` (alle 5 Minuten): lädt nur die Geoblocking-Routen nach, meldet dabei keine + Fehler. + +Eine Watchdog-Mail bedeutet also praktisch immer: ein GRE-Tunnel ist (vermeintlich) +ausgefallen. diff --git a/docs/ip-adressplan.md b/docs/ip-adressplan.md new file mode 100644 index 0000000..a60839c --- /dev/null +++ b/docs/ip-adressplan.md @@ -0,0 +1,60 @@ +# IP-Adressplan + +Zentrale Referenz für alle IPv4-/IPv6-Adressbereiche und Adress-Schemata, die im Backbone +verwendet werden. Die Details zu den einzelnen Bausteinen stehen in +[Backbone-Netzwerk](backbone-netzwerk.md) und [Komponenten](komponenten.md); dieses +Dokument fasst nur die Zahlen an einem Ort zusammen. + +## Regionen: Chemnitz und Umland + +Das Freifunk-Chemnitz-Mesh ist in zwei Regionen mit eigenen Adressbereichen aufgeteilt: +die Stadt Chemnitz und das „Chemnitzer Umland“. Ein Server wird durch seine Konfiguration +(`conf/bird.local.conf`, `conf/dnsmasq.local.conf`, `BATMAN_IFS` in `general.local.conf`) +einer der beiden Regionen zugeordnet — es gibt keinen eigenen Feature-Flag dafür, sondern +schlicht andere Werte in denselben Konfigurationsdateien. + +| | Chemnitz (Standard) | Umland | +|---|---|---| +| Statische BIRD-Route (`protocol static` in `bird.conf`) | `10.149.0.0/20` | `10.149.16.0/20` | +| DHCP-Range (`dnsmasq.conf`) | `10.149.1.0`–`10.149.14.255` (`/20`, 30 min Lease) | `10.149.17.0`–`10.149.30.255` (`/20`, 30 min Lease) | +| `BATMAN_IFS` | GRE-Interfaces der Chemnitz-Backbone-Server | GRE-Interfaces der für das Umland zuständigen Server | + +Beide Regionen liegen im selben `10.149.0.0/16`, das insgesamt über BIRD als Mesh-Netz +announced wird (siehe [Backbone-Netzwerk](backbone-netzwerk.md)) — die Aufteilung in zwei +`/20`-Bereiche dient nur der Adressvergabe innerhalb des Mesh, nicht einer Trennung auf +Routing- oder batman-adv-Ebene. + +## IPv4-Adressbereiche + +| Bereich | Zweck | +|---|---| +| `10.149.0.0/16` | Gesamtes Mesh-Netz (Freifunk-Router und Endgeräte), über BIRD announced. | +| `10.149.0.0/20` | Statische Route/DHCP-Pool für die Region Chemnitz (siehe oben). | +| `10.149.16.0/20` | Statische Route/DHCP-Pool für die Region Umland (siehe oben). | +| `SERVICE_ADDRESSES` (frei, pro Server) | Adresse(n) auf `bat0`, z. B. DNS-/DHCP-Gateway-Adresse; wird beim Freifunk-Chemnitz-Team erfragt und in `general.local.conf` sowie `dnsmasq.local.conf` eingetragen. | +| `169.254.<3. Oktett>.<4. Oktett>` | Link-Local-Adresse eines Backbone-Servers auf seinen GRE-Tunnel-Interfaces, abgeleitet aus den letzten beiden Oktetten seiner öffentlichen IPv4. Dient nur als BGP-Session-Endpunkt, nicht dem Mesh-Verkehr. | +| `__WANIP__/32` | Die öffentliche IPv4 des jeweiligen Servers selbst, wird als eigene Route ins Mesh announced. | + +## IPv6-Adressbereiche + +| Bereich | Zweck | +|---|---| +| `2001:bc8:3f13:ffc2::/64` | IPv6-Präfix, das `radvd` auf `bat0` per Router Advertisement announced (SLAAC für Mesh-Clients). | +| `2001:bc8:3f13:ffc3::/64` | Zweites IPv6-Präfix, in `conf/radvd.conf` für ein Interface `bat1` konfiguriert. In den `lib/*.sh`-Skripten wird ausschließlich `bat0` automatisiert aufgebaut — der genaue Zweck/Betriebsstatus von `bat1`/`ffc3` ist anhand des Codes allein nicht abschließend zu klären und sollte im Zweifel beim Team erfragt werden. | +| `fe80::ffc::/64` | IPv6-Link-Local-Adresse eines Backbone-Servers auf seinen GRE-Tunnel-Interfaces, das IPv6-Gegenstück zur `169.254.x.y`-Adresse oben. | +| DNS-Resolver (RDNSS, `radvd.conf`) | `2001:0bc8:3f13:ffc2::1` und `…ffc2::53` (mesh-interne Resolver), sowie `2a01:4f8:110:1405::1` (externer Resolver) werden den Mesh-Clients announced. | + +## Abgeleitete Kennungen + +| Kennung | Ableitung | Zweck | +|---|---|---| +| BIRD-Router-ID | `169.254.<3. Oktett>.<4. Oktett>` der öffentlichen IPv4 | Eindeutige Router-ID pro Server ohne zentrale Vergabestelle. | +| BGP-AS-Nummer | `<3. Oktett><4. Oktett>` der öffentlichen IPv4 (z. B. aus `5.199.142.119` wird AS `142119`) | Eindeutige AS-Nummer pro Server für die BGP-Vollvermaschung, ebenfalls ohne zentrale Vergabestelle. | + +## DHCP/DNS-Optionen (`dnsmasq.conf`) + +| Option | Wert | Zweck | +|---|---|---| +| `dhcp-option=3` | `SERVICE_ADDRESSES[0]` | Default-Gateway für Mesh-Clients. | +| `dhcp-option=6` | `10.149.0.1`, `SERVICE_ADDRESSES[0]` | DNS-Server für Mesh-Clients — bevorzugt ein mesh-interner (Site-Local) Resolver vor dem eigenen Server, statt eines rein externen. | +| `dhcp-option=119` | `ffcmesh` | DNS-Suchdomäne im Mesh. | diff --git a/docs/komponenten.md b/docs/komponenten.md new file mode 100644 index 0000000..c028478 --- /dev/null +++ b/docs/komponenten.md @@ -0,0 +1,121 @@ +# Komponenten + +Dieses Dokument beschreibt jede Komponente des Backbone-Servers einzeln: was sie ist, wozu +sie dient und wo sie im Repository konfiguriert wird. Für das Zusammenspiel der Komponenten +siehe [Architektur](architektur.md) und [Backbone-Netzwerk](backbone-netzwerk.md). + +## Externe Software + +Diese Programme werden vom Server genutzt und in `README.md` installiert; die +`lib/*.sh`-Module (siehe unten) konfigurieren und steuern sie. + +### B.A.T.M.A.N. advanced (`batman-adv`, `batctl`) + +Mesh-Routing-Protokoll auf [Schicht 2](backbone-netzwerk.md#grundlagen-was-ist-ein-layer-2-netz) +(Kernelmodul `batman-adv` + Steuerwerkzeug `batctl`). +Es bildet das eigentliche Freifunk-Mesh: Alle GRE-Tunnel zu anderen Servern und alle +fastd-Verbindungen zu Freifunk-Routern werden als Slave-Interfaces in eine gemeinsame +batman-adv-Instanz (`bat0`) gehängt. batman-adv übernimmt Pfadwahl, Redundanz und +Schleifenvermeidung: Jeder Knoten flutet periodisch sogenannte Originator-Nachrichten +(OGMs) und muss dabei nur den jeweils besten nächsten Hop pro Ziel kennen, nicht die +komplette Netz-Topologie. Die Version aus den Debian-Paketquellen ist zu alt, daher wird +sie aus dem offiziellen `open-mesh.org`-Repo selbst gebaut. +([Kernel-Doku](https://docs.kernel.org/networking/batman-adv.html), +[Wikipedia](https://en.wikipedia.org/wiki/B.A.T.M.A.N.)) + +### alfred / batadv-vis + +Zusatzwerkzeuge aus demselben `open-mesh`-Projekt. `alfred` verteilt beliebige +Metadaten (z. B. Knotennamen, Standort) im Mesh, `batadv-vis` exportiert die +Mesh-Topologie. Beides zusammen liefert die Rohdaten für die Freifunk-Kartendarstellung +(Meshviewer). Gestartet über `lib/batman.sh` bzw. `lib/meshviewer.sh`. +([open-mesh.org-Doku](https://www.open-mesh.org/doc/alfred/)) + +### fastd + +Schlankes, für Embedded-Router geeignetes VPN auf +[Schicht 2](backbone-netzwerk.md#grundlagen-was-ist-ein-layer-2-netz) (`mode multitap`). Freifunk-Router +bauen darüber eine verschlüsselte Verbindung zum Server auf; jede neue Verbindung wird beim +Aufbau automatisch per `batctl interface add` in batman-adv eingehängt (siehe `on up`-Hook in +`conf/fastd.conf`). Damit ist fastd der Zugangspunkt der Endgeräte zum Mesh. Gesteuert über +`lib/fastd.sh`, ein Prozess pro CPU-Kern für bessere Lastverteilung. +([fastd-Doku](https://fastd.readthedocs.io/)) + +### GRE / `gretap` (Kernel-Feature, `iproute2`) + +Kein separat zu installierendes Programm, sondern eine Tunnel-Technik des Linux-Kernels. +Zwischen den Backbone-Servern werden `gretap`-Tunnel (GRE mit Ethernet-Framing statt +reinem IP-GRE) aufgebaut — dadurch lassen sich die Tunnel wie normale Ethernet-Interfaces +direkt in batman-adv einhängen. Ergebnis: Ein +[vollvermaschtes](backbone-netzwerk.md#grundlagen-was-ist-eine-vollvermaschung) +[Layer-2-Netz](backbone-netzwerk.md#grundlagen-was-ist-ein-layer-2-netz) zwischen allen +Backbone-Servern über das öffentliche Internet. Konfiguriert über `lib/gre.sh`. +([Red Hat Developer: Linux-Tunnel-Interfaces](https://developers.redhat.com/blog/2019/05/17/an-introduction-to-linux-virtual-interfaces-tunnels)) + +### BIRD / BIRD6 + +Zwei getrennte Daemon-Binaries aus derselben BIRD-1.x-Codebasis: `bird` für IPv4, `bird6` +für IPv6 (BIRD 2.x hat diese Aufteilung später zu einem einzigen Binary zusammengeführt; +dieses Repository nutzt noch die klassische 1.x-Aufteilung, erkennbar an den getrennten +`lib/bird.sh`/`lib/bird6.sh`-Modulen und `bird.conf`/`bird6.conf`-Dateien). +Jeder Server betreibt darüber eine eigene BGP-Instanz und baut zu jedem GRE-Peer eine +interne BGP-Session auf. So lernen sich die Server gegenseitig Routen (eigene IP, Mesh-Netz, +Service-Adressen, Internet-Default-Route) und ermöglichen serverübergreifendes, +ausfallsicheres Routing zusätzlich zur reinen +[Layer-2](backbone-netzwerk.md#grundlagen-was-ist-ein-layer-2-netz)-Erreichbarkeit von batman-adv. +Konfiguriert über `lib/bird.sh`/`lib/bird6.sh`, nur aktiv wenn `USE_BIRD=1`. +([Ankündigung der Zusammenführung in BIRD 2](https://bird.network.cz/pipermail/bird-users/2011-August/002341.html)) + +### dnsmasq + +DHCP-Server und DNS-Cache für Endgeräte im Mesh. Vergibt IPv4-Adressen aus +`10.149.0.0/16` an Clients auf `bat0` und dient als DNS-Resolver für die Domäne +`ffcmesh` (Details zu den genauen Adressbereichen im [IP-Adressplan](ip-adressplan.md)). +Nur auf ausgewählten Gateway-Servern aktiv (`USE_DNSMASQ=1`), gesteuert über +`lib/dnsmasq.sh`. + +### radvd + +Router-Advertisement-Daemon für IPv6. Kündigt auf `bat0` die IPv6-Präfixe +(`2001:bc8:3f13:ffc2::/64`, `ffc3::/64`) sowie DNS-Server per SLAAC an, sodass sich +Mesh-Clients selbst eine IPv6-Adresse konfigurieren können. Nur auf IPv6-Gateway-Servern +aktiv (`USE_RADVD=1`, erfordert `USE_BIRD=1`), gesteuert über `lib/radvd.sh`. + +## Eigene Skripte (dieses Repository) + +| Datei | Zweck | +|---|---| +| `ffc-server.sh` | Zentrales Steuerskript. Lädt Konfiguration und alle `lib/*.sh`-Module und bietet die Kommandos `start`, `stop`, `watchdog` an — orchestriert damit alle oben genannten Komponenten in der richtigen Reihenfolge. | +| `initd-ffc.sh` | Bindet `ffc-server.sh` als klassischen SysV-Init-Dienst (`/etc/init.d/ffc`) ein, damit der Server automatisch beim Boot startet. | +| `lib/log.sh` | Gemeinsames Logging für alle Module: Meldungen gehen nach syslog, im Watchdog-Kontext (`IS_CRON=1`) zusätzlich per Mail an `LOG_TO`. | +| `lib/gre.sh` | Baut die GRE-Tunnel zu allen in `GRE_PEERS` gelisteten Servern auf/ab und prüft im Watchdog per ICMPv6-Ping, ob sie noch erreichbar sind. | +| `lib/batman.sh` | Initialisiert batman-adv, hängt GRE- und fastd-Interfaces ein, konfiguriert `bat0` (Service-Adressen, Bridge-Loop-Avoidance, Bonding) und startet `alfred`/`batadv-vis`. | +| `lib/fastd.sh` | Startet/stoppt die fastd-Prozesse für den Client-Zugang. | +| `lib/bird.sh` / `lib/bird6.sh` | Generieren die BIRD-/BIRD6-Konfiguration aus den Templates in `conf/`, tragen BGP-Peers und Routen ein, richten Policy-Routing (Tabelle 100) und NAT ein, laden per Watchdog die Geoblocking-Routen nach. | +| `lib/dnsmasq.sh` | Generiert die dnsmasq-Konfiguration und startet/überwacht den Dienst. | +| `lib/radvd.sh` | Startet/überwacht radvd und trägt die IPv6-Default-Route in BIRD6 ein. | +| `lib/meshviewer.sh` | Startet `alfred`/`batadv-vis` eigenständig, falls der Server unabhängig von `lib/batman.sh` primär als Meshviewer-Datenquelle dienen soll. | + +## Konfigurationsdateien (`conf/`) + +| Datei | Zweck | +|---|---| +| `general.conf` (+ `general.local.conf`) | Zentrale Server-Konfiguration: Netzwerk-Interface/IP, Feature-Flags (`USE_*`), GRE-Peer-Liste, Geoblocking-Einstellungen. Die `.local.conf`-Variante enthält die serverspezifischen, nicht versionierten Werte. | +| `bird.conf`, `bird6.conf` | Templates für die BIRD-/BIRD6-Hauptkonfiguration inkl. Policy-Routing-Tabelle `ffc`. | +| `bird-peers.conf` | Template für eine einzelne BGP-Peer-Definition, wird pro GRE-Peer in `bird-peers.local.conf`/`bird6-peers.local.conf` dupliziert. | +| `bird-routes.conf` | Template für eine einzelne statische Route, wird pro Service-Adresse dupliziert. | +| `fastd.conf` | fastd-Konfiguration inkl. der Hooks, die neue Client-Interfaces automatisch in batman-adv einhängen. | +| `dnsmasq.conf` | Template für DHCP-Range, DNS-Domäne und Gateway-Optionen im Mesh. | +| `radvd.conf` | Router-Advertisement-Konfiguration für die beiden IPv6-Mesh-Präfixe. | +| `sysctl.conf` | Kernel-Netzwerkparameter (IP-Forwarding, rp_filter, Connection-Tracking-Limits), die beim Start angewendet werden. | + +## Quellen + +- [batman-adv — The Linux Kernel documentation](https://docs.kernel.org/networking/batman-adv.html) +- [B.A.T.M.A.N. — Wikipedia](https://en.wikipedia.org/wiki/B.A.T.M.A.N.) +- [Batman-adv Bridge Loop Avoidance — open-mesh.org](https://www.open-mesh.org/doc/batman-adv/Bridge-loop-avoidance.html) +- [A.L.F.R.E.D. — open-mesh.org](https://www.open-mesh.org/doc/alfred/) +- [fastd Documentation](https://fastd.readthedocs.io/) +- [An introduction to Linux virtual interfaces: Tunnels — Red Hat Developer](https://developers.redhat.com/blog/2019/05/17/an-introduction-to-linux-virtual-interfaces-tunnels) +- [Merging bird and bird6 — bird-users Mailingliste](https://bird.network.cz/pipermail/bird-users/2011-August/002341.html) +- [BIRD2 BGP Configuration on a Linux VPS](https://www.virtua.cloud/learn/en/tutorials/bird2-bgp-configuration-linux-vps) diff --git a/docs/sicherheitsmodell.md b/docs/sicherheitsmodell.md new file mode 100644 index 0000000..0facd50 --- /dev/null +++ b/docs/sicherheitsmodell.md @@ -0,0 +1,57 @@ +# Sicherheitsmodell + +Dieses Dokument beschreibt, welche Verbindungen im Backbone verschlüsselt/authentifiziert +sind und welche nicht, sowie das Vertrauensmodell, das sich daraus ergibt. Es fasst +Beobachtungen aus den Konfigurationsdateien zusammen — die dahinterliegenden +Design-Entscheidungen (z. B. warum genau so und nicht anders) sind nicht aus dem Code +ableitbar und sollten im Zweifel beim Freifunk-Chemnitz-Team erfragt werden. + +## fastd (Freifunk-Router ↔ Server): verschlüsselt, aber offen zugänglich + +`conf/fastd.conf` konfiguriert zwei unabhängige Eigenschaften: + +- **Verschlüsselung:** `method "salsa2012+umac"` verschlüsselt die Verbindung (Salsa2012 + als Stream-Cipher) und sichert sie gegen Verfälschung ab (UMAC als Message + Authentication Code). Der Datenverkehr zwischen einem Freifunk-Router und dem Server ist + also vertraulich und manipulationsgeschützt. +- **Zugangskontrolle:** `on verify "true"` lässt **jeden** Client mit einem gültigen + fastd-Schlüsselpaar zu — der Server prüft nicht, ob der öffentliche Schlüssel eines + Knotens vorher irgendwo hinterlegt wurde. Das passt zum Grundprinzip eines offenen + Freifunk-Netzes: Ein neuer Knoten kann ohne Anmeldung beim Server-Betreiber beitreten, + sobald er den öffentlichen Schlüssel *des Servers* kennt (verteilt über die + Firmware-Konfiguration der jeweiligen Domäne). + +Das bedeutet: Es findet keine Autorisierungsprüfung statt, welche Person oder welches +Gerät sich verbindet — jeder mit passender Firmware kann Teilnehmer werden. Die +Verschlüsselung schützt die Vertraulichkeit der Verbindung, nicht die Frage, *wer* sie +aufbaut. + +## GRE-Tunnel (Backbone-Server ↔ Backbone-Server): unverschlüsselt + +Die GRE/`gretap`-Tunnel aus `lib/gre.sh` bieten **keine** eingebaute Verschlüsselung oder +Authentifizierung — GRE kapselt Frames lediglich, ohne sie kryptografisch zu schützen. +Ebenso enthält `conf/bird-peers.conf` keine BGP-Session-Authentifizierung (z. B. ein +MD5-Passwort). Wer Zugriff auf den Netzwerkpfad zwischen zwei Backbone-Servern im +Internet bekommt, kann den GRE- und BGP-Verkehr zwischen ihnen technisch mitlesen oder +manipulieren. + +Das ist ein bewusster Unterschied zur fastd-Strecke: Backbone-Server werden — anders als +die anonymen Freifunk-Router — vom Team selbst betrieben und administriert. Das +Sicherheitsmodell verlässt sich hier offenbar auf die Absicherung der Server selbst +(SSH-Zugriff, Firewalling, Auswahl vertrauenswürdiger Hoster) statt auf +Transportverschlüsselung zwischen ihnen. Diese Einschätzung ist eine Ableitung aus der +Konfiguration, keine im Repository dokumentierte Policy-Aussage. + +## Zusammenfassung + +| Strecke | Verschlüsselt? | Zugangskontrolle? | +|---|---|---| +| Freifunk-Router ↔ Server (fastd) | Ja (`salsa2012+umac`) | Nein (`on verify "true"`, jeder mit Schlüsselpaar) | +| Backbone-Server ↔ Backbone-Server (GRE) | Nein | Nein (statische `GRE_PEERS`-Liste, keine Authentifizierung auf dem Tunnel selbst) | +| Backbone-Server ↔ Backbone-Server (BGP) | Nein | Nein (keine Session-Authentifizierung in `bird-peers.conf`) | + +Praktische Konsequenz für den Betrieb: Die Sicherheit des Backbones hängt maßgeblich +davon ab, dass ausschließlich vertrauenswürdige, vom Team kontrollierte Server als +GRE-/BGP-Peers in `GRE_PEERS` eingetragen werden — anders als beim fastd-Zugang für +Endgeräte gibt es hier keine kryptografische Absicherung, die einen kompromittierten oder +böswilligen Peer nachträglich ausschließen würde.