Zwei On-Prem-VPN-Adressen: zwei Azure-Peers, nicht einer

Das Diagramm zeigt zwei Internetanbindungen am Standort und ein Azure-VPN-Gateway, also erhält das lokale Netzwerkgateway beide öffentlichen Adressen. Das sieht ordentlich aus und funktioniert nicht so, wie das Diagramm es nahelegt. Jedes lokale VPN-Gerät ist eine eigene Peer-Beziehung, und Microsofts Entwurf für mehrere Geräte gibt jedem ein eigenes lokales Netzwerkgateway und eine eigene Verbindung. Eine zweite Adresse zu einer einzigen Ressource hinzuzufügen, erzeugt keinen zweiten Peer. Es erzeugt eine Ressource, die keines der beiden Geräte richtig beschreibt.

Der Mythos: ein Gateway, zwei Adressen

Ein lokales Netzwerkgateway beschreibt einen entfernten Peer: einen öffentlichen Endpunkt und die privaten Präfixe dahinter. Es gibt keine unterstützte Möglichkeit, dieser Ressource die Bedeutung »eines dieser beiden Geräte« zu geben.

Dieselbe Verwechslung gibt es in der anderen Richtung, wo zwei öffentliche Azure-IPs als Beleg dafür gelesen werden, dass zwei Azure-Gateways existieren.

Zählen Sie die Objekte, dann die Tunnel

Nehmen Sie zwei unabhängig betriebene lokale Geräte, jedes mit eigener öffentlicher Adresse und Zugang zu denselben privaten Netzen, plus ein routenbasiertes Azure-Gateway im Aktiv-Aktiv-Modus. Das Azure-Gateway hat zwei aktive Instanzen mit getrennten öffentlichen IPs. Jedes lokale Gerät verbindet sich mit beiden Instanzen. Das ist das vollständige Mesh, und die Objektzahl folgt daraus, nicht aus dem Diagramm.

Die Arithmetik ist kurz genug, um sie in das Designdokument zu kopieren:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

Eine Verbindungsressource kann mehr als einen zugrunde liegenden Tunnel tragen, vier Tunnel bedeuten also nicht vier virtuelle Netzwerkgateways. Zwei öffentliche Azure-IPs sind auch nicht dieselben Objekte wie die beiden lokalen Netzwerkgateways, die den entfernten Standort beschreiben.

Was Aktiv-Aktiv auf der Azure-Seite hinzufügt

Aktiv-Aktiv ändert das Azure-Gateway von einer aktiven Instanz auf zwei, jede mit eigener öffentlicher IP, und erst dadurch wird ein vollständiges Mesh überhaupt möglich. Es verdoppelt nicht den Durchsatz eines einzelnen Flows. Es beseitigt auch nicht die Notwendigkeit, dass die lokale Seite Multipath mit gleichen Kosten unterstützt, wenn beide Geräte gleichzeitig weiterleiten. Bestätigen Sie Gatewaymodus, SKU und Fähigkeiten des entfernten Geräts, bevor Sie etwas bereitstellen.

Ein Gateway im passiven Standby ist ein völlig gültiges Design; es ergibt nur eine andere Tunnelzahl.

BGP macht beide Wege nutzbar

Für den Entwurf mit mehreren Geräten betreiben beide lokalen Geräte BGP. Geben Sie jedem eine eindeutige BGP-Peer-Adresse und annoncieren Sie dieselben vorgesehenen privaten Präfixe über die relevanten Wege. Die privaten Präfixe kennzeichnen die geschützten Netze, während die öffentlichen Adressen kennzeichnen, wo die verschlüsselten Trägerverbindungen enden. Wer beides verwechselt, erhält einen Entwurf, in dem jeder Tunnel steht und die Routen falsch sind.

Planen Sie die Rückwegführung und jede zustandsbehaftete Prüfung, die jeden der beiden Wege aushalten muss. Eine gesunde IKE-Sitzung an jedem Endpunkt beweist nicht, dass eine Arbeitslast jede angekündigte Route nutzen kann.

Flussbasierte Auswahl ist kein Bündeln von Bandbreite

Azure wählt pro Fluss einen Weg über einen Hash aus Adressierung und Ports des Flusses. Im stationären Zustand nehmen Pakete eines bestimmten TCP- oder UDP-Flusses normalerweise denselben Tunnel, und die lokale Seite kann für die Rückrichtung einen anderen Tunnel wählen. Zwei Geräte und vier Tunnel verbessern daher die Verfügbarkeit, nicht die Geschwindigkeit einer Übertragung. Wenn eine Anbieterseite Aggregation verspricht, beschreibt sie eine andere Funktion oder ein Missverständnis.

Testen Sie mit parallelen Flüssen, wenn Sie die Wege sehen wollen, und mit einem einzelnen Fluss, wenn Sie die Grenze sehen wollen.

Welche Redundanz Sie tatsächlich entfernt haben

Zwei WAN-Adressen auf einem Gerät verbessern die Optionen für die Zugangsleitung, teilen aber Stromversorgung, Software und Fehlerzustand dieses Geräts. Sie sind nicht dasselbe wie zwei Geräte, und keine Azure-seitige Konfiguration ändert das. Folgen Sie dem unterstützten Dual-WAN- oder Cluster-Entwurf des Herstellers, statt Redundanz aus der Adresszahl abzuleiten. Testen Sie es dann: Entfernen Sie jeweils einen Weg und bestätigen Sie die verbleibenden Routen plus einen echten Anwendungsaustausch in beide Richtungen.

Erwarten Sie Verzögerungen bei Erkennung und Konvergenz, und erwarten Sie, dass einige bestehende Sitzungen enden.