Site-to-Site-VPN-Diagramm: IPsec-Tunnel, BGP-Routing und Redundanz

Dein Rechenzentrum erreicht seine AWS-Workloads über ein Site-to-Site-VPN, das seit einem Jahr ruhig läuft. Eines Nachts ersetzt AWS bei Routinewartung einen Tunnel-Endpunkt, und jede Verbindung zur VPC bricht ab. Auf der Firewall war nur Tunnel 1 konfiguriert. Tunnel 2 stand seit dem Tag seiner Erstellung auf DOWN.

In den meisten Diagrammen ist ein Site-to-Site-VPN eine einzige Linie. In der Praxis sind es zwei IPsec-Tunnel, zwei BGP-Sessions und ein MTU-Budget, und Ausfälle entstehen in den Teilen, die diese Linie verbirgt. Dieser Beitrag behandelt die IPsec-Bausteine, ein AWS-Beispiel, statisches Routing gegenüber BGP, Redundanz, MTU und MSS, Monitoring und die Frage, wann eine dedizierte Leitung besser passt.

Site-to-Site- versus Remote-Access-VPN

Ein Site-to-Site-VPN verbindet zwei Netzwerke: Die Gateways an beiden Enden halten die Tunnel, und die Hosts dahinter brauchen keine VPN-Software. Ein Remote-Access-VPN verbindet ein einzelnes Gerät, mit einem Client auf jedem Laptop und einer Person, die sich anmeldet. Wenn eigentlich Menschen auf interne Apps zugreifen sollen, passt ein identitätsbasierter Proxy in einer Zero-Trust-Architektur oft besser als beides.

Die IPsec-Bausteine

IKEv2 (RFC 7296) authentifiziert die Peers und handelt die Schlüssel aus. ESP (RFC 4303) verschlüsselt den Datenverkehr.

IKEv2 baut die IKE SA und die erste Child SA normalerweise mit vier Nachrichten auf (IKE_SA_INIT und IKE_AUTH). IKEv1 wurde 2023 durch RFC 9395 für veraltet erklärt. Bei den Algorithmen macht RFC 8247 die DH-Gruppe 14 zur Pflicht für Implementierungen und empfiehlt Gruppe 19; die Gruppen 2, 5, 23 und 24 sollten nicht verwendet werden, Gruppe 22 darf nicht verwendet werden.

Zwei Tunnel pro Verbindung: ein AWS-Beispiel

Ein AWS Site-to-Site VPN verbindet dein Customer-Gateway-Gerät mit einem Gateway auf der AWS-Seite. Laut der AWS-Dokumentation zu den Tunneloptionen hat jede Verbindung zwei Tunnel, jeder mit eigener öffentlicher IP und Terminierung in unterschiedlichen Availability Zones.

AWS ersetzt Tunnel-Endpunkte für Patches und die Ausmusterung von Hardware, jeweils einen Tunnel nach dem anderen. Ein Gerät, das nur einen Tunnel nutzt, kann deshalb jedes Mal die Konnektivität verlieren, wenn dieser Endpunkt ersetzt wird. AWS Health sendet monatlich eine Meldung, wenn ein Tunnel an einem Tag länger als eine Stunde ausgefallen ist.

Jeder Tunnel hat ein Inside-/30 aus 169.254.0.0/16. AWS nimmt die erste nutzbare Adresse, dein Gerät die zweite, und dazwischen läuft BGP. Dein Gerät startet IKE, sofern du die Startup-Aktion nicht auf start setzt (nur IKEv2). AWS wertet Vorschläge ab dem niedrigsten Wert seiner Liste erlaubter Werte aus, egal in welcher Reihenfolge dein Gerät sie sendet. Entferne deshalb auf beiden Seiten IKEv1, SHA-1 und die DH-Gruppen 2, 5 und 22 bis 24.

Definiere die Tunnel als Code, damit beide identisch bleiben. In Terraform, Tunnel 1:

resource "aws_vpn_connection" "dc" {
  vpn_gateway_id      = aws_vpn_gateway.main.id
  customer_gateway_id = aws_customer_gateway.dc.id
  type                = "ipsec.1"
  static_routes_only  = false

  tunnel1_inside_cidr                  = "169.254.10.0/30"
  tunnel1_ike_versions                 = ["ikev2"]
  tunnel1_phase1_encryption_algorithms = ["AES256-GCM-16"]
  tunnel1_phase1_integrity_algorithms  = ["SHA2-384"]
  tunnel1_phase1_dh_group_numbers      = [20]
  tunnel1_phase2_encryption_algorithms = ["AES256-GCM-16"]
  tunnel1_phase2_dh_group_numbers      = [20]
  tunnel1_dpd_timeout_seconds          = 30
  tunnel1_dpd_timeout_action           = "restart"
  tunnel1_startup_action               = "start"
  # tunnel2_*: the same values with 169.254.10.4/30
}

Statisches Routing oder BGP

Statisches Routing listet deine Präfixe an der Verbindung auf und überlässt das Failover den Health-Checks deines Geräts. Mit BGP läuft pro Tunnel eine eBGP-Session, und die Routen eines ausgefallenen Tunnels werden zurückgezogen, sobald seine Session abbricht. AWS empfiehlt BGP überall, wo das Gerät es unterstützt, und ECMP setzt es voraus. Vier Regeln:

1. Verwende unterschiedliche private ASNs. Die AWS-Seite nutzt standardmäßig 64512. Gib deinem Standort eine eigene private ASN: 64512 bis 65534 oder 4200000000 bis 4294967294 (RFC 6996).
2. Annonciere Zusammenfassungen. Ein Virtual Private Gateway akzeptiert höchstens 100 Routen von deinem Gerät, ein festes Limit.
3. Überlappe nie CIDRs. Die lokale Route der VPC schlägt jede VPN-Route, selbst eine spezifischere. Plane den Adressraum standortübergreifend oder setze NAT auf einer Seite ein.
4. Kenne die Tie-Breaker. Für dasselbe Präfix bevorzugt ein Virtual Private Gateway zuerst Direct Connect, dann statische VPN-Routen, dann BGP-Routen; danach den kürzesten AS-Pfad, dann den niedrigsten MED.

Ohne ECMP schickt AWS den Rückverkehr jeweils über einen Tunnel, markiert mit MED. Die AWS-Hinweise zur Routenpriorität lauten: asymmetrisches Routing zulassen und die AS-Pfade gleich halten. Kommt deine Stateful-Firewall damit nicht zurecht, verlängere den AS-Pfad auf Tunnel 2 per Prepending und senke dessen Local Preference; ein Wechsel des AWS-Egress-Pfads kann dann Flows abbrechen. Die AWS-Beispielkonfiguration nutzt 10 Sekunden Keepalive und 30 Sekunden Hold Time, nicht die 90 Sekunden, die RFC 4271 vorschlägt.

Redundanz-Designs

Zwei Tunnel decken Ausfälle auf der AWS-Seite ab. Sie teilen sich aber weiterhin dein Gerät, deinen ISP und deinen Standort.

Bei zwei Geräten hat jedes seine eigene VPN-Verbindung, und beide annoncieren dieselben Präfixe. ECMP hasht jeden Flow auf einen Tunnel, vier Tunnel ergeben also rund 5 Gbps insgesamt, aber eine einzelne TCP-Verbindung kommt weiterhin nur auf 1,25 Gbps, und eine Stateful-Firewall braucht für die Symmetrie unter Umständen Source NAT. Bei vielen Standorten wird das Transit Gateway zum Hub eines Hub-and-Spoke-Netzwerks.

MTU und MSS Clamping

Jedes getunnelte Paket trägt einen neuen IP-Header plus ESP-Overhead. AWS unterstützt höchstens eine MTU von 1.446 Byte und eine TCP-MSS von 1.406 Byte, ohne Path MTU Discovery und ohne Jumbo Frames. Die genauen Werte hängen von deinen Algorithmen ab, laut den AWS Best Practices für Customer Gateways:

Setze die Tunnel-MTU und clampe die MSS der TCP-SYN-Pakete in beide Richtungen, da jede Seite ihre eigene ankündigt. Auf einem Linux-Gateway:

ip link set dev vti1 mtu 1446
iptables -t mangle -A FORWARD -o vti1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1406
iptables -t mangle -A FORWARD -i vti1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1406

Das klassische Symptom eines falschen Werts: Ping und SSH funktionieren, aber Dateikopien hängen. Die AWS-Seite mit den Geräteanforderungen schlägt 1.399 Byte vor, was ebenfalls funktioniert, aber ein paar Byte verschenkt.

Die Tunnel überwachen

• Tunnelstatus. CloudWatch veröffentlicht TunnelState pro Tunnel; bei BGP-Verbindungen bedeutet 1, dass die Session aufgebaut ist. Löse einen Alarm aus, sobald einer der beiden Tunnel unter 1 fällt. TunnelDataIn und TunnelDataOut zeigen, welcher Tunnel Traffic trägt.
• Logs. Site-to-Site-VPN-Logs erfassen IKE-Zustände, DPD-Ereignisse, den BGP-Status und Routenänderungen.
• Deine Seite. Beobachte pro Tunnel den BGP-Zustand und die empfangenen Präfixe. Eine aufgebaute Session ohne Präfixe ist trotzdem ein Ausfall.

Wenn ein Tunnel nicht hochkommt, prüfe schichtweise: IKE SA, IPsec SA, ein Ping auf die AWS-Inside-Adresse, dann BGP.

Wann der Wechsel zu Direct Connect sinnvoll ist

Wechsle, wenn der Traffic dauerhaft im Gigabit-Bereich liegt, Latenz wichtig ist oder der Internet-Egress mehr kostet als ein Port. Seit September 2026 können dedizierte Verbindungen mit 10 und 100 Gbps eine Flatrate-Preisgestaltung nutzen, die ausgehenden Datentransfer innerhalb einer Stufe einschließt. Behalte das VPN als Backup: Ein Virtual Private Gateway bevorzugt Direct-Connect-Routen, der Traffic nutzt die Tunnel also nur, wenn die Leitung ausfällt. Das Diagramm einer Disaster-Recovery-Architektur behandelt diese Planung.

Das Site-to-Site-VPN-Diagramm

So liest du es:

• Links das Rechenzentrum: 10.20.0.0/16 in AS 65010. Das LAN schickt VPC-Traffic an die Edge-Firewall, das Customer-Gateway-Gerät.
• Zwei Tunnel führen zu zwei Endpunkten des Virtual Private Gateway, jeder mit eigenem Inside-/30 und eigener BGP-Session. Beide sind aktiv; AWS wählt den Rückweg.
• Rechts die VPC: 10.50.0.0/16, mit privaten Subnetzen in zwei Availability Zones und einer propagierten Route nach 10.20.0.0/16.
• Der Markdown-Block listet die Einstellungen auf, die auf beiden Tunneln übereinstimmen müssen.
• Die Notizen unten sagen, was zwei Tunnel abdecken (Endpunkt-Ersetzungen) und was nicht (eine Firewall, ein ISP).

Site-to-Site-VPN-Diagramme übersichtlich zeichnen

• Beschrifte beide Enden mit CIDR, ASN und öffentlicher IP. Die meisten VPN-Tickets beginnen mit einem davon.
• Zeichne beide Tunnel mit ihren Inside-/30s und BGP-Peers und gib an, welcher bevorzugt wird und warum.
• Fasse die gemeinsamen Einstellungen in einem Kasten zusammen: IKE-Version, Algorithmen, DH-Gruppe, Lifetimes, MTU und MSS.
• Zeige Single Points of Failure, etwa ein einzelnes Gerät oder einen einzelnen ISP.
• Lass weg: Pre-Shared Keys, ISP-Interna und Hostlisten.

Das Netzwerktopologie-Diagramm behandelt die Büroseite; das AWS-VPC-Diagramm behandelt Subnetze und Routentabellen.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und erstelle ein Diagramm.
2. Füge für das Rechenzentrum einen Rahmen aus dem Paket Basis hinzu, benannt mit CIDR und ASN. Setze darin ein Subnetz mit zwei Server-Nodes und einer Firewall ein, alle aus dem Paket Netzwerk.
3. Füge eine VPC aus dem Paket Netzwerk hinzu. Setze darin einen Rahmen für das Virtual Private Gateway mit zwei Router-Nodes ein sowie zwei private Subnetz-Nodes mit je einer Recheninstanz aus dem Paket Cloud.
4. Zeichne die Tunnel von der Firewall zu den Endpunkten mit Pfeilen an beiden Enden, beschriftet mit dem Inside-/30 und den BGP-Peers. Füge Kanten vom LAN zur Firewall und vom Gateway zu den Subnetzen hinzu.
5. Füge zwischen den Tunneln einen Markdown-Block aus dem Paket Basis für die gemeinsamen Einstellungen hinzu, dazu Text-Notizen.

Wenn das VPN in Terraform definiert ist, liefert dir das kostenlose Terraform-zu-Diagramm-Tool einen ersten Entwurf; siehe auch Netzwerkdiagramme.

Das Beispiel nutzt 14 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was sollte ein Site-to-Site-VPN-Diagramm zeigen? Beide Netzwerke mit ihren CIDRs, die öffentliche IP und ASN jedes Gateways, die Inside-Adressen jedes Tunnels, das Routing und die Einstellungen, die beide Seiten teilen müssen.

Warum hat ein AWS Site-to-Site VPN zwei Tunnel? Jede Verbindung hat zwei Tunnel zu Endpunkten in verschiedenen Availability Zones. AWS wartet sie nacheinander, sodass der Traffic bei beiden konfigurierten Tunneln umzieht, statt zu stoppen.

Sollte ich statisches Routing oder BGP über IPsec verwenden? BGP, sobald dein Gerät es unterstützt. Es zieht die Routen eines ausgefallenen Tunnels automatisch zurück und ist für ECMP erforderlich. Statisches Routing ist für Geräte ohne BGP.

Welche MTU und MSS sollte ich für ein AWS-VPN verwenden? Höchstens 1.446 und 1.406 Byte, mit AES-GCM und ohne NAT Traversal. CBC-Cipher und NAT-T brauchen kleinere Werte aus der AWS-Tabelle.

Wann sollte ich Direct Connect statt eines VPN verwenden? Wenn der Traffic dauerhaft im Gigabit-Bereich liegt, die Latenz vorhersagbar sein muss oder du bis zu 99,99 % SLA brauchst. Behalte das VPN als verschlüsseltes Backup.

Kostenlos starten — ein Seat, keine Kreditkarte.