Netzwerk & WAN
OpenVPN
OpenVPN ist eine etablierte, quelloffene VPN-Lösung, die einen TLS-gesicherten Steuerkanal mit einer X.509-PKI nutzt und Verkehr wahlweise über UDP oder TCP tunnelt.
- TLS-gesicherter Steuerkanal
- X.509-PKI, Zertifikate
- TUN (Layer 3) oder TAP (Layer 2)
- UDP oder TCP/443
- DCO für Performance
OpenVPN ist eine der etabliertesten VPN-Lösungen überhaupt, quelloffen und seit 2002 im Einsatz. Es baut auf TLS auf: Ein gesicherter Steuerkanal authentifiziert die Gegenseite und handelt die Schlüssel aus, ein separater Datenkanal transportiert dann den verschlüsselten Nutzverkehr. Die Authentifizierung läuft über eine eigene Zertifikatsinfrastruktur (PKI).
Dieser Artikel erklärt die Zwei-Kanal-Architektur und die Härtung des Steuerkanals, die PKI mit Zertifikaten und Sperrliste, den Unterschied zwischen TUN und TAP, die Transportwahl samt dem TCP-over-TCP-Problem, die Aushandlung der Cipher, die Authentifizierungswege über Zertifikate hinaus sowie den Data Channel Offload, der den alten Performance-Engpass auflöst.
1. Zwei Kanäle: Steuerung und Daten
OpenVPN trennt sauber in zwei logische Kanäle, die über einen Port laufen. Der Control Channel ist eine TLS-Verbindung und erledigt Authentifizierung, Aushandlung der Datenverschlüsselung und das regelmäßige Neuschlüsseln. Der Data Channel trägt die eigentlichen IP-Pakete, verschlüsselt mit dem dabei ausgehandelten symmetrischen Schlüssel.
Den Steuerkanal selbst kann man zusätzlich härten: tls-auth signiert alle Steuerpakete mit einem gemeinsamen Schlüssel, tls-crypt verschlüsselt sie zusätzlich (auch vor dem TLS-Handshake), und tls-crypt-v2 gibt jedem Client einen eigenen abgeleiteten Schlüssel. Das wehrt unauthentifizierte Verbindungsversuche und einfache DoS-Angriffe ab.
2. Die PKI: Zertifikate und Sperrliste
Im TLS-Modus braucht OpenVPN eine vollständige X.509-PKI. Eine eigene CA signiert das Server- und alle Client-Zertifikate; beide Seiten prüfen sich gegenseitig gegen dieselbe CA. Der Aufbau läuft typischerweise über das Begleitwerkzeug Easy-RSA. Wichtig für den Betrieb: Mit einer Sperrliste (CRL) lassen sich einzelne Zertifikate widerrufen, ohne die ganze PKI neu aufzubauen, etwa wenn ein Laptop verloren geht.
Die Sperrliste hat ein Ablaufdatum
Eine abgelaufene CRL blockiert je nach Konfiguration alle Verbindungen. Die Erneuerung der Sperrliste und die Zertifikatsrotation gehören in den Betriebsablauf, sonst steht der VPN-Zugang plötzlich still.
3. TUN oder TAP
OpenVPN kann auf zwei Ebenen arbeiten:
| TUN (Layer 3) | TAP (Layer 2) |
|---|---|
| tunnelt IP-Pakete, geroutet | tunnelt Ethernet-Frames, gebrückt |
| Standard für Remote-Access und Site-to-Site | nur wenn echte Layer-2-Transparenz nötig ist |
| geringer Overhead, gut skalierbar | höherer Overhead, schlechter skalierbar |
| mit Data Channel Offload kompatibel | nicht mit dem Offload kombinierbar |
4. UDP oder TCP und das TCP-over-TCP-Problem
Standard ist UDP auf Port 1194, und UDP ist auch die empfohlene Wahl. TCP wird gebraucht, wenn restriktive Firewalls nur HTTP und HTTPS durchlassen: Über TCP auf Port 443 ist OpenVPN-Verkehr kaum von HTTPS zu unterscheiden.
Der Preis dafür ist das TCP-over-TCP-Problem (TCP-Meltdown): Läuft eine TCP-Anwendung durch einen TCP-Tunnel, reagieren beide Schichten unabhängig auf Paketverlust und verstärken ihre Wiederholungen gegenseitig. Schon geringer Verlust lässt den Durchsatz einbrechen. TCP gehört deshalb nur als Notlösung gewählt, nicht als Standard.
5. Cipher-Aushandlung
Anders als WireGuard handelt OpenVPN die Datenverschlüsselung aus. Über die data-ciphers-Liste werden moderne AEAD-Verfahren angeboten, in der Regel AES-256-GCM, AES-128-GCM und ChaCha20-Poly1305. Der alte Standard BF-CBC (Blowfish) gilt als unsicher und wird ohne ausdrücklichen Kompatibilitätsmodus nicht mehr akzeptiert. Für den Produktivbetrieb gehören Mindest-TLS-Version und Cipher-Liste bewusst gesetzt.
Server-Konfiguration (Auszug)
# /etc/openvpn/server.conf (Auszug)
dev tun
topology subnet
proto udp
port 1194
data-ciphers AES-256-GCM:CHACHA20-POLY1305
tls-crypt ta.key
remote-cert-tls client
crl-verify crl.pem
push "redirect-gateway def1"
push "dhcp-option DNS 10.8.0.1"6. Authentifizierung über das Zertifikat hinaus
Zur gegenseitigen Zertifikatsprüfung lassen sich weitere Faktoren kombinieren: Benutzername und Passwort gegen PAM oder LDAP, Hardware-Token und Smartcards über PKCS#11 (etwa YubiKey), Einmalcodes per TOTP für Mehrfaktor-Authentifizierung sowie kurzlebige Tokens, die der Server nach erfolgreicher Anmeldung ausgibt. Diese Kombinierbarkeit ist eine der Stärken von OpenVPN.
7. Performance: Data Channel Offload
Historisch verarbeitete OpenVPN den Datenpfad in einem einzelnen Userspace-Thread, was den Durchsatz auf einem Kern deckelte. Der Data Channel Offload (DCO) verlagert Ver- und Entschlüsselung in ein Kernelmodul; der Daemon bleibt nur noch Steuerinstanz. Das hebt den Engpass deutlich an. DCO hat allerdings Bedingungen: nur TUN, nur die subnet-Topologie, nur AEAD-Cipher und nur UDP, ohne Kompression. Wer diese Voraussetzungen erfüllt, gewinnt spürbar an Geschwindigkeit.
8. MTU und Overhead
Wie jeder Tunnel verkleinert OpenVPN die nutzbare Paketgröße. Damit innere TCP-Verbindungen nicht über die Tunnel-MTU hinauslaufen und still fragmentiert oder verworfen werden, senkt mssfix die maximale Segmentgröße passend ab; für andere Verkehrsarten kann OpenVPN intern fragmentieren. Diese Werte gehören zur Strecke passend gesetzt, sonst treten schwer zu findende Probleme mit großen Paketen auf.
9. Community Edition und Access Server
OpenVPN gibt es in zwei Ausprägungen:
| Community Edition | Access Server |
|---|---|
| kostenlos, GPLv2, reine Kommandozeile | kommerziell lizenziert, Weboberfläche und API |
| Authentifizierung manuell über PKI und Plugins | LDAP, SAML, Mehrfaktor und Richtlinien integriert |
| Skalierung und Hochverfügbarkeit selbst aufbauen | Clustering und Failover eingebaut |
| für erfahrene Linux-Teams | für Unternehmen ohne tiefe VPN-Expertise |
10. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Sehr flexibel und reif, breite Plattformunterstützung | Betrieb einer PKI (CA, Zertifikate, CRL) ist aufwendig |
| Firewallfreundlich, notfalls als HTTPS über TCP/443 getarnt | TCP-over-TCP bricht den Durchsatz ein (UDP bevorzugen) |
| Gegenseitige Zertifikate plus optionale Mehrfaktor-Auth | Höhere Konfigurationskomplexität als schlanke Alternativen |
| Gezielter Zertifikatswiderruf über die Sperrliste | Abgelaufene CRL kann alle Verbindungen blockieren |
| Data Channel Offload löst den alten Single-Thread-Engpass | DCO nur mit TUN, subnet, AEAD und UDP nutzbar |
Häufige Fragen zu OpenVPN
In der Regel UDP (Standardport 1194). TCP ist nur als Notlösung sinnvoll, wenn eine restriktive Firewall ausschließlich HTTP und HTTPS durchlässt, dann kann OpenVPN über TCP auf Port 443 wie HTTPS aussehen. TCP durch einen TCP-Tunnel führt jedoch zum TCP-over-TCP-Problem, bei dem schon geringer Paketverlust den Durchsatz einbrechen lässt.
Über die Sperrliste (CRL) der PKI. Das betreffende Client-Zertifikat wird widerrufen und die aktualisierte CRL auf dem Server eingespielt, ohne dass die übrige Infrastruktur neu aufgebaut werden muss. Wichtig ist, die CRL rechtzeitig zu erneuern, da eine abgelaufene Sperrliste je nach Konfiguration alle Verbindungen blockiert.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
OpenVPN im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.