Netzwerk & WAN
Site-to-Site VPN
Ein Site-to-Site-VPN koppelt ganze Standorte über verschlüsselte Tunnel, sodass die Netze zusammenarbeiten, als wären sie direkt verbunden.
- Netz-zu-Netz-Kopplung
- IPsec-verschlüsselt
- Hub-Spoke oder Mesh
- Route-based (VTI) vs. Policy-based
- IKEv2 als Unterbau
Ein Site-to-Site-VPN koppelt ganze Netze bzw. Standorte dauerhaft über einen verschlüsselten Tunnel zwischen den Gateways. Für die Endgeräte ist das transparent: Sie kommunizieren mit dem entfernten Netz, als wäre es direkt angebunden, ohne VPN-Client je Gerät.
Dieser Artikel erklärt den entscheidenden Unterschied zwischen policy-based und route-based (VTI), warum dynamisches Routing über den Tunnel eine Tunnel-Schnittstelle braucht, IPsec/IKEv2 als Unterbau, die Topologien Hub-and-Spoke und Full-Mesh samt Skalierungsgrenze, Redundanz und die typischen Stolperfallen von überlappenden Subnetzen bis MTU.
1. Was ein Site-to-Site-VPN leistet
Statt einer gemieteten Standleitung nutzt ein Site-to-Site-VPN das Internet als Transport und legt darüber einen dauerhaften, verschlüsselten Tunnel. Das Gateway jedes Standorts ver- und entschlüsselt; die Clients merken davon nichts. Das macht die Standortkopplung günstig und flexibel, verlagert aber die Verantwortung für Verfügbarkeit und korrektes Routing auf die Gateways.
2. Policy-based oder Route-based (VTI)
Die Bauart entscheidet über Flexibilität und Wartbarkeit:
| Bauart | Funktionsweise und Folge |
|---|---|
| Policy-based (Crypto-Map) | eine Policy aus Quell-/Ziel-Netz-Paaren (Proxy-IDs) bestimmt, was in den Tunnel kommt; je Paar eine eigene SA. Bei vielen Subnetzen vervielfachen sich die SAs, kein dynamisches Routing |
| Route-based (VTI) | der Tunnel ist ein logisches Interface; die Routing-Tabelle lenkt den Verkehr hinein. Eine SA (meist any-to-any), beliebig viele Subnetze, dynamisches Routing möglich |
Route-based mit VTI ist für neue Setups der sauberere Weg: ein Tunnel-Interface, über das auch Routing-Protokolle, Failover und mehrere Subnetze ohne SA-Wildwuchs laufen. Policy-based ist vor allem in Interop- und Altbestand-Szenarien noch anzutreffen.
3. Routing über den Tunnel
Reines IPsec im Tunnel-Modus transportiert keinen Multicast, den Routing-Protokolle wie OSPF aber nutzen. Deshalb braucht dynamisches Routing entweder ein VTI (route-based, das Tunnel-Interface trägt die Routing-Nachbarschaft) oder GRE über IPsec. Über statische Routen lässt sich ein policy-based Tunnel betreiben, aber ohne automatische Anpassung an Topologieänderungen.
4. Unterbau: IPsec und IKEv2
Site-to-Site-VPNs setzen fast immer auf IPsec mit IKEv2 auf (Details im IPsec-Artikel). Zur Authentifizierung dienen ein Pre-Shared Key oder, skalierbarer und sicherer, X.509-Zertifikate. Für mehr als eine Handvoll Standorte sind Zertifikate klar vorzuziehen, weil sie sich pro Standort ausstellen und gezielt sperren lassen.
Cisco IOS: route-based VPN über IPsec-VTI
interface Tunnel1
ip address 10.255.0.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel destination 203.0.113.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile S2S5. Topologien und ihre Skalierung
Bei Hub-and-Spoke hat jeder Standort einen Tunnel zur Zentrale; Verkehr zwischen zwei Außenstellen läuft über den Hub (Hairpinning). Einfach zu verwalten, aber der Hub wird zu Engpass und Single Point of Failure. Bei Full-Mesh hat jeder Standort direkte Tunnel zu allen anderen, das ergibt n·(n−1)/2 Tunnel: 10 Standorte = 45, 20 = 190, 50 = 1225. Konfigurations- und Lastaufwand wachsen quadratisch.
Genau hier setzen dynamische Mesh-Ansätze an: DMVPN und ADVPN bauen direkte Standort-zu-Standort-Tunnel bei Bedarf automatisch auf und reißen sie wieder ab, statt eine Vollvermaschung dauerhaft von Hand zu pflegen.
6. Redundanz und Hochverfügbarkeit
Für Ausfallsicherheit dienen mehrere Tunnel zu redundanten Peers, als aktiv/standby (ein Tunnel primär) oder aktiv/aktiv (beide tragen Last, ECMP, setzt route-based voraus). Zur Ausfallerkennung nutzt IPsec Dead Peer Detection; über ein VTI erkennt zusätzlich BFD einen toten Pfad im Millisekundenbereich und schwenkt das Routing schneller um. Ein bewährtes Muster ist BGP über die VTIs.
7. Typische Fehler in der Praxis
- Überlappende Subnetze liegen beide Standorte im selben Bereich (etwa 192.168.1.0/24), wird der Verkehr als lokal behandelt und nie in den Tunnel geroutet. Adressräume standortübergreifend eindeutig planen.
- Proxy-ID-Mismatch bei policy-based müssen die Selektoren auf beiden Seiten exakt spiegeln, sonst kommt keine SA zustande.
- MTU/MSS der IPsec-Overhead sprengt sonst die MTU; MSS-Clamping auf dem Tunnel-Interface und PMTU-Behandlung einplanen.
- Proposal-/PSK-Mismatch unterschiedliche Algorithmen, Lebensdauern oder ein falscher PSK lassen IKE scheitern, oft nur mit kryptischer Fehlermeldung.
8. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Günstige Standortkopplung über das Internet statt Standleitung | Verfügbarkeit hängt am Internet und an den Gateways |
| Transparent für Endgeräte, kein Client je Gerät | Full-Mesh skaliert quadratisch (n·(n−1)/2 Tunnel) |
| Route-based (VTI): dynamisches Routing, Failover, viele Subnetze | Policy-based ist starr und SA-intensiv |
| Herstellerübergreifend über IPsec/IKEv2 | Interop-Tücken (Proxy-IDs, Defaults) zwischen Herstellern |
| Redundanz über mehrere Tunnel, DPD/BFD, BGP | MTU/Overhead und Adressplanung erfordern Sorgfalt |
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Site-to-Site VPN im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.