Routeninjektion in Spoke-virtuellen Netzwerken

Azure Route Server vereinfacht die Netzwerkverwaltung in Hub-and-Spoke-Architekturen, indem Routen automatisch in virtuelle Speichennetzwerke eingefügt werden. Diese Funktion beseitigt die Notwendigkeit, benutzerdefinierte Routen über mehrere Speichennetzwerke manuell zu erstellen und zu verwalten und gleichzeitig dynamisches Routing über virtuelle Netzwerkgeräte zu ermöglichen.

In herkömmlichen Designs für Hub-and-Spoke müssen Administratoren benutzerdefinierte Routen (UDRs) in jedem Spoke-Netzwerk konfigurieren, um den Datenverkehr über geteilte Netzwerkgeräte im Hub zu leiten. Dieser manuelle Ansatz wird schwierig zu halten, da die Anzahl der Speichen steigt. Azure Route Server behebt diese Komplexität, indem eine zentrale Routinglösung bereitgestellt wird, die automatisch Routen verteilt, die von virtuellen Netzwerkgeräten an alle verbundenen Spoke-Netzwerke gelernt werden.

Zu den wichtigsten Vorteilen der Route Server-Routeneinfügung gehören:

• Vereinfachte Verwaltung: Beseitigt die manuelle UDR-Konfiguration in Speichennetzwerken.
• Dynamisches Routing: Passt sich automatisch an Netzwerktopologieänderungen an
• Zentrale Steuerung: Stellt einen einzelnen Punkt für die Routenverteilung vom Hub bereit.
• Skalierbare Architektur: Unterstützt das Wachstum der Speichennetzwerkanzahl ohne mehr Komplexitätsinjektion in virtuelle Speichennetzwerke

Grundlegende Hub-and-Spoke-Topologie

Das folgende Diagramm veranschaulicht ein typisches Hub-and-Spoke-Design mit Azure Route Server. Das virtuelle Hubnetzwerk enthält sowohl eine virtuelle Netzwerk-Appliance als auch einen Routenserver, während zwei virtuelle Spoke-Netzw=eichennetze Anwendungsworkloads hosten.

Diagramm, das die Hub-and-Spoke-Topologie mit Azure Route Server zeigt, der automatisch Routen zu virtuellen Speichennetzwerken einfügt.

Funktionsweise der Routeneinfügung

In dieser Konfiguration kündigt die virtuelle Netzwerkanwendung Netzwerkpräfixe an den Route Server über BGP-Peering an. Der Route-Server fügt diese Routen dann automatisch in die effektiven Routen virtueller Computer sowohl im Hub als auch in virtuelle Netzwerke ein.

Wichtige Anforderungen für die Routeneinfügung:

• Virtuelle Spoke-Netzwerke müssen mit dem virtuellen Hubnetzwerk verbunden sein.
• Virtuelles Netzwerkpeering muss die Einstellung Gateway oder Route Server des virtuellen Remotenetzwerks verwenden enthalten.
• Virtuelle Netzwerk-Appliance muss BGP-Peering mit Route Server einrichten

Bei diesem Ansatz wird die Notwendigkeit manueller benutzerdefinierter Routen in Speichennetzwerken beseitigt, da der Route Server die Routenverteilung automatisch verarbeitet. Eine Standardroute (0.0.0.0/0), die von der NVA angekündigt wird, leitet zum Beispiel den gesamten Datenverkehr aus Spoke-Netzwerken über die Sicherheitsappliance zur Inspektion weiter.

Lokale Konnektivität über virtuelle Netzwerkgeräte

Virtuelle Netzwerkgeräte können über verschiedene Technologien wie IPsec VPNs und SD-WAN Lösungen verbindungen mit lokalen Netzwerken bereitstellen. Die dynamischen Routingfunktionen von Route Server verbessern diese Szenarien, indem der automatische Routenaustausch zwischen Azure und lokalen Netzwerken ermöglicht wird.

Bidirektionales Routenlernen

In dieser Konfiguration erleichtert Route Server bidirektionales Routenlernen:

Azure zu lokalen Umgebungen: Die NVA lernt Azure-Netzwerkpräfixe von Routenservern und übermittelt sie mit dynamischen Routingprotokollen an lokale Netzwerke.

Lokal in Azure: Die NVA empfängt lokale Routen und kündigt sie an Route Server an, wodurch sie in virtuelle Spoke-Netzwerke eingefügt werden.

Dieser dynamische Ansatz beseitigt die Notwendigkeit einer statischen Routenkonfiguration und passt sich automatisch an Netzwerktopologieänderungen an beiden Seiten der Verbindung an.

Strategien zur Privaten Verkehrsüberwachung

Wenn Sie die Datenverkehrsüberprüfung für die Kommunikation von Speiche zu Speiche und Speiche zu On-Premises implementieren, ist das Verständnis des Routenankündigungsverhaltens von Route Server entscheidend für die ordnungsgemäße Konfiguration.

Einschränkungen für Routenanzeigen

Azure Route Server weist bestimmte Verhaltensweisen beim Behandeln von Routenanzeigen auf:

• Gleiche oder längere Präfixe: Route Server kündigt keine Routen mit Präfixen an, die dem virtuellen Netzwerkadressraum entsprechen oder länger sind.
• Kürzere Präfixe: Route Server kündigt Routen mit kürzeren Präfixen (Supernets) als den Adressraum des virtuellen Netzwerks an.

Supernet-Ansatz für private Verkehrskontrollen

Um privaten Datenverkehr zwischen Spokes zu prüfen, konfigurieren Sie die NVA so, dass Supernets angekündigt werden, die Ihre virtuellen Netzwerkadressen umfassen:

Beispielkonfiguration:

• Virtueller Netzwerkadressraum: 10.0.0.0/16
• NVA angekündigte Route: 10.0.0.0/8 (Supernet)
• Ergebnis: Der Route Server fügt die Supernetz-Route ein und leitet den Datenverkehr durch die NVA.

Dieses Verhalten entspricht den BGP-Routenanzeigeprinzipien mit VPN-Gateway.

Hybridkonnektivität mit virtuellen Netzwerkgateways

Wenn Sie Route Server mit VPN- oder ExpressRoute-Gateways im selben virtuellen Netzwerk kombinieren, wird die Routenrangfolge für die Datenverkehrsflussverwaltung wichtig.

Routenrangfolgeverhalten

Virtuelle Netzwerkgatewayrouten haben Vorrang vor Route serverinjizierten Routen aufgrund ihrer Spezifität:

• Gatewayrouten: Spezifischere Präfixe, die von VPN- oder ExpressRoute-Gateways gelernt wurden
• Route Server Routes: Weniger spezifische Routen (z. B. Standardrouten) von NVAs

Diese Rangfolge bedeutet, dass lokale Präfixe, die von Gateways gelernt wurden, Standardrouten außer Kraft setzen, die von Route Server eingefügt werden, um ein optimales Routing für bekannte Ziele sicherzustellen.

Steuern der Routenverteilung

So verwalten Sie, welche Routen virtuelle Spoke-Netzwerke erreichen:

Verbreitung von Gatewayrouten deaktivieren: Verhindern Sie, dass Speichensubnetze lokale Routen erlernen, indem Sie "Gatewayrouten propagieren" in Speichenroutentabellen deaktivieren.

Verwenden Sie Standardrouten-UDRs: Konfigurieren Sie benutzerdefinierte Routen mit 0.0.0.0/0, die auf die NVA verweisen, um die Datenverkehrsüberprüfung sicherzustellen.

BGP-Community-Kontrolle: Konfigurieren Sie NVAs so, dass Routen mit der no-advertise BGP-Community (65535:65282) angekündigt werden, um zu verhindern, dass Route Server Routen an andere BGP-Peers weiterleitet.

SD-WAN Koexistenz mit ExpressRoute und Azure Firewall

Unternehmensumgebungen kombinieren häufig SD-WAN, ExpressRoute und Azure Firewall, um umfassende Konnektivität und Sicherheit zu bieten. Route Server ermöglicht eine nahtlose Integration dieser Technologien bei gleichzeitiger Aufrechterhaltung der zentralen Datenverkehrsüberprüfung.

Architekturkomponenten

Spoke-Netzwerke: Konfigurieren mit Routentabellen, die das Lernen von Routen von ExpressRoute oder Route Server verhindern, indem sie auf Standardrouten (0.0.0.0/0) verweisen, die auf Azure Firewall zeigen.

Azure Firewall: Erlernt Routen von ExpressRoute und SD-WAN-NVAs über den Route Server und trifft intelligente Routingentscheidungen für den lokalen Datenverkehr.

Routenanzeigesteuerung: SD-WAN NVAs sollten Routen mit der no-advertise BGP-Community bewerben, um die Routeinjektion über ExpressRoute zu verhindern.

Überlegungen zu privaten Endpunkten

Berücksichtigen Sie bei der Implementierung dieser Architektur mit privaten Endpunkten die Routingsymmetrieanforderungen:

• Asymmetrisches Routingrisiko: Der Datenverkehr von lokalen zu privaten Endpunkten umgeht die Firewallüberprüfung.
• Lösung: Aktivieren von Routingtabellen-Netzwerkrichtlinien für private Endpunkte in Subnetzen, die private Endpunkte hosten

Diese Konfiguration stellt die Routingsymmetrie sicher und verwaltet Sicherheitsrichtlinien für privaten Endpunktdatenverkehr.

Überlegungen zur Netzwerkdatenverkehrssymmetrie

Wenn Sie mehrere NVA-Instanzen für hohe Verfügbarkeit oder Skalierbarkeit bereitstellen, ist die Aufrechterhaltung der Datenverkehrssymmetrie für zustandsbehaftete Netzwerkgeräte wie Firewalls der nächsten Generation von entscheidender Bedeutung.

Verkehrsflussszenarien

Internetgebundener Datenverkehr: NVAs verwenden die Quellnetzwerkadressübersetzung (Source Network Address Translation, SNAT), um sicherzustellen, dass der Rückgabedatenverkehr dieselbe Appliance erreicht, die den ausgehenden Fluss verarbeitet hat.

Eingehender Internetdatenverkehr: NVAs erfordern sowohl ZIEL-NAT (DNAT) als auch Quell-NAT (SNAT), um bidirektionale Datenverkehrssymmetrie sicherzustellen.

Azure-zu-Azure-Datenverkehr: Da virtuelle Quellcomputer unabhängige Routingentscheidungen treffen, ist SNAT erforderlich, um die Datenverkehrssymmetrie über mehrere NVA-Instanzen hinweg zu erreichen.

Bereitstellungsoptionen für hohe Verfügbarkeit

Aktive/aktive Konfiguration: Stellen Sie mehrere NVA-Instanzen mit identischen Routenanzeigen bereit und verwenden Sie SNAT für die Datenverkehrssymmetrie.

Aktive/passive Konfiguration: Stellen Sie mehrere NVA-Instanzen bereit, bei denen die sekundäre Instanz Routen mit längerem AS-Pfad ankündigt, wobei die primäre Pfadpriorität gewährleistet ist, bis ein Failover auftritt.

Einschränkungen des Routenservers

Route Server wird nur in der Steuerebene betrieben und beteiligt sich nicht an der Weiterleitung im Datenverkehr. Wenn Routen an den Route-Server angekündigt werden, müssen NVAs die nächsten Hop-Ziele wie folgt angeben:

• Die NVA selbst
• Ein Load-Balancer vor dem NVA
• Eine andere NVA oder Firewall im selben virtuellen Netzwerk

Dieser Entwurf stellt eine ordnungsgemäße Datenverkehrsweiterleitung sicher, während die Rolle des Routingservers als Routingsteuerungspunkt beibehalten wird.

Verwandte Inhalte

• Erfahren Sie mehr über die Unterstützung von Azure Route Server für ExpressRoute und Azure VPN.
• Erfahren Sie, wie Sie das Peering zwischen Azure Route Server und Network Virtual Appliance konfigurieren.