gw07.in.ffmuc.net:~# ff_fastd_conn -a | awk -F ' ' '$1 {sum += $2} END {print sum}'
543
Also auf unseren Gateways ist schon Party ;).
Gut, ich verstehe, daß ich die Motivation nicht wirklich verstehe 
Geht’s Euch dann wirklich nur um die verschlüsselte Verbindung? Ist ja letztlich auch egal; die Eleganz von L2TP mit Tunneldigger ist für mich gerade, daß da nichts ausgetauscht werden muß. (Unser fastd-Skript ist etwas komplexer, if [ ${CURPEERS} -ge ${MAXPEERS} ]; — 4 fastds auf dem Blech, aber ab $Anzahl Clients kommt die CPU nicht hinterher – Fluch des singlethreaded fastd-Prozesses – und so sichern wir zumindest serverseitig etwas Performance bei fastd.)
Zurück zu WG:
Aber Ihr müßt doch auf jedem GW vor der Verbindung zu Wireguard den Pubkey des sich verbindenden Knotens kennen, also müßt Ihr doch wissen, welcher Knoten welchen Pubkey hat (oder zumindest, welche Pubkeys es gibt), damit auf dem GW entsprechend die WG-Config erzeugt werden kann?
Wieso verstehst du die Motivation nicht? Zum Debuggen und zur Übersicht auf dem Gateway ist das schon ganz nett.
Und ja, Verschlüsselung ist für uns ein wichtiges Thema und wurde von der Community auch immer wieder verlangt, dass das beibehalten werden soll.
Auf dem Blech dass du oben siehst mit seinen knapp 600 fastd Verbindungen laufen 11 fastds.
Ja, aber nur genau IN dem Moment wenn sich ein Knoten verbindet (so die Hoffnung). Wir wollen keine Historie darüber führen und einen regelmäßigen Cleanup Job auf den Gateways.
Und den Satz verstehe ich nicht, da wird doch schon ziemlich viel ausgetauscht. Nämlich fastd gegen Tunneldigger.
Für den Betrieb müssen Knoten und Gateway keine Infos vorab austauschen, läuft das Gateway voll, hänge ich 'n weiteres unter dem FQDN hinzu, fertig.
Bei fastd geht’s fast genauso einfach, allerdings muß ich vorher dafür sorgen, daß das neue Gateway den passenden Key zur FQDN hat. (Sofern keine Positivliste geprüft wird; sonst brauche ich zentrales Repository für alle Keys, welches im Setupmode befüllt wird, und einen Mechanismus, dieses auf die Gateways zu spiegeln.)
Mit Wireguard muß ich dieses zentrale Repo und den Verteilmechanismus haben/bauen/reaktivieren, da sonst keine Verbindung zustande kommen kann. Das seht Ihr AFAICS ja auch vor (Kommentar „For later“ oder so beim Registrations-wget).
Das meinte ich mit dem Austausch, Datenaustausch also.
Aus operativer Sicht will ich jederzeit die Infrastruktur umbauen können, ohne eine neue FW ausrollen zu müssen. Tunneldigger wie fastd kann ich so laufen lassen — bei Tunneldigger mit dem Nachteil, daß die Knoten sich darauf verlassen müssen, daß sich hinter der IP zum FQDN auch das Richtige verbirgt.
Bei fastd und tunneldigger musst du doch auch irgendwo die Gateways angeben oder einen Punkt haben an dem die Infos zu den Gateways bereit stehen. Sehe hier jetzt keinen Unterschied zu unserem Setup.
Entweder man baut mehrere Gateways direkt in die Firmware oder der Broker gibt einem am Ende ein Gateway zu dem man verbindet.
Konkret setzt Ihr also auf einen Webservice auf jedem Gateway, den der Knoten quasi zur temporären Anmeldung vor dem Verbindungsaufbau nutzt? Da habe ich etwas Bammel, daß sich nach einem Strom- oder Netzausfall da die http-Requests auf den Gateways stauen (und/oder Wireguard mit den geballten Konfigurationsänderungsanforderungen nicht klar kommt).
Nein, der Service ist zentral und nicht pro Gateway um eben dieses Szenario zu verhindern.
(Im Moment ist es ein GW und ein Service weil eben PoC Status)
Und die paar HTTP Requests pro Minute sollten kein GW/Service aus dem Internet werfen. Ansonsten sind es für den Linuxkernel nur ein paar Routen Updates, auch das sollte nicht wirklich wehtun. Aber time will tell.
Wir drehen uns irgendwie im Kreis, oder? Neuer Versuch, das habe ich verstanden:
Zentraler Service, der Pubkeys einsammelt. Derzeit bedient von jedem Knoten vor Kontaktaufnahme, prinzipiell aber auch denkbar analog zu fastd, also „Registration“ des Pubkeys im Rahmen des Setup-Prozesses. (Wäre meine Präferenz. Das also nicht zu verbauen wäre nett.)
Dann braucht es doch einen Service, der die Keys zu den Gateways bringt, damit dort Wireguard auf die Kontaktaufnahme vorbereitet werden kann. Ihr braucht den im PoC nicht, weil nur ein GW? Und später soll das ein Message-Bus werden?
Mein Bauchgefühl sagt mir momentan, daß ich das nicht mag; zuviele Zahnrädchen, die da ineinandergreifen müssen, bis der Knoten seine Verbindung hinbekommt, und serverseitig auch komplex zu debuggen (zumindest ist das meine Bereitschaftserfahrung mit über den Zaun gekippten Bussen); ich ziehe autark agierende Systeme vor.
Ich würde also die Pubkeys lieber bei der Erstinstallation registrieren (das per Meta-http-equiv-Reload durch die Schlußsseite des Config-Modes zu triggern tat hier vor ~5 Jahren ganz gut; notfalls kann der Knoten ihn bei jedem Neustart ja auch noch einmal schicken) und dann wohl per rsync auf die Gateways schieben. Und ein Cron-Job baut lokal die Wireguard-Config; Münsterland – als Beispiel eines mittelgroßen Setups – hat ca. 5000 Knoten, verteilt über ca. 80 Meshes, das sollte rsync auch bei Verdoppelung alle 5 Minuten hinbekommen.
Wenn Unitymedia Vodafone das Kabelnetz ausgewartet hat, kommen auf einen Schlag alle Endgeräte wieder, und die würden sich nach meinem Verständnis von checkuplink dann pseudo-zufällig auf die eingetragenen Gateways (bei uns tendenziell 2-3) verteilen. Oder laß’ es ein Routingproblem geben und alle Knoten waren kurz offline. Bauch sagt halt »grummel« an der Stelle.
Also entweder mesh-vpn-fastd oder mesh-vpn-tunneldigger oder gluon-mesh-vpn-wireguard-vxlan.
Muß das wirklich in die site.conf? Ich baue unsere Tunneldigger-FW mit sed -i -e s/mesh-batman-adv-14/mesh-batman-adv-15/g -e s/mesh-vpn-fastd/mesh-vpn-tunneldigger/g site/site.mk und tausche nur das site/domains-Verzeichnis gegen das mit Tunneldigger-VPN-Einstellungen aus …
Du kannst auch einfach alle Keys auf alle Gateways deployen.
Ich bau’ mir da mal was.
Noch besser wäre wenn du es für die Allgemeinheit baust ;).
1 „Gefällt mir“
Es wird auf GitHub liegen, dann schau’n mer mal 
1 „Gefällt mir“
Das ist doch auch die site.mk wie von mir beschrieben? Ansonsten auch die sites/domains austauschen für die Wireguard Einstellungen.
Wir fügen jetzt automatisch die Keys auf unserem TestGateway hinzu und folgende Segmente können nun Wireguard:
welt, uml_west, uml_ost, muc_cty, muc_ost und gauting
Die Firmware hat einen eigenen Autoupdater. Den Branch findet ihr hier:
https://github.com/freifunkMUC/site-ffm/tree/wireguard
Downloads wie immer hier:
http://firmware.ffmuc.net/wireguard/
Builds triggern wir nun automatisch in unserem Jenkins nach commit im Repo alle 15min.
Hier sammeln wir jetzt die Ideen für die Serverseite des Problems:
Nächste Steps sind den Messagebus zu etablieren und mit Python direkt Netlink zu sprechen um Wireguard und vxlan zu programmieren.
Wie immer help-wanted und welcome ;).
2 „Gefällt mir“
Pyroute2 kann das. Hat auch WireGuard support. Ich hatte da mal den L2TP support eingebaut: generic: add L2TP support by kaechele · Pull Request #709 · svinota/pyroute2 · GitHub
Von Pyroute2 sprechen wir auch in den issues :). Und ja, damit werden wir das wohl aufziehen. Ansonsten PRs welcome :).
Ein weiterer Vorteil, der sich langsam zeigt auf Gatewayseite sind die Ressourcen die notwendig sind auch massiv gesunken. Wenn ein Client nun 200 - 300Mbit/s drückt reichen die 2 Cores der aktuellen VM immer noch gut aus.
Bei fastd laufen wir zu Peakzeiten mit 8 Cores am Anschlag bei 500mbit/s Traffic. Davon abgesehen sind 200-300Mbit/s auf einem fastd Prozess fast nicht schaffbar.
1 „Gefällt mir“
Hmm. VM mit 192.168.122.0/24, v4-only:
root@33332-FW-Test-Wireguard-d081:~# wg
interface: mesh-vpn
public key: KH9IWkDwDYmX9nTcZ5I5+fJoD3qZrmC9HpZi6cVI2SY=
private key: (hidden)
listening port: 58688
peer: mSA2oxzfCc+2hHCHjShJcVM9RM5HOMZJBnVrV0+Zhy0=
endpoint: [2a06:e881:1707:1::c1ff:fe1a:78e8]:60001
allowed ips: fe80::f000:22ff:fe12:1/128
persistent keepalive: every 25 seconds
Das wird nicht tun, br-wan hat nur v4 … Ist Wireguard schlau genug, auch die v4-IP zu probieren, auch wenn als Gegenstelle v6 gelistet ist? Oder muß auf der Knotenseite ggf. nur die v4-IP des FQDN in die WG-Konfiguration übernommen werden?