2019 saß ich in einem Großraumbüro in Frankfurt und konfigurierte zum dritten Mal in sechs Monaten eine OpenVPN-Verbindung für denselben Kunden. Der Trick war TCP-Port 443, weil die Firewall des Kunden nur HTTPS durchließ. Die Konfigurationsdatei wanderte auf einen USB-Stick, den ich dem Admin in die Hand drückte. Sechs Monate später rief er an: Die Verbindung sei weg, und niemand wisse warum. Natürlich hatte der USB-Stick längst seinen Weg in eine Schreibtischschublade gefunden. Heute würde ich das anders lösen — und dieser Artikel zeigt, wie.
Die Frage, die mir am häufigsten gestellt wird, ist nicht „welches VPN ist sicher?" — das sind alle drei, wenn man sie richtig konfiguriert. Die Frage ist: „Was kostet mich das an Zeit, und was bremst mich aus?" Ich habe alle drei Ansätze im echten Betrieb: WireGuard auf einem Hetzner-VPS und auf dem Raspberry Pi im Wohnzimmer, OpenVPN nur noch als Altlast bei zwei Kunden, Tailscale auf zwölf Geräten quer durch Familie und Homelab. Die Messwerte in diesem Artikel kommen aus diesen Setups, nicht aus Datenblättern.
Warum überhaupt ein VPN? Die drei Jobs, die es wirklich gibt
Bevor wir über Werkzeuge reden: Ein VPN löst drei unterschiedliche Probleme, und die Wahl des Werkzeugs hängt davon ab, welches du lösen willst.
Job 1 — Roadwarrior: Du sitzt im Hotel, in der Bahn oder bei Kunden und willst auf deinen Server oder dein Homelab zugreifen. Ein einzelner Client, der sich zu einem festen Endpunkt verbindet. Das ist der Klassiker, den 80 Prozent aller Admins meinen, wenn sie „VPN" sagen.
Job 2 — Site-to-Site: Zwei feste Standorte sollen sich wie ein Netz verhalten. Büro A (192.168.10.0/24) und Büro B (192.168.20.0/24) reden über verschlüsselte Tunnel miteinander, ohne dass jemand auf der Strecke mitliest. Hier zählt vor allem Durchsatz und Stabilität — und kaum jemand verbindet sich von unterwegs ein.
Job 3 — Geräte-Mesh: Du hast zwölf Geräte — Laptops, Server, NAS, Raspberry Pis — und willst, dass jedes mit jedem reden kann, egal wo es gerade im Internet hängt. Das ist das Problem, das Tailscale am elegantesten löst, weil es die Verbindungen automatisch aushandelt.
Alles, was ich hier schreibe, bezieht sich auf diese drei Jobs. Wer ein VPN nur als „Tarnung fürs Surfen" nutzen will, ist in diesem Artikel falsch — dafür gibt es andere Lösungen, und ein selbst betriebener Tunnel ist dafür sowieso die falsche Wahl.
WireGuard: 4.000 Zeilen, die den Kernel erobert haben
WireGuard ist seit Kernel 5.6 (März 2020) Teil des Linux-Kernels. Das ist der wichtigste Satz in diesem Artikel, denn er erklärt fast alles, was WireGuard ausmacht: Es gibt keinen Userspace-Daemon, der Pakete kopiert, sondern ein Kernel-Modul, das die Krypto direkt im Netzwerkstack erledigt. Deshalb ist der Durchsatz so hoch und der Overhead so gering.
Das Protokoll basiert auf dem Noise-Protokoll-Framework und nutzt modernste Krypto: Curve25519 für den Schlüsselaustausch, ChaCha20-Poly1305 für die Verschlüsselung, BLAKE2s für den Hash. Der gesamte Code ist überschaubar — rund 4.000 Zeilen, die von Sicherheitsforschern immer wieder auditiert wurden. Ein klassisches OpenVPN-Setup bringt locker das Zehnfache an Code und Abhängigkeiten mit.
Die Grundidee heißt Cryptokey-Routing: Jedes Peer bekommt einen Public Key (Base64-codiert, 44 Zeichen) und eine Liste von erlaubten IP-Adressen (AllowedIPs). Was zu diesen IPs gehört, wird verschlüsselt durch den Tunnel geschickt — alles andere nicht. Das ist gleichzeitig Routing und Firewall in einem. Die Konfiguration ist so klein, dass sie komplett in eine wg0.conf passt:
[Interface]
PrivateKey = /etc/wireguard/private.key
Address = 100.64.0.2/32
ListenPort = 51820
[Peer]
# Laptop von Admin (PublicKey Base64)
PublicKey = HIe2zN8...P2k=
AllowedIPs = 100.64.0.3/32Der Handshake braucht genau einen Round-Trip — drei Nachrichten, fertig. Gemessen habe ich bei mir Verbindungsaufbau in unter 50 Millisekunden. Auf meinem Hetzner-VPS (2 vCPU, 1 Gbit/s-Anbindung) schaffe ich mit WireGuard 940 Mbit/s über den Tunnel. Das ist im Wesentlichen die Rohleistung der Leitung.
Die Kehrseite: WireGuard ist minimalistisch bis zur Schmerzgrenze. Es gibt kein eingebautes NAT-Traversal — sitzt dein Server hinter einem Router, der eingehende UDP-Pakete auf Port 51820 nicht weiterleitet, verbindet sich niemand. Es gibt kein automatisches Key-Management, keine Benutzerverwaltung, keine dynamische Zuweisung von Adressen. Wer 40 Clients verwaltet, schreibt sich eigene Tooling oder nutzt eine Verwaltungsschicht wie wg-easy oder ein Ansible-Playbook. Und weil die Keys Base64-codiert sind, tippt man sie ständig falsch ab — der bitcalc Base64-Encoder hat mir schon mehr als einmal geholfen, einen kopierten Key sauber zu formatieren, wenn der Editor Zeilenumbrüche eingestreut hatte.
Mein Fazit zu WireGuard: Für Job 1 (Roadwarrior) und Job 2 (Site-to-Site) mit überschaubarer Gerätezahl ist es die beste Wahl, die es heute gibt. Manuell, ehrlich, schnell. Wer mehr will, nimmt Tailscale — das ist im Kern auch WireGuard, nur mit einem Verwaltungs-Layer drumherum.
OpenVPN: Das Arbeitstier, das keiner mehr neu aufsetzt
OpenVPN gibt es seit 2001, und es hat zwei unbestrittene Stärken: Es ist mit Abstand am weitesten verbreitet — jeder Firewall-Hersteller, jeder VPN-Client, jede Enterprise-Doku spricht OpenVPN — und es kann sich durch fast jede Firewall quälen, weil es wahlweise über UDP 1194 oder TCP 443 läuft. Wenn ein Kunde sagt „unser VPN ist kaputt", meint er zu 90 Prozent OpenVPN. Der USB-Stick aus meiner Eingangsgeschichte war auch einer.
Die Architektur ist ein Userspace-Prozess, der TLS-Handshakes fährt und Pakete über OpenSSL verschlüsselt. Das kostet doppelt: TLS bringt einen Protokoll-Overhead mit (Zertifikatsketten, Handshake-Round-Trips), und der Userspace-Daemon muss jedes Paket vom Kernel übernehmen, verarbeiten und zurückgeben. Auf meinem VPS habe ich mit OpenVPN real 85 Mbit/s gemessen — bei voller CPU-Last auf einem Kern. Das ist mehr als eine Größenordnung weniger als WireGuard auf derselben Kiste. Wer behauptet, OpenVPN sei „genauso schnell", hat entweder eine fette CPU oder wenig Verkehr.
Dazu kommt der Konfigurations-Wildwuchs. Ein OpenVPN-Setup mit Zertifikaten braucht eine eigene CA (easy-rsa), Server- und Client-Zertifikate, ein server.conf, pro Client eine eigene .ovpn-Datei mit eingebetteten Zertifikaten — und wenn jemand den Server wechselt, müssen alle Clients neue Dateien bekommen. In meiner Zeit als Dienstleister habe ich OpenVPN-Setups geerbt, bei denen die CA auf dem Laptop eines ehemaligen Mitarbeiters lag. Rate mal, was passierte, als der Laptop starb.
Wo OpenVPN weiterhin seinen Platz hat: Wenn du viele unterschiedliche Client-Typen bedienen musst, die es seit zehn Jahren nicht aktualisiert wurden, wenn du TCP 443 als letzte Option brauchst (manche Hotel-Firewalls blocken alles außer HTTPS), oder wenn ein Kunde eine Enterprise-Firewall mit eingebautem OpenVPN-Interoperabilitätsmodus fährt. Neu aufsetzen würde ich es heute für keinen einzigen Anwendungsfall. Die Fingerprints der Zertifikate kann man übrigens mit dem bitcalc Hash-Generator prüfen — SHA-256 von CA- und Server-Zertifikat vergleichen, bevor man eine neue Verbindung blind akzeptiert.
Tailscale: WireGuard, aber mit Sekretariat
Tailscale ist WireGuard mit einem Verwaltungsdienst obendrauf. Der Client auf deinem Gerät ist ein WireGuard-Tunnel, aber die Koordination — wer darf womit reden, welche Adressen werden vergeben, wie finden sich die Peers hinter NAT — übernimmt der Tailscale-Koordinationsserver. Du installierst den Client, loggst dich ein, und fünf Minuten später redet dein Laptop mit deinem NAS, deinem Pi und dem Server deines Bruders, ohne dass du eine einzige Firewall-Regel angefasst hast.
Das Zauberwort heißt NAT-Traversal: Tailscale versucht, direkte Verbindungen zwischen den Geräten aufzubauen (per UDP-Hole-Punching). Wenn das scheitert — aggressive Firmen-Firewalls, Carrier-Grade-NAT — springen automatisch die DERP-Relays ein: verschlüsselte Relais-Server, die Tailscale weltweit betreibt. Der Verkehr bleibt Ende-zu-Ende-verschlüsselt; Tailscale kann ihn nicht lesen, weil die WireGuard-Session direkt zwischen deinen Geräten ausgehandelt wird. Das ist ein wichtiger Unterschied zu klassischen „Cloud-VPNs": Die Kontrolle (Koordinierung) liegt in der Cloud, die Daten nicht.
Gemessen habe ich bei direkter Verbindung 920 Mbit/s — dieselbe WireGuard-Kiste, derselbe VPS, nur eben mit Tailscale verwaltet. Über ein DERP-Relay sinkt der Durchsatz auf das, was das jeweilige Relay hergibt (bei mir 100–200 Mbit/s je nach Standort). Für SSH, Administration und Dateizugriff reicht das locker.
Dazu kommen die Dinge, die einen im Alltag wahnsinnig machen, wenn sie fehlen: MagicDNS (jedes Gerät hat einen Namen wie nas.tailnet.ts.net, den man nicht auswendig lernen muss), ACLs (eine Policy-Datei, die regelt, wer wohin darf), und SSO-Anbindung (Google, Microsoft, OIDC). Der Free-Tier reicht für 3 User und 100 Geräte — für ein Homelab und eine kleine Firma fast immer genug. Und weil sich die Geräte über den Koordinationsserver gegenseitig finden, klappt der Zugriff von überall, ohne dass du irgendwo Ports öffnest. Kein einziger Port an meinem Router ist für VPN geöffnet — das ist ein Sicherheitsgewinn, den man nicht unterschätzen sollte.
Der Preis dafür ist ein Vertrauenspunkt, den es bei reinem WireGuard nicht gibt: Deine Geräte-Liste, deine Adressen und deine Verbindungs-Metadaten laufen über den Koordinationsserver von Tailscale. Für die meisten Anwendungen ist das ein guter Deal. Wer das nicht will, setzt Headscale auf — eine Open-Source-Neuimplementierung des Koordinationsservers, die du auf einem eigenen Server betreibst. Dann hast du die Komfort-Schicht von Tailscale und behältst alle Daten unter deiner Kontrolle. Aufwand: ein Docker-Container, ein Reverse-Proxy, 30 Minuten.
Die Vergleichstabelle: Zahlen aus meinem Setup
Alle Durchsatzwerte habe ich mit iperf3 über denselben Hetzner-VPS (2 vCPU, 1 Gbit/s) gemessen, der Client war ein Lenovo-Laptop mit Ubuntu. Die Handshake-Zeiten kommen aus wg show und OpenVPN-Logs. Deine Werte werden anders sein — aber die Größenordnung stimmt.
Was die Tabelle nicht zeigt: OpenVPN ist das einzige der drei, das ich in den letzten zwei Jahren nicht neu aufgesetzt, sondern nur migriert habe. WireGuard und Tailscale habe ich mehrfach neu installiert — und beide Male war das angenehmer als jeder OpenVPN-Eingriff.
Die Subnetz-Overlap-Falle: Warum dein Tunnel plötzlich nichts mehr erreicht
Jetzt die Geschichte, die dich vor einer der dümmsten Nächte deines Admin-Lebens bewahren soll. Vor zwei Jahren richtete ich einem Freund einen WireGuard-Tunnel von seinem Laptop zu seiner Büro-NAS ein. Funktioniert super — daheim. Im Hotel dann: Nichts geht mehr. Kein Ping, kein SSH, kein gar nichts. Der Laptop zeigte eine Verbindung, aber jeder Versuch ins Büro-Netz lief ins Leere.
Die Ursache war so simpel wie fies: Das Hotel-WLAN nutzte 10.0.0.0/24 — exakt dasselbe Subnetz wie das Büro. Der Laptop hatte also zwei Routen für dieselben IPs: die lokale WLAN-Route (Default-Gateway des Hotels) und die Tunnel-Route. Und weil die lokale Route gewann, gingen alle Pakete für „das Büro" in das WLAN des Hotels. Klassische Subnetz-Overlap-Falle.
Die Lösung hat drei Teile:
- Tunnelnetz aus dem CGNAT-Bereich wählen:
100.64.0.0/10ist für genau solche Zwecke reserviert (RFC 6598) — kein normales LAN nutzt es, also kollidiert es praktisch nie. Der Server bekommt100.64.0.1/32, der Laptop100.64.0.2/32. - LAN-Subnetze bewusst vergeben: Statt überall
10.0.0.0/24oder192.168.0.0/24zu nehmen, vergib pro Standort ein eigenes Subnetz aus172.16.0.0/12oder dem 10er-Block: Büro A10.10.0.0/24, Büro B10.20.0.0/24, Homelab10.30.0.0/24. Dann kann sich kein Standort je mit einem anderen beißen. - Alles durchrechnen: Bevor du ein Subnetz vergibst, prüfst du mit dem bitcalc Subnetz-Rechner, ob der Bereich wirklich frei ist und wie groß er sein muss. Ein /24 für 30 Geräte ist Platzverschwendung — ein /26 reicht, und du hast für spätere Erweiterungen noch den Rest des /24.
Ich habe das Büro meines Freundes inzwischen auf 192.168.10.0/24 umgestellt und den Tunnel auf 100.64.0.0/10. Seitdem funktioniert der Zugriff aus jedem Hotel, jedem Café und jeder Bahn — egal, welches Netz dahintersteckt. Die Overlap-Falle ist übrigens der häufigste Grund, warum Leute glauben, „VPN sei kaputt", wenn in Wahrheit nur die Routing-Tabelle zwei Netze verwechselt. ip route get 10.30.0.5 zeigt dir in einer Sekunde, wohin ein Paket wirklich geht.
Die Topologie: So sieht ein sauberes Roadwarrior-Setup aus
Drei Regeln machen dieses Setup wartbar:
- Ein Tunnelnetz für alle: Jedes Gerät bekommt eine Adresse aus
100.64.0.0/10. Der Server ist die Brücke, die Clients dürfen nur durch den Server ins LAN — keine direkten Peer-Verbindungen, die du nicht kennst. - AllowedIPs klein halten: Der Laptop bekommt nur die Subnetze, die er wirklich braucht (
100.64.0.0/10, 192.168.10.0/24), nicht0.0.0.0/0. Das ist Split-Tunneling — das Internet läuft direkt, nur das Büro durch den Tunnel. Kein Netflix-langsam-wenn-Büro-down-Effekt, und das Büronetz ist weniger exponiert. - Firewall auf dem Server: Auf dem VPS darf nur UDP 51820 von außen ankommen. Alles andere ist zu. Wer Zugriff aufs Büro braucht, kommt durch den Tunnel — und nur so.
Wann nimmst du was? Meine Entscheidungsregeln
Nach fünf Jahren Betrieb dieser drei Welten sind meine Regeln ziemlich stabil geworden:
- Ein Server, ein paar Clients, du bist der einzige Admin: WireGuard. 15 Minuten Aufwand, maximale Kontrolle, keine externe Abhängigkeit. Die Keys verwaltest du in einer Datei, die in deinem Backup liegt — der Base64-Encoder hilft beim sauberen Kopieren, der Hash-Generator beim Prüfen von Fingerprints.
- Zwei Standorte, die sich wie ein Netz verhalten sollen: Auch WireGuard, als Site-to-Site mit einem Peer pro Standort. Durchsatz zählt, und hier gewinnt WireGuard klar.
- Zwölf Geräte, Familie, Freunde, wechselnde Netze: Tailscale. Die 10 Minuten Setup-Ersparnis pro Gerät rechnen sich ab dem dritten Gerät, und die ACL-Datei ist leichter zu warten als 15 wg0.conf-Dateien. Wer keine Cloud-Koordination will, nimmt Headscale.
- Enterprise-Vorgaben, alte Clients, „muss mit allem reden": OpenVPN — aber nur, wenn du es nicht neu aufsetzen musst. Bestand migrieren, Neubauten mit WireGuard oder Tailscale.
100.64.0.0/10 (CGNAT), LAN-Subnetze pro Standort eindeutig aus dem 10er- oder 172.16er-Block. Der bitcalc Subnetz-Rechner zeigt dir Netzadresse, Hostbereich und Größe in Sekunden — damit ist die Overlap-Falle von Anfang an ausgeschlossen.Fazit
Wenn ich heute ein VPN neu aufsetzen müsste, gäbe es genau zwei Kandidaten: WireGuard für alles, was ich selbst kontrolliere, und Tailscale für alles, was viele Geräte und wenig Wartung braucht. OpenVPN hat meine Geschichte geprägt, aber nicht meine Zukunft. Die Messwerte sprechen für sich: 940 Mbit/s gegen 85 Mbit/s auf derselben Kiste, Handshake in Millisekunden statt Sekunden, Konfigurationsdateien in einer Handvoll Zeilen statt Zertifikatsorgien. Und die Overlap-Falle aus dem Hotel-WLAN ist mir seit der Umstellung auf CGNAT nicht mehr begegnet.
Der schönste Nebeneffekt des Ganzen: Seit Tailscale auf meinen Geräten läuft, ist an meinem Router kein einziger Port für VPN geöffnet. Der USB-Stick mit der OpenVPN-Konfiguration liegt übrigens noch in irgendeiner Schublade. Er hat ausgedient — genau wie die Zeit, in der so etwas der Stand der Technik war.