Mqtt/autol3VERALTET

Hier möchte ich mal kurz beschreiben was ich mir grob unter autol3 vorstelle:

Ziele

• Die komplette Konfiguration soll im WebUI ermöglicht werden, kein SSH mehr nötig
• Der Router soll auf Wunsch vollkommen automatisch konfiguriert werden und als Layer 3 Router funktionieren
• Es soll jederzeit manuell eingegriffen werden können und auch nur Teile manuell konfiguriert werden können z.b.:
  • VLAN Settings default laden aber IPv4 und IPv6 manuell konfigurieren
  • IPv4 und IPv6 automatisch konfigurieren aber VLAN Settings manuell anpassen
  • VLAN und IPv4/IPv6 automatisch konfigurieren aber einen manuellen wireguard Tunnel anlegen
  • Prinzipiell ist die Idee jede Kombination schon von grundauf zu ermöglichen so das kein geschlossenes System, wie es bei der aktuellen Node Firmware ist, entsteht und jeder manuell dort eingreifen kann wo er es für nötig hält aber Sachen automatisch konfigurieren lassen kann die selbst (noch) nicht verstanden werden.
• Standardmässig soll immer eine manuelle Konfiguration vorgegeben sein, das autol3 muss explizit aktiviert werden.
• Die automatische Konfiguration soll so dezentral wie möglich sein
  • MQTT Broker werden als Cluster betrieben das jeder mitbetreiben kann, es läuft masterlos so das es keine zentrale Stelle gibt
    • Ein Routerbetreiber kann sich einen MQTT Server aussuchen den er anfragt, er ist auf keinen bestimmen angewiesen und hat die freie Wahl
  • Jeder kann IP Adressen im MQTT Cluster anbieten

Automatische IPv6 Konfiguration

Wird der Haken gesetzt wird das package fff-autoconfig-v6 aktiv. Per Cronjob wird der Router per mqtt eine Nachricht versenden an /ipv6/asknew und als Inhalt seine MAC Adresse. Nun können viele Leute antworten mit "ich hab hier eine IP Adresse nutzt diese" dies geschieht auf dem Topic IPv6/usethis/$MAC/$ASSIGNER mit einer kleinen json als Inhalt:

{ "assigner": "$ASSIGNER", "ip": "ipv6 Adresse mit Subnetzangaben z.b. 2001:db8::/64" }

was der Router nach seinem asknew abhört. In der aktuellen Version wird einfach die erste Antwort verwendet und die IP Adresse konfiguriert und sich in der /etc/config/fff gemerkt woher die Adresse stammt und welche verwendet wird.

Alle 5 Minuten fragt der Router nun nach, ob er die Adresse noch verwenden darf. Dazu prüft er erst ob er eine Adresse hat und wenn das der Fall ist sendet er an das Topic /ipv6/canusethis/$ASSIGNER eine JSON mit folgenden Inhalt:

{ "mac":"$MAC", "ip":"$IP" }

er erwartet innerhalb von 5 Sekunden eine Antwort auf dem Topic /ipv6/canusethisanswer/$MAC (aktuell wird als Inhalt ein ack versendet, prinzipiell wird aber nur geprüft ob eine Antwort kommt). Sollte keine Antwort kommen, wird die aktuelle IPv6 Konfiguration komplett verworfen und wieder mit asknew von vorne angefangen.

Zum aktuellen Zeitpunkt wird immer die erste IP Adresse genommen die per MQTT kommt, der User hat aber jetzt schon manuelle Eingriffsmöglichkeit indem er bestimmte Assigner blacklistet. Zukünftig ist auch angedacht hier den User auf Wunsch freie Wahl zu lassen, welche der vielen möglichen Antworten er verwenden will. Dies ist zum aktuellen Zeitpunkt aber noch nicht implementiert.

Automatische IPv4 Konfiguration

Dies funktioniert grundsätzlich nach dem gleichen Prinzip wie IPv6 nur das der Router hier sich nur eine einzelne Adresse per mqtt geben lässt, als /32 konfiguriert und für Clients das Subnetz 192.168.0.1/16 verwendet, welches auf die einzelne Adresse geNATtet wird. Prinzipiell machen wir hier cgnat wie es große Provider auch machen. Als Topic wird hier statt /ipv6 dann /ipv4 verwendet.

Automatische wireguard Konfiguration

Hier ist noch kein Code vorhanden, daher nur eine grobe Vorstellung wie das ganze vielleicht funktionieren könnte:

1. Der Router sendet seinen Public Key und E-Mail Adresse ins mqtt und erwartet eine Rückmeldung von Servern wohin er sich verbinden darf

2. Der Router konfiguriert sich diese Verbindung und nutzt diese

Da hier eine automatische Konfiguration erfolgt, müssen auf den wireguard Gegenstellen einige Sicherheitsmaßnamen greifen. Ich könnte mir z.b. folgendes vorstellen:

• Verfizierung der E-Mail Adresse
• Man lernt von den Routern nur /64 IPv6 Adressen
• Man lernt von den Routern nur /32 IPv4 Adressen
• Man lernt von den Routern nur 10/8 (oder 10.50/16 bzw. 10.83/16) Adressen
• Man lernt von den Routern nur v6 Subnetze die auch im mqtt durch die Gegend fliegen
• Man lernt nur eine bregrenzte Anzahl an Routen von den Routern um ein flooden zu verhinden oder trennt Verbindungen einfach komplett wenn irgendwas rein kommt was nicht da sein sollte

Allgemein hab ich hier noch am meisten Bauchschmerzen wie man das sinnvoll umsetzt

Komplett automatische Konfiguration ohne Internet

Ein Problem kann entstehen, wenn sich jemand per RF anbinden will und IP Adressen automatisch konfigurieren will. Da hier kein Internetzugang zur Verfügung steht, kann hier der MQTT Server auch nicht erreicht werden und es kann keine Konfiguration bezogen werden. Dazu hab ich folgende Idee:

• User klickt auf automatisch konfigurieren
• Router generiert sich eine ULA v6 /48 Netz (das ist mit sehr sehr [...] sehr sehr hoher Wahrscheinlich einzigartig)
• Router announced dies ins Babel und kann damit dann die ULA anycast Adresse des MQTT Brokers erreichen => fd43:5602:29bd:ffff::1883
• Jetzt kann der Router sich eine IP Konfiguration vom MQTT Broker ziehen und sich korrekt mit Internetzugang konfigurieren

\o/ Ist die Idee nicht geil? ;)

Voting

Angedacht ist eine Art Voting System. Auch hier gibt es noch keinen Code und es ist eine reine Überlegung: Es wird geprüft ob erhaltene IP Adressen oder Wireguards funktionieren. Funktionieren diese nicht, wird eine retain Message ins MQTT gelegt das $ASSIGNER bei Protokoll X (IPv6, IPv4, wireguard, etc.) defekt ist. Andere Router können diese retain Message lesen und den $ASSIGNER sofort blacklisten (mosquitto_sub -T Parameter, deshalb ist der $ASSIGNER in den Topics immer enthalten damit man danach filtern kann. Grundsätzlich funktioniert auf diese Art auch schon die manuelle Blacklist). Da retain Messages von jedem überschrieben werden können, kann der Betreiber, wenn er sein Zeug repariert hat die retain msg löschen. Sollte die Reparatur nicht funktioniert haben, wird der nächste Router der auf das Problem stößt die retain msg direkt wieder ins System blasen.

Aber die Sicherheit und Ausfall und überhaupt...

Ja ein Problem, wenn jeder MSQ ins MQTT blasen kann, kann auch jeder Unsinn da rein blasen. Das ist aber mit der Node Firmware auch nicht anders, wer will kann die auch jederzeit lahm legen da hier die Gateways auch einfach jede Verbindung akzeptieren. Mutwillige Angriffe sind gegen das System natürlich sehr einfach möglich.

Wie man mit automatisch Zugänge zum Babel arbeitet muss man sich noch überlegen wo hier Angriffsvektoren sind, einige Vorschläge hab ich schon im wireguard Abschnitt niedergeschrieben was man wegfiltern könnte