Moin,
wer die Firmware-Entwicklung nicht eng verfolgt: die Gluon-Entwickler nutzen Tunneldigger – unsere VPN-Variante – selbst nicht und haben das Paket entsprechend aus dem Gluon-Framework geworfen. Relevant wird dies für Gluon-Versionen nach v2023.2, was derzeit – 1Q2024 – die aktuelle Version ist.
Die »Lösung« sehen die Gluon-Entwickler in fastd mit der »null@l2tp«-Verschlüsselung (die keine Verschlüsselung ist sondern ein Hack, L2TP-Frames mit fastd nutzen zu können; fastd ist ja, wie OpenVPN, als Userspace-VPN chronisch langsam auf schwachen CPUs, wie sie in WLAN-APs vorkommen).
Alternativ wurde die Tunneldigger-Komponente ins »Community-Repository« gelegt, sodaß »Tunneldigger-Communities« diese VPN-Technik weiterhin nutzen können — allerdings ohne Unterstützung und Rücksichtnahme durch die Gluon-Entwickler: sollten sich Gluon-Interna ändern, die Änderung auf am Tunneldigger-Package notwendig machen sollten, wird das entsprechenden Nutzern erst beim Bau ihrer Gluon-basierten Community-Firmware auffallen … (Das ist ein bißchen anders als bislang, wo die Firmware zumindest baute, aber ggf. im Tunneldigger-System es zu Problemem kam — Tunneldigger wurde eben nirgends bei Gluon-Entwicklern eingesetzt, anders als fastd, was ja von einem OpenWrt- und Gluon-Entwickler stammt.)
Einschub: VPN-Optionen in Gluon v2023.x
In Gluon v2023 gibt es grundsätzlich 3 Varianten, wie die Knoten mit den Gateways kommunizieren:
-
fastd: Usermode-VPN mit speziellen Crypto-Libraries, um damals auf 841er-Klasse-Systemen ein Layer-2-VPN-Interface (›tap‹) mit Verschlüsselung und Authentisierung bereitstellen zu können (OpenVPN mit den OpenSSL-Abhängigkeiten war zu groß).
In der Version in Gluon v2023 wird der sogenannte »null@l2tp«-Modus unterstützt, der den Paketversand aus demfastd-Prozeß löst und an das Kernelmodul für L2TP übergibt, womit ähnliche Datenraten und CPU-Belastungen wie bei Tunneldigger erwartet werden können. -
tunneldigger: das Stiefkind, das durch externe Patches nach Gluon kam und, weil es ca. Faktor 5 mehr Durchsatz auf den 841ern brachte (und auch auf schnelleren CPUs signifikant besser lief), schnell bei einigen Communities zum neuen Standard avancierte. Ja, die Performance wird erkauft durch eine fehlende Verschlüsselung im Tunnel: L2TP-Pakete werden ohne Verschlüsselung übertragen (auch beifastd).
Allerdings muß man sich die Technologie Stand 2018 ins Gedächtnis rufen: Freifunk-WLAN — unverschlüsselt. Datenverkehr ab Gateway via Internet — unverschlüsselt. Einzig den – in der Luft unverschlüsselten – Datenverkehr zwischen Knoten und Gateways – in den der transportierende ISP sowieso nicht reinsehen darf – aufwendig zu verschlüsseln. leuchtete nicht wirklich ein. Zumal TLS schon existierte, also alles, wo man Passwörter o. ä. übertragen hat, schon Ende-zu-Ende-verschlüsselt übertragen wurde.
Problem: anders alsfastdundwireguardkanntunneldiggerauch 2024 keine Tunnel per IPv6 aufbauen/verwalten und das wird sich vermutlich auch nicht mehr ändern. -
wireguard: Die Kollegen aus München wollten WireGuard als Tunnel nutzen und haben entsprechende Gluon-Pakete beigesteuert. Problem: WireGuard bietet einzig Layer-3-Tunnel — Gluon mitbatman-advancedbenötigt aber Layer-2-Verbindungen. Die Münchener Lösung: zwischen Knoten und Gateway wird ein L3-Tunnel aufgebaut, und über die beiden Endpunkte ein L2-Tunnel per VXLAN gespannt, der diebatman-Interfaces verbindet. Dank WireGuard-Unterbau ist dieser Tunnel in jedem Fall kryptographisch verschlüsselt.
Problem: effektiv werden 2 Tunneltechniken gestapelt, dies führte auch zu einer Bug-Meldung für den Linux-Kernel wegen massiven Performanceeinbruchs. Aber auch mit aktuellem Kernel bleibt WireGuard weit unter 10G-Linespeed. Zudem ist VXLAN, anders als L2TP, nicht in der Lage, durch Fragmentierung einen MTU-1500-Tunnel bereitzustellen.
Handlungoptionen:
-
VPN wechseln
Voraussetzung:
- neue
fastd-Gateways
Auswirkung:
- Knoten mit alter Firmware (4/32 & Co.) werden abgeklemmt
Variante:
- Rollout einer 1.4er (Gluon-v2021-Basis) Firmware mit
fastdstattTunneldigger— alte Knoten werden auf ca. 20% der VPN-Geschwindigkeit eingebremst, da ›null@l2tp‹ hier noch nicht verfügbar war und alles mehrfach durch die CPU läuft (auch auf den Gateways!), aber immerhin blieben sie online
- neue
-
VPN (Tunneldigger-L2TP) beibehalten und auf Community-Package setzen
Voraussetzung:
- keine
Auswirkung:
- keine im Betrieb — latent zunehmend Probleme mit der Einbindung der Tunneldigger-Lösung im Gluon-Framework, auch abhängig davon, wie viele Communities diesen Weg beschreiten wollen ab 2HJ2024, und die fehlende IPv6-Fähigkeit bleibt ein lungerndes Problem
Und ja, theoretisch könnte man auch fastd und tunneldigger auf den gleichen Gateways laufen lassen, oder auf getrennten. Beides bedeutet aber eine höhere Bürde für den Betrieb, der durch nichts gerechtfertigt erscheint und daher abzulehnen ist; ich stehe dafür nicht zur Verfügung.