February 26, 2026

VPN Dokumentation: Konfig, Topologie und Betriebsprozesse festhalten

Eine saubere VPN Dokumentation ist der Unterschied zwischen einem stabil betreibbaren Remote-Access- oder Site-to-Site-Setup und einem System, das nur „bei bestimmten Leuten“ funktioniert. In der Praxis ist VPN-Technik selten das Problem – es sind fehlende oder veraltete Informationen: Welche Tunnel existieren überhaupt? Welche Netze sind geroutet? Welche IKE-Parameter sind vereinbart? Wer ist Owner eines Partnerzugangs? Wo liegen die Zertifikate, wann laufen sie ab und wie wird widerrufen? Wie testen wir Failover, und was tun wir, wenn das VPN „up“ ist, aber der Zugriff nicht funktioniert? Ohne Dokumentation werden Änderungen riskant, Audits teuer und Troubleshooting langsam. Eine gute VPN-Dokumentation ist dabei nicht nur ein Konfig-Dump. Sie beschreibt Topologie, Sicherheitsmodell, Betriebsprozesse und Verantwortlichkeiten so, dass ein anderes Team (oder Ihr zukünftiges Ich) das System zuverlässig verstehen, ändern und wiederherstellen kann. Dieser Leitfaden zeigt, welche Inhalte in eine professionelle VPN-Dokumentation gehören, wie Sie Konfiguration, Topologie und Betriebsprozesse praxisnah strukturieren und welche „Must-haves“ Ihnen in Reviews, Incident Response und Compliance-Prüfungen regelmäßig Zeit sparen.

Table of Contents

Warum VPN-Dokumentation ein Security- und Betriebs-Thema ist

VPNs verbinden Netze, Rollen und Identitäten. Damit sind sie ein kritischer Bestandteil der Sicherheitsarchitektur: Ein falsches Routing kann ganze Subnetze exponieren, eine überbreite Policy ermöglicht laterale Bewegung, und ein abgelaufenes Gateway-Zertifikat kann Remote Work oder Standortvernetzung lahmlegen. Dokumentation macht diese Risiken sichtbar, steuerbar und auditierbar.

Sicherheit: Nachvollziehbarkeit von Zugriffspfaden, Rollen und Kontrollen (MFA, Segmentierung, Least Privilege).
Stabilität: Schnelleres Troubleshooting durch bekannte Abhängigkeiten (DNS, MTU, NAT-T, Routing).
Verfügbarkeit: Geplante Failover- und Recovery-Prozesse statt improvisierter Notfallaktionen.
Compliance: Nachweise für Reviews, Policies, Protokollierung und Change-Historie.

Als praxisnahe Orientierung für VPN-Controls eignet sich das Kompendium BSI IT-Grundschutz: NET.3.3 VPN. Es hilft, Dokumentationsinhalte an Sicherheitsanforderungen auszurichten.

Grundprinzipien: So wird Dokumentation nutzbar statt „Ablage“

Viele Dokus scheitern nicht am Inhalt, sondern an der Form. Diese Prinzipien machen VPN-Dokumentation praxistauglich:

Single Source of Truth: Eine definierte Stelle (Wiki/CMDB/Repo), nicht fünf unterschiedliche PDFs.
Versionierung: Änderungen sind nachvollziehbar (Changelog, Git, Tickets).
Owner und RACI: Wer pflegt was? Wer genehmigt? Wer wird informiert?
Standard-Templates: Gleiche Struktur für alle Tunnels/Standorte erleichtert Betrieb und Audits.
„Docs as Code“ wo möglich: Doku nah an Konfig/IaC, damit Updates nicht vergessen werden.
Security by Design: Keine Secrets in Klartext, keine PSKs in ungeschützten Dokumenten.

Dokumentationsstruktur: Drei Ebenen, die zusammengehören

Eine robuste VPN-Dokumentation lässt sich in drei Ebenen gliedern. Jede Ebene beantwortet andere Fragen:

Architektur & Topologie: Was ist aufgebaut, wie sind Standorte/Clouds verbunden, welche Zonen gibt es?
Konfiguration & Policies: Wie ist das VPN technisch eingestellt (IKE/IPsec/TLS), welche Routen, welche Zugriffskontrollen?
Betrieb & Prozesse: Wie wird das System betrieben (Monitoring, Changes, Incident Response, Zertifikate, Reviews)?

Wenn eine dieser Ebenen fehlt, entsteht entweder Wissenslücke (Betrieb kann nicht handeln) oder Audit-Lücke (Nachweise fehlen).

Teil 1: Topologie dokumentieren

Topologie ist die Landkarte. Sie muss nicht grafisch perfekt sein, aber eindeutig. In der Praxis bewähren sich zwei Darstellungen: ein High-Level-Architekturdiagramm und eine tabellarische Übersicht pro Tunnel/Standort.

High-Level-Architekturdiagramm: Was hinein gehört

Standorte/Regionen: Rechenzentrum, Filialen, Cloud-Regionen (VPC/VNet), Partnernetze.
VPN-Knoten: Gateways, Firewalls, Cloud VPN Gateways, Load Balancer, HA-Paare.
Zonen: VPN-Zone, Business-Zone, Dev/Test, Data-Zone, Management-Zone.
Verbindungstypen: Site-to-Site, Remote Access, Partnerzugang, Always-On, Hub-and-Spoke.
Abhängigkeiten: DNS-Resolver, IdP/SSO, PKI/CRL/OCSP, SIEM/Log-Collector.

Wichtig: Das Diagramm sollte eine Legende haben und eindeutig zeigen, was intern, extern und öffentlich exponiert ist.

Tunnel-Übersicht: Minimaldaten je Verbindung

Name/ID: eindeutiger Tunnelname, Ticket-/Change-Referenz
Endpunkte: öffentliche IPs, interne IPs, Interface/Zone
Typ: IPsec/IKEv2, SSL-VPN, WireGuard, Cloud VPN
Status: produktiv, staging, geplant, deaktiviert
Owner: Team, Kontakt, Eskalation
Zweck: z. B. Standortvernetzung, Adminzugang, Partnerzugang, Backup/DR

Teil 2: Konfiguration dokumentieren

Konfiguration ist mehr als „hier steht AES“. Sie ist die Kombination aus Kryptoparametern, Routing, Policies, DNS und Client-Profilen. Ziel ist, dass ein erfahrener Engineer den Tunnel reproduzieren oder sicher ändern kann.

Protokoll- und Kryptoparameter

Bei IPsec/IKEv2 ist es sinnvoll, Parameter strukturiert aufzuschreiben, weil Mismatches zu Handshake-Problemen führen. Grundlagen: RFC 7296 (IKEv2) und RFC 4301 (IPsec Architecture).

IKE-Version: IKEv2 bevorzugt, IKEv1 nur mit Begründung
Auth: Zertifikat oder PSK (inkl. Hinweis: PSKs nicht im Klartext in der Doku)
Encryption/Integrity: z. B. AES-GCM, Hash-Algorithmen
DH-Gruppen/PFS: aktiviert? welche Gruppen?
Lifetimes: IKE SA Lifetime, Child SA Lifetime, Rekey-Strategie
NAT-T: aktiviert? Ports (UDP/4500), Keepalives/DPD; Spezifikation: RFC 3947 und RFC 3948

Routing und Netzdefinitionen

Viele „VPN läuft, aber kein Zugriff“-Tickets entstehen durch Routing-Details. Dokumentieren Sie daher konsequent:

Local/Remote Subnets: alle gerouteten Prefixes, inklusive Ausnahmen
Route-Source: statische Routen, BGP, Policy-Based Routing
Split Tunnel Regeln: welche Ziele laufen durch den Tunnel, welche lokal?
Asymmetrisches Routing: bekannte Risiken, erwartete Rückwege, Statefulness
IP-Overlaps: bekannte Überschneidungen (RFC 1918) und gewählte Strategie (Renumbering/NAT); RFC 1918

DNS und Namensauflösung

DNS ist ein häufiger „Hidden Dependency“. Ohne saubere Doku ist Split-DNS schwer zu betreiben. DNS-Grundlagen: RFC 1034 und RFC 1035.

DNS-Server: welche Resolver werden gepusht, welche Zonen werden intern aufgelöst?
Split-DNS Regeln: interne Domains vs. externe Domains
Search Suffix: falls genutzt, inklusive Risiken (falsche Auflösung)
DoH/DoT Governance: wenn relevant, wie wird Umgehung verhindert oder akzeptiert?

MTU/MSS und Performance-Parameter

VPN-Encapsulation reduziert die effektive MTU. Ohne dokumentierte MTU/MSS-Strategie entstehen Blackholes. PMTUD: RFC 1191 und RFC 8201.

Tunnel MTU: konfiguriert oder Default
MSS Clamping: aktiv? wo? für welche Flows?
QoS: Klassifizierung/Markierung, Priorisierung kritischer Anwendungen (VoIP/VDI)

Firewall-Policies und Zugriffskontrolle

Dokumentieren Sie Policies so, dass Least Privilege nachvollziehbar ist:

Zone-to-Zone Regeln: VPN-Zone → Business-Zone, VPN-Zone → Management-Zone
Ports/Protokolle: erlaubte Services, verbotene Protokolle (z. B. SMB für Standardnutzer)
Adminzugänge: Bastion/Jump Host, separate Admin-Profile, Step-up MFA
Partnerzugänge: zeitliche Begrenzung, Scope, Audit-Logging

Client-Profile und Plattformdetails

Remote Access VPN ist oft plattformspezifisch. Dokumentieren Sie daher je Clienttyp:

Profile: Name, Verteilung (MDM/GPO), Parameter (Full/Split, DNS, Routes)
Auth: SSO/MFA, Zertifikate, erforderliche Clientversion
Always-On: Trigger, Reauth-Intervalle, Verhalten bei Netzwechsel
Supportgrenzen: unterstützte OS-Versionen, bekannte Inkompatibilitäten

Teil 3: Betriebsprozesse festhalten

Ohne Betriebsdoku wird VPN-Betrieb zur „Personenabhängigkeit“. Der wichtigste Teil ist daher nicht die Technik, sondern das „Wie arbeiten wir damit?“. Diese Prozesse sollten klar beschrieben sein.

Change Management und Versionierung

Change-Kategorien: Standard Change (z. B. neue Usergruppe), Normal Change (Policy-Änderung), Emergency Change (kritischer Fix)
Review: Peer Review der Änderungen, Security-Review bei sensiblen Zonen
Rollback: definierter Rückweg (Konfig-Backup, previous known good)
Dokumentationspflicht: welche Felder müssen pro Change aktualisiert werden?

Ein praxistauglicher Ansatz ist, Konfig-Auszüge und Doku in einem Repository zu versionieren, während Secrets separat in einem Vault liegen.

Monitoring und Alerting

Dokumentieren Sie, was überwacht wird, wo die Daten landen und wer reagiert:

Verfügbarkeit: Tunnel up/down, Flap-Rate, DPD-Timeouts, HA-Failovers
Kapazität: CPU/Crypto, Memory, Interface Drops, NAT/conntrack
Security: Login-Fails, MFA-Fails, ungewöhnliche Datenmengen, Admin-Changes
Zertifikate: Ablaufdaten (30/14/7 Tage), Erneuerungsstatus, Revocation-Health

Logging, Retention und SIEM-Integration

Eine gute VPN-Doku beschreibt nicht nur „Logs existieren“, sondern welche Events wichtig sind und wie lange sie aufbewahrt werden:

Auth-Logs: Erfolg/Fehlschlag, MFA-Status, Rolle/Profil
Session-Logs: Connect/Disconnect, Sessiondauer, zugewiesene VPN-IP
Policy-Logs: Denies/Allows mit Regelbezug
Admin-Logs: Konfigänderungen (wer/was/wann), idealerweise mit Ticketbezug
Retention: getrennte Aufbewahrung für Detail-Logs vs. Audit-Trails (begründet, dokumentiert)

Onboarding, Offboarding und Access Reviews

Benutzerverwaltung ist ein Betriebsprozess. Dokumentieren Sie Joiner/Mover/Leaver und externe Zugänge:

Onboarding: Voraussetzungen (MFA, Device Compliance), Rollen, Profilzuweisung
Offboarding: Account deaktivieren, Sessions terminieren, Zertifikate widerrufen (falls genutzt)
Rezertifizierung: regelmäßige Reviews von Gruppenmitgliedschaften, insbesondere Admins und Externe
Ausnahmen: Ablaufdatum, Owner-Prinzip, Review vor Verlängerung

Schlüssel- und Zertifikatsprozesse

Viele Ausfälle entstehen durch fehlende oder nicht gelebte Zertifikatsprozesse. Halten Sie fest:

PKI-Chain: Root/Intermediate, Trust Stores, Zuständigkeiten
Rotation: Laufzeiten, Renewal Windows, Automatisierung (MDM/EST/ACME), Notfallplan
Widerruf: CRL/OCSP, Testverfahren, Monitoring

Grundlagen für X.509: RFC 5280. Für automatisiertes Zertifikatsmanagement (TLS) ist RFC 8555 (ACME) relevant.

Incident Response und Troubleshooting-Runbooks

Dokumentation ist am wertvollsten, wenn es brennt. Ein gutes VPN-Runbook beantwortet: „Was prüfen wir in welcher Reihenfolge?“

Runbook-Inhalte für typische Vorfälle

VPN-Verbindung kommt nicht zustande: DNS/IdP erreichbar? Zertifikat gültig? Ports offen? Auth-Logs?
VPN läuft, aber kein Zugriff: Routen, Firewall-Policies, asymmetrisches Routing, NAT, Split Tunnel
Abbrüche/Flaps: DPD/Keepalive, NAT-T, ISP-Probleme, Rekey-Fehler, MTU
Performance-Probleme: Gateway-CPU, Drops, MTU/MSS, QoS, Backhaul
Security-Incident: Account sperren, Sessions killen, Keys/Zertifikate widerrufen, Log-Sammlung, Scope-Analyse

Ergänzend ist es sinnvoll, bekannte Tools zu dokumentieren (mtr, iperf3, tcpdump/Wireshark) und zu definieren, welche Mindestdaten ein Ticket enthalten muss (Client OS, Zeitfenster, Zielsystem, Logauszug, IPs).

Dokumentations-Template: Felder, die sich bewährt haben

Wenn Sie eine standardisierte Vorlage pro Tunnel/Profil nutzen, sparen Sie später sehr viel Zeit. Ein praxistaugliches Template umfasst:

Metadaten: Name, Zweck, Owner, Kritikalität, Status, Change-Historie
Endpunkte: IPs, Interfaces, Zonen, Provider/Region
Netze: Local/Remote Prefixes, Routingmethode, Split/Full Tunnel
DNS: Resolver, Split-DNS, Search Suffix
Krypto: IKE-Version, Auth, Cipher Suites, PFS, Lifetimes, NAT-T
Policies: erlaubte Ports/Services, Adminzugänge, Bastion, Deny-Default
Clients: unterstützte Plattformen, Profilverteilung, Mindestversionen
Monitoring: KPIs, Alerts, Dashboard-Link (ohne interne Referenzen im Text)
Runbooks: Troubleshooting-Pfade, Notfallplan, Failover-Prozedur

Typische Dokumentationsfehler und wie Sie sie vermeiden

Konfig-Dumps ohne Kontext: Ergänzen Sie immer Zweck, Owner und Datenflüsse.
Secrets in Klartext: PSKs, private Keys und Tokens gehören in einen Secret Store, nicht in die Doku.
Keine Aktualisierungspflicht bei Changes: Legen Sie fest, welche Dokumente bei welchem Change zwingend angepasst werden.
Keine HA-/Failover-Doku: Viele Ausfälle passieren beim Failover; dokumentieren und testen Sie es.
Fehlende Abhängigkeiten: DNS, IdP, PKI, CRL/OCSP, Proxy – alles muss sichtbar sein.

Outbound-Links zur Vertiefung

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Netzwerkdesign & Topologie-Planung
Router- & Switch-Konfiguration (Cisco IOS)
VLAN, Inter-VLAN Routing
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
NAT, ACL, DHCP, DNS-Konfiguration
Troubleshooting & Netzwerkoptimierung
Packet Tracer Projektentwicklung & Dokumentation
CCNA Lern- & Praxisunterstützung

Lieferumfang:

Konfigurationsdateien
Packet-Tracer-Dateien (.pkt)
Netzwerkdokumentation
Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.