Lt. Meeting-Notes wird Tunneldigger als Transport in Gluon v2023.2 abgekündigt?
Zu den Punkten:
Als Tunneldigger-Community-Admin würde ich die Frage genau anders herum stellen, welchen Vorteil bringt mir der Wechsel von Tunneldigger (zurück) zu fastd, jetzt mit null@l2tp? Non-l2tp-Modes fressen enorme Mengen an CPU-Zeit auf Clients und Gateways, da möchte ich nie wieder hin, das ist also kein Argument. Beide Tunnel sind somit nicht verschlüsselt, 0:0.
Aber um die Frage zu beantworten, aus Adminsicht:
es funktioniert in der vorhandenen Infrastruktur seit Jahren „einfach“
die Verbindungen landen übersichtlich in 'ner Bridge statt wie bei fastd (zumindest vor null@l2tp) in einem singlethreaded Prozeß, aus dem man den Status mühsam rauspuhlen muß
kein Schlüsselaustausch notwendig
wer das VPN wechselte ist, hatte seine Gründe (ich persönlich möchte fastd definitiv nicht wiederhaben, ist so’n Unix- vs. systemd-Philosophie-Ding)
Definitiv nicht. Migrationsfirmware wird notwendig plus parallele Backend-Infrastruktur für den Wechsel. Plus, zuvor, Anpassung der Automatisierung — $hier zumindest wurde der fastd-Zweig des Deployments vermutlich ca. 5. Jahre nicht mehr durchlaufen.
Das bedeutet was konkret für »Tunneldigger-Communities«? Wieviele der 42k Nodes lt. Gluon-Census betrifft diese Entscheidung?
Die Diskussion auf dem Meetup erfolgte aus der Gluon Perspektive. Dort gibt es aktuell zwei VPN Protokolle welche letztlich das gleiche können, aber halt nicht identisch gute Optionen sind.
Denn das eine erfordert halt einen Watchdog um es am Leben zu halten, hat keinen IPv6 Support und wird nicht regelmäßig getestet.
Gut sichtbar wurden die Probleme mit dem Release von v2023.1. Wie sich nun herausgestellt hat war Tunneldigger damit im Prinzip komplett kaputt. Die konkreten Probleme wurden zwar mit dem gestern veröffentlichten v2023.1.1 behoben, aber die grundsätzlichen Probleme verändert das natürlich nicht.
Der aktuelle Stand ist das fastd so konfiguriert werden kann das es sich sehr ähnlich wie Tunneldigger verhält:
Die Verbindungsthematik kann man auf verschiedene Arten angehen. Entweder zum Beispiel über hook skripte welche von fastd aufgerufen werden und die Interfaces in eine bridge packen, oder aber auch z.B. über systemd-networkd und Interfaces welche einem Pattern matchen.
Beispiele zu beidem finden sich hier: fastd L2TP Offloading on Supernodes · freifunk-gluon/gluon Wiki · GitHub
fastd kann so konfiguriert werden das es einfach alle Verbindungen annimmt. Es gibt einen on verify Parameter in der Config. Hier kann auch einfach immer true zurück gegeben werden. Dann wird einfach jede Verbindung angenommen.
Es geht ja explizit um fastd mit der null@l2tp Methode. Nicht um andere Methoden von fastd.
Die Migrationsfirmware sehe ich nicht. Der Wechsel muss ja nicht zeitgleich erfolgen. Ein Wechsel des VPNs kann einfach über ein reguläres Update erfolgen und die neue Firmware baut die VPN Verbindung dann halt per fastd statt tunneldigger auf.
Aber ja, im Backend muss fastd natürlich installiert werden. Das ist aber halt auch nur einmaliger Aufwand und anschließend gibt es dafür ja auch klare Vorteile.
Es bedeutet das der aktuelle Plan ist den Communities mit Tunneldigger zu empfehlen fastd mit null@l2tp als die bessere Alternative zu tunneldigger zu evaluieren. Im darauf folgenden Major Release soll Tunneldigger dann nicht mehr im Core Gluon enthalten sein.
Es besteht natürlich die Option tunneldigger fortan als community-package zu unterhalten wenn Communities dies tun möchten.
Mir persönlich erscheint der einamlige Aufwand zu wechseln aber nicht den Aufwand wert weiterhin tunneldigger zu pflegen.
Communities mit Tunneldigger im Einsatz sind aktuell mindestens: Eulenfunk: 902, Gütersloh: 560, Münsterland: 3900, Saarland: 741, Südwest: 1005
So ganz genau lässt sich das aber nicht sagen da die Info zum verwendeten VPN Protokoll oft nicht in den Exports enthalten ist.
@wusel vielleicht geht es bisher nicht so hervor, es ist eben ein Thema was keiner pflegt. und wir werfen sowas lieber raus, als wie mit 2023.1 plötzlich ein release zu haben, in dem soetwas defekt ist, weil sich niemand darum schert unter den aktiveren Entwicklern.
Lieber ein geplantes Ende als immer wieder unerwartete Probleme um die sich keiner kümmert…
… und als community-Package bleibt es ja möglich, auch da muss sich aber jemand darum kümmern.
There’s a catch: ich für meinen Teil habe genug anderes auf der ToD-Liste, als daß ich der Gluon-Entwicklung folgen könnte, zumal ohne auch der OpenWrt-Entwicklung zu folgen. Themen auf dem IRC-Channel sind zu 70+% böhmische Dörfer für mich.
Das »Tunneldigger-Problem« war, AFAICS, die Einführung/Umstellung auf procd? DAS müßte dann in den Developer Notes zur jeweiligen Gluon-Release stehen, damit daß »off-tree« gepflegt werden könnte — das wäre vermessen zu verlangen (und selbst in kommerziellen Projekten für mich kaum vorstellbar, daß da jede popelige Änderung am Gesamtsystem dokumentiert ist — read the fscking commits, Dude!).
Was heißt denn »es ist eben ein Thema was keiner pflegt«? Kein Gluon-Entwickler sitzt in (mehr?) einer Community, die Tunneldigger einsetzt?
es gab (korrigiert mich gerne) noch nie einen Gluon-Maintainer der Tunneldigger genutzt hat. Es war also immer nur Arbeit für andere…
Hinzugefügt wurde es 2017 von einem github user namens lcb01a der sich danach nie mehr darum gekümmert hat.
Tja, dann wird ›man‹ (@collimas (FFLIP), @corny456 (FFMS) ansehend; wer für FFNW (fehlt in obiger Liste) hier mitliest weiß ich nicht, dito für Saarland und Südwest – @adorfer würde ich beim Eulenfunk sehen?) sich entscheiden müssen, wie ›man‹ weitermacht.
Wir haben mit Tunneldigger angefangen, als dieser noch nicht vom Gluon Core supported wurde.
In Lippe sind es ca. 1200 Nodes, die wir umstellen müssten, das würde ich gerne vermeiden, wenn das möglich ist. Ich möchte fastd auch nicht wiederhaben.
Ich könnte gut damit leben, den Tunneldigger wieder als externes Paket einzubinden.
Aber die Scherzantwort greift zu kurz: Wie ausgeführt – und leider ignoriert –, denke ich nicht, daß man Kernkomponenten wie einen VPN-Dienst sinnvoll out-of-tree und losgelöst vom Gluon-Kern-Team pflegen kann. Hätten wir das heute schon, wären die – von OpenWrt oder Gluon forcierten – Änderungen ja schon jetzt »der Community« auf die Füße gefallen, oder?
Es gab’ ja schein’s mindestens zwei Probleme, #2998 und #2977? Mindestens an #2998 hätte ich, ohne jedwede OpenWrt-Affinität, vermutlich Wochen gesucht. Das macht man eimal und dann ist man ›mal weg‹ …
BTW, FFIN (Paging @citronalco) ist AFAICS auch eine, zumindest in Teilen, »L2TP-Community«:
fastd
Fastd ist klein, unkompliziert und zuverlässig und hat sich deswegen in den Anfangsjahren von Freifunk schnell als Standardlösung etabliert. Mit fastd aufgebaute VPN-Tunnel sind außerdem zusätzlich verschlüsselt.
Leider läuft fastd im Userspace und ist deswegen, anders als der Name suggeriert, ziemlich langsam. Günstige Access Points erreichen damit nur einen VPN-Durchsatz von etwa 10MBit/s.
L2TP
Seit einigen Jahren existiert als Alternative L2TP: L2TP läuft direkt im Linux-Kernel und erreicht so auf identischer Hardware einen etwa 4x so hohen VPN-Durchsatz wie fastd. Freifunk Ingolstadt bietet seit Juni 2020 L2TP an.
VPN-Tunnel mit L2TP sind im Gegensatz zu fastd-VPN-Tunneln nicht verschlüsselt, d.h. der Internetanbieter hat theoretisch die (illegale) Möglichkeit herauszufinden, welche Daten über den VPN-Tunnel zwischen Access Point und unseren Gateway-Servern übertragen werden. Obwohl der Internetverkehr heutzutage größtenteils ohnehin SSL/TLS-verschlüsselt ist und eine zusätzliche Verschlüsselung des VPN-Tunnels an der rechtlichen Stellung des Freifunk-Access Point-Aufstellers nichts ändert, haben wir deswegen beschlossen, zusätzlich zu L2TP auch weiterhin fastd anzubieten.
Wireguard
An der Unterstützung für Wireguard-VPN-Tunnel wird gearbeitet. Wireguard ist etwa doppelt so schnell wie fastd und halb so schnell wie L2TP. Mittelfristig wollen wir fastd durch Wireguard ersetzen.
(Zu Wireguard: Kudos to FFMUC, das umzusetzen. Aber Batman in VXLAN in Wireguard ist meines Erachtens 'n halber Kontinent neben KISS. Das mag daran liegen, daß ich den Sinn nicht sehe, IP-Pakete, die aus einem offenen, unverschlüsselten, WLAN kommen (das hat sich mit OWE geändert, ja, und das ist da auch gut, ändert aber nichts bzgl. Weitertransport) und die gen Transit und ab dort generell unverschlüsselt transportiert werden, auf meiner letzten Meile exorbitant teuer zu verschlüsseln.)
Für den Fall, daß nicht nur ich diese »klaren Vorteile« nicht wertzuschätzen weiß: welche konkret?
Naja. Hast Du Ports kommuniziert, kannst Du die GWs nicht auf den gleichen Servern laufen lassen — 10000-10999 sind von Deinen L2TP-GWs belegt, also braucht’s eine Dopplung der GW-VMs. Juckte mich jetzt nicht, aber woanders täte das ggf. weh. Ich denke, es hängt schon von den lokalen Umständen ab, ob so ein VPN-Wechsel »trivial« oder »schmerzhaft« würde.
Ich vermisse als Anwender (wiedereinmal) eine Empathie der Entwickler bezüglich ihrer Nutzer.
Granted. Nach aktuellem Stand sind rd. 11k (add: FFLIP 1200, FFNW 2230) von rd. 42k Nodes betroffen, also grob ein Viertel. Oder stimmt diese Gluon-Census-Rechnung nicht?
Einem Viertel ›seiner‹ Knoten den Stinkefinger zu zeigen, klar, kann man machen, aber ist es auch zielführend?
Nochmal vorab: es geht nicht um „morgen fliegt was raus aus Gluon“ sondern um die Ankündigung, das heißt es wird mind. noch ein Gluon-Release damit geben!
Heißt, es geht darum, in ~1 Jahr mit der Umstellung anzufangen oder das community-Repository zu nutzen.
wir haben schon befürchtet, dass alte Animositäten hier vor sachlichen Argumenten stehen könnten.
Bitte packt alte Informationen in den Müll und schaut euch die aktuellen Fakten an.
Gleich Zwei aus heutiger Sicht falsche Informationen die du hier einbindest.
mit der null@l2tp methode ist die Geschwindigkeit nicht mehr durch den userspace limitiert
so billige Geräte die selbst mit userspace im fastd nur 10mbit/s schaffen gibt es doch gar nicht mehr?
die Umstellung von Tunneldigger auf Wireguard dürfte deutlich aufwändiger sein als auf fastd mit l2tp
wenn auch nicht hier (wegen des weiten Vorlaufs) vermisse ich die auch manchmal, aber kann man halt nicht ändern im Ehrenamt und sich nur freuen wenn man es schafft nichts plötzlich zu machen (wo ich dann auch mich ärgere) sondern mit weitem Vorlauf wie hier.
Also wer so kommt, dem kann man auch entgegnen: Ein Viertel der Knoten bzw. der zugehörigen Communities beteiligt sich nicht an der Weiterentwicklung von Gluon und schnorrt einfach nur?
Aber vielleicht ist das in beiden Richtungen nicht zielführend
Habe angefangen, eine kleine Übersicht zu den Features der verschiedenen in Gluon supporteten VPN Provider zu erstellen, um eine objektivere Beurteilung zumindest von der Feature-Seite aus zu ermöglichen und vereinfachen (was dann vll. später ins Gluon readthedocs könnte?):
Wenn noch wem was an Vor- und Nachteilen einfallen sollte, gerne Bescheid sagen oder ergänzen. Auch soweit keine Garantie auf Richtigkeit, also auch bei Fehlern gerne Bescheid sagen bzw. selber korrigieren :-).
Es fehlt mir eine Betrachtug der ›Performance‹ der jeweiligen VPN-Methoden, was sicherlich ein Entscheidungsfaktor ist. Und ob wer, von fastd dereinst geschwind verputzt, heute zu fastd zurückkehren will?
Andererseits ist »Gluon« an sich ›feature complete‹, insofern steht nur die jeweilige Anpassung an den OpenWrt-Unterbau an.
Allein, für 4/32-Geräte ist dann »Tunneldämmerung« — außer, die Community beschließt für das Gros ihrer Knoten eine »Legacy«-Infrastruktur (mit Tunneldigger) weiterzubetreiben.
Hatte ein paar Faktoren zur Geschwindigkeit in der Tabelle mit „… → faster“ in den Spaltennamen angemerkt.
„fastd, null@l2tp, offloaded“ und „Tunneldigger (L2TP)“ sollten an sich gleich schnell sein. Denn beide leiten den Traffic nicht selber weiter, sondern richten den Linux Kernel nur entsprechend ein, dass dieser das selber übernimmt über das standardisierte „Layer 2 Tunneling Protocol“.
Ob Wireguard oder „fastd, null@l2tp, offloaded“ / „Tunneldigger (L2TP)“ mehr Durchsatz bringt, habe ich nicht getestet, hätte aber auf L2TP getippt, weil diese nichts verschlüsseln und weniger VPN header overhead haben.
Theoretisch, wenn der Flaschenhals nicht die Router-CPU ist sondern die Bandbreite des Internetuplinks selber (extremes Beispiel x86 Gluon auf einem flotten PC, aber an einer 1.5MBit/s Internetleitung), könnte auch alles schneller sein als Wireguard+VXLAN, weil es dann nur noch auf den VPN header overhead ankäme.
Im Grunde müßte mal wer ein Pseudo-GW aufsetzen, eine 4040 als Knoten per GBit-LAN daran hängen, daran einen PC und von dort mit iperf3 den Durchsatz zum, optimalerweise „nur“ durch das, GW testen; jeweils für „fastd, null@l2tp“, „Tunneldigger“ und „Wireguard+VXLAN“.
diese Geräte sind schon seit Gluon v2022.1 nicht mehr unterstützt, weil OpenWrt ab 22.03 und der zugehörige Kernel zu viel Platz brauchen.
Da ändert sich also nichts, deren Dämmerung hat schon vor Jahren begonnen
siehe Release Notes unter „Removed devices“: Gluon 2022.1 — Gluon 2023.2.2 documentation
Das folgende hilft natürlich höchstens für die Zukunft, aber in Darmstadt sind kommunizierte Port Ranges extra so groß gewählt das es genügend freie Ports gibt um multiple Migrationen zu machen.
dom0 verwendet aktuell 10000, dom1 10010, dom2 10020 usw. und auch nach hinten hin sind auch noch ein paar Ports ungenutzt und es könnten noch Domains nach dem gleichen Schema hinzugefügt werden bevor es an die Zwischenräume gehen müsste.
Es kann ja immer mal sein das man das VPN Protokoll, die MTU oder irgendwas anderes wechseln möchte oder muss und dann kann das auf den gleichen Gateways mit den gleichen IPs parallel als anderer Service laufen.
