Hey zusammen,
in den vergangenen zwei Jahren fiel mir immer häufiger auf, wie schwer es ist, eine Babel-Gluon-Community zu finden, deren letztes Release nicht Monate wenn gar Jahre alt ist.
Um Bugfixes in gluon auch gegen den babel-code darin zu testen, wäre es praktisch, einer solchen firmware mal wieder über den Weg zu laufen.
In Hannover nutzen wir batman-adv, und haben einen nightly branch. Haben also jede Nacht ein neues Image, dass gluons aktuellen Entwicklungszustand abbildet.
Wenn irgendjemand eine Community benennen kann, die das babel-pendant dazu betreibt, wäre das die größte Hilfe für mich.
Ansonsten würde ich mich freuen, wenn wir in diesem Thread möglichst frische Gluon-Babel-Releases sammeln könnten.
Name der Community; Firmware-Version; Gluon-Version; evtl. Site Version; wenn verfügbar, Commit-Datum des letzten enthaltenen Commits; Link zum Fimware-Ordner; Link zur verwendeten Site.
Das sollte helfen zu jeder Zeit möglichst neue Babel Firmwares zum Testen zu Verfügung stehen zu haben. Vielen Dank für eure Mihilfe!
Nach meinem letzten Stand hat ffffm seine Babel Infrastruktur nicht mehr im Betrieb, und die von Bremen funktionierte nicht, als ich sie das letzte mal vor einem halben Jahr mit @genofire getestet hatte. Ich lass’ mich da aber gerne korrigieren.
In der Kürze hat es mit dein Router wirklich nicht hingehauen.
Gerade bin ich umgezogen und hab die virtuellen Maschinen (unter anderem den alten Babel Gluon von FFHB ) gestartet:
http://[2a06:8782:ffbb:bab0:5054:ff:fe3a:555d]
Doch ja, die wireguard-broker waren damals noch nicht ganz ausgereitzt und inzwischen ist gluon selbst auch etwas davon ab …
Einige Komponenten sind auch relativ waklig damals gewesen …
doch in Bremen herrscht gerade auch etwas stillstand … wenn man sich die aktuellen Gluon-Batman-Firmware anschaut, sind die prioritäten etwas verlagert …
Ich interessiere mich weiterhin für babel und freue mich über den aktuellen Entwicklungsstand (und eine Lösung, bei der die wireguard keys ohne extra Nutzeraufwand verteilt werden)
Inwiefern ist das bei Babel anders als bei Batman-Adv? Sprich: kann nicht der Mechanismus verwendet werden, der bei VXLAN-über-Wireguard Anwendung findet?
Die Idee Persistent wireguard-keys zu speichern finde ich gut. Allerdings nicht die Single-Point-of-Failure Struktur durch Mosuitto und WGKey-Broker.
Warum wurde nichts gebaut, das auf den Gateways-/VPN-Server direkt läuft?
Die Keys werden nicht gestored. Sie werden exakt bei Anmeldung über Mosquito an die GWs verteilt. Und wenn das GW rebooted hat es keine Keys mehr. Und alle Nodes müssen sich neu anmelden. Man kann die Komponenten auch direkt auf den Gateways laufen lassen. Unsere Struktur aus 4 Gateways die alle die selben Keys brauchen, nutzt aber den verteilten Ansatz aus broker läuft in einem Docker Container mit mehreren Webfrontends davor und mehreren Gateways die per worker zu mosquito verbinden.
Ein bisschen Hintergründe gibt es hier:
Die Packages lassen sich alle schnell anpassen auf Babel.
Danke für die Informationen:
Doch weiterhin ist Mosquito nach wie vor ein Single-Point of Failure oder?
Die Packageanpassung für Babel sehe ich auch als ein kleine Aufgabe, die nötigen Anpassungen auf wgkex und Gateway Seite sind noch etwas größer:
ohne vxlan müsste ein wireguard interface auf dem Gateway pro Node laufen, um mit AllowedIPs ::/0 laufen zu können - daher muss dem Node noch sein Port mitgeteilt bekommen - auf dem der passende Wireguard-Interface auf dem Gateway läuft
zudem möchte man villt. nich auf jeden Gateway den Port blockieren (ansonsten kann man mit mehreren Gateways nicht eine höhere Anzahl an Nodes bedienen)
Für den Betrieb verschiedenen Webfrontends des wgkex pro Gateway sehe ich folgende Probleme:
Die Konfigurations-Struktur des Packages gibt allerdings vor, das es nur eine URL für den wgkex broker für alle gateways gibt - eine Änderung um dort je nach Gateway eine anderen Frontend anzusprechen wäre etwas komplexer.
Jup, mosquitto ist ein SPOF, könnte man aber durch ein Mosquitto Cluster reparieren. Das war bei uns aber noch nie ein Problem. Für deinen Zweck wäre eventuell der wgkex Fork von ffrgb was. GitHub - ffrgb/wgskex
Um jeweils das Gateway direkt anzusprechen für den Key, könntest du einfach hier das gewürfelte Gateway als Variable nehmen anstatt die globale Broker URL.
Schon, aber es ging explizit nur um »(und eine Lösung, bei der die wireguard keys ohne extra Nutzeraufwand verteilt werden)«, und da hat die gluon-vxlan-wg-vpn-Fraktion eben einen Verteilmechanismus ersonnen — den von @awlnx ja zwischenzeitlich verlinkten wgkex. Ich habe mir das nicht weiter angesehen, wollte darauf aber hingewiesen haben; nicht mehr, nicht weniger. Daß WireGuard und Babel – effektiv zwei konkurierende L3-Routingebenen – vielleicht nicht optimal harmonieren, ist ja ein ganz anderes Thema. Allerdings eines, das die Nutzung von WireGuard in dem Kontext imho grundsätzlich in Frage stellen sollte — dennoch sollte sich die wgkex-Methodik auch für andere Schlüsselaustausche nutzen lassen. Oder als Blaupause für eine eigene Lösung.