Spezifikation Gluon Supernode FFLE

Fastd für Nodes

Version v22
Jeder Supernode benötigt einen eigenen privaten Schlüssel
Der Port ist frei wählbar
Als MTU ist 1300 zu verwenden
Als Verschlüsselungsmethode muss mindestens salsa2012+umac aktiviert sein
Der Node sollte über einen Domainnamen erreichbar sein

Kommunikation zwischen Supernodes

Zu diskutieren
Openvpn?
Version
Konfiguration

BATMAN adv

Auf Fastd + Openvpn Devices
Version, aktuelle
Konfiguration

DHCPd v4 für die Clients (Nodes)

Eigenes Subnetz für jeden Supernode
Supernode ist Gateway
NAT ins Internet bzw. zu VPN-Provider
Eindeutige IP im deutschlandweiten Freifunk-Netz
entweder ein /22 pro Supernode oder mehrere /24
Zu prüfen ist, welche Bereiche noch frei sind
Bedarf: 20 /24er Netze
Dr. Broiler hat eine Liste von freien Supernodes
- TODO: hier ergänzen

RADVd und/oder DHCPv6

Brauchen wir?
Unbekannt, weil keine IPv6 Erfahrungen
Vermutlich kein Support in BATMAN
Nächste Iterationsstufe

Wireguard

Ausleitung an mullvard
Martin stellt uns mindestens 2 mullvard VPNs zur Verfügung
Michael stellt uns mindestens 2 mullvard VPNs zur Verfügung
Alex stellt uns mindestens 2 mullvard VPNs zur Verfügung
Optional, nicht Teil der Spezifikation. Obliegt dem Betrieber des Supernode, ob er über VPN ausleitet

Firewallregeln

Enforcement auf Wireguard, ohne den kein Internet für Nodes
DHCP-Traffic auf dem fastd (von nodes) verhindern
RADVd-Traffic auf dem fastd (von nodes) verhindern

Vorschläge zur Architekur

alex

Iteration 1 (Bootstrap)

Wir betrachten jede Supernode zunächst als Insel, d.h.

eigenes IPv4 Netz, was bei jeder Supernode gleich ist
- bspw. 10.50.0.0/21
- einzelner DHCPv4 Server pro Supernode
eigenes IPv6 Netz, was für jede Supernode einzigartig
- bspw. fdef:ffc0:7030:::/64
- HOOD-IDs werden im Wiki gepflegt
- einzelner DHCPv6 Server pro Supernode
alle Pakete, die nicht als Destination das eigene IP-Netz haben, werden markiert und über Wireguard ausgeleitet
interne HTTP-Server für Download der Firmware mit fester URL
rundimentären DNS server für bereitstellung des Downloadmirrors, ansonsten Ausleitung an externen DNS-Server bspw. von Mullvad)
Hood-Node hat explizit keine Redundanz
einzelne Services werden über Docker Container bereitgestelt, ganzes Deployment wird über Kubernetes Beschreibung zusammen gebaut -> Plan wäre installiere k3s und führe folgendes Deployment darauf aus

Interation 2 - Interconnect und Services

Wir nutzen die einzigartigen IPv6 Netz der Nodes, um untereinander über wireguard zu Routen, dadurch haben wir kein Layer2-Traffic, der über die Nodes hinausgeht. Warum:

fastd passt besser für Router und batman
müssen uns weniger um Firewall Regeln kümmern, da nur Layer3 betrachtet wird

Wer eine weitere Hood zusteuern will, muss mit uns in Verbindung treten und wir schalten das Routering für das Netz frei zum bestehenden Netz zu. Einzige Voraussetzung ist, dass "externe" Nodes sich um die Ausleitung zunächst selbst kümmern sich an das IPv6-Adress-Schema halten müssen und dann die entsprechenden Routen kümmern müssen.

Weitere Funktionen, die ich sehe:

DNS namen Registrierung über DHCP
NTP Server

Iteration 3 - Failover

Wir bringen Redundanz ins Netz rein, d.h. wir splitten alle Nodes in zwei, d.h.

synchronisierte DHCP-Server
synchronisierte DNS-Server
wireguard-Failover -> zz. hab ich da noch kein konkretes Konzept