Azure-Peering oder VNet-zu-VNet-VPN? Entscheiden, bevor geroutet wird

Azure bietet mindestens zwei Wege, zwei virtuelle Netzwerke zu verbinden, und es sind keine austauschbaren Einstellungen am selben Objekt. Peering verbindet die VNets über Microsofts Backbone ohne Gateway; ein VNet-zu-VNet-VPN setzt eine IPsec-Beziehung zwischen zwei Gateways, die Sie bereitstellen, dimensionieren und überwachen. Die Entscheidung hängt an drei Bedingungen, und wer vor dem Setzen einer Route nicht alle drei beantworten kann, baut eine Krücke für ein Modell, das er nie gewählt hat.

Drei Bedingungen, die das Modell entscheiden

Die erste ist, ob irgendetwas in der Anforderung eine IPsec-Grenze braucht, die Ihnen gehört und auf die Sie zeigen können. Die zweite ist, ob die Adressräume sauber sind und die beiden VNets nur miteinander sprechen müssen. Die dritte ist, wem ein transitiver Pfad und die Gateway-Rechnung gehören. Beantworten Sie sie in dieser Reihenfolge, denn die erste kann Peering ausschließen, so attraktiv die zweite auch wirkt.

Gemeinsam ist beiden Modellen eine harte Adressregel: Die VNet-Adressräume dürfen sich nicht überlappen. Weder Peering noch ein VNet-zu-VNet-VPN ist ein unterstützter Weg, zwei identische Bereiche eindeutig zu machen, und eine Überlappung verlangt ein Mapping-Design oder eine Neugestaltung, nicht einen anderen Verbindungstyp.

Bedingung 1: Brauchen Sie eine IPsec-Grenze, die Ihnen gehört?

Peering führt Verkehr über Azures privates Backbone und benötigt für die Peering-Verbindung selbst kein VPN-Gateway. Das ist eine Aussage über den Transport, keine Aussage über Verschlüsselung, die Sie einem Prüfer als „wir fahren IPsec“ vorlegen können. Wenn die Anforderung einen kundenseitig konfigurierten Tunnel, eine bestimmte IKE-Richtlinie oder eine Grenze nennt, die auf Geräten endet, die Sie kontrollieren, erfüllt Peering das nicht, so privat das Backbone auch ist.

Ein VNet-zu-VNet-VPN liefert diese Grenze: zwei Gateways, eine IPsec/IKE-Beziehung, gemeinsame Schlüssel und die gesamte Betriebsfläche, die dazugehört. Sie erben Tunnelzustand, Gateway-Kapazität, SKU-Grenzen und die Überwachung, die belegt, dass der Tunnel steht. Das ist die richtige Antwort, wenn es in der Anforderung genau um diese Grenze geht, die in der Peering-Übersicht als eigener Verbindungstyp gegenüber Peering beschrieben wird.

Seien Sie in der anderen Richtung genauso sorgfältig. „Wir brauchen Verschlüsselung zwischen VNets“ erfüllt oft schon das TLS der Workload, und dann ist ein Gateway ein Kostenfaktor ohne Anforderung dahinter. Schreiben Sie den Satz, den der Prüfer lesen wird, bevor Sie den Mechanismus wählen.

Bedingung 2: Ist die Topologie direkt, oder muss etwas transitieren?

Peering ist nicht transitiv. Zwei VNets, die mit einem Hub gepeert sind, sind dadurch nicht miteinander verbunden, und eine Route, die in eine Richtung zu funktionieren scheint, ist meist ein Peering, das nur auf einer Seite Connected erreicht hat. Beide Seiten müssen existieren und beide müssen Connected zeigen — das ist das Erste, was Sie prüfen, wenn Verkehr still verschwindet.

Geht es in der Anforderung um Erreichbarkeit des lokalen Netzes über einen Hub, ist Gateway-Transit ein eigenes Design mit bestimmten Rollen: Der Hub besitzt das Gateway, das Spoke-Peering erlaubt Gateway-Transit, und das Spoke muss weitergeleiteten Verkehr zulassen. Das sind Eigenschaften des Peerings, keine automatischen Folgen des Verbindens der VNets:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Die effektive Routentabelle ist die ehrliche Antwort auf „existiert der Pfad?“. Sie zeigt den Typ des nächsten Hops, den die Plattform tatsächlich nutzt, daher erscheint ein Peering, das konfiguriert aussieht, aber nicht verbunden ist, als fehlende oder falsche Route statt als Rätsel.

Bedingung 3: Wem gehören der transitive Pfad und die Rechnung?

Jeder zusätzliche Hop hat einen Eigentümer. Bei Peering bedeutet ein neues VNet ein neues Peering-Paar auf beiden Seiten und für Transit einen Hub, der Verkehr weiterleitet, sowie eine Routentabelle, die weiter darauf zeigt. Bei einem VPN bedeutet ein neues VNet ein weiteres Gateway oder eine weitere Verbindung an einem bestehenden, mit eigener Kapazitätsgrenze, die zu beobachten ist.

Die Kosten folgen derselben Form, aber nicht denselben Posten: Peering berechnet Verbindung und Datenübertragung, ein VPN addiert Gateway-Stunden und eigene Übertragungskosten. Vergleichen Sie die Summe für die Topologie, die Sie tatsächlich ein Jahr betreiben, einschließlich des zweiten Tunnels und der Überwachung, nicht den Preis einer Verbindung von heute. Rechnen Sie die Arbeit ein, die niemand fakturiert: Jemand muss Schlüssel rotieren, den Tunnelzustand beobachten und nachts um drei den Alarm beantworten, wenn ein Gateway neu startet. Dieser Posten entscheidet meist die Diskussion, weil er der einzige ist, der nie in einem Angebot auftaucht.

Was immer Sie wählen, testen Sie drei Flüsse: den beabsichtigten, einen abgelehnten, der abgelehnt bleiben muss, und den Wiederherstellungsfall, in dem das Hub-Gateway oder ein Peering ausgefallen ist. Ein Modell, das nur den glücklichen Pfad erklärt, ist nicht verifiziert, sondern vorgeführt.

Prüfen Sie die Wahl gegen ihre eigene Behauptung

Schreiben Sie einen Satz, der Modell, Grenze und Eigentümer nennt, und prüfen Sie dann, ob der bereitgestellte Zustand dazu passt. Bei Peering heißt das: beide Peering-Zustände Connected, die effektive Route zeigt den Peering-Nexthop für das Zielpräfix, und kein Gateway im Pfad. Bei einem VNet-zu-VNet-VPN heißt es: beide Verbindungen Connected, passende Schlüssel und Richtlinien auf beiden Gateways und eine Route, deren nächster Hop das virtuelle Netzwerk-Gateway ist.

Widersprechen die Prüfungen dem Satz, korrigieren Sie zuerst den Satz. Der größte Teil der Verwirrung in diesen Designs kommt von einem Hybrid, den niemand beschrieben hat: ein Peering für das Workload-Subnetz, ein VPN für einen Altbestand und eine Routentabelle, die still einen davon bevorzugt.