Site-to-Site VPN für Niederlassungen: IPSec vs WireGuard vs IKEv2 unter russischen Bedingungen

Einleitung: Warum das Thema wichtig ist und was Sie lernen werden

Site-to-Site VPN ist 2026 zur Basis jeder Unternehmensnetzwerkstruktur geworden. Büros, Rechenzentren, Clouds und entfernte Standorte benötigen geschützte Verbindungen über das unvorhersehbare Internet und die L3-Infrastrukturen der Provider. Warum ist das gerade in Russland besonders relevant? Aufgrund der volatilen Routing-Situation, periodischer Filterungen und DPI, der Heterogenität der Anbieter, der Notwendigkeit zur Importsubstitution sowie wachsender Anforderungen an den Schutz personenbezogener Daten und Geschäftsgeheimnisse. Dieses Handbuch vergleicht drei praxisbewährte S2S-Ansätze: IPSec, WireGuard und IKEv2 (als IKEv2+IPSec-Stack) mit Fokus auf die Praxis: Architektur, Kryptoprofile, Hochverfügbarkeit, Performance, Betrieb, typische Fehler und reale Fälle.

Was Sie erwartet: klare Kriterien zur Protokollwahl passend zu Ihrer Topologie und den regulatorischen Vorgaben, Schritt-für-Schritt-Anleitungen zur Einrichtung, Checklisten für Audits, Empfehlungen zu MTU, NAT-T, BGP über VPN sowie ein TCO-Rahmenwerk und Risikobewertungen. Wir vermeiden bewusst akademische Theorie und konzentrieren uns auf das, was in den russischen Bedingungen jetzt funktioniert.

Grundlagen: fundamentale Konzepte (für Einsteiger)

Was ist Site-to-Site VPN

Site-to-Site VPN verbindet zwei oder mehr Netzwerke auf IP-Ebene, sodass Hosts in Niederlassung A auf Ressourcen in Niederlassung B zugreifen können, als stünden sie im selben lokalen Netzwerk oder über ein geroutetes Backbone. Der Tunnel kapselt und verschlüsselt Pakete über das öffentliche Internet oder einen L3-Kanal.

Schlüsselelemente

• Transport: UDP oder TCP über IP. IPSec nutzt ESP und häufig UDP 500/4500 (NAT-T). WireGuard verwendet UDP (standardmäßig 51820, aber konfigurierbar).
• Kryptografie: Verschlüsselungssuiten, Authentifizierung, PFS, KDF. Fokus auf AEAD (AES-GCM, ChaCha20-Poly1305) für Performance und Einfachheit.
• Schlüsselmanagement: IKEv2 für IPSec, bei WireGuard statische Schlüssel oder Managementsysteme, periodische Rotation im Protokoll.
• Routing: statische Routen oder dynamische Protokolle (BGP, OSPF) im Tunnel.
• Zuverlässigkeit: DPD, Keepalive, SLA-Monitoring, Backup-Verbindungen, HA-Cluster.

Was sind IPSec, WireGuard, IKEv2

• IPSec: Netzwerk-Protokoll-Stack (ESP/AH) mit Verschlüsselung und Authentifizierung. Flexibel, etabliert, wird von den meisten Routern und Firewalls unterstützt. Üblicherweise via IKEv2 verwaltet.
• WireGuard: modernes VPN-Protokoll basierend auf dem Noise-Protokollset (NoiseIK), arbeitet ausschließlich über UDP, minimalistisch, schnell und einfach konfigurierbar.
• IKEv2: Protokoll zur Schlüsselaushandlung und Sicherheitsparameter für IPSec. Im Unternehmenskontext steht „IKEv2“ meist für „IPSec mit IKEv2“.

Russische Besonderheiten

• DPI und unstabile Routen: UDP-Traffic kann zeitweise einbrechen; wichtig sind Backup-Lösungen, flexible NAT-T-Parameter und Fallback-Kanäle.
• Regulierung: Schutz von personenbezogenen Daten (PDS) und kritischer Infrastruktur (KII) erfordert technische und organisatorische Maßnahmen; zertifizierte Lösungen oder GOST-Kryptografie sind manchmal notwendig.
• Importsubstitution: Open-Source-Lösungen (StrongSwan, VyOS, FRR) und russische Anbieter werden immer häufiger gewählt und sorgen durch Standardprotokolle für Kompatibilität.

Deep Dive: Fortgeschrittene Themen

Sicherheit: Kryptoprofile und Schlüsselrotation

• IPSec/IKEv2: Empfohlene Chiffren für 2026 – AES-GCM-128/256 mit PFS (DH Gruppe 14 oder 19+), Authentifizierung per Zertifikat (RSA-3072 oder ECDSA P-256/P-384). Lebensdauer: IKE SA 8–24 h, Child SA 1–4 h; rechtzeitiges Rekeying.
• WireGuard: ChaCha20-Poly1305, Curve25519, HKDF; Schlüsselrotation per Protokoll-Timer und Betriebsrichtlinien; Speicherung privater Schlüssel in HSM oder sicheren Umgebungen.

Performance und Latenz

• Verzögerungen: IPSec ESP auf Hardware mit AES-NI bietet vorhersehbare Latenzen; WireGuard punktet bei kleinen Paketen und hoher Thread-Konkurrenz durch schlanken Stack.
• Overhead: IPSec ESP verursacht 50–80 Bytes Overhead pro Paket (je nach Konfiguration), WireGuard 32–60 Bytes. Das beeinflusst MTU und MSS Clamp-Bedarf.
• Durchsatz: Auf x86 mit AES-NI ist ein Kern für 1–3 Gbit/s IPSec AES-GCM optimiert; WireGuard schneidet dort oft mit 2–4 Gbit/s ab. Ausdrucksstark abhängig von NIC-Offload, IRQ Pinning und NUMA.

Zuverlässigkeit und Hochverfügbarkeit

• DPD/Keepalive: IPSec empfiehlt DPD alle 10–15 Sekunden, 3–5 Wiederholungen; bei WireGuard persistent Keepalive 15–25 Sekunden bei NAT.
• Redundanz: Zwei eigenständige Provider pro Standort, mehrere Tunnel (Active-Active mit ECMP oder Active-Standby), VRRP/Keepalived an Edge-Knoten, BGP im Tunnel.
• DPI/Blockaden: Bevorzugt UDP, bei Blockade-Risiken parallele Profile (SSTP oder TCP-Obfuskation) für Notfallzugriff auf kritische Services.

Netzwerkdesign

• Full-Tunnel vs Split-Tunnel: Bei Niederlassungen meist Split-Tunnel: Nur Unternehmenspräfixe über VPN, Internetverkehr lokal, um Bandbreite zu sparen.
• Adressraum: Vermeiden Sie Überschneidungen von RFC1918-Adressen zwischen Standorten; planen Sie /24 oder /23-Blöcke pro Standort und reservieren Sie IPs für Verwaltungsservices.
• Dynamisches Routing: BGP mit MED/LocalPref zur Auswahl der besten Verbindung, OSPF für abgeschirmte Perimeter; vermeiden Sie komplexe Redistribute zwischen VRFs.

Praxis 1: Site-to-Site-Architekturen für verschiedene Anforderungen

Architektur A: Hub-and-Spoke

Ein zentraler Hub (Rechenzentrum oder Cloud) verbindet dutzende Niederlassungen. Vorteile: vereinfachte Kontrolle, einheitlicher Sicherheits-Punkt, ganzheitliche Analyse. Nachteile: SPOF-Risiko, Last auf Kern, schwierige Skalierbarkeit ohne ECMP/Cluster.

• IPSec/IKEv2: ausgereifte Lösung mit StrongSwan/VyOS oder Hardware-Gateways. Empfohlen: BGP pro Spoke, Ankündigung von Niederlassungspräfixen über zwei unabhängige Tunnel zum Hub.
• WireGuard: Einfachere Automatisierung bei vielen Spokes dank übersichtlicher Konfigurationen und Templates. Schlüsselkontrolle und CMDB-Inventarisierung sind Pflicht.

Architektur B: Partielles Mesh

Kritische Niederlassungen sind zusätzlich zum Hub direkt verbunden. Vorteile: kürzere Pfade, weniger Latenz. Nachteile: Anzahl der Tunnel wächst quadratisch, erfordert Auto-Orchestrierung.

Architektur C: Dual-Hub Active-Active

Zwei Hubs an unterschiedlichen Standorten, ECMP oder BGP Multipath, Session-Balancing. Besonderheit: symmetrisches Routing oder Session Stickiness. IPSec mit separaten SAs pro Pfad; WireGuard mit mehreren Peers und Prioritäten.

Protokollwahl nach Kontext

• Maximale Kompatibilität zu Hardware: IPSec/IKEv2.
• Einfachheit und Geschwindigkeit: WireGuard.
• Zertifizierungsanforderungen: IPSec mit bewährten Stacks oder spezialisierte GOST-VPN-Lösungen.

Checkliste Architektur

• Zwei unabhängige Provider für Hub und kritische Standorte.
• MTU-Plan: 1400–1420 für VPN-Interface, MSS Clamp 1360–1380.
• BGP im VPN, Präfixfilter, Blockierung von „0/0“ aus Niederlassungen.
• Backup-Verwaltung: OOB oder LTE-Modem mit Notfalltunnel.

Praxis 2: IPSec/IKEv2 – Theorie, Schritt-für-Schritt-Konfiguration, Optimierung

Kryptoprofil

• Phase 1 (IKEv2): AES-GCM-256, PRF SHA-256, DH Gruppe 19 (ECDH P-256), Lifetime 8h, Reauth aktiviert.
• Phase 2 (Child SA): AES-GCM-256, PFS Gruppe 19, Lifetime 1–2h, Replay-Fenster 64–128.
• Authentifizierung: X.509-Zertifikate, CRL/OCSP oder kurze Gültigkeit (90–180 Tage) mit automatischer Rotation.

Schritt-für-Schritt-Anleitung (universelle Logik)

1. Adressierung vorbereiten: lokale und entfernte Netze festlegen, Überschneidungen vermeiden. NAT-Ausnahmen planen.
2. PKI: internen CA aufsetzen, Zertifikate für Gateways ausstellen, Key Usage und SAN mit FQDN/IP konfigurieren.
3. IKE-Parameter: Chiffren, Lifetimes, DPD 10s definieren. Bei CG-NAT im Filialprovider NAT-T aktivieren.
4. IPSec-Parameter: ESP im Transport- oder Tunnelmodus (meist Tunnel), PFS aktivieren, Rekey rechtzeitig (z.B. 10% vor Ablauf).
5. Routing: statische Routen initial, später BGP mit Peering via Tunneladressen einführen.
6. MTU/MSS: MTU auf 1400 setzen, MSS Clamp 1360 für TCP im LAN-Interface aktivieren.
7. Monitoring: Metriken an Prometheus/Influx exportieren, Alerts bei SA-Ausfällen oder erhöhter Paketwiederholung.

Feintuning für russische Netzwerke

• Aggressives NAT-T: bei wechselndem NAT und verlorenen Keepalives DPD-Frequenz erhöhen, Rekey-Intervalle verkürzen.
• Port-Duplikation: alternative UDP-Ports bei DPI-Profilen; manche Geräte erlauben unübliche Ports.
• Failover: zwei parallele Tunnel zu unterschiedlichen Hub-IP-Adressen, ECMP oder SLA-gesteuerte Priorität.

Implementierungsframework IPSec

• Pilotierung mit 1–3 Niederlassungen, Last bis 200 Mbit/s, Metrik-Erfassung.
• MTU/MSS/Fragmentierung auditieren und anpassen.
• BGP aktivieren, statische Routen wo möglich aufgeben.
• Sicherheitslogprotokollierung einschalten, Incident Tests (Link-Ausfall, Schlüssel-Komprimittierung, CA-Rotation) durchführen.

Praxis 3: WireGuard – schneller Start, Betrieb, Sicherheit

Warum WireGuard

Stabil über UDP, minimalistischer Code, hohe Geschwindigkeit, einfache Konfiguration. Ideal für Großrollouts in Niederlassungen mit Linux/RouterOS/VyOS sowie x86-Gateways.

Schritt-für-Schritt-Anleitung

1. Schlüssel: Erstellen Sie Schlüsselpaaren für jeden Knoten. Private Keys zentral mit Zugriffskontrolle speichern.
2. Interface: Legen Sie das Interface wg0 mit Adressen aus einem separaten Tunnelnetz (z.B. 10.10.0.0/24) an.
3. Peers: Im Hub alle Niederlassungen als Peers eintragen, in den Niederlassungen den Hub, erlaubte Präfixe auf nötige Subnets einschränken.
4. Keepalive: Aktivieren Sie persistent keepalive 20–25 Sekunden, besonders bei NAT-Umgebungen.
5. Routen: Statische oder BGP-Routen über FRR auf dem wg-Interface konfigurieren.
6. MTU/MSS: Startwerte MTU 1420, MSS Clamp 1380.

WireGuard-Sicherheit

• Schlüsselmanagement: CMDB zur Inventarisierung, Rotationspläne (alle 90–180 Tage), und Rückruf bei Vorfällen.
• Minimale Zugriffsrechte: AllowedIPs auf reale Subnetze begrenzen, ohne 0.0.0.0/0, sofern kein Full-Tunnel benötigt wird.
• Filterung: Systemfirewall auf eingehendes UDP am WG-Port begrenzen, Whitelists für Quellen wenn möglich.

Performanceoptimierung

• CPU Pinning für NIC-Interrupts und WireGuard Threads auf NUMA-lokale Kerne.
• GRO/LRO, RPS/RFS Einstellungen unter Linux; Überwachung von Drops mit ethtool -S.
• Parallele Tunnel für hohe Bandbreiten, ECMP auf Routing-Ebene.

WireGuard Checkliste

• UDP-Verkehr auf dem gewählten Port von beiden Seiten erreichbar.
• Persistent Keepalive gesetzt bei NAT-Knoten.
• MTU 1420 und MSS Clamp 1380 per Traceroute und Tests validiert.
• Logs und Metriken (wg show, Prometheus-Export) erfasst.

Praxis 4: IKEv2 im Enterprise – Zertifikate, MDM, hybride Szenarien

Warum IKEv2

Standardisiert, wird von Hardware- und Software-Gateways gut unterstützt, eignet sich für gemischte Umgebungen (Windows, iOS, Android, Linux). Im S2S meist IPSec mit IKEv2, aber in hybriden Unternehmen kann dieselbe PKI S2S und Mitarbeiterzugang bedienen.

Schrittweises Vorgehen

1. PKI und Richtlinien: Zertifikatvorlagen für Gateways erstellen, Extended Key Usage für IPsec IKE einschließen.
2. IKE-Profile: Chiffren und DH-Gruppen definieren; MOBIKE aktivieren bei mobilen Anwendungsszenarien.
3. Rollen trennen: S2S-Zertifikate getrennt von User-VPN-Zertifikaten; strikte Rotation und Audit.
4. MDM-Integration: IKEv2-Profile für Clients publizieren bei Bedarf hybrider Remote-Zugänge.

Praxis-Tipps

• CRL/OCSP: Bei OCSP-Ausfällen auf kurzlebige Zertifikate setzen; CRL lokal vorhalten.
• Skalierung: Einzelnen CA für alle Segmente vermeiden; auf Intermediate CAs nach Perimeter aufteilen.

Praxis 5: NAT, MTU, DPI – wie man Paketverlust vermeidet

MTU-Diagnose

1. PMTUD mit DF-Flag und wachsender Paketgröße durchführen, stabilen Durchsatz erreichen.
2. MTU im Tunnel 20–80 Bytes unter Maximalwert einstellen.
3. MSS Clamp an Grenzinterfaces für TCP konfigurieren.

CG-NAT und instabiles UDP

• Erhöhte Keepalive-Frequenz; Dopplung von Tunnelports.
• Bei chronischem Abfall Backup-Profil über TCP (z. B. SSTP oder OpenVPN TCP) für kritische Dienste, jedoch nicht als Haupt-S2S.

DPI

• Legitimes Traffic-Profil einhalten, Standardports nutzen, wenn möglich.
• Verwaltungs- und Datentunnel trennen, um Kontrolle nicht zu verlieren.

Praxis 6: Routing und HA – BGP über VPN

Warum BGP

Statische Routing-Tabellen skalieren schlecht. BGP bietet Pfadkontrolle, schnelles Failover und Vorhersagbarkeit in Multi-Hub-Setups. Passt natürlich als Transport über S2S.

Schritt für Schritt

1. Loopback-Adressen: Je Gate eine Loopback-Schnittstelle hochfahren und für BGP-Peering im Tunnel nutzen.
2. Filter: Nur eigene Präfixe ankündigen, am Hub fremde filtern.
3. Richtlinien: MED/LocalPref zur Hub-Priorisierung, Prepend für Ausweichrouten.
4. Failover: Schnelle Timer (Hello 3s, Hold 9s) bei stabilen Netzwerken oder BFD bei Unterstütztung.

HA an Gateways

• VRRP/Keepalived auf Gateway-Paaren in Niederlassungen.
• Konfigurationssynchronisation; Backup-CA-Verfügbarkeit.
• Berücksichtigung asymmetrischer Routen, Besonderheiten von stateful Firewalls.

Praxis 7: Observability, Betrieb, SLO

Metriken

• Tunnelverfügbarkeit: Uptime SA oder wg-Peers, RTO, Jitter.
• Durchsatz: p95/p99 Durchsatz, Fehler und Drops auf Interfaces.
• Sicherheit: Fehlgeschlagene Authentifizierungen, Rekey-Frequenz, verdächtige Routing-Dynamik.

Alerting

• SLO: 99,9% Verfügbarkeit des Niederlassungsverkehrs; Alert bei Unterschreitung über rollendes Zeitfenster.
• Wiederherstellungszeiten: MTTR bis 5 Minuten je Standort bei Backup-Verbindung.

Betriebsprozesse

• Quartalsweise Rotation von Schlüsseln/Zertifikaten.
• DR-Tests: Provider-Ausfall, Schlüsselkompromittierung, Gateway-Ausfall.
• Inventarisierung: aktuelles Verzeichnis der Niederlassungen, Präfixe, Schlüssel, Providerkontakte.

Typische Fehler: Was Sie vermeiden sollten

• Gleiche RFC1918-Adressen in verschiedenen Niederlassungen: Führt zu Asymmetrie und Hairpin-Effekten. Planen Sie Adressräume im Voraus.
• Fehlender MSS Clamp: Fragmentierung, unvorhersehbare TCP-Timeouts.
• Schwache Verschlüsselungsprofile: Veraltete Algorithmen (3DES, CBC ohne AEAD), fehlendes PFS.
• Einzelne CA für alle Perimeter: Domino-Effekt bei Sicherheitsvorfällen.
• Monitoring nachträglich: Implementieren Sie Metriken und Alerts vor der Skalierung.
• Ungetestetes Failover: Backup-Tunnel vorhanden, aber Timings, BGP und NAT-Regeln ungetestet.
• Single Uplink: Ein Provider am kritischen Knoten bedeutet Ausfallrisiko.

Tools und Ressourcen: Empfehlungen

Software-Stacks

• IPSec/IKEv2: StrongSwan, Libreswan, VyOS, pfSense; Netzwerk-OS mit Hardwarebeschleunigung (AES-NI).
• WireGuard: im Linux-Kernel integriert; Unterstützung auf Windows, BSD, RouterOS 7, VyOS.
• Dynamisches Routing: FRR (BGP/OSPF), BFD wenn unterstützt, Keepalived/VRRP für HA.

Monitoring und Testing

• Prometheus, VictoriaMetrics, Grafana für Dashboards.
• iperf3 für Durchsatz und Jitter, hping für MTU/DF-Tests.
• Packet Capture an Rändern (tcpdump) gefiltert nach ESP/UDP-Ports.

Konfigurationsmanagement

• GitOps-Ansatz: Tunnel-Templates und BGP-Richtlinien im Repository halten.
• Ansible für Rollouts in großem Maßstab; Secrets im Vault sichern.

Schnellstart für Piloten

Für Pilotprojekte und POCs, bei denen schnelle Inbetriebnahme und flexible Abrechnung in Russland wichtig sind, hat sich vpn.how bewährt. Es bietet persönlichen VPN-Server mit dedizierter IP (kein Shared-IP), Unterstützung für WireGuard, OpenVPN, IKEv2, L2TP und SSTP – sodass Sie das passende Protokoll für Ihr Netzwerk wählen können. Serverstandorte umfassen Moskau, St. Petersburg, Amsterdam, Frankfurt, London, New York, San Jose, Chicago, Singapur, Sydney, Madrid, Helsinki, Stockholm, Warschau, Kopenhagen, Stavanger. Akzeptierte Zahlungsmittel: russische Karten (Tinkoff, Ozon), SBP und USDT/BTC. Preise ab 490 ₽ pro Tag und ab 2490 ₽ pro Monat mit Mengenrabatten; automatischer Start 5 Minuten nach Zahlung, keine Logfiles – so lassen sich Hypothesen schnell testen ohne langwierige Beschaffungsprozesse. Für produktive Großumgebungen empfiehlt sich eigene Infrastruktur oder GOST-konforme Lösungen.

Case Studies und Ergebnisse: Praxisbeispiele

Case 1: Einzelhandelskette, 120 Niederlassungen

Kontext: Zwei Datenvitrinen, ERP und Kassensysteme. Lösung: Hub-and-Spoke mit IPSec/IKEv2, zwei Hubs (Moskau, SPb), BGP über Tunnel. Parameter: AES-GCM-256, DH19, Child SA 90 Minuten, DPD 10s. Ergebnis: Verfügbarkeit 99,94% im Quartal, p95-Durchsatz 250 Mbit/s pro Niederlassung, MTTR 4 Minuten dank BFD+BGP Failover. Insight: MSS Clamp 1360 beseitigte 80% der Fragmentierungsprobleme in den ersten zwei Wochen.

Case 2: Logistik, Backbone-Flows bis 3 Gbit/s

Kontext: Telemetrie- und Videodatenverkehr zwischen Hub und 8 Standorten. Lösung: WireGuard mit ECMP, zwei Provider pro Site, FRR BGP. Ergebnis: Insgesamt bis 6 Gbit/s mit zwei parallelen Tunneln, 10–15 % niedrigere Latenz als IPSec-Pilot, unkomplizierter Betrieb. Insight: IRQ-Pinning und Deaktivierung unnötiger NIC-Offloads brachten +20 % Durchsatz.

Case 3: FinTech, strenge Policies

Kontext: Anforderungen an Segmentierung und Audit, Multicloud. Lösung: IPSec/IKEv2 mit starker PKI, kurzen Zertifikaten, getrennten CAs für PROD/NON-PROD, Escrow-Prozesse. Ergebnis: Erfolgreiches Audit, automatisierte Rotation alle 90 Tage, keine Kompromittierung seit einem Jahr. Insight: Zentrales Register für Tunnel und Schlüssel mit verpflichtender Change Review senkte Betriebsfehler um 60 %.

Case 4: Produktion, instabile Provider in Regionen

Kontext: Einige Standorte hinter CG-NAT, periodische UDP-Instabilität. Lösung: WireGuard als Hauptprotokoll, Backup über IKEv2/ISAKMP bei anderem Provider; für Problemstandorte Notfall-SSTP-Managementprofil. Ergebnis: Ausfallzeiten auf 0,3 % pro Monat reduziert, Wiederherstellungszeit 2–3 Minuten. Insight: Aggressive Keepalives und Trennung von Management/Data verhinderten Fehlalarme im Monitoring.

FAQ: 7–10 tiefgehende Fragen

1. Was wählen für ein Netzwerk mit 10–20 Niederlassungen und kleinem IT-Team?

WireGuard bietet Einfachheit und schnelle Einführung, besonders mit x86/VyOS/RouterOS. Für heterogene Firewalls und strenge Regelwerke IPSec/IKEv2.

2. Welcher MTU-Wert ist Standard?

Startwerte: IPSec 1400, WireGuard 1420, MSS Clamp 1360–1380. Feineinstellung per PMTUD und Fragmentationsanalyse.

3. Können WireGuard und IPSec/IKEv2 gemischt werden?

Ja. Häufig WireGuard für Bulk-Traffic, IPSec/IKEv2 für Kompatibilität oder Backup. Wichtig: abgestimmtes Routing und BGP-Prioritäten.

4. Wie sicher ist WireGuard ohne IKE?

WireGuard entspricht aktuellen Sicherheitsstandards, nutzt robuste Primitive. Risiko liegt nicht im Protokoll, sondern im Betrieb: Schlüsselmanagement, minimaler AllowedIPs-Umfang, schnelle Rotation.

5. Wie ist die Lage bezüglich DPI und UDP-Blockaden in Russland?

Gelegentliche Fälle kommen vor. Halten Sie Backups bereit: alternative Ports, parallele Tunnel über andere Provider, Notfall-TCP-Profile fürs Management.

6. Wann lohnt BGP, wann ist statisches Routing genug?

Bis 5–7 Niederlassungen und ohne komplexe HA reichen statische Routen. Ab dann reduziert BGP Risiken und beschleunigt Failover.

7. Wie plant man Performance?

Spitzen- und p95-Verbrauch bewerten, 30–50 % Reserve auf CPU/Uplink einkalkulieren, Offload und NUMA beachten. Für IPSec AES-NI prüfen, bei WireGuard parallele Tunnel für Gigabit nutzen.

8. Was sind Anforderungen für PDS und KII?

VPN ist Teil der Lösung. Organisatorische Maßnahmen, Segmentierung, Logging, Zugriffsmanagement sind Pflicht. Bei Zertifizierungen auf zertifizierte Lösungen oder GOST-Kryptografie achten.

9. Wie oft müssen Schlüssel und Zertifikate rotiert werden?

Praxis: alle 90–180 Tage automatisiert. Bei Vorfall sofort ersetzen und sperren.

10. Kann man Multicast/VoIP über VPN realisieren?

Ja, aber MTU, Jitter und QoS berücksichtigen. Oft ist SRTP über gesonderten Tunnel vorzuziehen mit WAN-Priorisierung.

Fazit: Zusammenfassung und nächste Schritte

In Russland basieren funktionierende Site-to-Site VPNs auf zwei Haupttechnologien: IPSec/IKEv2 als universeller Standard und WireGuard als leichtes, performantes Werkzeug. Die Wahl ist kein Entweder-Oder: In etablierten Netzwerken ist eine Hybridlösung sinnvoll, die für Standort und Traffic das optimale Profil nutzt. Schlüssel zum Erfolg sind Netzwerkdisziplin, durchdachter Adressplan, BGP über Tunnel, korrekte MTU/MSS-Werte, Ausfallsicherheit auf Kanal- und Gateway-Level, Observability und formalierte Sicherheit. Starten Sie mit einem Pilot: 2–3 Standorte, Monitoring, Lasttests, Notfallproben. Testen Sie Profile, skalieren Sie mit GitOps und CMDB. Für schnelle POCs eignet sich ein persönlicher Server beim Provider wie beschrieben, für produktive Umgebungen eigene Cluster oder zertifizierte Lösungen. Grundlegend: Observability und DR-Tests nicht aufschieben, Kryptoprofile und Schlüssel diszipliniert verwalten. Dann wird der VPN kein «Black Box» mehr, sondern ein verlässliches Rückgrat Ihres Business.