VPN (IPsec, OpenVPN, WireGuard) #

1. Überblick #

VPNs gehören zu den wichtigsten Grundtechnologien moderner Netzwerke. Sie werden eingesetzt, um entfernte Standorte zu verbinden, mobile Mitarbeiter sicher auf Unternehmensressourcen zugreifen zu lassen, Verwaltungszugänge abzusichern oder Datenverkehr über unsichere Netze vertraulich zu transportieren. Der Begriff ist weit verbreitet, wird aber in der Praxis oft zu ungenau verwendet. Viele verstehen unter einem VPN lediglich „eine verschlüsselte Verbindung ins Firmennetz“ oder „einen Tunnel ins Internet“. Technisch ist das Thema deutlich umfassender.

Ein VPN schafft einen geschützten Kommunikationskanal über ein unsicheres oder nicht vollständig kontrollierbares Netzwerk, typischerweise das Internet. Dieser Kanal sorgt je nach Technologie dafür, dass Daten vertraulich übertragen, gegen Manipulation geschützt und die Kommunikationspartner gegenseitig authentifiziert werden. Das Ziel ist dabei nicht nur Sicherheit im engeren Sinn, sondern auch kontrollierte Erreichbarkeit: Systeme, Standorte oder Benutzer können logisch so miteinander kommunizieren, als befänden sie sich in einem gemeinsamen, vertrauenswürdigen Netz.

In der Praxis gibt es nicht „das eine VPN“, sondern unterschiedliche technische Ansätze. Besonders verbreitet sind:

• IPsec, ein auf IP-Ebene arbeitender Standard mit starker Einbindung in Netzwerkinfrastrukturen
• OpenVPN, eine flexible, TLS-basierte VPN-Lösung auf Benutzer- bzw. Anwendungsebene
• WireGuard, ein moderner, schlanker VPN-Ansatz mit Fokus auf Einfachheit, Geschwindigkeit und überschaubarem kryptographischem Design

Diese Technologien lösen ähnliche Grundprobleme, unterscheiden sich aber deutlich in Architektur, Konfiguration, Betriebsmodell, Fehlersuche und Einsatzszenarien.

Ein professionelles Verständnis von VPNs umfasst daher nicht nur die Frage, was ein VPN ist, sondern auch:

• warum VPNs überhaupt nötig sind,
• wie Tunneling technisch funktioniert,
• wie Authentifizierung, Verschlüsselung und Routing zusammenspielen,
• wo sich IPsec, OpenVPN und WireGuard unterscheiden,
• und welche Betriebsfehler in realen Umgebungen besonders häufig auftreten.

2. Definition und Zweck #

Ein VPN ist ein Virtual Private Network. Gemeint ist damit ein logisches, abgesichertes Kommunikationsnetz, das über ein physisch nicht exklusiv kontrolliertes Netzwerk aufgebaut wird. „Virtual“ bedeutet hier: Die private Verbindung ist nicht durch eine eigene physische Leitung realisiert, sondern durch einen logisch separierten, kryptographisch geschützten Kanal.

Warum gibt es VPNs? #

Früher wurden Standorte oder entfernte Benutzer oft über dedizierte Leitungen oder geschlossene Netzinfrastrukturen verbunden. Das war teuer, unflexibel und organisatorisch aufwendig. Mit der zunehmenden Verfügbarkeit des Internets entstand der Wunsch, Standardnetze als Transportmedium zu nutzen, ohne auf Vertraulichkeit und Kontrolle zu verzichten.

VPNs existieren daher, um zwei zentrale Probleme zu lösen:

1. Sichere Kommunikation über unsichere Transportnetze
2. Logische Netzkopplung über Distanz hinweg

Was ist der Zweck eines VPNs? #

Der konkrete Zweck hängt vom Szenario ab, typischerweise geht es aber um eine Kombination aus:

• Vertraulichkeit
  Daten sollen auf dem Übertragungsweg nicht mitgelesen werden können.
• Integrität
  Daten sollen nicht unbemerkt verändert werden können.
• Authentifizierung
  Die Kommunikationspartner sollen sicher feststellen können, mit wem sie sprechen.
• Erreichbarkeit
  Systeme oder Benutzer sollen definierte Netze oder Dienste sicher erreichen können.
• Netzlogik über Distanz
  Mehrere Standorte oder einzelne Clients sollen so verbunden werden, als lägen sie innerhalb einer kontrollierten logischen Topologie.

Wofür werden VPNs typischerweise eingesetzt? #

• Standortvernetzung zwischen Niederlassungen
• Remote Access für Mitarbeiter oder Administratoren
• sichere Verbindung von Cloud und On-Premises
• Wartung und Fernzugriff
• Schutz von Management-Traffic
• Absicherung von Datenverkehr in öffentlichen Netzen
• Zugriff auf interne Dienste, ohne diese direkt ins Internet zu exponieren

Wichtige Einordnung #

Ein VPN ist nicht automatisch anonym, nicht automatisch „das ganze Internet durch einen Tunnel“ und nicht automatisch sicher, nur weil Verschlüsselung verwendet wird. Die Sicherheit und der Nutzen hängen stark davon ab, wie Authentifizierung, Routing, Zugriffskontrolle, Schlüsselmanagement und Betriebsmodell umgesetzt sind.

3. Grundprinzip #

Das Grundprinzip eines VPNs lässt sich einfach beschreiben:

• Zwei Endpunkte bauen eine vertrauenswürdige Beziehung auf.
• Zwischen ihnen wird ein verschlüsselter und authentifizierter Tunnel etabliert.
• Nutzdaten werden nicht direkt über das unsichere Netz transportiert, sondern in diesem Tunnel gekapselt.
• Der Empfänger entkapselt die Daten wieder und verarbeitet das innere Paket oder den Nutzdatenstrom.

Vereinfachtes Denkmodell #

Man kann sich ein VPN wie einen gesicherten Rohrpostkanal durch ein öffentliches Gebäude vorstellen:

• Das öffentliche Gebäude ist das Internet.
• Die Rohrpostkapsel ist das äußere VPN-Paket.
• Die eigentliche Nachricht in der Kapsel ist das ursprüngliche Nutzpaket.
• Nur autorisierte Stationen können die Kapsel öffnen und die Nachricht lesen.

Was bedeutet „Tunneling“? #

Tunneling bedeutet, dass ein Protokoll oder ein Datenstrom innerhalb eines anderen Transportmechanismus übertragen wird.

Ein einfaches Bild:

[Originales Paket]
   wird verpackt in
[VPN-Tunnel-Paket]
   und über das Internet gesendet

Das äußere Paket enthält Informationen, die für die Übertragung zwischen den VPN-Endpunkten notwendig sind. Das innere Paket bleibt aus Sicht des Transportnetzes verborgen oder zumindest kryptographisch geschützt.

Was bedeutet „virtuell privat“? #

Die Verbindung ist nicht physisch privat, sondern logisch privat:

• Das Transportnetz wird gemeinsam mit vielen anderen genutzt.
• Die Abgrenzung entsteht durch Kryptographie, Tunnelmechanismen und Zugriffskontrolle.
• Privat ist also nicht das Medium, sondern die geschützte Kommunikationsbeziehung.

Typische VPN-Formen #

Site-to-Site-VPN #

Zwei Netze oder Standorte werden verbunden.

Beispiel:

• Hauptsitz ↔ Filiale
• Rechenzentrum ↔ Cloud-VPC

Remote-Access-VPN #

Ein einzelner Benutzer oder Client verbindet sich mit einem Netz oder Gateway.

Beispiel:

• Mitarbeiter im Homeoffice ↔ Firmennetz
• Administrator ↔ Management-Netz

Host-to-Host-VPN #

Zwei einzelne Systeme kommunizieren direkt per VPN.

Beispiel:

• Server A ↔ Server B über verschlüsselten IP-Tunnel

4. Technische Funktionsweise im Detail (Schritt für Schritt) #

Dieser Abschnitt ist besonders wichtig, weil VPNs oft zu abstrakt beschrieben werden. In der Praxis muss man verstehen, wie Tunnelaufbau, Authentifizierung, Schlüsselmanagement, Routing und Datentransport tatsächlich zusammenwirken.

4.1 Gemeinsame Grundlogik aller VPNs #

Ob IPsec, OpenVPN oder WireGuard: Die Grundlogik ist immer ähnlich.

1. Ein Endpunkt möchte geschützten Verkehr zu einem anderen Endpunkt senden.
2. Beide müssen sich gegenseitig identifizieren oder mindestens authentifizieren.
3. Sie handeln kryptographische Parameter aus oder verwenden zuvor definierte Schlüssel.
4. Es entsteht ein gesicherter Tunnel oder Transportkanal.
5. Nutzdaten werden gekapselt und verschlüsselt übertragen.
6. Der empfangende Endpunkt entschlüsselt, prüft und le-injiziert die Nutzdaten in sein lokales Netzwerk oder Interface-Modell.

Der große Unterschied liegt im Wie:

• Auf welcher OSI-Schicht arbeitet die Technik?
• Wie werden Schlüssel vereinbart?
• Wie werden Peers identifiziert?
• Wie wird Routing an den Tunnel gebunden?
• Wie komplex ist NAT-Traversal?
• Wie flexibel ist das Betriebsmodell?

4.2 Tunneling allgemein: inneres und äußeres Paket #

Ein VPN transportiert in der Regel ein inneres Paket durch ein äußeres Transportpaket.

Beispielhaftes Schema #

Äußeres Paket:
+---------------------------------------------------------+
| Internet-IP-Header | UDP/TCP oder ESP | VPN-Daten       |
+---------------------------------------------------------+Innere Nutzdaten:
+----------------------------------------------+
| Original-IP-Header | TCP/UDP | Anwendung     |
+----------------------------------------------+

Die äußere Hülle bringt das Paket von VPN-Endpunkt zu VPN-Endpunkt.
Die innere Struktur repräsentiert die eigentliche Kommunikation der Endsysteme.

Warum ist das wichtig? #

Weil dadurch zwei verschiedene Ebenen gleichzeitig existieren:

• Transportebene des VPNs
  Wie kommt der Tunnelverkehr überhaupt durch das Internet?
• Logische Nutzdatenebene
  Welche eigentliche Kommunikation soll durch den Tunnel laufen?

Viele Praxisprobleme entstehen genau an dieser Stelle, etwa durch:

• falsches Routing
• MTU-/MSS-Probleme
• NAT-Interaktionen
• unklare Trennung von Tunnelnetz und Nutznetz

4.3 IPsec: technische Funktionsweise Schritt für Schritt #

IPsec ist kein einzelnes Protokoll, sondern ein Protokoll-Framework zur Absicherung von IP-Kommunikation. Es arbeitet auf Netzwerkebene und ist besonders für Site-to-Site-Szenarien verbreitet.

4.3.1 Die Grundidee von IPsec #

IPsec schützt IP-Pakete direkt. Das ist ein großer konzeptioneller Unterschied zu OpenVPN und WireGuard, die häufig als eigenständige Tunnelinterfaces oder user-space-nahe Tunnel wahrgenommen werden.

IPsec kann im Wesentlichen in zwei Modi arbeiten:

• Transport Mode
  Nur der Nutzdatenanteil eines IP-Pakets wird geschützt; der äußere IP-Header bleibt der ursprüngliche.
• Tunnel Mode
  Das komplette ursprüngliche IP-Paket wird gekapselt und innerhalb eines neuen äußeren IP-Pakets transportiert.

Für klassische VPNs ist vor allem der Tunnel Mode relevant.

4.3.2 Wesentliche Bausteine von IPsec #

IPsec nutzt unter anderem:

• IKE / IKEv2 für Aushandlung und Schlüsselmanagement
• ESP (Encapsulating Security Payload) für Verschlüsselung und Integrität
• optional historisch AH (Authentication Header), heute im VPN-Alltag deutlich weniger relevant

4.3.3 Schritt-für-Schritt: Verbindungsaufbau mit IKEv2 #

Schritt 1: Peer-Erreichbarkeit #

Zwei Gateways oder ein Client und ein Gateway kennen sich über öffentliche IPs oder DNS-Namen und können sich grundsätzlich erreichen.

Schritt 2: IKE-Sicherheitsparameter aushandeln #

Die Gegenstellen handeln über IKEv2 aus:

• Schlüsselaustauschverfahren
• Authentifizierungsverfahren
• Verschlüsselungsalgorithmen
• Integritätsverfahren
• Lebensdauer der Security Associations

Schritt 3: Authentifizierung #

Die Peers authentifizieren sich, typischerweise mit:

• Pre-Shared Key (PSK)
• Zertifikaten
• EAP-basierten Verfahren bei Remote Access

Schritt 4: IKE-SA entsteht #

Es wird zunächst ein sicherer Kontrollkanal aufgebaut: die IKE Security Association.

Schritt 5: Child SAs für Nutzdaten #

Im nächsten Schritt werden die eigentlichen IPsec Security Associations für den Nutzverkehr erzeugt.

Diese definieren unter anderem:

• welche Netze geschützt werden
• welche Verschlüsselung genutzt wird
• welche SPI-Werte verwendet werden
• wie Verkehr ver- und entschlüsselt wird

Schritt 6: Tunnelbetrieb #

Nun werden passende IP-Pakete mit ESP geschützt und über das Transportnetz übertragen.

4.3.4 Vereinfacht dargestellter Ablauf #

Peer A                           Peer B
  |                                |
  |---- IKE_SA_INIT -------------> |
  |<--- IKE_SA_INIT -------------- |
  |                                |
  |---- IKE_AUTH ----------------> |
  |<--- IKE_AUTH ----------------- |
  |                                |
  |==== IKE-SA steht ============= |
  |                                |
  |---- CHILD_SA Aufbau ---------> |
  |<--- CHILD_SA bestätigt ------- |
  |                                |
  |==== IPsec-Tunnel aktiv ======= |
  |                                |
  |---- ESP-geschützte Daten ----> |

4.3.5 Ports und Protokolle bei IPsec #

Typisch relevant sind:

• UDP 500 für IKE
• UDP 4500 für NAT-T (NAT Traversal)
• ESP als IP-Protokoll 50 für die eigentlichen verschlüsselten Daten

Warum NAT-T? #

Weil NAT und IPsec in reiner Form historisch problematisch sein können. NAT-T kapselt IPsec-Nutzdaten zusätzlich in UDP, typischerweise auf Port 4500, damit sie NAT-freundlicher transportiert werden können.

4.4 OpenVPN: technische Funktionsweise Schritt für Schritt #

OpenVPN ist eine softwarebasierte VPN-Lösung, die typischerweise TLS nutzt und über UDP oder TCP transportiert werden kann. Es ist flexibel, plattformübergreifend und besonders verbreitet in Remote-Access- und kleineren bis mittleren Site-to-Site-Szenarien.

4.4.1 Grundidee von OpenVPN #

OpenVPN arbeitet nicht direkt als IPsec-Framework auf Netzwerkebene, sondern baut einen verschlüsselten Tunnel zwischen OpenVPN-Instanzen auf. Es nutzt dafür meist:

• TLS zur Authentifizierung und Aushandlung
• ein virtuelles Interface wie tun oder tap
• UDP oder TCP als Transport

TUN vs. TAP #

• TUN transportiert Layer-3-Verkehr, also IP-Pakete
• TAP transportiert Layer-2-Verkehr, also Ethernet-Frames

In der Praxis ist TUN häufiger, weil es effizienter und für klassische IP-basierte VPNs meist ausreichend ist.

4.4.2 Schritt-für-Schritt: OpenVPN-Tunnelaufbau #

Schritt 1: Client erreicht den Server #

Der OpenVPN-Client verbindet sich zur öffentlichen Adresse oder zum DNS-Namen des Servers, meist über UDP.

Schritt 2: TLS-Handshake #

Client und Server führen einen TLS-basierten Handshake durch. Dabei werden:

• Zertifikate geprüft
• die Gegenstelle authentifiziert
• Sitzungsschlüssel vereinbart

Schritt 3: Kontrollkanal steht #

Nach erfolgreichem TLS-Handshake existiert ein abgesicherter Kontrollkanal.

Schritt 4: Tunnelparameter werden gesetzt #

Der Server weist dem Client typischerweise Tunnelparameter zu:

• virtuelle IP-Adresse
• Routing-Informationen
• DNS-Optionen
• Kompressions- oder Policy-Details, sofern konfiguriert

Schritt 5: Datenkanal #

Der eigentliche Datenverkehr wird nun über das TUN/TAP-Interface aufgenommen, verschlüsselt und durch das äußere UDP- oder TCP-Transportprotokoll gesendet.

4.4.3 Vereinfachtes Schema #

OpenVPN-Client                       OpenVPN-Server
      |                                     |
      |----- UDP/TCP Verbindung ----------> |
      |<---- erreichbar ------------------- |
      |                                     |
      |----- TLS Handshake ----------------> |
      |<---- Zertifikat / TLS Antwort ----- |
      |                                     |
      |===== Kontrollkanal steht ========== |
      |                                     |
      |----- Tunnelparameter -------------- |
      |<---- virtuelle IP / Routes -------- |
      |                                     |
      |===== Datenkanal aktiv ============= |
      |                                     |
      |----- verschlüsselte Tunnelpakete -->|

4.4.4 Transport über UDP oder TCP #

OpenVPN kann über UDP oder TCP betrieben werden.

• UDP ist meist bevorzugt, weil es weniger Overhead und bessere Echtzeiteigenschaften bietet.
• TCP kann in restriktiven Netzumgebungen nützlich sein, birgt aber Nachteile, wenn im Tunnel selbst wieder TCP-Verkehr läuft. Das kann zu sogenannten TCP-over-TCP-Problemen führen.

4.4.5 Ports bei OpenVPN #

Standardmäßig wird häufig UDP 1194 genutzt, technisch sind aber auch andere Ports möglich.

4.5 WireGuard: technische Funktionsweise Schritt für Schritt #

WireGuard ist ein moderner VPN-Ansatz mit bewusst schlankem Design. Er setzt auf wenige, moderne kryptographische Primitive und eine im Vergleich zu klassischen Lösungen deutlich reduzierte Konfigurationslogik.

4.5.1 Grundidee von WireGuard #

WireGuard arbeitet mit:

• festen Schlüsselpaaren pro Peer
• klar definierten AllowedIPs
• UDP als Transport
• einem minimalistischen Protokoll mit Fokus auf Effizienz und Einfachheit

Es gibt keine klassische, umfangreiche IKE- oder TLS-Parameterwelt wie bei IPsec oder OpenVPN. Das ist eine bewusste Designentscheidung.

4.5.2 Schritt-für-Schritt: WireGuard-Verbindungslogik #

Schritt 1: Peer-Konfiguration #

Jeder Peer kennt:

• seinen eigenen privaten Schlüssel
• den öffentlichen Schlüssel der Gegenstelle
• Endpoint-Adresse der Gegenstelle, falls bekannt
• AllowedIPs, also welche inneren Zielnetze oder Adressen zu welchem Peer gehören

Schritt 2: Initiales Paket #

Sobald ein Peer Verkehr zu einem Ziel senden will, das zu den AllowedIPs eines Peers gehört, versucht WireGuard, die Verbindung zum Endpoint herzustellen.

Schritt 3: Kryptographischer Handshake #

WireGuard nutzt ein modernes Handshake-Protokoll, das auf dem Noise-Framework basiert. Dabei werden Sitzungsschlüssel abgeleitet und eine sichere Transportbeziehung aufgebaut.

Schritt 4: Datenübertragung #

Anschließend werden Tunnelpakete über UDP verschlüsselt übertragen.

Schritt 5: Zustandsaktualisierung #

WireGuard merkt sich die zuletzt beobachtete Quelladresse eines Peers. Das hilft bei NAT-Szenarien und roaming-artigem Verhalten.

4.5.3 AllowedIPs: Routing und Identität zugleich #

AllowedIPs sind bei WireGuard ein zentrales Konzept. Sie definieren:

• welche inneren Adressen oder Netze an einen Peer geschickt werden
• welche Quelladressen von diesem Peer akzeptiert werden

Das ist wichtig, weil WireGuard damit Routing- und Zugriffsfunktion eng verknüpft.

4.5.4 Vereinfachtes Schema #

Peer A                               Peer B
  |                                    |
  |--- UDP Paket / Handshake Init ---> |
  |<-- Handshake Response ------------ |
  |                                    |
  |=== Sitzungsschlüssel aktiv ======= |
  |                                    |
  |--- verschlüsselte Daten ---------->|
  |<-- verschlüsselte Daten ---------- |

4.5.5 Port bei WireGuard #

Standardmäßig wird häufig UDP 51820 verwendet, aber auch andere UDP-Ports sind möglich.

4.6 Routing im VPN-Kontext #

Ein VPN besteht nicht nur aus Verschlüsselung. Es muss auch klar sein, welcher Verkehr überhaupt in den Tunnel gehört.

Zwei zentrale Fragen #

1. Welche Ziele sollen über das VPN erreichbar sein?
2. Welche Ziele sollen nicht über das VPN gehen?

Split Tunnel #

Nur bestimmte Netze werden durch das VPN geleitet.

Beispiel:

• 10.0.0.0/8 über VPN
• restlicher Internetverkehr direkt lokal

Full Tunnel #

Der gesamte Verkehr, inklusive Standardroute, läuft durch das VPN.

Beispiel:

• 0.0.0.0/0 über VPN

Warum ist das wichtig? #

Weil sich daraus massive Auswirkungen ergeben auf:

• Sicherheit
• Bandbreite
• Internet-Breakout
• DNS-Verhalten
• Performance
• Unternehmensrichtlinien

4.7 MTU, Fragmentierung und Overhead #

VPNs erhöhen durch Kapselung fast immer die Größe eines Pakets.

Warum? #

Weil zusätzlich zu den ursprünglichen Nutzdaten weitere Header und kryptographische Metadaten hinzukommen.

Das kann zu Problemen führen bei:

• MTU-Überschreitungen
• Fragmentierung
• PMTU-Blackholes
• schlechter Performance
• „kleine Pings gehen, große Downloads brechen“

Praxisrelevanz #

Gerade bei IPsec und OpenVPN tauchen MTU-/MSS-Probleme häufig auf. WireGuard ist hier oft einfacher, aber nicht grundsätzlich immun.

5. Wichtige Bestandteile / Mechanismen / Konzepte #

5.1 Tunnel Mode und Transport Mode #

Transport Mode #

Nur Teile des Originalpakets werden geschützt. Das ist eher bei Host-to-Host-Schutz relevant.

Tunnel Mode #

Das gesamte innere IP-Paket wird gekapselt. Das ist der typische Modus für Site-to-Site- und viele Remote-Access-Szenarien.

Warum ist der Unterschied wichtig? #

Weil er bestimmt:

• wie das äußere Paket aussieht
• welche Header sichtbar bleiben
• wie Routing und Netzlogik aufgebaut werden

5.2 Authentifizierung #

Ein VPN muss die Identität der Gegenstellen absichern.

Typische Varianten:

• Pre-Shared Key (PSK)
  einfacher gemeinsamer geheimer Schlüssel
• Zertifikate
  besonders in größeren Umgebungen skalierbar und professionell
• Benutzername/Passwort plus TLS
  häufig bei OpenVPN-Remote-Access
• statische Public Keys
  zentral bei WireGuard
• EAP-basierte Verfahren
  häufig bei IPsec Remote Access

Warum ist Authentifizierung so wichtig? #

Weil Verschlüsselung allein nicht genügt.
Man muss auch sicher sein, mit wem man verschlüsselt kommuniziert.

5.3 Schlüsselmanagement #

Schlüssel müssen:

• sicher erzeugt
• sicher verteilt
• regelmäßig erneuert
• im Fehlerfall widerrufen oder ersetzt

werden.

Unterschiede in der Praxis #

• IPsec kann komplexe SA- und Rekey-Modelle nutzen
• OpenVPN arbeitet oft mit PKI und Zertifikatsverwaltung
• WireGuard setzt auf einfachere statische Schlüsselpaare, dafür mit weniger integrierter Verwaltungslogik

5.4 NAT Traversal #

Viele VPN-Endpunkte sitzen hinter NAT. Das ist in Heimnetzen, Cloud-Setups und Unternehmensumgebungen normal.

Herausforderungen #

• Der externe Endpunkt sieht nicht die echte interne IP.
• Protokolle, die empfindlich auf Header-Änderungen reagieren, brauchen Hilfsmechanismen.
• Idle-Verbindungen können durch NAT-Timeouts verschwinden.

Umsetzung je Technologie #

• IPsec nutzt typischerweise NAT-T über UDP 4500
• OpenVPN ist meist NAT-freundlich, weil es ohnehin auf UDP oder TCP basiert
• WireGuard arbeitet über UDP und kann mit Keepalives NAT-Mappings offenhalten

5.5 Rekeying und Lebensdauer #

Sichere Tunnel verwenden nicht dauerhaft denselben Sitzungsschlüssel. Stattdessen werden Schlüssel regelmäßig erneuert.

Warum? #

• Begrenzung der Datenmenge pro Schlüssel
• Verringerung kryptographischer Risiken
• Erhöhung der Langzeitsicherheit

IPsec ist hier traditionell sehr explizit mit SA-Lifetimes.
OpenVPN und WireGuard haben jeweils ihre eigene Logik zur Sitzungs- bzw. Schlüsselerneuerung.

5.6 Policies, SAs und Selektoren bei IPsec #

IPsec arbeitet stark mit:

• Policies: welcher Verkehr soll geschützt werden?
• Security Associations (SAs): mit welchen Parametern wird er geschützt?
• Selektoren: welche Quell-/Zielnetze gehören zu einer SA?

Warum ist das wichtig? #

Weil viele IPsec-Probleme nicht an der Verschlüsselung selbst scheitern, sondern an nicht passenden Traffic Selectors oder unklaren Policies.

5.7 Virtuelle Interfaces #

OpenVPN und WireGuard erzeugen typischerweise ein virtuelles Tunnelinterface, über das der Verkehr geroutet wird.

Beispiele:

• tun0
• wg0

Vorteil #

Das ist für viele Administratoren intuitiv:

• Interface hat Adresse
• Route zeigt auf Interface
• Verkehr geht darüber in den Tunnel

Bei IPsec ist diese Interface-Logik je nach Implementierung oft weniger direkt sichtbar oder herstellerspezifisch gelöst, auch wenn moderne Route-based-VPN-Modelle IPsec zunehmend interface-näher machen.

5.8 Route-based vs. Policy-based VPN #

Vor allem bei IPsec wichtig.

Policy-based #

Bestimmter Verkehr wird anhand von Regeln oder Selektoren automatisch verschlüsselt.

Route-based #

Ein Tunnelinterface oder virtuelles Interface dient als Routingziel, und der Verkehr wird über Routingtabellen in den Tunnel gelenkt.

Bedeutung #

Route-based-Modelle sind oft flexibler und besser mit modernem Routing, dynamischen Protokollen und komplexen Topologien vereinbar.

6. Einsatzgebiete in der Praxis #

Site-to-Site zwischen Standorten #

Ein Hauptsitz und mehrere Niederlassungen sollen logisch verbunden werden.

Typische Technologie:

• häufig IPsec
• manchmal OpenVPN
• zunehmend auch WireGuard in kleineren oder modernen Setups

Remote Access für Mitarbeiter #

Benutzer sollen von außen auf interne Dienste zugreifen.

Typische Technologie:

• OpenVPN
• IPsec/IKEv2
• WireGuard, wenn das Betriebsmodell passt

Cloud-Anbindung #

On-Premises und Cloud-Netze sollen sicher verbunden werden.

Typische Technologie:

• oft IPsec
• teils OpenVPN
• je nach Plattform auch WireGuard über eigene Gateways

Administrationszugänge #

Admins benötigen sicheren Zugriff auf Management-Netze, Hypervisoren oder Server.

Typische Technologie:

• oft OpenVPN oder WireGuard
• IPsec bei größeren Appliance- oder Enterprise-Umgebungen

Temporäre Projektvernetzung #

Externe Dienstleister oder Projektumgebungen sollen kontrolliert angebunden werden.

Hier ist wichtig:

• präzise Zugriffskontrolle
• sauberes Schlüsselmanagement
• kurze Gültigkeiten
• eindeutige Trennung der Tunnelzwecke

Schutz in unsicheren Netzen #

Beispiel:

• Mitarbeiter im Hotel-WLAN
• Techniker im öffentlichen Netz
• mobilen Zugang absichern

Wichtig:
Ein VPN schützt den Transport zum VPN-Endpunkt, nicht automatisch jede Anwendung oder jedes Ziel hinter diesem Endpunkt.

7. Mehrere ausführliche Praxisbeispiele #

Praxisbeispiel 1: Site-to-Site-IPsec zwischen Hauptsitz und Filiale #

Ausgangssituation #

Ein Unternehmen hat einen Hauptsitz mit dem Netz 10.0.0.0/16 und eine Filiale mit dem Netz 10.20.0.0/24. Beide Standorte sollen sicher über das Internet verbunden werden, damit Clients und Server gegenseitig erreichbar sind.

Ziel #

• sichere Kopplung der Standorte
• transparente Kommunikation zwischen beiden Netzen
• keine Freigabe interner Dienste ins öffentliche Internet

Ablauf #

1. Beide Firewall- oder VPN-Gateways erhalten öffentliche Erreichbarkeit.
2. IKEv2 wird konfiguriert, inklusive:
   • Peer-Adressen
   • Authentifizierung
   • Algorithmen
3. Es werden Traffic Selectors definiert:
   • Hauptsitz: 10.0.0.0/16
   • Filiale: 10.20.0.0/24
4. Nach dem IKE-Aufbau entstehen Child SAs für den Nutzverkehr.
5. Pakete zwischen diesen Netzen werden per ESP verschlüsselt durch das Internet transportiert.

Bedeutung #

Für Endsysteme wirkt es oft so, als wären beide Netze logisch direkt verbunden. Tatsächlich läuft der Verkehr aber durch einen abgesicherten Tunnel.

Lernpunkt #

Das VPN ist nur ein Teil der Lösung. Zusätzlich müssen Routing, Firewall-Regeln und ggf. DNS-Auflösung zwischen den Standorten sauber umgesetzt sein.

Praxisbeispiel 2: OpenVPN für Homeoffice-Mitarbeiter #

Ausgangssituation #

Ein Unternehmen möchte Mitarbeitern im Homeoffice Zugriff auf interne Ressourcen geben:

• Fileserver
• Intranet
• Ticketsystem
• interne DNS-Dienste

Ziel #

• sichere Benutzeranbindung
• möglichst einfache Client-Nutzung
• kontrollierter Zugriff auf definierte interne Netze

Ablauf #

1. Auf einem zentralen OpenVPN-Server wird eine PKI oder ein Zertifikatsmodell eingerichtet.
2. Jeder Benutzer erhält ein Client-Zertifikat oder ein Benutzerprofil.
3. Der OpenVPN-Client verbindet sich zum Server.
4. Nach TLS-Authentifizierung bekommt der Client:
   • eine Tunnel-IP
   • Routen zu internen Netzen
   • ggf. interne DNS-Server
5. Der Benutzer kann auf interne Dienste zugreifen.

Bedeutung #

Das Unternehmen muss interne Dienste nicht öffentlich zugänglich machen. Der Zugriff erfolgt kontrolliert über den VPN-Einstiegspunkt.

Lernpunkt #

OpenVPN eignet sich gut, wenn plattformübergreifender Client-Betrieb, TLS-basierte Authentifizierung und flexible Policy-Verteilung wichtig sind.

Praxisbeispiel 3: WireGuard für Administratorenzugriff auf ein Management-Netz #

Ausgangssituation #

Ein kleines Infrastrukturteam möchte Hypervisoren, Backup-Server und Switch-Management nur aus einem dedizierten Administrations-VPN zugänglich machen.

Ziel #

• schlanke, schnelle Lösung
• einfacher Betrieb
• geringe Angriffsfläche
• klar definierte Admin-Clients

Ablauf #

1. Auf einem Gateway wird ein WireGuard-Interface wg0 eingerichtet.
2. Jeder Admin erhält ein eigenes Schlüsselpaar.
3. Das Gateway kennt die öffentlichen Schlüssel aller Administratoren.
4. Über AllowedIPs wird jedem Peer eine feste Tunneladresse zugeordnet.
5. Firewall-Regeln erlauben von wg0 aus nur Management-Dienste wie SSH, HTTPS oder RDP.

Bedeutung #

Nur Clients mit passendem Schlüssel und korrekt konfigurierter Tunneladresse gelangen in das Management-Netz.

Lernpunkt #

WireGuard ist besonders stark, wenn Klarheit, Einfachheit und geringe Betriebsreibung wichtiger sind als hochkomplexe Enterprise-Features im Protokoll selbst.

Praxisbeispiel 4: Cloud-Anbindung eines Rechenzentrums an eine VPC #

Ausgangssituation #

Ein Unternehmen betreibt lokale Server, nutzt aber zusätzlich Cloud-Ressourcen. Die Netze sollen privat kommunizieren können, ohne dass Datenbank- oder Applikationsports öffentlich exponiert werden.

Ziel #

• sicheres Site-to-Site-VPN zwischen On-Premises und Cloud
• definierte Routen für Cloud-Subnetze
• Trennung zwischen produktivem und administrativem Verkehr

Typischer Ablauf #

1. Lokaler Gateway-Endpunkt und Cloud-VPN-Endpunkt werden konfiguriert.
2. Es werden lokale und entfernte Subnetze definiert.
3. Tunnel werden aufgebaut, oft redundant.
4. Routingtabellen auf beiden Seiten leiten Cloud-/On-Premises-Ziele in den Tunnel.
5. Sicherheitsgruppen bzw. Firewalls begrenzen die tatsächlich erlaubten Dienste.

Bedeutung #

Das VPN stellt Erreichbarkeit her, ersetzt aber nicht die segmentierte Sicherheitslogik innerhalb der Cloud oder des Rechenzentrums.

Lernpunkt #

Ein häufiger Fehler ist anzunehmen, dass ein Site-to-Site-VPN automatisch „vollständiges Vertrauen“ bedeuten soll. In der Praxis sollten nur benötigte Pfade geöffnet werden.

Praxisbeispiel 5: Full-Tunnel-VPN für mobile Mitarbeiter in öffentlichen Netzen #

Ausgangssituation #

Mitarbeiter arbeiten häufig unterwegs in Hotel-WLANs oder öffentlichen Hotspots. Das Unternehmen will den gesamten Internetverkehr dieser Geräte durch das eigene Sicherheitsgateway leiten.

Ziel #

• Schutz des gesamten Traffics im öffentlichen Netz
• zentrale Sicherheitskontrolle
• DNS und Webzugriffe über Unternehmensinfrastruktur

Ablauf #

1. Der Remote-Access-Client baut einen VPN-Tunnel zum Unternehmensgateway auf.
2. Der VPN-Server pusht eine Default-Route oder das Client-Profil setzt 0.0.0.0/0 in den Tunnel.
3. Nun geht nicht nur interner Verkehr, sondern auch Websurfen und DNS über das Unternehmensgateway.
4. Dort greifen Proxy, Logging, Filter oder Security Policies.

Bedeutung #

Im lokalen Hotel-WLAN ist der Verkehr bis zum Unternehmensgateway geschützt. Gleichzeitig kann das Unternehmen Internetzugriffe zentral kontrollieren.

Lernpunkt #

Full Tunnel erhöht Kontrolle, kann aber Bandbreite, Latenz und Gateway-Last deutlich steigern. Deshalb muss das Design bewusst gewählt werden.

8. Typische Probleme, Fehler und Missverständnisse #

8.1 „VPN bedeutet automatisch sicher“ #

Ein VPN ist nur so sicher wie:

• seine Authentifizierung
• sein Schlüsselmanagement
• seine Endgeräte
• seine Routing- und Firewall-Policies
• seine Betriebsprozesse

Ein schlecht verwalteter VPN-Zugang kann ein enormes Risiko sein.

8.2 Verschlüsselung ersetzt keine Zugriffskontrolle #

Ein Tunnel macht Kommunikation vertraulich, aber nicht automatisch angemessen eingeschränkt. Wenn ein Benutzer nach erfolgreichem VPN-Login unbeschränkt ins gesamte Netz darf, entsteht schnell ein Sicherheitsproblem.

8.3 Routing wird unterschätzt #

Viele VPN-Probleme sind keine Kryptographie-Probleme, sondern Routing- oder Policy-Probleme.

Typische Symptome:

• Tunnel steht, aber keine Erreichbarkeit
• Ping geht, Anwendung nicht
• nur eine Richtung funktioniert
• Internetverkehr läuft unerwartet durch den Tunnel

8.4 NAT und VPN werden falsch kombiniert #

Besonders bei IPsec können NAT-Szenarien zu Verwirrung führen:

• NAT vor oder nach dem Tunnel?
• stimmen die Selector?
• wird NAT-T verwendet?
• kollidieren gleiche interne Netze auf beiden Seiten?

8.5 Überlappende Netze #

Ein Klassiker im Site-to-Site-Betrieb:

• beide Seiten verwenden z. B. 192.168.1.0/24

Dann ist unklar, wohin Pakete gehören. Das führt zu Routing- und Selektorproblemen und ist ohne zusätzliche Maßnahmen sehr unpraktisch.

8.6 MTU-/MSS-Probleme #

Wenn VPN-Overhead nicht berücksichtigt wird, entstehen Symptome wie:

• Webseiten laden unvollständig
• große Transfers brechen ab
• manche Anwendungen funktionieren, andere nicht
• Verbindungen sind instabil

8.7 TCP über TCP bei OpenVPN #

Wenn OpenVPN über TCP läuft und im Tunnel wiederum TCP-Verkehr transportiert wird, kann das zu Performance- und Stauproblemen führen.

In den meisten Fällen ist UDP die bessere Wahl.

8.8 WireGuard wird als „magisch einfach“ missverstanden #

WireGuard ist konzeptionell schlanker, aber nicht automatisch narrensicher. Auch dort braucht man:

• sauberes Routing
• sinnvolle AllowedIPs
• korrektes Schlüsselmanagement
• geeignete Firewall-Regeln
• Verständnis für NAT- und Keepalive-Verhalten

8.9 IPsec wird als „immer kompliziert“ abgestempelt #

IPsec ist komplexer als WireGuard, aber auch sehr leistungsfähig und standardisiert. Besonders in Enterprise-Umgebungen und bei Herstellerinteroperabilität ist IPsec nach wie vor hochrelevant.

8.10 Full Tunnel wird mit „mehr Sicherheit“ gleichgesetzt #

Full Tunnel kann sinnvoll sein, ist aber nicht immer automatisch besser. Er erzeugt auch:

• mehr Last
• mehr Abhängigkeit vom zentralen Gateway
• potenziell schlechtere Benutzererfahrung
• höhere Anforderungen an zentrale Infrastruktur

9. Sicherheit / Risiken #

9.1 Sicherheitsziele eines VPNs #

Ein korrekt implementiertes VPN soll vor allem erreichen:

• Vertraulichkeit der übertragenen Daten
• Integrität der Kommunikation
• Authentizität der Peers
• Kontrollierte Erreichbarkeit definierter Netze und Dienste

Diese Ziele beziehen sich primär auf den Transportweg zwischen den VPN-Endpunkten.

9.2 Was ein VPN nicht schützt #

Ein VPN schützt nicht automatisch vor:

• kompromittierten Endgeräten
• Malware auf dem Client
• unsicheren Anwendungen hinter dem Tunnel
• falschen Berechtigungen im Zielnetz
• Identitätsmissbrauch nach erfolgreicher Anmeldung
• schlechter Segmentierung

Wenn ein infizierter Laptop per VPN ins interne Netz gelangt, kann der Tunnel sogar zum Risikoverstärker werden.

9.3 Risiko kompromittierter Schlüssel oder Zertifikate #

Wenn private Schlüssel, Zertifikate oder PSKs kompromittiert werden, kann ein Angreifer Tunnel aufbauen oder sich als legitimer Peer ausgeben.

Schutzmaßnahmen #

• starke Schlüssellängen und moderne Algorithmen
• sichere Speicherung privater Schlüssel
• Widerrufskonzepte
• Rotation
• getrennte Identitäten pro Benutzer oder Standort
• kein Teilen von Schlüsseln zwischen vielen Teilnehmern

9.4 Risiken durch zu breite Netzzugriffe #

Ein häufiger Fehler:
Ein erfolgreicher VPN-Login öffnet zu viele interne Netze.

Besser ist:

• Least Privilege
• nur notwendige Subnetze routen
• serverseitige Firewall-Regeln
• rollenbasierte Zuweisung

9.5 Risiken bei schwacher Authentifizierung #

Vor allem bei Remote Access sind problematisch:

• reine Passwortanmeldung ohne MFA
• geteilte Accounts
• gemeinsam genutzte Zertifikate
• schwache PSKs

Gerade bei Benutzerzugängen sollte starke Authentifizierung Standard sein.

9.6 Denial-of-Service und Erreichbarkeit #

VPN-Gateways sind zentrale Eintrittspunkte. Sie können Ziel sein von:

• Portscans
• Flooding
• Authentifizierungsangriffen
• Ressourcenerschöpfung

Deshalb wichtig:

• Rate-Limiting
• Monitoring
• saubere Internet-Exponierung
• ggf. vorgelagerte Schutzmaßnahmen

9.7 Best Practices #

Allgemein #

• nur notwendige Tunnel einrichten
• starke Authentifizierung verwenden
• moderne Kryptographie bevorzugen
• Schlüsselrotation etablieren
• Segmentierung trotz VPN beibehalten
• Logs und Monitoring nutzen
• Zugriffe regelmäßig überprüfen

Für Remote Access #

• MFA einführen
• Gerätehygiene und Posture-Prüfung erwägen
• Split/Full Tunnel bewusst wählen
• Benutzer- und Admin-Zugänge trennen

Für Site-to-Site #

• eindeutige Netze verwenden
• Policies sauber dokumentieren
• Redundanz planen
• Routing und Firewalling zusammen denken

10. Vergleich mit ähnlichen Technologien #

VPN vs. SSH-Tunnel #

Ein SSH-Tunnel schützt ebenfalls Verkehr, ist aber meist punktueller und hostbezogener.

SSH-Tunnel:

• gut für einzelne Dienste
• ideal für Admin- und Debug-Szenarien
• weniger geeignet als generische Standortkopplung

VPN:

• verbindet ganze Netze oder systematische Client-Zugriffe
• besser skalierbar für dauerhafte Netzlogik

VPN vs. MPLS / dedizierte Leitungen #

Dedizierte oder providerbasierte Netze bieten kontrollierte Transportwege, aber nicht automatisch Ende-zu-Ende-Verschlüsselung.

VPN:

• günstiger
• flexibel über das Internet
• kryptographisch abgesichert

Dedizierte Leitungen:

• oft stabiler und vorhersagbarer
• aber teurer und weniger flexibel

In der Praxis werden oft beide kombiniert.

VPN vs. Zero Trust Network Access (ZTNA) #

ZTNA verfolgt einen stärker identitäts- und applikationszentrierten Ansatz.

VPN:

• gibt oft Netzebene-Zugriff
• häufig subnetzbezogen

ZTNA:

• stärker an Benutzer, Gerät und Anwendung gebunden
• granularere Freigabe einzelner Dienste

VPNs bleiben dennoch relevant, besonders für:

• Site-to-Site
• Infrastrukturzugriffe
• klassische Remote-Netzzugänge

IPsec vs. OpenVPN vs. WireGuard #

Einordnung #

• IPsec ist stark standardisiert und in Enterprise- und Appliance-Umgebungen sehr wichtig.
• OpenVPN ist flexibel, plattformübergreifend und gut für benutzerorientierte VPN-Szenarien.
• WireGuard überzeugt durch Einfachheit, moderne Kryptographie und geringen Konfigurationsaufwand.

Die „beste“ Lösung hängt vom Einsatzzweck ab, nicht von einem generellen Ranking.

11. Praxis-Teil (Befehle, Tools, reale Anwendungsszenarien) #

Die konkrete Syntax variiert je nach Plattform und Distribution. Die folgenden Beispiele dienen dem Praxisverständnis und orientieren sich an verbreiteten Linux-Werkzeugen.

11.1 IPsec mit strongSwan: Status prüfen #

Viele Linux-IPsec-Installationen nutzen strongSwan.

Typische Statusabfragen:

ipsec status
ipsec statusall

Bedeutung #

Damit sieht man unter anderem:

• IKE-SAs
• Child-SAs
• Peer-Zustände
• verwendete Algorithmen
• Traffic-Selektoren

Praxisnutzen #

Diese Befehle sind zentral, wenn ein Tunnel zwar „irgendwie da“ wirkt, aber nicht klar ist, ob:

• der IKE-Kanal steht,
• die Child-SAs aktiv sind,
• oder nur ein Teil des Aufbaus erfolgreich war.

11.2 strongSwan: Logische Konfigurationsidee #

Je nach Version und Konfigurationsstil können Dateien variieren, aber typisch sind Definitionen wie:

• lokaler Endpoint
• entfernter Endpoint
• Authentifizierung
• lokale und entfernte Netze
• IKE-/ESP-Algorithmen

Beispielhaft vereinfacht gedacht:

conn standort-a-b
    left=203.0.113.10
    leftsubnet=10.0.0.0/16
    right=198.51.100.20
    rightsubnet=10.20.0.0/24
    ike=aes256-sha256-modp2048
    esp=aes256-sha256
    keyexchange=ikev2
    auto=start

Bedeutung #

Die zentrale Frage ist hier:
Welcher Verkehr zwischen welchen Netzen soll mit welchen Parametern geschützt werden?

11.3 OpenVPN: Client-Verbindung starten #

Typischer Aufruf unter Linux:

openvpn --config client.ovpn

Bedeutung #

Die Konfigurationsdatei enthält typischerweise:

• Serveradresse
• Zertifikate oder Referenzen darauf
• Transportprotokoll und Port
• Tunneloptionen
• Routen oder Pull-Verhalten

Praxisnutzen #

Das ist der klassische Einstieg für Test- und Fehleranalyse auf Client-Seite.

11.4 OpenVPN: Typische Status- und Diagnoseansätze #

Hilfreiche Elemente sind:

• Client-Logs
• Server-Logs
• Sicht auf das TUN-Interface
• Routenprüfung

Beispiele:

ip addr show
ip route
ss -ulpn
journalctl -xe

Was prüft man damit? #

• Wurde ein tun0 angelegt?
• Hat der Client eine Tunnel-IP bekommen?
• Wurden Routen gesetzt?
• Hört der Server auf dem erwarteten UDP-Port?
• Gibt es TLS- oder Zertifikatsfehler?

11.5 WireGuard: Schlüsselpaar erzeugen #

Ein typischer Workflow ist:

wg genkey | tee privatekey | wg pubkey > publickey

Ergebnis #

• privatekey enthält den privaten Schlüssel
• publickey enthält den öffentlichen Schlüssel

Wichtig #

Der private Schlüssel muss vertraulich behandelt werden.

11.6 WireGuard: Beispielkonfiguration auf Linux #

Ein typisches Interface wg0 könnte konzeptionell so aussehen:

[Interface]
Address = 10.100.0.1/24
ListenPort = 51820
PrivateKey = <server-private-key>[Peer]
PublicKey = <client-public-key>
AllowedIPs = 10.100.0.2/32

Auf Client-Seite entsprechend:

[Interface]
Address = 10.100.0.2/24
PrivateKey = <client-private-key>[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.0.0.0/16, 10.100.0.0/24
PersistentKeepalive = 25

Erklärung #

• Address definiert die Tunneladresse
• AllowedIPs steuert, welche Netze durch diesen Peer gehen
• PersistentKeepalive hilft bei NAT-Szenarien

11.7 WireGuard: Interface aktivieren #

Typisch unter Linux:

wg-quick up wg0
wg show
ip addr show wg0
ip route

Bedeutung #

• wg-quick up wg0 startet das Interface
• wg show zeigt Peer-Status, Handshakes und Traffic
• ip route zeigt, ob die gewünschten Netze auf wg0 geroutet werden

11.8 Praxis-Szenario: Split Tunnel bewusst konfigurieren #

Ziel #

Ein Mitarbeiter soll nur das interne Firmennetz 10.0.0.0/8 über das VPN erreichen, nicht aber den gesamten Internetverkehr.

Technische Logik #

• Route 10.0.0.0/8 in den Tunnel
• Standardroute bleibt lokal

Bedeutung #

Das entlastet das zentrale Gateway und reduziert unnötigen Tunnelverkehr.

Aber: #

Man muss dann bewusst prüfen:

• welche DNS-Server genutzt werden
• ob sensible Anwendungen außerhalb des Tunnels landen könnten
• ob Unternehmensrichtlinien Split Tunnel zulassen

11.9 Praxis-Szenario: Full Tunnel erzwingen #

Ziel #

Der gesamte Client-Verkehr soll durch das Unternehmensgateway laufen.

Logik #

Es wird die Standardroute in den Tunnel gesetzt, z. B. mit:

• 0.0.0.0/0
• und bei IPv6 zusätzlich ::/0

Bedeutung #

Das erhöht zentrale Kontrolle, erfordert aber:

• ausreichend Gateway-Kapazität
• DNS-Planung
• klare Egress-Policies
• gute Nutzerkommunikation bei Performanceänderungen

11.10 Typische Fehlersuche in der Praxis #

Wenn ein VPN „steht, aber nicht funktioniert“, sollte man strukturiert vorgehen.

Schritt 1: Ist der Tunnel wirklich aktiv? #

• Handshake erfolgreich?
• SA vorhanden?
• Tunnelinterface up?
• letzter erfolgreicher Peer-Kontakt?

Schritt 2: Stimmt das Routing? #

• zeigt die Route wirklich in den Tunnel?
• gibt es asymmetrische Rückwege?
• kollidieren lokale und entfernte Netze?

Schritt 3: Greifen Firewalls? #

• sind UDP/TCP-Transportports offen?
• ist ESP erlaubt, falls relevant?
• blockiert eine interne Segmentierungsfirewall den enttunnelten Verkehr?

Schritt 4: Stimmen Identität und Schlüssel? #

• Zertifikat gültig?
• PSK korrekt?
• WireGuard-Public-Key passend?
• falscher Peer oder falscher Endpoint?

Schritt 5: MTU/MSS prüfen #

Typische Symptome:

• kleiner Ping geht
• Anwendungen sind träge
• Downloads oder Webapps brechen ab

Nützliche Linux-Kommandos #

ip addr
ip route
ping
traceroute
ss -ulpn
wg show
ipsec statusall
journalctl -xe
tcpdump -ni any

Wofür ist tcpdump hilfreich? #

Damit kann man sehen:

• ob Tunnelpakete überhaupt ankommen
• ob Handshakes passieren
• ob innerer Verkehr gesendet wird
• ob Antwortverkehr zurückkommt

11.11 ASCII-Darstellung eines Site-to-Site-VPNs #

  Standort A                                 Standort B
+-------------+                           +-------------+
| LAN A       |                           | LAN B       |
| 10.0.0.0/16 |                           | 10.20.0.0/24|
+------+------+                           +------+------+
       |                                         |
       |                                         |
   +---+---+                                 +---+---+
   | VPN   |========= Internet ============= | VPN   |
   | GW A  |   verschlüsselter Tunnel        | GW B  |
   +-------+                                 +-------+

Bedeutung #

Die Endsysteme sehen typischerweise nur die Erreichbarkeit des jeweils anderen Netzes. Der eigentliche Transportweg durchs Internet wird durch die Gateways abgesichert.

11.12 ASCII-Darstellung eines Remote-Access-VPNs #

[Notebook]
    |
    |  öffentliches WLAN / Internet
    |
    v
+------------------+
| VPN-Gateway      |
| Firma / DC       |
+------------------+
    |
    +---- Intranet
    +---- Fileserver
    +---- DNS
    +---- Admin-Zugänge

Bedeutung #

Der mobile Client hat keinen direkten, ungeschützten Zugriff auf interne Dienste. Alles läuft kontrolliert über das VPN-Gateway.

12. Fazit #

VPNs sind ein zentraler Baustein moderner IT-Infrastrukturen, weil sie sichere Kommunikation und kontrollierte Erreichbarkeit über unsichere oder nicht exklusiv kontrollierte Netze ermöglichen. Ihr eigentlicher Wert liegt dabei nicht nur in der Verschlüsselung, sondern in der Kombination aus:

• Authentifizierung,
• Tunneling,
• Routing,
• Policy-Steuerung,
• und strukturiertem Zugriff auf entfernte Netze oder Dienste.

Wer VPNs wirklich verstehen will, muss deshalb mehr betrachten als nur den Tunnel selbst. Entscheidend ist, wie Identitäten geprüft werden, welche Netze über den Tunnel laufen, wie Schlüssel verwaltet werden, wie Firewalls den enttunnelten Verkehr behandeln und wie sich das gesamte Design in eine Sicherheitsarchitektur einfügt.

Die drei häufigsten Technologien haben jeweils klare Stärken:

• IPsec ist stark standardisiert, netznah und besonders wichtig für Enterprise- und Site-to-Site-Szenarien.
• OpenVPN ist flexibel, weit verbreitet und besonders gut für plattformübergreifenden Remote Access geeignet.
• WireGuard überzeugt durch modernes Design, geringe Komplexität und oft sehr guten Praxisnutzen bei überschaubaren, klar strukturierten Szenarien.

Die beste Lösung ist nicht die „modernste“ oder „traditionellste“, sondern diejenige, die technisch, organisatorisch und betrieblich zum Einsatzzweck passt.

Ein gutes VPN-Design ist daher nicht einfach „Tunnel an, Problem gelöst“, sondern eine bewusste Kombination aus Sicherheit, Erreichbarkeit, Segmentierung und nachvollziehbarer Betriebslogik.