wie vermutlich Einige von euch schon mitbekommen haben, basteln wir bei Freifunk München fleißig an einer Implementation von Wireguard mit VXLAN und BATMAN.
Vorteil der Lösung ist, wir haben für das ganze Konstrukt auf Gatewayseite bei egal wievielen Clients eine konstante Anzahl an Interfaces pro Site.
Wir fügen im Moment die Keys semi-automatisiert hinzu nach Review.
Wir träumen als Backend von einem Stateless Service der die Keys entgegen nimmt und dann das jeweilige Gateway notifiziert dass ein Client verbinden will.
Im Moment ist alles im PoC Status und kein Cleanup hat stattgefunden. Wir wären trotzdem um jegliches Feedback dankbar!
Vielleicht noch ein bisschen Erklärung zum Ansatz.
Wir nutzen den Domain_Seed für die vxlan IDs für die Interfaces die über Wireguard gebaut werden um auch hier nichts in die site-config einfügen zu müssen.
Durch den Publickey errechnen wir die ipv6 Adresse des Nodes und damit wissen wir was in allowed-ips des Gateways muss. Diese v6 IP fügen wird dann als statische Route auf das jeweilige wireguard Interface hinzu und fügen außerdem die IP der forward Table des VXLAN hinzu.
Alles davon erfolgt nur rein auf Basis des Publickeys der ausgetauscht wird. Im Besten Fall errechnen wir auch die IPv6 vom Gateway an Hand seines Publickeys und müssen auch für das Gateway noch weniger statisch konfigurieren.
Ok Im Ernst, warum der Aufriß, über einen L3-Tunnel einen L2-Tunnel zu legen und das dann an Batman anzuknoten? Wireguard ist ein L3-Tunnel, würde es dann nicht Sinn machen, auf den Knoten (v4 und) v6 per Babel zu routen? Die Franken haben das AFAICS doch schon recht gut im Griff mit Babel und public IPv6 in ihrem Netz — halt ohne Gluon. Mit Gluon ist’s IIRC Frankfurt, die sich von Batman, sprich der L2-Wolke, trennen wollen?
Mit Tunneldigger gibt’s eine (noch immer v4-only?) Lösung, ein L2-Mesh mit Batman zu stricken — außer noch weniger Payload sehe ich gerade nicht den Vorteil, 1 In-Kernel-Protokoll durch 2 gestapelte abzulösen? Muß ja auch alles durch die Plaste-CPUs
Tunnel per v4 sind nervig (vor allem, da v4-Adressen Mangelware sind), ja — andererseits ist es nur v4, was man heute voraussetzen kann. Und auf UDP-Basis kommt der Kram auch weitgehend gut durch die NATs da draußen. Und ich halte es noch immer für fragwürdig, den Datenverkehr eines offenen WLANs auf dem Transport zm Gateway zu verschlüsseln um der Verschlüsselung willen — zumal er nach dem Gateway sowieso nackig im Internet vom/zum Ziel läuft
Das als theoretisierende Frage nach dem Warum (Aus meiner Sicht funktionieren Batman-L2-Netze so bis wenige hundert Knoten/tausend Geräte leidlich gut, sodaß ich, auch wegen KISS, durchaus Sympathien für Batman-basierte Ansätze habe.)
Zur Umsetzung: um eine FW damit zu bauen brauche ich welchen Branch, Tag, Commit, whatever von freifunk-gluon/gluon? Und zu dem kommt dann gluon-mesh-vpn-wireguard-vxlan im Branch gluon-mesh-vpn-wireguard-vxlan aus freifunkMUC/community-packages, richtig? Plus entsprechende site.conf-Einträge, und das war’s? (Klar kann ich Eure FW gegen Euer Setup fahren, aber wenn schon, denn schon ) Was ist der Hintergrund von wireguard-tools, wo muß das hin? Danke für’s nicht hauen
Mit Tunneldigger habe ich 827382633 Interfaces die ich nicht verwalten, kontrollieren oder sonst irgendwas kann. Wir wollen auch keine unencrypted Verbindungen zum Gateway, genau das Problem lösen wir. Wir können damit v4 und v6 für den Tunnel.
Wir wollen/können im Moment nicht einfach auf Babel switchen. VXLAN wird in Gluon bereits erfolgreich für Meshing eingesetzt.
Wir lösen damit das Problem keine Infrastruktur anfassen zu müssen die funktioniert (BATMAN_V) und keine unverschlüsselten Verbindungen einzuführen und trotzdem mehr Geschwindigkeit zu bekommen.
Die Plaste CPUs quititeren diese Versuche bereits mit 2x bis 5x mehr Speed als mit fastd. Alleine das dürfte Beweis genug sein dass es gut ist ;).
Du diskutierst mit dem Küchenchef, ob er dem Gast nicht Moussaka statt der bestellten Lasagne hätte machen sollen?
Oder anders: Das hier gibt es, weil es eine Lösung ist für einen Request, den schon viele geäußert haen.
Ob man technisch nicht vielleicht etwas ganz anderes bauen möchte, oder ob man nicht mal wieder eine „niemand braucht vpn-verschlüsselung für die Tunnel“-Diskussion führen möchte:
Hier geht es um eine technische Lösung, die seit vielen Jahren von Leuten gewünscht wird.
Nein, ich frage den Gastwirt, warum eine Hochzeitstorte bestellt wird, wenn eine üppige Schwarzwälder Kirsch schon daneben steht und die hungrige Meute schon im Saal sitzt. Nachdem ich vorher geklärt habe, ob denn solche Fragen gewünscht sind. Deinen Off-Topic-Post hingegen hättest Du somit lieber sein lassen sollen. Also zum Thema:
Das mit der Zugangskontrolle leuchtet mir ein, das ist bei L2TP eher schwierig. (Daß ein Missetäter sich per Mesh dennoch unkontrolliert Konnektivität verschaffen kann, bleibt aber eine Schwachstelle, weswegen wir auf die Key-Registrierung bei fastd dann konsequent verzichtet haben.)
Die L2TP-Tunnel landen in der Bridge zum Mesh, verwalten tut das Tunneldigger; aber ok, die Geschmäcker sind verschieden. (L2TP-Infra parallel zu fastd läuft $hier im Testbetrieb, mit der gleichen Motivation: mehr Durchsatz/weniger verbratene CPU-Zyklen auf den Gateways.)
v6 für den Tunnel ist das zweite Argument, das ich nachvollziehen kann.
Insofern danke für die Darlegung der Motivation. Mal am Wochenende gucken, ob ich 'nen Piloten damit hinbekomme, primär denke ich da ans GW
Auf die Beweggründe, warum Menschen „Wireguard statt fastd und nicht babel und nicht l2tp“ wollen, das haben wir an vielen anderen Stellen x-mal diskutiert.
awlnx hat hier endlich eine eine offensichtlich funktionionierende Lösung, die von ganz bösen Kinderkrankheiten der Urversion aus Süd-NRW befreit wurde.
Ob Du das jetzt für Dich als sinnvoll erachtest oder nicht: Es ist genau das, was viele Leute seit langer Zeit nachgefragt haben.
Optisch ist das natürlich schöner.
Technisch isst es aber n dem Rahmen in dem wir bislang Supernodes beschafft haben ist das mit einer zwischengeschalteten Bridge machbar. d.h. 150 Tunnelinterraces auf einer Bridge sind nach meinem Gefühl nicht schlimm, solange nicht größere Anzahl von Leuten „in der Drehtür“ stecken und alle x Sekunden reconnected.
Daher meine Frage aus Unwissenheit:
Wie verhält sich Wireguard in so einem Szenario? Also 100 Clients, die z.B. auf Grund von CGN-f’up bei ihrem Broadband-Anbieter im Handshake failen und sofort einen reconnect versuchen?
Ruiniert das die „Experience“ der Clients, die schon drin sind?
Wir hätten wenn wir alle Nodes auf L2TP umstellen etwa 750 manchmal auch 1000 Tunnelinterfaces auf einem Gateway. Das kommt uns nicht so vor als ob das gut laufen würde.
Gute Frage :). Genau das versuchen wir gerade auch mit den Tests zu klären da wir keine Erfahrung damit haben. Bis jetzt scheint das hinzufügen oder löschen von Clients keinen Einfluss auf die Anderen zu haben.
Reconnect-Orgien sollten egal sein, da der Partner einmal mit seinem Key hinzugefügt wird und damit nicht für ständiges flappen der Konfiguration sorgt.
Du warst allerdings explizit gar nicht gefragt, zudem wurde die Frage von kompetenterer Stelle – aus dem Entwicklerkreis nämlich, an den sich die Frage richtete – schon beantwortet.
Und durch Deine unqualifizierte Antwort, die sofort wieder zur Metadiskussion über das, worum es hier Deiner Meinung nach gehen sollte, abhebt, derailst Du den Thread — erreichst also das, was Du vorgeblich verhindern willst. Gratuliere.
Es ist im Bereich Technik doch durchaus eine legitime Frage, warum eine Implementation so gewählt wurde, wie sie gewählt wurde — auch wenn Dich konkret das langweilen sollte.
Statt Wireguard unter einen L2-Tunnel zu legen, hätte es auch IPSec sein können; statt VXLAN über einen L3-Tunnel zu legen, hätte man auch beim etablierten Tunneldigger bleiben können. Die Frage an die Entwickler nach dem Grund für die konkrete Wahl sollte daher legitim sein, zumal vorab zugelassen; die Metadiskussion um die Frage ist es eher nicht.
Anyway:
Hmm. „1771 Knoten, davon 1661 Knoten online mit 1874 Nutzern auf 44 Gateways“ zeigte Meshviewer - loading... gerade.
Auf 750-1000 Verbindungen komme ich bei ~1800 Knoten und Batman (d. h. vorzugsweise nur genau 1 aktive Verbindung Knoten-Gateway zwecks Routenreduktion) nur bei Reduktion von 44 auf ca. 2-3 GWs, oder was übersehe ich?
Wie funktioniert die Gateway-Selection? Es werden ja aus Redundanzgründen mehrere WG-Gegenstellen eingetragen, hat der Knoten dann im Beispiel 3 wg-Tunnel offen, oder gibt es eine Steuerinstanz auf oder außerhalb des Knotens, die das steuert? Und wie funktioniert die Synchronisation/Aufteilung von Keys auf Gateways? wgked scheint alles, was nach einem Key aussieht, nach /var/lib/wgke/public.keys zu schreiben; rsynct Ihr das minütlich/per inotify auf die Gateways? Sofern WIP (sieht noch nach Single-Domain aus), was ist der Plan?
Dein Einstieg in die inhaltliche Diskussion war das Folgende.
Ob das hinsichtlich eines konkreten Proposals für „Wireguard für Batman-Gluon“ sachbezogen war? Ich denke, dass unsere Einschätzungen da schlicht abweichend sind.
Der Knoten, der hier -vorsätzlich auf einem 841er- mit dem Münchener wg seit ein paar Tagen läuft, der scheint trotz alarmierender load-Werte stabil zu sein (keine Reboots, keine sonstigen Ausfälle) und mit etwa(!) doppelt bis dreifachem Durchsatz im Verhältnis zu fastd zu liefern.
Von daher ist es zumindest für mich der klare Favorit für das Szenario bei dem bislang Leute beharrlich bei fastd geblieben sind.
Die 44 Gateways sind in Wirklichkeit 3 Maschinen, nur durch die unterschiedlichen Respondd Instanzen tauchen sie mehrmals auf. Wir wollen generell aber in der Lage sein alle Knoten auf einem Gateway laufen zu lassen (Wartung, Ausfall etc).
Wir würfeln im Moment random zwischen den Gateways und wählen eins aus.
Der Plan ist über einen Messagebus oder Polling der Gateways diese Informationen bereitzustellen aka es kommt ein Key rein an dem auch dran steht welches Gateway gewählt wurde. Das wird auf den Bus geschrieben und das Gateway führt die notwendigen Aktionen durch. Und alle 1-2std wurden stale Keys von den Gateways mit „Last Handshake“ > 1h gepurged.
Somit sparen wir es uns States abzugleichen, jedes Gateway entscheidet bei neuem PublicKey selbst welche Aktionen notwendig sind (keine weil Key schon da oder anlegen).
D. h. auf dem Knoten wird geguckt, ob eine Verbindung besteht (ping?) und wenn nicht wird zufällig ein Eintrag aus dem Wireguard-Block genommen? (Mir geht’s um den Ziel-GW-down-Fall.)
Das klingt eher so, als ob die GW-Auswahl vor/bei Key-Upload stattfände? (Wir können das, falls hier unpassend, auch gerne auf PN/Mail verlagern.)
Das wäre quasi egal, entweder wir schicken dem Knoten welches GW er nehmen soll. Oder er schickt uns eins dass er random selektiert hat. Das ist für den Vorgang hinten raus egal. Wir müssen ja immer den Pubkey bekommen bevor irgendwohin verbunden werden kann.
Im Moment ist es aber einfach ein Random würfeln durch das Node.
fastd guckte ja in einem Verzeichnis, ob er den Key kennt. Im Grunde könnte man den Pubkey zentral ‚registrieren‘ und dann an die GWs verteilen. Und die GWs bauen aus den bekannten Keys mit generate.sh die lokale wg.conf bzw. fügen die bekannten Peers hinzu. Ggf. kann man bei der Gelegenheit alte/hängende Verbindungen auch rauswerfen. Dann können alle GWs genutzt werden (und auf dem GW Verbindungen gekickt, falls Überlast oder anstehende Wartung oder …). Muß nachher mal zwei 3600v1 rauskramen zum Vergleich.
wow, ist das realistisch? Du schriebst weiter oben, dass ca. 750 VPN-Verbindungen eingehen müssen.
Geht das wirklich über eine Gigabit-Karte? Oder habt ihr 10 Gig Gateways? Abgesehen davon, dass jedem Knoten dann rechnerisch selbst bei 10 Gig maximal 13 Mbit/s zur Verfügung stünden, klappt das überhaupt?
Bei L2TP ist derzeit bei 350-400 Knoten Maximum. Danach wird’s hart unperformant und Pakete gehen über die Wupper, was zu einer unschönen Endnutzererfahrung führt.
Ist Wireguard so viel effizienter als der Linux-Netzwerk-Stack?
Genau das wollen wir nicht, wir wollen keinen Status bewahren wer da war oder nicht. Wir clearen nicht verbundene Clients und lassen jeden zu der mitspielen will wie jetzt auch :). Unser fastd key script ist true.
Geht schon wir hatten auch schon 900 fastd Knoten auf einem Gateway. Unsere Kisten sind ziemlich potent. Wir haben an den GWs 2x1G. Bandbreite ist meistens das letzte was trotz allem knapp wird. Meistens gibt irgendeine CPU vorher auf.
Im Ernst, warum der Aufriß, über einen L3-Tunnel einen L2-Tunnel zu legen und das dann an Batman anzuknoten? Wireguard ist ein L3-Tunnel, würde es dann nicht Sinn machen, auf den Knoten (v4 und) v6 per Babel zu routen? Die Franken haben das AFAICS doch schon recht gut im Griff mit Babel und public IPv6 in ihrem Netz — halt ohne Gluon. Mit Gluon ist’s IIRC Frankfurt, die sich von Batman, sprich der L2-Wolke, trennen wollen?
) Was ist der Hintergrund von wireguard-tools, wo muß das hin? Danke für’s nicht hauen