WireGuard-Firmware oder Freifunk München wird endlich schnell! - #USEMOREBANDWIDTH

Überblick

Am 19.11.2020 war es dann soweit: Wir haben unser komplettes Netzwerk von fastd-VPN auf WireGuard-VPN umgestellt. Was einfach klingt, war überhaupt nicht einfach. Viele Softwarekomponenten auf unseren Servern und auf den Teilnehmer-Routern mussten neu eingebunden und angepasst werden. Vor allem mussten viele, viele Tests durchgeführt werden, um dieses Projekt zu verwirklichen.

Alles begann mit der Idee, Freifunk München für die Benutzer endlich schneller zu machen und das volle Potential der Teilnehmer-Router und Gateways im Backend abzurufen. Zudem stand ein größerer Umbau der Server-Infrastruktur an und so ergab es sich, dass sich unser Team sowieso mit dem gesamten FFMUC-Ökosystem auseinandersetzen musste.

Es war uns klar, dass es mit der vorhandenen VPN-Technik nicht möglich wäre, mehr Leistung herauszuholen. Deswegen suchten wir Alternativen zum bestehenden fastd-Ansatz und wurden bei WireGuard fündig. Aber vorher gab ein großes Problem zu lösen: WireGuard transportiert nur Layer-3-Verbindungen und keine Layer-2-Verbindungen, die wir aber für das von uns eingesetzte Meshprotokoll, B.A.T.M.A.N.-Advanced batman-adv, benötigen.

Aber wir haben ja findige Techniker und die haben eine Lösung gefunden! Also transportieren wir nun über WireGuard ein Virtual eXtensible LAN (VXLAN, siehe RFC 7348) und in diesem VXLAN läuft dann batman-adv. Klingt ein bisschen nach Matroschka-Puppe? Stimmt, genauso ist es auch. Doch trotz des dreifachen “Encapsulierens” sind wir bis zu fünf Mal schneller auf den aktuellen Teilnehmer-Routern und auf älteren Modellen holen wir immerhin bis zu Faktor 2,5 heraus! Und das ist für viele Teilnehmer der Unterschied von “gefühlt lahm” zu “gefühlt flott”.

Technik

WireGuard

WireGuard verwendet eine Public/Private-Key-Architektur, dass heißt, es ist notwendig, dass wir vorher den Public-Key eines Knotens (Teilnehmer-Routers) wissen müssen und bei den Backend-Gateways entsprechend anmelden müssen. Hierzu haben wir, wie weiter unten ausgeführt wird, eine eigene Softwarekomponente geschrieben, den WireGuard Key Exchange wgkex. Diese Komponente sorgt dafür, dass die Knoten ihren Public-Key den Gateways mitteilen und die Gateways ihn in den entsprechenden WireGuard-Strukturen ablegen. Auch wird aus diesem Public-Key die interne IPv6-Adresse der Knoten berechnet und für WireGuard freigegeben, die wir wiederum wir für die VXLAN-Kommunikation benötigen.

VXLAN

Wir verwenden VXLAN um die Limitierung von WireGuard zu umgehen, nur “geroutete” Pakete auf Layer 3 zu übertragen. Mit VXLAN ist es uns nun möglich, via Layer 3 wieder Layer-2-Pakete, in unserem Fall B.A.T.M.A.N.-Pakete, zu übertragen. Dazu richten wir zwischen den Gateways und den Knoten eine 1:1-IPv6-Verbindung ein. Auch hier werden die IPv6-Adressen des Gateways und des Knoten wieder aus den jeweiligen Public-Keys errechnet. So stellen wir sicher, dass alle generierten IPv6-Adressen im System einmalig sind.

Softwareprojekte

Klingt das Ganze für euch nach Pionierarbeit? Richtig, das war es auch! Deswegen haben wir auch einige neue Softwareprojekte ins Leben gerufen. Diese wollen wir hier zum Schluss kurz vorstellen.

Wireguard Key Exchange

Wie oben erwähnt, brauchten wir einen Broker zum Entgegennehmen der WireGuard-Public-Keys. Diesen haben wir zusammen mit Freifunk Regensburg und Freifunk Darmstadt Wireguard Key Exchange wgkex getauft und den Code auf GitHub veröffentlicht. wgkex besteht aus zwei Komponenten: Dem broker, der die Public-Keys per Webrequest annimmt und einem worker, der dann die Gateways so umkonfiguriert, dass die Public-Keys im System bekannt sind und alle Routen korrekt gesetzt werden.

Gluon-Firmwarekomponente

Natürlich benötigten wir auch einen Teil in der Firmware der Teilnehmer-Knoten, der statt einem fastd- oder L2TP-VPN eine WireGuard/VXLAN-Verbindung aufbaut. Dieses Projekt haben wir gluon-mesh-vpn-wireguard-vxlan genannt und ihr findet es natürlich auch auf GitHub.

systemd-networkd

Damit auf den Gateways alles rund läuft, haben wir uns zu guter Letzt noch eine systemd-Erweitung ausgedacht. Diese Komponente ist natürlich keine Vorraussetzung für das Setup. Sie macht uns und anderen systemd-Nutzern das Leben aber deutlich einfacher, da systemd nun auch B.A.T.M.A.N.-Interfaces unterstützt! Den entsprechenden Pull-Request findet ihr im systemd-Projekt, wieder öffentlich auf GitHub.

Fehlersuche

Direkt nach der Umstellung fiel auf, dass wir zwar deutlich schnellere Einzelverbindungen haben, die Gateways aber unter deutlich höherer Last litten, als zuvor. Auch mehr, als durch die Zunahme des Traffics zu erklären gewesen wäre. Also ging es los mit der Fehlersuche. Dabei wurden Flamegraphen angefertigt, Linux-Kernelcode studiert sowie der batman-adv-Code näher unter die Lupe genommen.

Es wurde relativ schnell klar, dass innerhalb des Kernels die Netzwerkpakete zu oft umkopiert werden mussten, was zu großen Performanceverlusten im Netzwerkstack führte. Nach mehreren Tagen intersiver Suche durch das FFMUC-Server-Team und auch dank der Unterstützung der B.A.T.M.A.N.-Advanced-Entwickler konnte das Problem eingegrenzt und schließlich behoben werden.

Aktuell (12/2020) laufen unsere Gateways deswegen auf einem Linux-Kernel mit Custom-Patches, sozusagen an der “bleeding edge”, aber wir hoffen, dass bald auch die Allgemeinheit von unserer Arbeit profitieren kann.

B.A.T.M.A.N.-Advanced-Patches

batman-adv: Reserve needed_*room for fragments
batman-adv: Don’t always reallocate the fragmentation skb head
batman-adv: Consider fragmentation for needed_headroom

Linux-Kernel-Patch im VXLAN-Code

vxlan: Add needed_headroom for lower device

Fazit

Heute, fast einen Monat nach Inbetriebnahme des neuen Systems, können wir zufrieden auf das Projekt zurückblicken. Es hat uns zwar unzählige Stunden Arbeit gekostet, war aber für alle Beteiligten immer spannend und lehrreich. Mit den Performance-Gewinnen sind wir auch sehr zufrieden und für die Freifunk- und systemd-Community ist auch etwas herausgekommen.

Für die Freifunk-München-Benutzer, die vom Umbau hoffentlich garnichts mitbekommen haben, hat es ein insgesamt besseres Freifunk-Erlebnis mit einer höheren nutzbaren Freifunk-Bandbreite gebracht.

Und vielleicht zeigt es für andere Freifunk-Communities einen Weg auf, Engpässe im eigenen Netz zu beheben und unbekannte Leistungsreserven auszuschöpfen.