3
SuperNode Spezifikation
alex edited this page 12 months ago
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+umacaktiviert 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