Freifunk-Leipzig
/
gluon-site
13
0
Fork 1
Code Issues Pull Requests Projects Releases Wiki Activity

Vorschlag Architektur

alex 2022-04-07 19:57:18 +02:00
parent 48b3fb107c
commit 192d0f1013
1 changed files with 42 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
SuperNode-Spezifikation.md

@ -49,6 +49,7 @@
* 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
@ -60,3 +61,44 @@
* 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:<HOOD-ID>::/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