Site icon bintorosoft.com

WireGuard Site-to-Site: Routing, AllowedIPs und Skalierungsgrenzen

Red Snapper

Internet connections and wires connected to ports may be seen in the vertical server cabinet background image created using generative AI.

WireGuard Site-to-Site ist für viele Unternehmen ein attraktives Architekturpattern, weil es mit wenig Protokollkomplexität sehr hohe Performance und eine klare Konfigurationslogik liefert. Im Gegensatz zu klassischen IPSec-Setups mit umfangreichen Negotiation-Optionen und herstellerspezifischen Sonderwegen arbeitet WireGuard bewusst minimalistisch: feste moderne Kryptografie, ein schlanker Handshake und eine zentrale Steuergröße namens AllowedIPs. Genau hier liegt jedoch die Enterprise-Herausforderung: AllowedIPs ist nicht nur „eine Route“, sondern gleichzeitig Routing-Entscheidung, Zugriffskontrolle und – in vielen Betriebsmodellen – auch der Mechanismus, der Skalierung begrenzt oder ermöglicht. Wer WireGuard für Standortvernetzung (Branch-to-Hub, Hub-and-Spoke, Dual-Hub, Teil-Mesh) einsetzen will, muss daher Routing und Governance sauber entwerfen: Welche Präfixe werden wo announced? Wie vermeiden Sie Overlaps und Route Leaks? Wie umgehen Sie Full-Mesh-Explosionen? Wie bauen Sie Failover ohne Tunnel-Flapping? Und wie bleiben Design und Betrieb auditierbar, wenn die Anzahl der Standorte steigt? Dieser Artikel erklärt WireGuard Site-to-Site auf Profi-Niveau: Routing-Grundmuster, AllowedIPs-Design, typische Skalierungsgrenzen und bewährte Betriebsmodelle, damit WireGuard nicht nur „läuft“, sondern langfristig stabil bleibt.

Grundlagen: WireGuard als Overlay – Routing entscheidet über Reichweite

WireGuard ist ein Layer-3-Overlay: Es transportiert IP-Pakete verschlüsselt über UDP. Im Unterschied zu vielen klassischen VPN-Stacks gibt es bei WireGuard keine „Policy“-Aushandlung. Stattdessen definieren Sie pro Peer statisch, welche Zielnetze (Präfixe) über diesen Peer erreichbar sein sollen. Diese Definition ist AllowedIPs. Sie wirkt in der Praxis wie eine Kombination aus Routingtabelle und Access Control List.

Als offizielle Einstiegsreferenz lohnt ein Blick auf wireguard.com sowie auf die Linux-Dokumentation WireGuard im Kernel, weil dort die Funktionsweise (Peers, AllowedIPs, Handshake, Roaming) sehr klar beschrieben ist.

AllowedIPs: Routing-Mechanismus und Policy in einem

AllowedIPs ist die wichtigste Stellschraube bei WireGuard Site-to-Site. Für jeden Peer definieren Sie eine Liste von IP-Präfixen, die über diesen Peer gesendet werden dürfen. Gleichzeitig akzeptiert WireGuard eingehende Pakete nur dann als „legitim für diesen Peer“, wenn sie aus einer Quelle stammen, die zu dessen AllowedIPs passt. Das ist eine starke Sicherheitsidee, aber sie hat Konsequenzen:

AllowedIPs als „Routing-Tabelle“ interpretieren

In vielen Implementierungen verhält sich AllowedIPs wie ein Lookup: „Für Zielpräfix X nutze Peer Y“. Das ist der Grund, warum Sie bei Site-to-Site eine saubere IP-Adressplanung und eindeutige Präfixzuordnung benötigen. Wenn zwei Peers dasselbe Präfix beanspruchen, ist das nicht nur ein Routingfehler, sondern ein Policy-Fehler.

Topologien: Hub-and-Spoke, Dual-Hub und Teil-Mesh mit WireGuard

WireGuard eignet sich für verschiedene Topologien. Entscheidend ist, welche davon Sie langfristig betreiben wollen, denn die Topologie bestimmt direkt, wie AllowedIPs und Routingregeln wachsen.

Hub-and-Spoke als Standard für Skalierung

Dual-Hub (Primary/Secondary) für Resilienz

Teil-Mesh für kritische Direktpfade

Full Mesh: Warum es selten Enterprise-Default ist

Ein Full Mesh bedeutet, dass jeder Standort zu jedem anderen peert. Die Anzahl der Peer-Beziehungen wächst ungefähr quadratisch:

P=n(n–1)2

Bei 50 Standorten sind das bereits 1225 Peerings. Selbst wenn WireGuard „einfach“ ist, sind Keys, AllowedIPs, Monitoring und Change-Prozesse in einem Full Mesh selten dauerhaft beherrschbar. Deshalb ist Hub-and-Spoke (mit optionalen Direktpfaden) in Enterprise-Szenarien meist die bessere Standardtopologie.

Routing über WireGuard: Statisch vs. dynamisch

WireGuard selbst ist kein Routingprotokoll. Routing passiert im Betriebssystem/Router. Für Site-to-Site haben sich zwei Grundmodelle etabliert:

Statisches Routing: robust, aber begrenzt

BGP über WireGuard: Skalierung und kontrollierte Policies

In großen Site-to-Site-Landschaften ist BGP häufig das skalierbarste Routingmodell, weil Sie Präfixe dynamisch verteilen und gleichzeitig Policies (Filter, Preferenzen) sauber implementieren können. BGP ist in RFC 4271 beschrieben.

OSPF über WireGuard: möglich, aber empfindlicher

OSPF kann funktionieren, ist aber über Internet-Underlays sensibler gegenüber Jitter, Loss und MTU-Problemen. OSPFv2 ist in RFC 2328 beschrieben. In Enterprise-Site-to-Site-Overlays wird OSPF häufig nur in klar begrenzten Domänen empfohlen, in denen Underlay-Qualität gut kontrolliert ist.

AllowedIPs-Designmuster für Site-to-Site

Die größte praktische Frage ist: Was tragen Sie in AllowedIPs ein, wenn Sie skalieren wollen? Es gibt drei Muster, die sich in der Praxis bewährt haben.

Muster 1: Präfixe pro Standort explizit (kleine Umgebungen)

Muster 2: Segment-/Summary-Präfixe mit strenger Governance

Muster 3: AllowedIPs minimal, Routing entscheidet (für große Umgebungen)

Skalierungsgrenzen: Wo WireGuard im Enterprise „wehtun“ kann

WireGuard ist performant, aber Skalierung ist nicht nur Durchsatz. In Enterprise-Site-to-Site treten Grenzen meist an organisatorischen und operativen Punkten auf:

Failover ohne Flapping: Dual Uplinks und Dual Hubs mit WireGuard

WireGuard-Roaming hilft bei wechselnden Client-IPs, ersetzt aber kein sauberes Failover-Design für Site-to-Site. Für stabile Umschaltung brauchen Sie deterministische Preferenzen und Hysterese.

NAT, Keepalive und Real-World Underlays

In mobilen oder providergeprägten Netzen (CGNAT, Hotel-WLAN) laufen UDP-Mappings aus. Für Site-to-Site über solche Underlays kann Persistent Keepalive entscheidend sein, um den Tunnel „warm“ zu halten.

MTU/MSS und PMTUD: Stabilität für BGP, TLS und große Transfers

Encapsulation senkt die effektive MTU. Wenn PMTUD durch gefiltertes ICMP scheitert, entstehen Blackholes. Besonders kritisch ist das bei TCP-basierten Control-Planes (BGP), bei TLS-Handshakes und bei großen Transfers. PMTUD-Hintergründe: RFC 1191 und RFC 8201.

Security und Audit-Readiness: WireGuard Site-to-Site als „Produkt“

In Enterprise-Umgebungen muss Site-to-Site nicht nur funktionieren, sondern prüfbar sein. Das betrifft insbesondere Key Management und AllowedIPs-Governance.

Als Architekturleitplanke für „minimale Rechte“ und „kontinuierliche Verifikation“ ist NIST SP 800-207 hilfreich, auch wenn WireGuard selbst kein Zero-Trust-System ist.

Observability: Was Sie messen müssen, um Skalierung zu beherrschen

WireGuard liefert bewusst wenige Protokollsignale. Enterprise-Betrieb braucht deshalb ergänzende Telemetrie:

Häufige Anti-Patterns bei WireGuard Site-to-Site

Checkliste: WireGuard Site-to-Site sauber skalieren

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:

Lieferumfang:

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.

 

Exit mobile version