senn-techWireGuard: VPN für den Alltag
VPN ist kein Nischenthema. Remote-Arbeitsplatz, Standortvernetzung, Zugriff auf interne Dienste — das braucht jede Organisation. WireGuard macht es einfacher, als VPN jemals war.
Warum WireGuard?
WireGuard ist 4.000 Zeilen Code — gegen IPsecs Hunderttausende. Es läuft im Kernel, braucht keine Zertifikatsinfrastruktur, kein IKE-Handshake-Theater. Ein Schlüsselpaar, eine Config-Datei, fertig.
# Schlüsselpaar erzeugen
wg genkey | tee privatekey | wg pubkey > publickey
# /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <...>
Address = 10.10.0.1/24
ListenPort = 51820
[Peer]
PublicKey = <...>
AllowedIPs = 10.10.0.2/32, 192.168.181.0/24
Das ist die ganze Site-to-Site-Konfiguration zwischen Kufstein und dem Hetzner-Root-Server. Kein Verbindungsaufbau, kein Aushandeln — die Tunnel sind da, sobald die Interfaces hoch sind.
Site-to-Site: Standorte wie ein Netz
Zwei Standorte, ein VPN-Tunnel, und beide Seiten erreichen einander, als wären sie im selben VLAN. Wir nutzen das:
- Kufstein → Hetzner: Proxmox-Backup-Traffic läuft über WireGuard, verschlüsselt, ohne zusätzliche Authentifizierungsschicht
- Kufstein → Kundenstandort: Zugriff auf deren Monitoring, Logging, Helpdesk — ohne Port-Forwarding auf deren Firewall
Road-Warrior: Ein mobiler Client, ein Eintrag
Laptop, Handy, Tablet — WireGuard-Clients gibt es für alles. Ein Peer-Eintrag pro Gerät, und der Mitarbeiter ist im internen Netz, egal von wo.
# Client-seitig
[Interface]
PrivateKey = <...>
Address = 10.10.0.10/32
[Peer]
PublicKey = <server-key>
Endpoint = vpn.senn-tech.com:51820
AllowedIPs = 192.168.181.0/24
PersistentKeepalive = 25
PersistentKeepalive = 25 ist bei Clients hinter NAT (also praktisch jedem Laptop im Hotel-WLAN) kein Detail, sondern Pflicht: Ohne regelmässige Keepalive-Pakete schliesst der NAT-Router das UDP-Mapping, und der Rückweg zum Client ist tot. Bei Tunnel-in-Tunnel-Szenarien lohnt zudem ein Blick auf die MTU (häufig 1420), sonst zerschellen grosse Pakete an der Fragmentierung.
Viele Clients? Eine Management-Schicht
Ein Peer-Eintrag pro Gerät ist bei fünf Mitarbeitern charmant, bei fünfzig mühsam. Tools wie wg-easy, wg-portal oder Firezone legen eine Verwaltungsoberfläche über WireGuard — Peers, QR-Codes fürs Handy und Ablaufdaten inklusive, ohne den Kernel-Vorteil aufzugeben.
WireGuard vs. OpenVPN vs. IPsec
| Kriterium | WireGuard | OpenVPN | IPsec |
|---|---|---|---|
| Komplexität | Minimal | Mittel | Hoch |
| Performance | Kernel, sehr schnell | Userspace, gut | Kernel, schnell |
| Roaming | Transparent | Mühsam | Kaum |
| Auditierbarkeit | Sehr gut (kleiner Code) | Gut | Schwierig |
Sicherheit: Das Einfachheitsprinzip
WireGuard hat keine Optionen für unsichere Cipher. Es gibt nicht "den falschen Algorithmus" auszuwählen, weil es keine Auswahl gibt. Curve25519, ChaCha20, Poly1305 — das sind die einzigen Primitive, und das ist ausreichend.
Fazit
WireGuard ersetzt IPsec und OpenVPN für alle KMU-VPN-Zwecke. Keine Konfigurationsorgien, keine Zertifikatsprobleme, kein Verbindungsroulette. Ein Schlüsselpaar, eine Config — dann ist der Tunnel da.
Ist WireGuard ohne wählbare Verschlüsselung und Zertifikate sicher genug?+
Gerade weil es keine Auswahl gibt. WireGuard bietet keine Optionen für unsichere Cipher — Curve25519, ChaCha20 und Poly1305 sind die einzigen Primitive, und das ist ausreichend. Es gibt keinen „falschen Algorithmus“ zu wählen. Dazu sind es nur rund 4.000 Zeilen Code gegenüber IPsecs Hunderttausenden, was die Auditierbarkeit deutlich erhöht.
Wird die Verwaltung bei vielen Mitarbeitern nicht mühsam?+
Ein Peer-Eintrag pro Gerät ist bei fünf Mitarbeitern charmant, bei fünfzig mühsam. Dafür gibt es Verwaltungsoberflächen wie wg-easy, wg-portal oder Firezone: Sie legen Peers an, erzeugen QR-Codes fürs Handy und setzen Ablaufdaten — ohne den Kernel-Vorteil von WireGuard aufzugeben.
Warum reißt die Verbindung aus dem Hotel-WLAN ab?+
Clients hinter NAT — praktisch jeder Laptop im Hotel-WLAN — brauchen PersistentKeepalive = 25. Ohne regelmäßige Keepalive-Pakete schließt der NAT-Router das UDP-Mapping, und der Rückweg zum Client ist tot. Bei Tunnel-in-Tunnel-Szenarien lohnt zusätzlich ein Blick auf die MTU (häufig 1420), sonst zerschellen große Pakete an der Fragmentierung.