13. VPN

Stellt euch vor: Ihr arbeitet im Homeoffice und müsst auf interne Firmenserver zugreifen. Oder zwei Standorte sollen so miteinander verbunden sein, als lägen sie im selben Netz. Beides löst ein VPN – ein verschlüsselter Tunnel durch das öffentliche Internet. Dieser Block zeigt euch die wichtigsten Protokolle und wann ihr welches einsetzt.

Nach diesem Block könnt ihr:

  • erklären, was ein VPN ist und worin sich Site-to-Site und Client-to-Site unterscheiden
  • die Funktionsweise von IPsec (ESP, IKEv2, Tunnel- vs. Transportmodus) beschreiben
  • WireGuard und OpenVPN vergleichen und je nach Szenario das passende Protokoll wählen
  • Split Tunneling vs. Full Tunnel bewerten und die Sicherheitsimplikationen benennen
  • einen einfachen WireGuard-Tunnel konfigurieren und starten

Was ist ein VPN?

VPN (Virtual Private Network) ist eine verschlüsselte Verbindung über ein öffentliches Netz (meistens das Internet), die sich verhält wie ein privates, internes Netzwerk. Daten werden verschlüsselt durch das öffentliche Netz „getunnelt” – von außen sieht man nur verschlüsselten Traffic, nicht den Inhalt.

Ohne VPN:
  Laptop ───── Internet (unverschlüsselt) ──── Firmennetz
                   Jeder kann mitlesen

Mit VPN:
  Laptop ─────[verschlüsselter Tunnel]──────── Firmennetz
    │        (Internet als Transportweg)          │
    │                                             │
  VPN-Client                                VPN-Gateway
              Inhalt für Dritte unlesbar

Typische Einsatzgebiete:

  • Mitarbeiter im Homeoffice greifen sicher auf das Firmennetz zu
  • Zwei Unternehmensstandorte werden sicher verbunden
  • Schutz im öffentlichen WLAN
  • Sicherer Fernzugriff auf Server

Site-to-Site vs. Client-to-Site

Site-to-Site VPN (Standort-zu-Standort):

Verbindet zwei komplette Netzwerke miteinander. Der VPN-Tunnel läuft zwischen zwei Gateways (z.B. Routern oder Firewalls). Endgeräte in beiden Netzwerken merken nichts vom VPN – für sie ist es ein normales Netzwerk.

Standort München                          Standort Berlin
  ┌─────────────────┐                   ┌─────────────────┐
  │ PC1, PC2, NAS   │                   │ PC3, Server     │
  │                 │                   │                 │
  │  [VPN-Gateway]──┼───── Internet ────┼──[VPN-Gateway]  │
  └─────────────────┘   (verschlüsselt) └─────────────────┘

  PC1 kann auf Server zugreifen wie im lokalen Netz

Client-to-Site VPN (Fernzugriff):

Ein einzelner Client (z.B. Laptop im Homeoffice) verbindet sich mit dem Firmennetz. Der VPN-Client auf dem Gerät baut den Tunnel auf.

Homeoffice                                    Firmennetz
  Laptop                                    ┌──────────────┐
  │                                         │ Server       │
  │ [VPN-Client] ─────── Internet ──────────│ [VPN-Gateway]│
  │               (verschlüsselter Tunnel)  │ Drucker      │
                                            │ NAS          │
                                            └──────────────┘

IPsec – Internet Protocol Security

Stellt euch IPsec wie einen gepanzerten Kurierdienst vor: Es gibt einen äußeren Umschlag (den neuen IP-Header), darin liegt ein versiegelter Behälter (ESP), und im Behälter steckt der eigentliche Brief (eure Daten). Der Kurierdienst weiß, wohin der Umschlag muss – aber selbst er kann den Behälter nicht öffnen.

IPsec ist das am weitesten verbreitete VPN-Protokoll in Unternehmensumgebungen – nicht weil es einfach ist, sondern weil es seit Jahrzehnten zuverlässig läuft, in fast jeder Firewall und jedem Router eingebaut ist und von Herstellern wie Cisco, Juniper und Palo Alto offiziell unterstützt wird. Wenn ihr in einem Unternehmen ein VPN einrichtet, ist IPsec in den meisten Fällen die erste Wahl – egal ob ihr es mögt oder nicht. Es arbeitet auf Netzwerkebene (Layer 3) und kann gesamten IP-Traffic verschlüsseln.

Zwei Betriebsmodi:

IPsec kann Daten auf zwei Arten schützen – je nachdem, ob zwei einzelne Rechner direkt kommunizieren oder ob zwei Gateways ganze Netzwerke verbinden:

Transportmodus (Host-zu-Host):
  [Original-IP-Header] [ESP-Header] [verschlüsselte Nutzdaten]

  Nur die Nutzdaten werden verschlüsselt, der Original-Header bleibt sichtbar.
  Einsatz: Direkte Kommunikation zwischen zwei Hosts, z.B. zwei Server
  im selben Rechenzentrum, die vertraulich kommunizieren sollen.

Tunnelmodus (Gateway-zu-Gateway – der Normalfall):
  [neuer IP-Header] [ESP-Header] [verschlüsselt: Original-IP-Header + Nutzdaten]

  Das gesamte originale IP-Paket wird verschlüsselt und in ein neues Paket verpackt.
  Von außen sieht man nur die Gateway-Adressen – nicht, wer intern kommuniziert.
  Einsatz: Site-to-Site-VPN (München ↔ Berlin), Client-to-Site (Homeoffice → Firma).

ESP – das Arbeitstier von IPsec:

IPsec kennt zwei Protokolle: AH (Authentication Header) und ESP (Encapsulating Security Payload). In der Praxis begegnet euch fast ausschließlich ESP, weil es alles kann – verschlüsseln, authentifizieren und die Integrität sicherstellen. AH kann nicht verschlüsseln und ist damit für VPN-Tunnel nutzlos. Merkt euch ESP, vergesst AH.

ProtokollVerschlüsselungAuthentifizierungIntegritätsschutzPraxisrelevanz
AH (Authentication Header)NeinJaJaVeraltet
ESP (Encapsulating Security Payload)JaJaJaStandard

IKE – der Handshake vor dem Tunnel:

IPsec selbst verschlüsselt nur – aber bevor verschlüsselt werden kann, müssen sich beide Seiten auf Algorithmen und Schlüssel einigen. Das übernimmt IKEv2 (Internet Key Exchange, Version 2). Der Ablauf erinnert an den TLS-Handshake aus Block 08, nur auf Netzwerkebene:

Phase 1 (IKE SA – „Wer bist du, und wie reden wir sicher?"):
  Die beiden Gateways bauen einen sicheren Kontrollkanal auf.
  Sie authentifizieren sich gegenseitig – per Zertifikat oder Pre-Shared Key.
  Ergebnis: Ein verschlüsselter Kanal, über den Phase 2 laufen kann.

Phase 2 (IPsec SA – „Jetzt richten wir den eigentlichen Tunnel ein"):
  Über den sicheren Kanal aus Phase 1 handeln die Gateways
  die IPsec-Parameter für den Datentunnel aus:
  Welcher Algorithmus? Welche Schlüssellänge? Welche Netzwerke werden getunnelt?
  Ergebnis: Session-Keys für ESP, der Tunnel steht.

Schematisch sieht der IKEv2-Handshake so aus (vergleicht ihn mit dem TLS-Handshake aus Block 08 – das Prinzip ist dasselbe, nur auf Netzwerkebene):

Phase 1 (IKE SA):
Initiator                              Responder
    │                                      │
    │── IKE_SA_INIT ─────────────────────►│
    │   Diffie-Hellman-Parameter,         │
    │   unterstützte Algorithmen          │
    │                                      │
    │◄── IKE_SA_INIT ──────────────────────│
    │   DH-Antwort, gewählte Algorithmen  │
    │                                      │
    │  Beide berechnen gemeinsamen Key    │
    │  → verschlüsselter Kontrollkanal    │
    │                                      │
    │── IKE_AUTH (verschlüsselt) ────────►│
    │   Identität + Authentifizierung     │
    │   (PSK oder Zertifikat)             │
    │                                      │
    │◄── IKE_AUTH (verschlüsselt) ─────────│
    │   Identität + Authentifizierung     │

Phase 2 (Child SA / IPsec SA):
    │── CREATE_CHILD_SA ─────────────────►│
    │   Traffic-Selektoren               │
    │   (welcher Traffic durch Tunnel)    │
    │                                      │
    │◄── CREATE_CHILD_SA ──────────────────│
    │                                      │
    │  Ab jetzt: Datenverkehr durch       │
    │  ESP-verschlüsselten Tunnel        │

Authentifizierung in IPsec:

Damit sich zwei Gateways in Phase 1 gegenseitig erkennen, gibt es zwei Wege:

  • Pre-Shared Key (PSK): Beide Seiten kennen dasselbe Passwort. Einfach einzurichten, aber nicht skalierbar – bei 20 Standorten müsstet ihr jeden PSK einzeln pflegen. Für eine schnelle Verbindung zwischen zwei festen Standorten akzeptabel.
  • Zertifikate (PKI): Jede Seite hat ein eigenes Zertifikat, ausgestellt von einer gemeinsamen CA (Block 06). Skaliert gut, ist sicherer, aber erfordert eine PKI-Infrastruktur. Standard in größeren Unternehmensumgebungen.

WireGuard

Wenn IPsec der gepanzerte Kurierdienst ist – mit Formularen, Genehmigungen und dreifacher Identitätsprüfung –, dann ist WireGuard der Expressbote: Er nimmt das Paket, verschlüsselt es, liefert es ab. Fertig.

WireGuard ist das Gegenteil von IPsec: modern, schlank, meinungsstark. Statt hunderte von Konfigurationsoptionen zu bieten, trifft es alle kryptografischen Entscheidungen selbst – und zwar gute. Es ist seit Linux-Kernel 5.6 (2020) direkt im Kernel integriert, was es schnell und ausfallsicher macht. Die Lernkurve ist deutlich kürzer als bei IPsec – wer eine WireGuard-Konfiguration zum ersten Mal liest, versteht sie meistens sofort.

Eigenschaften:

  • Nur ~4.000 Zeilen Code (IPsec: ~400.000)
  • Feste, moderne Algorithmen: ChaCha20-Poly1305, Curve25519, BLAKE2
  • Kein komplexer Handshake – Authentifizierung ausschließlich per Public-Key-Kryptografie
  • Sehr schnell, besonders auf Mobilgeräten
  • Unterstützt Roaming (IP-Wechsel unterbricht Verbindung nicht)
# WireGuard-Schlüsselpaar generieren
wg genkey | tee private.key | wg pubkey > public.key

# Konfiguration /etc/wireguard/wg0.conf (Server)
[Interface]
Address = 10.0.0.1/24
PrivateKey = <Server-Private-Key>
ListenPort = 51820

[Peer]
PublicKey = <Client-Public-Key>
AllowedIPs = 10.0.0.2/32    # Welche IPs kommen von diesem Client?

# WireGuard starten
sudo wg-quick up wg0

# Status anzeigen
sudo wg show

OpenVPN

OpenVPN ist der Veteran unter den VPN-Lösungen – älter als WireGuard, flexibler als IPsec, und mit einem besonderen Trumpf: Es kann auf Port 443/TCP laufen und sieht dann von außen aus wie normaler HTTPS-Traffic. In restriktiven Netzwerken (Hotels, Flughäfen, Länder mit Internetzensur), die VPN-Protokolle aktiv blockieren, ist das oft der einzige Weg.

OpenVPN läuft als Userspace-Prozess (nicht im Kernel wie IPsec oder WireGuard), was es etwas langsamer macht, aber dafür einfach auf fast jedem Betriebssystem installierbar. Es nutzt TLS für den Verbindungsaufbau – die Konzepte aus Block 08 finden sich hier direkt wieder.

  • Standardport: 1194/UDP – oder 443/TCP, um Firewalls zu umgehen
  • Authentifizierung per Zertifikat + optionalem Passwort
  • TLS für den Control Channel, eigene symmetrische Verschlüsselung für den Data Channel
  • Plattformübergreifend verfügbar (Linux, Windows, macOS, Android, iOS)

Vergleich der VPN-Protokolle

EigenschaftIPsec/IKEv2WireGuardOpenVPN
KomplexitätHochGeringMittel
GeschwindigkeitHochSehr hochMittel
Kernel-IntegrationJaJa (seit Linux 5.6)Nein (Userspace)
AlgorithmenKonfigurierbarFest, modernKonfigurierbar
Firewalls umgehenSchwierigUDP 51820 (blockierbar)443/TCP (kaum blockierbar)
UnternehmenseinsatzSehr verbreitetWächst starkVerbreitet
Zertifikate / PKIJaNein (nur Public Keys)Ja

Welches Protokoll wann?

In der Praxis entscheidet nicht „das beste” Protokoll, sondern die Umgebung:

Euer Chef sagt: „Verbinde unsere zwei Standorte."
  → IPsec. Die Firewalls an beiden Standorten (Cisco, Juniper, Sophos)
    unterstützen IPsec nativ. Kein Extra-Server nötig.

Euer Chef sagt: „Die Entwickler brauchen VPN aus dem Homeoffice."
  → WireGuard. Schnell eingerichtet, schnelle Verbindung, Roaming
    funktioniert (Laptop geht vom WLAN ins Mobilnetz – Tunnel bleibt).

Ein Mitarbeiter sagt: „Im Hotel in China wird mein VPN geblockt."
  → OpenVPN auf Port 443/TCP. Sieht aus wie HTTPS, kommt durch
    fast jede Firewall.

Merke: IPsec ist Standard in Unternehmensumgebungen und direkt in Firewalls/Router integriert. WireGuard ist modern und schnell – die erste Wahl für neue Setups, wo keine Legacy-Hardware im Weg steht. OpenVPN ist der Ausweg, wenn restriktive Firewalls alles andere blockieren.

Split Tunneling

Die Frage, die in jedem VPN-Projekt irgendwann auftaucht: Soll wirklich der gesamte Traffic durch den Tunnel? Oder nur der, der ins Firmennetz muss?

Bei Full Tunnel VPN wird der gesamte Internettraffic durch das VPN geleitet – auch private Surfing-Aktivitäten gehen durch das Firmennetz. Vorteil: maximale Kontrolle und Sichtbarkeit. Nachteil: hohe Last auf dem VPN-Gateway, und Mitarbeitende verlieren im Homeoffice ihre Privatsphäre beim Surfen.

Bei Split Tunnel VPN wird nur der Traffic für das Firmennetz durch den Tunnel geleitet – der restliche Internettraffic geht direkt ins Internet.

Split Tunnel:
  10.0.0.0/8 (Firmennetz) → durch VPN-Tunnel
  Alles andere → direkt ins Internet

Vorteil: Entlastet das VPN-Gateway erheblich. Nachteil: Ein kompromittiertes Gerät hat gleichzeitig Zugang zum internen Netz und zum Internet – Malware kann über den ungeschützten Pfad kommunizieren. In sicherheitskritischen Umgebungen ist Full Tunnel deshalb oft Pflicht.

Typischer Denkfehler

„Ein VPN macht mich anonym im Internet.” – Nein. Ein VPN verschlüsselt den Tunnel zwischen eurem Gerät und dem VPN-Server – das schützt euch z.B. im öffentlichen WLAN. Aber der VPN-Anbieter sieht euren gesamten Traffic, und am Exit-Punkt (wo der Traffic das VPN verlässt) ist eure Verbindung wieder normal sichtbar. Webseiten sehen die IP-Adresse des VPN-Servers statt eurer eigenen – aber der VPN-Betreiber kann beides zuordnen. Ein VPN verschiebt das Vertrauen, es erzeugt keine Anonymität. Wer echte Anonymität braucht, braucht Tor – und selbst das hat Grenzen.

Probiert es selbst:

  1. Installiert WireGuard: sudo apt install wireguard (Debian/Ubuntu) oder brew install wireguard-tools (macOS)
  2. Generiert ein Schlüsselpaar: wg genkey | tee private.key | wg pubkey > public.key
  3. Schaut euch den Private Key an: cat private.key – und den Public Key: cat public.key
  4. Erstellt eine minimale Konfiguration /etc/wireguard/wg0.conf mit eurem Schlüsselpaar (siehe Beispiel oben im WireGuard-Abschnitt)
  5. Startet das Interface: sudo wg-quick up wg0
  6. Prüft den Status: sudo wg show – welche Informationen seht ihr?
  7. Stoppt das Interface wieder: sudo wg-quick down wg0

Zusammenfassung

  • Ein VPN tunnelt verschlüsselten Traffic durch ein öffentliches Netz – Site-to-Site verbindet Standorte, Client-to-Site verbindet einzelne Geräte
  • IPsec (mit ESP und IKEv2) ist der Unternehmensstandard, direkt in Firewalls und Routern integriert; Tunnelmodus ist der Normalfall
  • WireGuard ist modern, schlank und schnell – erste Wahl für neue Setups ohne Legacy-Anforderungen
  • OpenVPN auf Port 443/TCP umgeht restriktive Firewalls, weil es wie HTTPS-Traffic aussieht
  • Split Tunneling entlastet das Gateway, birgt aber Sicherheitsrisiken bei kompromittierten Geräten

Selbsttest

  1. Erklärt den Unterschied zwischen Tunnel- und Transportmodus bei IPsec. In welchem Szenario kommt welcher zum Einsatz?
  2. Warum ist WireGuard deutlich einfacher zu konfigurieren als IPsec, obwohl beide auf Netzwerkebene arbeiten?
  3. Ein Mitarbeiter nutzt Split Tunnel VPN im Homeoffice. Sein Laptop ist mit Malware infiziert. Warum ist das gefährlicher als ohne VPN?

Wie geht es weiter?

Ein VPN schützt den Transportweg – aber was ist mit den Nachrichten selbst? Block 13 zeigt euch, wie E-Mail-Verschlüsselung (S/MIME, PGP) dafür sorgt, dass eure Mails auch dann vertraulich bleiben, wenn sie nicht durch einen verschlüsselten Tunnel laufen.