Braucht ein per Peering verbundenes Azure VNet sein eigenes VPN-Gateway?

Ein neues Spoke-VNet entsteht, der Hub hat bereits ein funktionierendes Site-to-Site-Gateway, und die naheliegende Frage ist, ob Sie für ein zweites Gateway zahlen müssen. Meist nicht: Gateway-Transit lässt das Spoke das Gateway des Hubs über das Peering nutzen. Drei Bedingungen entscheiden, ob das funktioniert, und keine davon ist am Peering-Statusabzeichen zu sehen. Peering-Konnektivität und die Berechtigung, ein fremdes Gateway zu nutzen, sind getrennte Einstellungen, daher beweisen zwei VMs, die sich bereits anpingen können, nichts über den VPN-Pfad.

Erste Bedingung: das Gateway und das Fehlen eines eigenen im Spoke

Azure unterstützt Gateway-Transit für VPN Gateway-SKUs außer Basic, und sowohl regionales als auch globales Peering kann ihn tragen. Das Spoke nutzt ein Gateway, das es nicht besitzt, kann also kein eigenes haben: Existiert im Spoke bereits ein Gateway oder ist bereits eine Remote-Gateway-Option ausgewählt, ist die gewünschte Transit-Einstellung nicht verfügbar oder wirkungslos. Prüfen Sie das, bevor Sie irgendetwas debuggen, denn das deaktivierte Kontrollkästchen ist das Symptom, nicht der Fehler. Lesen Sie zuerst die SKU und das vorhandene Gateway und schauen Sie dann auf die Peering-Einstellungen.

Löschen Sie ein vorhandenes Spoke-Gateway nicht, nur damit die Option erscheint, solange Sie nicht wissen, was davon abhängt. Die Migrationsreihenfolge ist wichtiger als das Kontrollkästchen.

Zweite Bedingung: eine Einstellung in jeder Peering-Richtung

Ein Peering sind zwei Objekte, eines auf jedem VNet, und die Transit-Einstellungen liegen auf verschiedenen Seiten dieses Paars. Das Peering des Hubs zum Spoke muss dem Hub-Gateway erlauben, das Spoke zu bedienen; das Peering des Spokes zum Hub muss das Gateway des Hubs akzeptieren. Microsofts Leitfaden zum Gateway-Transit benennt sie pro Richtung, und nur so behält man sie richtig im Blick:

Ein mit remote beschriftetes Steuerelement ändert seine Bedeutung je nachdem, welches VNet-Peering Sie bearbeiten, lesen Sie also die Richtung, nicht das Wort. Setzen Sie beide Seiten, speichern Sie und bestätigen Sie, dass das Peering an beiden Stellen als verbunden gemeldet wird.

Dritte Bedingung: Adressraum und Berechtigungsgrenzen

Transit kann nicht dafür sorgen, dass dasselbe Zielpräfix zwei Netzwerke bedeutet, daher müssen Hub-, Spoke- und lokale Bereiche disjunkt sein, bevor irgendetwas davon funktioniert. Die VNets können auch in verschiedenen Abonnements oder verschiedenen Mandanten liegen; das ist kein Verbot, aber die Identität, die jedes Peering erstellt oder aktualisiert, braucht die erforderlichen Berechtigungen auf diesem Netzwerk. Änderungen über Abonnements hinweg scheitern häufig an Berechtigungen, und der Fehler wird leicht als Topologieproblem missverstanden.

Schreiben Sie die Bereiche und die Eigentümer vor der Änderung auf. Raten bei einem von beiden erzeugt ein Peering, das verbindet und nichts weiterleitet.

Prüfen Sie mit effektiven Routen, nicht mit dem Peering-Status

Sehen Sie sich die effektiven Routen auf der Netzwerkschnittstelle einer Spoke-Arbeitslast an und finden Sie das tatsächliche lokale Präfix. Prüfen Sie die Routentabelle des Subnetzes und ob die Gateway-Routenverteilung deaktiviert ist, denn eine benutzerdefinierte Route oder ein Prüfgerät kann den Pfad überstimmen, den die Peering-Flags nahelegen. Bestätigen Sie dann die andere Richtung: Das lokale Netzwerk muss wissen, wie es das Spoke-Präfix über die Site-to-Site-Verbindung erreicht, sei es durch gelernte Ankündigungen oder durch eine explizite Route und einen passenden Eintrag für das geschützte Netzwerk auf dem Kundengerät. Fehlt das Präfix auf einer der beiden Seiten, sind die Peering-Flags nicht das, was geändert werden muss.

Testen Sie einen Dienst aus einer Spoke-Arbeitslast und verfolgen Sie die Antwort. Ein Test vom VPN-Gateway oder von einer Hub-VM nutzt ein anderes Quellpräfix und einen anderen Pfad.

Wenn die Topologie auch Point-to-Site-Clients bedient, validieren Sie deren installierte Routen separat. Windows-Clientpakete müssen nach einer Topologieänderung möglicherweise neu erzeugt werden, und das ist eine Aufgabe für das Client-Routing, nicht der Beweis, dass die Gateway-Freigabe fehlgeschlagen ist.

Was die gemeinsame Nutzung eines Gateways nicht gewährt

Gateway-Transit ist eine Routing-Erleichterung, keine Autorisierung. Netzwerksicherheitsgruppen, lokale Filter und Regeln auf Dienstebene entscheiden weiterhin, was eine Spoke-Arbeitslast erreichen darf, aktivieren Sie also den konkreten Dienst von Quelle zu Ziel, statt anzunehmen, der gemeinsame Tunnel erlaube alles dahinter.

Peering ist auch nicht in der Weise transitiv, wie man es sich erhofft. Das Hinzufügen eines weiteren Spokes oder eines privaten Endpunkts bringt eigene Routing- und Zugriffsanforderungen mit, die die bestehende Transit-Einstellung nicht abdeckt.