ExpressRoute plus VPN: Welche Fehlerdomänen decken Sie ab?

Ein IPsec-Tunnel über ExpressRoute Private Peering ergänzt Verschlüsselung für einen Transport, der bereits existiert. Ein zweiter Tunnel verbessert die Endpunktverfügbarkeit und tut für den Carrier-Pfad unter beiden absolut nichts. Diese Unterscheidung geht leicht verloren, wenn die Dashboards zwei grüne Tunnel zeigen und die Designprüfung eine andere Frage stellt: Welche Ausfälle muss diese Verbindung überstehen? Beantworten Sie das zuerst und zählen Sie dann Tunnel, denn die Anzahl grüner Anzeigen ist eine Eigenschaft der Verschlüsselungsschicht und die Anzahl der Fehlerdomänen eine Eigenschaft des gesamten Pfads.

Beginnen Sie mit Ausfällen, nicht mit grünen Tunneln

Schreiben Sie vier Zeilen, bevor Sie irgendetwas zeichnen: ein fehlgeschlagener VPN-Endpunkt oder eine Peer-Instanz, ein fehlgeschlagener lokaler Router oder First-Mile-Anschluss, der gemeinsame ExpressRoute-Pfad, der ausfällt, und IPsec, das nicht verfügbar wird, während Private Peering weiterhin Datenverkehr trägt. Jede Zeile benennt, was das Design bewahren muss, und jede wird durch einen anderen Mechanismus beantwortet.

Microsoft dokumentiert Site-to-Site-VPN mit privaten IP-Adressen über ExpressRoute Private Peering und die unterstützte Koexistenz mit internetbasierten Site-to-Site-Verbindungen. Diese Koexistenz ist ein anderes Underlay-Design und entsteht nicht einfach dadurch, dass Sie einen weiteren privaten Tunnelendpunkt hinzugefügt haben.

Fehlerdomäne 1: der VPN-Endpunkt

Zwei Tunnel auf einem Gateway sind meist Active-Active-Paare, die auf derselben Azure-seitigen Ressource enden. Sie schützen vor einem Problem mit einem einzelnen Tunnel oder einer Instanz und schützen nicht davor, dass diese Ressource nicht verfügbar, umkonfiguriert oder ohne Kapazität ist. Endpunktredundanz bedeutet einen zweiten unterstützten Endpunkt mit eigenem Pfad und eigener Konfiguration sowie eine Route, die ihn erreichen kann.

Prüfen Sie, was Sie tatsächlich bereitgestellt haben, statt was das Diagramm sagt, denn das Portal gruppiert diese Ressourcen so, dass ihre Beziehung verborgen bleibt:

az network vpn-connection show -g rg-connectivity -n vpn-to-hub   --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub   --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'

Wenn beide Tunnel auf ein Gateway mit einer öffentlichen IP zeigen, haben Sie Endpunktredundanz einer bestimmten und begrenzten Art. Das mag genau das sein, was die Anforderung verlangt, und es sollte so formuliert werden, statt als redundante Verbindung beschrieben zu werden.

Fehlerdomäne 2: der lokale Pfad und der Carrier

Unter der Verschlüsselung liegt eine physische und kommerzielle Realität: ein Kundengerät, eine Querverbindung, ein Anbieternetz und ein Peering-Standort. die ExpressRoute-Verfügbarkeitsrichtlinien sind eindeutig, dass Ende-zu-Ende-Redundanz die Kunden- und die Dienstanbietersegmente einschließt, nicht nur die Microsoft-Seite. Zwei logische Pfade, die sich einen Router, eine Stromversorgung oder einen First-Mile-Anschluss teilen, teilen weiterhin diese Abhängigkeit.

Hier scheitert ein Design üblicherweise in einer ehrlichen Prüfung. Zwei Leitungen desselben Anbieters, die im selben Gebäude enden, auf Geräten aus derselben Bestellung, sind keine zwei Fehlerdomänen. Sie sind eine Fehlerdomäne mit zwei Rechnungen.

Stellen Sie die Carrier-Frage schriftlich: Welche dieser Pfade divergieren, wo, und was ist das dokumentierte Verhalten, wenn das gemeinsame Segment ausfällt? Eine mündliche Zusicherung während eines Design-Calls übersteht den Ausfall nicht, für den Sie entwerfen.

Fehlerdomäne 3: die Route, die ohne IPsec überlebt

Private Peering und IPsec können konkurrierende Routen zum selben Anwendungspräfix anbieten. Wenn die geschützte Route verschwindet, kann eine überlebende direkte ExpressRoute-Route weiterhin nutzbar sein, ohne die Verschlüsselungsschicht, die der Tunnel bot. Ob das akzeptabel ist, ist eine Richtlinienentscheidung, und sie wird am häufigsten implizit gelassen.

Verschlüsselungs- und Verfügbarkeitsanforderungen können hier tatsächlich kollidieren. „Jede überlebende Route zählt als Erfolg“ ist eine Verfügbarkeitsaussage, die die Verschlüsselungsfrage still mit „nein“ beantwortet. Schreiben Sie auf, welche gewinnt, für welche Präfixe und wer es genehmigt hat.

az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o table

Vergleichen Sie die gelernten Routen mit den erwarteten Präfixen. Ein Rückfallweg, der eine kleine Verwaltungslast trägt, kann für diese Last völlig ausreichend und weit von der Kapazität entfernt sein, die der Produktionsbedarf benötigt, also halten Sie die Kapazitätsannahme neben der Route fest.

Erfassen Sie drei getrennte Zeilen, kein einziges Urteil

Halten Sie Endpunktredundanz, Transportredundanz und Disaster Recovery als getrennte Einträge im Designprotokoll, jeder mit eigenem Mechanismus, eigener Verifikation und eigenem Verantwortlichen. Wenn eine Incident-Überprüfung fragt, warum die Verbindung einen Gateway-Neustart, aber keinen Fasernschnitt überstand, antworten drei Zeilen in einem Satz; ein einzelnes Kästchen „redundant“ kann das nicht.

Testen Sie dann die Zeilen, die Sie günstig testen können. Lassen Sie einen Tunnel ausfallen und bestätigen Sie, dass der Verkehr umzieht und neu verschlüsselt wird. Ziehen Sie eine Route zurück und bestätigen Sie, dass der überlebende Pfad der beabsichtigte ist, und bestätigen Sie dann, ob er noch verschlüsselt ist. Dokumentieren Sie die Ausfälle, die Sie nicht simulieren konnten, denn eine ungetestete Zeile ist eine Annahme und sollte als solche gekennzeichnet werden.

Das nützliche Ergebnis ist eine kurze Tabelle plus ein Satz pro Zeile. Hat eine Zeile keinen Mechanismus, ist das der Befund, und er ist in einer Designprüfung viel billiger zu entdecken als während eines Carrier-Ausfalls, den beide Tunnel nie überstanden hätten.