Hub-and-Spoke oder Full Mesh: welche VPN-Topologie zu Ihren Standorten passt

Zwei Filialen sprechen den ganzen Tag miteinander, und der Tunnel zwischen ihnen nimmt einen Umweg über ein Rechenzentrum in einer anderen Region. Jede Anfrage zahlt diesen Umweg zweimal, und niemand merkt es, bis sich die Dateisynchronisierung falsch anfühlt. Genau hier beginnt die Topologiefrage: nicht damit, welches Diagramm widerstandsfähiger aussieht, sondern damit, für welches Verkehrsmuster Sie bezahlen. Beide Entwürfe funktionieren, und sie scheitern auf unterschiedliche Weise zu unterschiedlichen Kosten.

Zählen Sie zuerst die Peer-Beziehungen

Bei N Standorten braucht ein Full Mesh N mal N minus eins, geteilt durch zwei, Tunnel; ein Hub braucht N. Bei fünf Standorten sind das zehn gegen fünf, was noch machbar klingt. Bei fünfzehn sind es 105 gegen fünfzehn, und der Unterschied ist keine Arithmetik mehr, sondern Personal.

Jede dieser Beziehungen trägt Zustand, den Sie besitzen müssen. In IPsec bedeutet das eine Security Association, eine Identität, einen Schlüssel oder ein Zertifikat, Dead-Peer-Erkennung und mindestens eine Route pro entferntem Präfix. In WireGuard bedeutet es einen öffentlichen Schlüssel und einen AllowedIPs Block pro Peer, was pro Peer günstiger ist, aber ganz ohne Erkennung kommt: ein neuer Standort ist so oder so eine Konfigurationsänderung an jedem bestehenden.

Lassen Sie den Verkehrsmix entscheiden, nicht die Zeichnung

Wenn der Filialverkehr überwiegend aus Anfragen an ein zentrales ERP- oder Dateisystem besteht, ist ein Hub kein Kompromiss, sondern die richtige Form: Der Verkehr wollte ohnehin dorthin, und ein einziger Richtlinienpunkt ist leichter zu prüfen als ein Mesh aus paarweisen Regeln. Ein Mesh verdient seine Komplexität, wenn Filialen Daten untereinander austauschen — Replikation zwischen zwei Büros, Telefonie zwischen Standorten, eine CAD-Freigabe, die ein Dutzend Ingenieure den ganzen Tag öffnen.

Die unangenehmen Fälle liegen dazwischen, und sie sind die Mehrheit. Messen Sie, bevor Sie streiten, statt aus einem Organigramm zu raten.

Lesen Sie die Tabelle als Stichentscheid, nicht als Regel. Drei von vier Zeilen in eine Richtung entscheiden den Entwurf meist; eine Spaltung bedeutet Hybrid, und darauf laufen die meisten reifen Netze ohnehin hinaus.

Einem Hub muss man das Weiterleiten sagen

Zwei funktionierende Spoke-zu-Hub-Tunnel schaffen keinen Spoke-zu-Spoke-Zugriff. Der Hub braucht aktivierte IP-Weiterleitung, eine Route zu jedem Spoke-Netz, eine Firewallregel, die den Transit erlaubt, und einen durchgerechneten Rückweg; jeder Spoke braucht eine Route für die Präfixe des anderen Standorts. Auf einem Linux-Hub ist das net.ipv4.ip_forward=1 plus FORWARD eine Kette, die das Paar nicht stillschweigend verwirft, und bei richtlinienbasiertem IPsec sind es Traffic Selectors, die das entfernte Spoke-Subnetz an beiden Enden auflisten. Bei strongSwan die Hinweise zur Weiterleitung decken die Kernel- und Firewallseite ab, wenn genau diese Schicht fehlt. Ein billiger Test ist, Verkehr von einem Spoke zu einem Dienst auf dem anderen zu schicken und dabei die Zähler des Hubs zu beobachten; eine Regel, die nie hochzählt, bedeutet, dass die Reihenfolge falsch ist, nicht die Route.

Zentrale Richtlinie ist auch der nützliche Teil. Filialen dürfen gemeinsam genutzte Dienste erreichen, ohne sich gegenseitig zu erreichen, und diese Zugriffsmatrix sollte man ausdrücklich aufschreiben. Fehlende Routen sind ein schlechter Ersatz für eine Regel, die jemand lesen kann.

Achten Sie auf die halbfertige Variante: Spoke A routet über den Hub zu Spoke B, der Hub routet in beide Richtungen, und die Firewall des Hubs erlaubt neue Verbindungen von A, aber nicht von B. Die erste Richtung testet sich gut, die zweite hängt, was wie ein Routingfehler aussieht und keiner ist.

Entwerfen Sie zuerst den Fehlerfall, dann den Normalfall

Ein einzelner Hub ist eine geteilte Abhängigkeit und ein Transitengpass, und bei der Redundanz gehen Hub-Entwürfe meist schief. Zwei Hubs bedeuten, dass jeder Spoke zwei Tunnel hält, und der Rückweg muss mit dem Hinweg übereinstimmen; tut er das nicht, verwirft eine zustandsbehaftete Firewall die Antworten, und das Symptom ist eine Verbindung, die sich öffnet und dann stirbt. Größere Installationen lösen das mit einem Routingprotokoll über die Tunnel statt mit statischen Präfixen, was mehr Maschinerie ist, aber das Raten entfernt. Was auch immer Sie wählen, schreiben Sie den Rückweg neben den Hinweg, denn die Rückhälfte ist die, die niemand testet.

Ein Mesh verteilt dieses Risiko: Fällt der Link eines Standorts aus, isoliert das die anderen nicht. Es vervielfacht auch die Stellen, an denen die Pfadwahl Sie überraschen kann, und Anwendungssitzungen überstehen einen Pfadwechsel weiterhin nicht ohne Hilfe.

Keiner der beiden Entwürfe hält eine TCP-Sitzung von sich aus über ein Failover am Leben. Wenn die Anwendung nicht neu verbinden kann, ist die Topologie nicht Ihr Problem.

Wählen Sie nach Änderungskosten, dann prüfen Sie die Routen

Fangen Sie mit dem Hub an, weil er die günstigere Sache ist, bei der man falsch liegen kann, und ergänzen Sie direkte Tunnel für die Paare, deren Verkehr sie rechtfertigen. Dieser Hybrid ist keine unterlassene Entscheidung; er ist der Entwurf, auf den sich die meisten Organisationen binnen eines Jahres zubewegen. Entscheidend ist, dass jeder direkte Link einen genannten Grund und einen Verantwortlichen hat.

Prüfen Sie dann beide Zeichnungen statt einer. Für den Normalweg, traceroute von jedem Standort zu jedem Dienstpräfix und bestätigen Sie, dass die Hops zum Diagramm passen. Für den Fehlerweg schalten Sie einen Tunnel ab und wiederholen es, denn eine Route, die nur funktioniert, solange alles läuft, ist nicht entworfen, sondern nur konfiguriert.

Bewahren Sie beide Zeichnungen zusammen mit der Zugriffsmatrix auf und sehen Sie sie wieder an, wenn ein Standort hinzukommt; die Kosten, die Sie verwalten, sind die Kosten der nächsten Änderung, nicht die Eleganz des aktuellen Bildes.