WireGuard@Informatik

Universitäten betreiben VPN-Infrastruktur, um Studierenden und ihren Mitarbeitenden einen sicheren Zugriff auf interne Netze, Forschungsdaten und Verwaltungsdienste zu ermöglichen. Die meisten VPN-Lösungen bringen eigene, spezialisierte Clients mit, die unteranderem auch Authentifizierungsverfahren implementieren.

WireGuard und das traditionelle IPsec

WireGuard zeichnet sich durch eine moderne und schlanke Architektur aus, die direkt in den Linux-Kernel integriert ist. Im Gegensatz zu älteren Protokollen gilt es als kryptografisch besonders sicher und beschränkt sich auf den reinen Austausch von IP-Paketen über das verbindungslose UDP-Protokoll. Die Sicherheit und Identifikation der Teilnehmer basiert dabei fundamental auf dem Austausch von öffentlichen Schlüsseln (Public Keys). WireGuard ist seit Version 5.6 Teil des Linux-Kernels und für andere Plattformen existieren Userspace-Implementierungen. Die Kernelintegration reduziert jedoch die Kontextwechsel zwischen User- und Kernel-Space, was eine effiziente Paketverarbeitung ermöglicht. Dies kann besonders bei datenintensiven Anwendungsfällen wie Remote-Desktop nützlich sein.

Zum besseren Verständnis der Vorteile von WireGuard lohnt sich ein Blick auf die klassische und weitverbreitete IPsec-Architektur. IPsec ist wesentlich komplexer aufgebaut und erfordert eine vertrauenswürdige Quelle. Die Datenübertragung wird hierbei durch Protokolle wie den Authentication Header (AH) oder die Encapsulating Security Payload (ESP) gesichert, während ein IP-Header vorangestellt wird. Der Verbindungsaufbau bei IPsec ist zweigeteilt: Zunächst erfolgt über den Internet Key Exchange (IKE) eine Verhandlungsphase, in der mittels Diffie-Hellman-Schlüsselaustausch die Authentifizierung der Gegenstellen geklärt wird. Erst danach wird der eigentliche IPsec-Tunnel über den sogenannten Quick Mode und die Etablierung einer IPsec Security Association aufgebaut, bevor die verschlüsselten Datenpakete abgeschickt werden können. Im Gegensatz verzichtet WireGuard auf Verhandlungsvielfalt und konzentriert sich auf feste kryptografische Primitive, was Konfiguration, Betrieb und Fehlersuche deutlich einfacher gestaltet und dementsprechend auch schlanker daherkommt.

Netzwerkarchitekturen: Hub-and-Spoke vs. Mesh

VPN-Infrastrukturen lassen sich grundsätzlich in verschiedene topologische Modelle unterteilen, die jeweils eigene Herausforderungen an das Routing und die Verwaltung stellen.

Veranschaulichung einer Hub-and-Spoke Architekur. Alle Nodes zu einem Hub.

Das traditionelle Modell ist die Hub-and-Spoke-Architektur. Hierbei fungiert ein zentrales Traditional VPN Gateway als Knotenpunkt (Hub), mit dem sich alle Clients und Server (die Spokes) verbinden, um beispielsweise auf ein gemeinsames Subnetz zuzugreifen. Dies bedeutet, dass der gesamte Datenverkehr über diesen zentralen Punkt geleitet werden muss.

Veranschaulichung eines Mesh-Netzwerk. Alle Nodes sind untereinander verbunden.

Ein modernerer Ansatz, der auch von fortgeschrittenen WireGuard-Setups genutzt wird, ist das Mesh-Netzwerk. In einer Mesh-Architektur stellen die einzelnen Knotenpunkte (Nodes) direkte Verbindungen untereinander her, was Engpässe vermeidet. Allerdings steigt der Verwaltungsaufwand enorm an, da jeder Knoten die Schlüssel der anderen kennen muss.Die Anzahl der benötigten WireGuard-Endpunkte wächst quadratisch. Bei 45 Knoten im Netzwerk werden somit bereits 90 Verbindungs-Endpunkte benötigt. Um dies handhabbar zu machen, benötigt es eine Koordinationsebene dies ist in der Regel ein zentraler Coordination Server. Dieser verwaltet öffentliche Schlüssel, Endpunktadressen und Routing-Informationen. Gerade bei dynamischen Nutzergruppen mit häufig wechselnden Endgeräten ist dies entscheidend.

Authentifizierung und Konfiguration

Veranschaulichung des Ablaufs von WireGuard

Das Kernkonzept der Authentifizierung bei WireGuard besteht letztendlich immer darin, die öffentlichen Schlüssel der zugelassenen Teilnehmer zu akzeptieren. Denn WireGuard selber kennt keine Benutzer Authentifizierung. Die kryptografische Identität eines Peers ist ausschließlich an dessen öffentlichen Schlüssel gebunden. Um dies im Universitätzumfeld einzusetzen, können bewährte Authentifizierungsverfahren wie LDAP, RADIUS oder OpenID im Provisionierungsprozess vorgeschaltet werden anstelle dies direkt im Protokoll zu tun. Klassisch wäre nach erfolgreicher Authentifizierung, dass ein neuer Schlüssel mit zugehöriger WieGuard-Konfiguration erzeugt oder aktualisiert wird.

Statische Einrichtung

Die statische Einrichtung eines WireGuard-Tunnels erfordert Konfigurationsdateien auf beiden Seiten, denn WireGuard selber bringt keine native dynamische Adressvergabe mit sich. Diese Entscheidung zwingt Betreiber dazu, Dynamik explizit über zusätzliche Komponenten abzubilden. Für die generelle Einrichtung wird auf Serverseite ein Interface mit bestimmten IP-Adressen (z. B. 10.192.122.1/24) definiert, an einem bestimmten Port (wie 51820) gelauscht und der private Schlüssel hinterlegt. Jedem erlaubten Peer wird sein öffentlicher Schlüssel sowie die für ihn zulässigen IP-Adressen (AllowedIPs) zugewiesen.

[Interface]

Address = 10.192.122.1/24

Address = 18.10.0.1/16

SaveConfig = true

PrivateKey = yAnz5TF+1XXJte14tji3z1MNq+hd2rYUIgJBgB3fBmk=

ListenPort = 51820

[Peer]

PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=

AllowedIPs = 10.192.122.3/32, 10.192.124.1/24

Der Client konfiguriert analog sein Interface mit einer eigenen IP und dem Verweis auf den DNS-Server sowie seinem privaten Schlüssel. Beim Peer-Eintrag des Servers wird dessen öffentlicher Schlüssel, der Endpoint (z. B. vpn.hu-berlin.de:51820) und optional ein Preshared Key angegeben. Durch das Setzen der AllowedIPs auf 0.0.0.0/0 kann der gesamte Traffic über den Tunnel geroutet werden.

[Interface]

Address = 10.200.100.8/24

DNS = 10.200.100.1

PrivateKey = oK56DE9Ue9zK76rAc8pB16opph+1v361m7cXXsQKrQM=

[Peer]

PublicKey = GtL7fZc/bLnqZldpVofMCD6hDjrK28SsdLxevJ+qtKU=

PresharedKey = /UwcSPg38hW/D9Y3tcS1FOV0K1wuURMbS0sesJEP5ak=

AllowedIPs = 0.0.0.0/0

Endpoint = vpn.hu-berlin.de:51820

Cryptokey Routing und Sicherheit

Ein zentrales Sicherheitsmerkmal von WireGuard ist das sogenannte Cryptokey Routing.

Wenn ein Paket an eine bestimmte IP-Adresse gesendet werden soll, prüft WireGuard, ob diese Adresse den AllowedIPs eines bekannten Peers mit dem entsprechenden kryptografischen Schlüssel zugeordnet ist. Stimmen kryptografische Identität und IP-Zuweisung nicht überein, wird das Paket konsequent verworfen (Drop).

Der WireGuard-Handshake basiert auf dem Noise-Protocol-Framework und ist als effizienter 1-RRT-Handshake ausgelegt. Die Verschlüsselung bietet zudem Perfect Forward Secrecy (PFS) durch den Einsatz von Curve25519-Schlüsseln für den Diffie-Hellman-Schlüsseltausch. Zusätzlich werden Ephemeral Keys (flüchtige Schlüssel) und Shared Secrets generiert. Der Handshake-Prozess nutzt eine Key Derivation Function (HKDF) zur Ableitung der Schlüssel, kann durch einen symmetrischen Preshared Key verstärkt werden und wird alle zwei Minuten automatisch erneuert.

Während WireGuard als äußerst resistent gegen Denial-of-Service-Angriffe (DOS) gilt und sich für Post-Quantum-Cryptography (PQC) mit den optionalen Pre-Shared Keys rüstet, bestehen bei fehlerhafter Implementierung Restrisiken. Ein Risiko stellt die reine Authentifizierung über den privaten Schlüssel dar, oder wenn auf ältere, unsicherere Verfahren ohne Ephemeral Keys ("Altes Sicher") zurückgegriffen wird. Diese PQC Implementierung erlaubt den schrittweisen umstieg ohne bestehende Infrastruktur vollständig zu ersetzen.

Dynamisierung und Automatisierung

Von Haus aus bietet WireGuard eine gewisse Dynamik durch das Full-Roaming. Sobald der initiale Handshake erfolgt ist, kann ein Client problemlos seine IP-Adresse oder das Netzwerk wechseln (z. B. vom WLAN ins Mobilfunknetz), ohne dass die Verbindung abbricht. WireGuard unterstützt auch Wildcard Clients, ist aber lokal an einen begrenzten, statischen Adressraum gebunden.

Um echte Dynamik zu erreichen, müssen Overlay-Konzepte angewendet werden. Möglichkeiten hierfür sind In-band-Management, Routing auf Layer 3 oder die Nutzung von IPv6 link-local Adressen.Geleaste IPs können hierbei dynamisch zu den Adressen hinzugefügt werden. In solchen Overlay-Netzen übernimmt oft ein IP Manager oder der Client selbst die dynamische Erzeugung der`.conf`-Dateien und wendet diese über Befehle wie`wg set`an.

Tailscale / Headscale und NAT Traversal

Lösungen wie Tailscale (SaaS) oder die weitgehend quelloffene Alternative Headscale bauen auf WireGuard auf, um dessen statische Limitationen zu überwinden. Headscale kann dementsprechend auch selbst gehostet werden. Sie etablieren vollautomatisiert Mesh-Netzwerke, die beispielsweise bis zu 1000 statische oder 80 dynamische Endpunkte verwalten können. Die Basis-Registrierung erfolgt oft unkompliziert via OpenID.

Veranschaulichung von STUN-Servern.

Ein entscheidender Vorteil solcher Lösungen ist das NAT Traversal. Stateful Firewalls lassen oft nur ausgehenden, aber keinen eingehenden Verkehr zu. Durch einen Coordination Server, Techniken wie das Senden von Paketen ohne direkte Antwort an NAT-Devices und den Einsatz von STUN-Servern können direkte Peer-to-Peer-Verbindungen auch durch komplexe Netzwerkstrukturen hindurch aufgebaut werden.

Neben der Mesh-Struktur ist es in Headscale auch möglich die Konfiguration so anzupassen, dass eine Hub-and-Spoke Architektur umgesetzt werden kann, wodurch alle Peers Beispielsweise direkt mit einem (oder mehreren) Universitätsrechnern verbunden werden können.

Fazit

WireGuard eignet sich aufgrund seiner Einfachheit, geringen CPU last, und klaren Sicherheitsarchitektur hervorragend als Baustein für den universitären Betrieb. Allerdings ist es erforderlich aufgrund seiner bewussten Einschränkungen ergänzende Systeme für Authentifizierung, Adressverwaltung und Betrieb zu nutzen, welche in eigenen Clients prima gebündelt werden kann.