Routing von Datenverkehr für virtuelle Netzwerke

  • Artikel

Es wird beschrieben, wie Azure Datenverkehr zwischen Azure, lokalen Speicherorten und Internetressourcen weiterleitet. Azure erstellt automatisch eine Routentabelle für jedes Subnetz in einem virtuellen Azure-Netzwerk und fügt der Tabelle Systemstandardrouten hinzu. Weitere Informationen zu virtuellen Netzwerken und Subnetzen finden Sie unter Virtuelle Netzwerke im Überblick. Sie können einige Systemrouten von Azure durch benutzerdefinierte Routen außer Kraft setzen und den Routentabellen weitere benutzerdefinierte Routen hinzufügen. Azure leitet ausgehenden Datenverkehr aus einem Subnetz basierend auf den Routen in der Routentabelle eines Subnetzes weiter.

Systemrouten

Azure erstellt automatisch Systemrouten und weist die Routen allen Subnetzen eines virtuellen Netzwerks zu. Sie können keine Systemrouten erstellen oder entfernen, aber Sie können einige Systemrouten durch benutzerdefinierte Routen außer Kraft setzen. Azure erstellt Standardsystemrouten für jedes Subnetz und fügt weitere optionale Standardrouten für spezifische Subnetze hinzu (bzw. jedes Subnetz, wenn Sie bestimmte Azure-Funktionen nutzen).

Standard

Jede Route enthält ein Adresspräfix und einen Typ des nächsten Hops. Wenn Datenverkehr, der ein Subnetz verlässt, an eine IP-Adresse innerhalb des Adresspräfix einer Route gesendet wird, ist die Route mit dem Präfix die von Azure verwendete Route. Erfahren Sie mehr darüber, wie Azure eine Route auswählt, wenn mehrere Routen die gleichen Präfixe oder überlappende Präfixe enthalten. Bei jeder Erstellung eines virtuellen Netzwerks erstellt Azure automatisch die folgenden Standardsystemrouten für jedes Subnetz im virtuellen Netzwerk:

Quelle Adresspräfixe Typ des nächsten Hops
Standard Für das virtuelle Netzwerk eindeutig Virtuelles Netzwerk
Standard 0.0.0.0/0 Internet
Standard 10.0.0.0/8 Keine
Standard 172.16.0.0/12 Keiner
Standard 192.168.0.0/16 Keine
Standard 100.64.0.0/10 Keine

Die in der obigen Tabelle aufgeführten Typen des nächsten Hops geben an, wie Datenverkehr von Azure weitergeleitet wird, der für das angegebene Adresspräfix bestimmt ist. Erklärungen zu den Typen des nächsten Hops:

  • Virtuelles Netzwerk: Leitet Datenverkehr zwischen Adressbereichen im Adressraum eines virtuellen Netzwerks weiter. Azure erstellt eine Route mit einem Adresspräfix, das jeweils dem Adressbereich entspricht, der im Adressraum eines virtuellen Netzwerks definiert ist. Wenn für den Adressraum des virtuellen Netzwerks mehrere Adressbereiche definiert sind, erstellt Azure für jeden Adressbereich eine gesonderte Route. Azure leitet Datenverkehr automatisch zwischen Subnetzen weiter, indem die Routen verwendet werden, die für jeden Adressbereich erstellt wurden. Es ist nicht erforderlich, dass Sie Gateways für Azure definieren, um Datenverkehr zwischen Subnetzen weiterzuleiten. Obwohl ein virtuelles Netzwerk Subnetze enthält und jedes Subnetz einen definierten Adressbereich aufweist, erstellt Azure keine Standardrouten für Subnetzadressbereiche. Jeder Subnetzadressbereich liegt in einem Adressbereich des Adressraums eines virtuellen Netzwerks.

  • Internet: Leitet Datenverkehr, der vom Adresspräfix angegeben wird, in das Internet weiter. Für die Systemstandardroute wird das Adresspräfix 0.0.0.0/0 angegeben. Wenn Sie die Standardrouten von Azure nicht außer Kraft setzen, leitet Azure Datenverkehr für alle Adressen, die nicht von einem Adressbereich in einem virtuellen Netzwerk angegeben sind, an das Internet weiter. Für dieses Routing gilt eine Ausnahme. Wenn die Zieladresse die Adresse von einem der Azure-Dienste ist, leitet Azure den Datenverkehr über das Azure-Backbonenetzwerk direkt an den Dienst weiter, und nicht in das Internet. Der Datenverkehr zwischen Azure-Diensten wird nicht über das Internet übertragen. Dies gilt unabhängig davon, in welcher Azure-Region das virtuelle Netzwerk vorhanden ist oder in welcher Azure-Region eine Instanz des Azure-Diensts bereitgestellt wird. Sie können die Standardsystemroute von Azure für das Adresspräfix 0.0.0.0/0 durch eine benutzerdefinierte Route außer Kraft setzen.

  • Keine: Datenverkehr, der an den Typ Keine des nächsten Hops weitergeleitet wird, wird verworfen und nicht an Orte außerhalb des Subnetzes weitergeleitet. Azure erstellt automatisch Standardrouten für die folgenden Adresspräfixe:

    • 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16: Für die private Nutzung in RFC 1918 reserviert.

    • 100.64.0.0/10: In RFC 6598 reserviert.

    Wenn Sie einen der obigen Adressbereiche innerhalb des Adressraums eines virtuellen Netzwerks zuweisen, ändert Azure den Typ des nächsten Hops für die Route automatisch von Keine in Virtuelles Netzwerk. Wenn Sie einen Adressbereich dem Adressraum eines virtuellen Netzwerks zuweisen, der eines der vier reservierten Adresspräfixe enthält (aber nicht identisch damit ist), entfernt Azure die Route für das Präfix und fügt eine Route für das von Ihnen hinzugefügte Adresspräfix mit Virtuelles Netzwerk als Typ des nächsten Hops hinzu.

Optionale Standardrouten

Azure fügt weitere Standardsystemrouten für unterschiedliche Azure-Funktionen hinzu. Dies gilt aber nur, wenn Sie die Funktionen aktivieren. Je nach Funktion fügt Azure optionale Standardrouten entweder spezifischen Subnetzen im virtuellen Netzwerk oder allen Subnetzen in einem virtuellen Netzwerk hinzu. Hier werden die weiteren Systemrouten und Typen des nächsten Hops aufgeführt, die von Azure hinzugefügt werden können, wenn Sie die unterschiedlichen Funktionen aktivieren:

`Source` Adresspräfixe Typ des nächsten Hops Subnetz im virtuellen Netzwerk, dem die Route hinzugefügt wird
Standard Eindeutig für das virtuelle Netzwerk, z.B.: 10.1.0.0/16 VNet-Peering All
Gateway des virtuellen Netzwerks Präfixe, die lokal oder per BGP angekündigt werden oder im Gateway des lokalen Netzwerks konfiguriert sind Gateway des virtuellen Netzwerks All
Standard Mehrere VirtualNetworkServiceEndpoint Nur das Subnetz, für das ein Dienstendpunkt aktiviert ist.

  • Peering virtueller Netzwerke (VNet): Wenn Sie das Peering virtueller Netzwerke zwischen zwei virtuellen Netzwerken erstellen, wird eine Route für jeden Adressbereich innerhalb des Adressraums der einzelnen virtuellen Netzwerke hinzugefügt, die am Peering beteiligt sind. Weitere Informationen hierzu finden Sie unter Peering virtueller Netzwerke.

  • Gateway für virtuelle Netzwerke: Mindestens eine Route mit Angabe von Gateway für virtuelle Netzwerke als Typ des nächsten Hops wird hinzugefügt, wenn ein Gateway für virtuelle Netzwerke einem virtuellen Netzwerk hinzugefügt wird. Die Quelle ist ebenfalls das Gateway für virtuelle Netzwerke, da das Gateway die Routen dem Subnetz hinzufügt. Wenn das Gateway des lokalen Netzwerks BGP-Routen (Border Gateway Protocol) mit einem Gateway eines virtuellen Netzwerks austauscht, wird für jede Route eine Route hinzugefügt. Diese Routen werden vom Gateway des lokalen Netzwerks weitergegeben. Es wird empfohlen, lokale Routen unter den größtmöglichen Adressbereichen zusammenzufassen, damit die kleinste Anzahl von Routen an ein Gateway des virtuellen Azure-Netzwerks weitergegeben wird. Es gelten Einschränkungen dafür, wie viele Routen Sie an ein Gateway des virtuellen Azure-Netzwerks weiterverteilen können. Ausführliche Informationen finden Sie im Artikel zu den Einschränkungen für Azure-Abonnements.

  • VirtualNetworkServiceEndpoint: Die öffentlichen IP-Adressen für bestimmte Dienste werden der Routentabelle von Azure hinzugefügt, wenn Sie einen Dienstendpunkt für den Dienst aktivieren. Dienstendpunkte werden für einzelne Subnetze in einem virtuellen Netzwerk aktiviert, sodass die Route nur der Routentabelle eines Subnetzes hinzugefügt wird, für das ein Dienstendpunkt aktiviert ist. Die öffentlichen IP-Adressen von Azure-Diensten ändern sich regelmäßig. Azure verwaltet die Adressen in der Routentabelle automatisch, wenn sich die Adressen ändern. Erfahren Sie mehr zu VNET-Dienstendpunkten und zu den Diensten, für die Sie Dienstendpunkte erstellen können.

    Hinweis

    Die Typen VNet-Peering und VirtualNetworkServiceEndpoint des nächsten Hops werden nur Routentabellen von Subnetzen in virtuellen Netzwerken hinzugefügt, die mit dem Azure Resource Manager-Bereitstellungsmodell erstellt wurden. Die Typen des nächsten Hops werden dagegen nicht Routentabellen hinzugefügt, die Subnetzen von virtuellen Netzwerken zugeordnet sind, wenn diese mit dem klassischen Bereitstellungsmodell erstellt wurden. Erfahren Sie mehr über Azure-Bereitstellungsmodelle.

Benutzerdefinierte Routen

Sie erstellen vom Benutzer definierte Routen, indem Sie entweder benutzerdefinierte Routen erstellen oder BGP-Routen (Border Gateway Protocol) zwischen Ihrem Gateway des lokalen Netzwerks und einem Gateway des virtuellen Azure-Netzwerks austauschen.

Benutzerdefiniert

Sie können benutzerdefinierte (statische) Routen in Azure erstellen, um Standardsystemrouten von Azure außer Kraft zu setzen oder der Routentabelle eines Subnetzes weitere Routen hinzuzufügen. In Azure erstellen Sie eine Routentabelle und ordnen die Routentabelle dann null oder mehr Subnetzen eines virtuellen Netzwerks zu. Jedem Subnetz können null oder mehr Routentabellen zugeordnet sein. Informationen zur maximalen Anzahl von Routen, die Sie einer Routentabelle hinzufügen können, und zur maximalen Anzahl von benutzerdefinierten Routentabellen, die Sie pro Azure-Abonnement erstellen können, finden Sie im Artikel zu den Einschränkungen für Azure-Abonnements. Wenn Sie eine Routentabelle erstellen und sie einem Subnetz zuordnen, werden die Routen der Tabelle mit den Standardrouten des Subnetzes kombiniert. Wenn es zu Konflikten bei der Routenzuweisung kommt, haben benutzerdefinierte Routen Vorrang vor Standardrouten.

Beim Erstellen einer benutzerdefinierten Route können Sie die folgenden Typen des nächsten Hops angeben:

  • Virtuelles Gerät: Ein virtuelles Gerät ist eine VM, auf der in der Regel eine Netzwerkanwendung wie z.B. eine Firewall ausgeführt wird. Informationen zu verschiedenen vorkonfigurierten virtuellen Appliances, die Sie in einem virtuellen Netzwerk bereitstellen können, finden Sie in Azure Marketplace. Wenn Sie eine Route mit dem Hop-Typ Virtuelles Gerät erstellen, können Sie auch eine IP-Adresse des nächsten Hops angeben. Bei der IP-Adresse kann es sich um Folgendes handeln:

    • Die private IP-Adresse einer Netzwerkschnittstelle, die an einen virtuellen Computer angefügt ist. Für jede Netzwerkschnittstelle, die an einen virtuellen Computer zum Weiterleiten von Netzwerkdatenverkehr an eine andere Adresse als die eigene Adresse angefügt ist, muss hierfür die Azure-Option Enable IP forwarding (IP-Weiterleitung aktivieren) aktiviert sein. Mit der Einstellung wird die Azure-Überprüfung der Quelle und des Ziels für eine Netzwerkschnittstelle deaktiviert. Erfahren Sie mehr dazu, wie Sie die IP-Weiterleitung für eine Netzwerkschnittstelle aktivieren. Enable IP forwarding (IP-Weiterleitung aktivieren) ist zwar eine Azure-Einstellung, aber unter Umständen müssen Sie die IP-Weiterleitung auch im Betriebssystem des virtuellen Computers aktivieren, damit das Gerät Datenverkehr zwischen privaten IP-Adressen weiterleitet, die Azure-Netzwerkschnittstellen zugewiesen sind. Wenn die Appliance Datenverkehr an eine öffentliche IP-Adresse weiterleiten muss, muss sie den Datenverkehr entweder per Proxy weiterleiten oder eine Netzwerkadressenübersetzung (NAT) der privaten IP-Adresse der Quelle in die eigene private IP-Adresse vornehmen. Azure führt dann eine Netzwerkadressenübersetzung in eine öffentliche IP-Adresse aus, bevor der Datenverkehr an das Internet gesendet wird. Informationen zum Bestimmen der erforderlichen Einstellungen auf dem virtuellen Computer finden Sie in der Dokumentation für Ihr Betriebssystem oder Ihre Netzwerkanwendung. Informationen zu den Grundlagen von ausgehenden Verbindungen in Azure finden Sie unter Grundlegendes zu ausgehenden Verbindungen.

      Hinweis

      Stellen Sie ein virtuelles Gerät in einem anderen Subnetz bereit als die Ressourcen, die durch das virtuelle Gerät geleitet werden. Das Bereitstellen des virtuellen Geräts in demselben Subnetz und das anschließende Anwenden einer Routingtabelle in dem Subnetz, aus dem Datenverkehr über das virtuelle Gerät geleitet wird, kann zu Routingschleifen führen, bei denen der Datenverkehr das Subnetz niemals verlässt.

      Eine private IP-Adresse eines nächsten Hops muss über eine direkte Verbindung ohne Weiterleitung über ein ExpressRoute-Gateway oder ein Virtual WAN verfügen. Wenn der nächste Hop auf eine IP-Adresse ohne direkte Verbindung festgelegt wird, wird die benutzerdefinierte Routingkonfiguration ungültig.

    • Die private IP-Adresse eines internen Lastenausgleichs von Azure. Ein Lastenausgleich wird häufig im Rahmen einer Hochverfügbarkeitsstrategie für virtuelle Netzwerkgeräte verwendet.

    Sie können eine Route mit dem Adresspräfix 0.0.0.0/0 definieren und den Typ für den nächsten Hop auf „virtuelle Appliance“ festlegen. Bei dieser Konfiguration kann die Appliance den Datenverkehr untersuchen und bestimmen, ob der Datenverkehr weitergeleitet oder verworfen werden soll. Wenn Sie eine benutzerdefinierte Route erstellen möchten, die das Adresspräfix 0.0.0.0/0 enthält, sollten Sie zuerst Adresspräfix 0.0.0.0/0 lesen.

  • Gateway für virtuelle Netzwerke: Geben Sie an, wenn Datenverkehr, der für bestimmte Adresspräfixe bestimmt ist, an ein Gateway für virtuelle Netzwerke weitergeleitet werden soll. Das Gateway für virtuelle Netzwerke muss mit dem Typ VPN erstellt werden. Sie können ein Gateway für virtuelle Netzwerke, das mit dem Typ ExpressRoute erstellt wurde, nicht in einer benutzerdefinierten Route angeben, da bei ExpressRoute für benutzerdefinierte Routen BGP verwendet werden muss. Wenn VPN- und ExpressRoute-Verbindungen parallel verwendet werden, können keine Virtual Network-Gateways angegeben werden. Sie können eine Route definieren, mit der Datenverkehr, der für das Adresspräfix 0.0.0.0/0 bestimmt ist, an ein routenbasiertes Gateway für virtuelle Netzwerke geleitet wird. Es kann sein, dass Sie lokal ein Gerät nutzen, mit dem der Datenverkehr untersucht und ermittelt wird, ob der Datenverkehr weitergeleitet oder verworfen werden soll. Wenn Sie eine benutzerdefinierte Route für das Adresspräfix 0.0.0.0/0 erstellen möchten, sollten Sie zuerst Adresspräfix 0.0.0.0/0 lesen. Anstatt eine benutzerdefinierte Route für das Adresspräfix 0.0.0.0/0 zu konfigurieren, können Sie eine Route mit dem Präfix 0.0.0.0/0 per BGP ankündigen, wenn Sie BGP für ein Gateway für virtuelle Netzwerke (VPN) aktiviert haben.

  • Keine: Geben Sie an, wenn Datenverkehr für ein Adresspräfix verworfen und nicht an ein Ziel weitergeleitet werden soll. Wenn Sie eine Funktion nicht vollständig konfiguriert haben, wird in Azure für einige optionale Systemrouten ggf. Keine angegeben. Wenn Keine beispielsweise als IP-Adresse für nächsten Hop mit Gateway für virtuelle Netzwerke oder Virtuelles Gerät unter Typ des nächsten Hops angezeigt wird, kann dies daran liegen, dass das Gerät nicht ausgeführt wird oder nicht vollständig konfiguriert ist. Azure erstellt Standardrouten des Systems für reservierte Adresspräfixe mit Keine als Typ des nächsten Hops.

  • Virtuelles Netzwerk: Geben Sie die Option Virtuelles Netzwerk an, wenn Sie das Standardrouting in einem virtuellen Netzwerk außer Kraft setzen möchten. Unter Routingbeispiel finden Sie ein Beispiel dafür, warum es ratsam sein kann, eine Route mit dem Hop-Typ Virtuelles Netzwerk zu erstellen.

  • Internet: Geben Sie die Option Internet an, wenn Sie Datenverkehr, der für ein Adresspräfix bestimmt ist, explizit an das Internet weiterleiten möchten oder wenn Datenverkehr, der für Azure-Dienste mit öffentlichen IP-Adressen bestimmt ist, im Azure-Backbonenetzwerk verbleiben soll.

Es ist nicht möglich, das Peering virtueller Netzwerke oder VirtualNetworkServiceEndpoint als Typ des nächsten Hops in benutzerdefinierten Routen anzugeben. Routen mit Peering virtueller Netzwerke oder VirtualNetworkServiceEndpoint als Typ des nächsten Hops werden von Azure nur dann erstellt, wenn Sie das Peering virtueller Netzwerke oder einen Dienstendpunkt konfigurieren.

Diensttags für benutzerdefinierte Routen

Sie können jetzt ein Diensttag als Adresspräfix für eine benutzerdefinierte Route anstelle eines expliziten IP-Bereichs angeben. Ein Diensttag steht für eine Gruppe von IP-Adresspräfixen eines bestimmten Azure-Diensts. Microsoft verwaltet die Adresspräfixe, für die das Diensttag gilt, und aktualisiert das Diensttag automatisch, wenn sich die Adressen ändern. Dadurch wird die Komplexität der häufigen Aktualisierungen benutzerdefinierter Routen minimiert und die Anzahl der zu erstellenden Routen reduziert. Sie können derzeit 25 oder weniger Routen mit Diensttags in jeder Routentabelle erstellen. Bei dieser Version wird auch die Verwendung von Diensttags in Routingszenarien für Container unterstützt.

Genaue Übereinstimmung

Wenn es eine genaue Präfixübereinstimmung zwischen einer Route mit einem expliziten IP-Präfix und einer Route mit einem Diensttag gibt, wird der Route mit dem expliziten Präfix der Vorzug gegeben. Wenn mehrere Routen mit Diensttags übereinstimmende IP-Präfixe aufweisen, werden die Routen in der folgenden Reihenfolge ausgewertet:

  1. Regionale Tags (z. B. Storage.EastUS, AppService.AustraliaCentral)

  2. Tags der obersten Ebene (z. B. Storage, AppService)

  3. Regionale AzureCloud-Tags (z. B. AzureCloud.canadacentral, AzureCloud.eastasia)

  4. Der AzureCloud-Tag

Um dieses Feature zu verwenden, geben Sie einen Diensttagnamen für den Adresspräfixparameter in Routingtabellenbefehlen an. In PowerShell können Sie beispielsweise eine neue Route erstellen, um den an ein Azure Storage-IP-Präfix gesendeten Datenverkehr an ein virtuelles Gerät zu leiten. Verwenden Sie dazu: 

$param = @{
    Name = 'StorageRoute'
    AddressPrefix = 'Storage'
    NextHopType = 'VirtualAppliance'
    NextHopIpAddress = '10.0.100.4'
}
New-AzRouteConfig @param

Der entsprechende Befehl für die CLI lautet wie folgt:

az network route-table route create \
    --resource-group MyResourceGroup \
    --route-table-name MyRouteTable \
    --name StorageRoute \
    --address-prefix Storage \
    --next-hop-type VirtualAppliance \
    --next-hop-ip-address 10.0.100.4

Typ des nächsten Hops für Azure-Tools

Der Name, der für Typen des nächsten Hops angezeigt und referenziert wird, unterscheidet sich für das Azure-Portal und Befehlszeilentools und die Bereitstellungsmodelle „Azure Resource Manager“ und „klassisch“. In der folgenden Tabelle sind die Namen aufgeführt, die zum Verweisen auf den Typ des nächsten Hops mit den unterschiedlichen Tools und Bereitstellungsmodellen verwendet werden:

Typ des nächsten Hops Die Azure CLI und PowerShell (Resource Manager) Die klassische Azure CLI und PowerShell (klassisch)
Gateway des virtuellen Netzwerks VirtualNetworkGateway VPNGateway
Virtuelles Netzwerk VNetLocal VNETLocal (im Dienstverwaltungsmodus in der klassischen CLI nicht verfügbar)
Internet Internet Internet (im Dienstverwaltungsmodus in der klassischen CLI nicht verfügbar)
Virtuelles Gerät VirtualAppliance VirtualAppliance
Keine Keine Null (im Dienstverwaltungsmodus in der klassischen CLI nicht verfügbar)
Peering in virtuellen Netzwerken VNet-Peering Nicht verfügbar
VNET-Dienstendpunkt VirtualNetworkServiceEndpoint Nicht verfügbar

Border Gateway Protocol

Ein Gateway des lokalen Netzwerks kann Routen mit einem Gateway des virtuellen Azure-Netzwerks austauschen, indem das Border Gateway Protocol (BGP) verwendet wird. Die Nutzung von BGP mit einem Gateway eines virtuellen Azure-Netzwerks ist abhängig von dem Typ, den Sie beim Erstellen des Gateways ausgewählt haben:

  • ExpressRoute: Sie müssen BGP verwenden, um lokale Routen zum Microsoft-Edgerouter anzukündigen. Sie können keine benutzerdefinierten Routen zum Erzwingen der Weiterleitung von Datenverkehr an das ExpressRoute-Gateway für virtuelle Netzwerke erstellen, wenn Sie ein Gateway für virtuelle Netzwerke mit dem Typ „ExpressRoute“ bereitstellen. Sie können benutzerdefinierte Routen beispielsweise zur Weiterleitung des Datenverkehrs von ExpressRoute zum virtuellen Netzwerkgerät verwenden.

  • VPN: Optional können Sie BGP verwenden. Ausführliche Informationen finden Sie unter Übersicht über BGP mit Azure-VPN-Gateways.

Wenn Sie Routen mit Azure per BGP austauschen, wird der Routentabelle aller Subnetze in einem virtuellen Netzwerk für jedes angekündigte Präfix eine separate Route hinzugefügt. Die Route wird mit Gateway für virtuelle Netzwerke als Quelle und Typ des nächsten Hops hinzugefügt.

Die ER- und VPN Gateway-Routenverteilung kann für ein Subnetz mithilfe einer Eigenschaft für eine Routentabelle deaktiviert werden. Wenn Sie die Routenweitergabe deaktivieren, werden keine Routen zu der Routingtabelle aller Subnetze hinzugefügt, bei denen die Routenweitergabe des Gateways für virtuelle Netzwerke deaktiviert ist. Dieser Prozess gilt sowohl für statische Routen als auch für BGP-Routen. Die Konnektivität mit VPN-Verbindungen wird über benutzerdefinierte Routen mit Gateway für virtuelle Netzwerke als Typ des nächsten Hops erreicht. Die Routenweitergabe sollte für das GatewaySubnet nicht deaktiviert werden. Das Gateway funktioniert nicht, wenn diese Einstellung deaktiviert ist. Ausführliche Informationen finden Sie unter Deaktivieren der Routenverteilung von Gatewayrouten des virtuellen Netzwerks.

Auswahl einer Route durch Azure

Wenn Datenverkehr in ausgehender Richtung aus einem Subnetz gesendet wird, wählt Azure eine Route basierend auf der IP-Zieladresse aus, indem der längste Präfixübereinstimmungsalgorithmus verwendet wird. Eine Routentabelle hat beispielsweise zwei Routen: Mit einer Route wird das Adresspräfix 10.0.0.0/24 angegeben, und mit der anderen Route wird das Adresspräfix 10.0.0.0/16 angegeben. Azure leitet Datenverkehr, der für 10.0.0.5 bestimmt ist, an den in der Route angegebenen Typ des nächsten Hops mit dem Adresspräfix 10.0.0.0/24 weiter. Dieses Verhalten tritt auf, weil 10.0.0.0/24 ein längeres Präfix als 10.0.0.0/16 ist, obwohl 10.0.0.5 zu beiden Adresspräfixen gehört. Azure leitet Datenverkehr, der für 10.0.1.5 bestimmt ist, an den in der Route angegebenen Typ des nächsten Hops mit dem Adresspräfix 10.0.0.0/16 weiter. Dieses Verhalten tritt auf, weil 10.0.1.5 nicht im Adresspräfix 10.0.0.0/24 enthalten ist, sodass die Route mit dem Adresspräfix 10.0.0.0/16 das längste übereinstimmende Präfix ist.

Wenn mehrere Routen das gleiche Präfix enthalten, wählt Azure den Routentyp nach den folgenden Prioritätsregeln aus:

  1. Benutzerdefinierte Route

  2. BGP-Route

  3. Systemroute

Hinweis

Systemrouten für Datenverkehr im Zusammenhang mit virtuellen Netzwerken, virtuellen Netzwerken über Peerings oder VNET-Dienstendpunkten sind die bevorzugten Routen, auch wenn BGP-Routen spezifischer sind.

Eine Routentabelle enthält beispielsweise die folgenden Routen:

`Source` Adresspräfixe Typ des nächsten Hops
Standard 0.0.0.0/0 Internet
Benutzer 0.0.0.0/0 Gateway des virtuellen Netzwerks

Wenn Datenverkehr für eine IP-Adresse außerhalb der Adresspräfixe von anderen Routen in der Routentabelle bestimmt ist, wählt Azure die Route mit der Quelle Benutzer aus, da benutzerdefinierte Routen eine höhere Priorität als Systemstandardrouten haben.

Eine umfassende Routentabelle mit Erklärungen der Routen in der Tabelle finden Sie unter Routingbeispiel.

Adresspräfix 0.0.0.0/0

Eine Route mit dem Adresspräfix 0.0.0.0/0 gibt Azure Anweisungen. Anhand dieser Anweisungen leitet Azure Datenverkehr für eine IP-Adresse weiter, die nicht innerhalb des Adresspräfixes einer anderen Route in einer Routingtabelle des Subnetzes liegt. Bei der Erstellung eines Subnetzes erstellt Azure eine Route vom Typ Standard zum Adresspräfix 0.0.0.0/0 mit Internet als Typ des nächsten Hops. Wenn Sie diese Route nicht außer Kraft setzen, leitet Azure den gesamten Datenverkehr, der für IP-Adressen außerhalb des Adresspräfix einer anderen Route bestimmt ist, in das Internet weiter. Die Ausnahme besteht darin, dass Datenverkehr an die öffentlichen IP-Adressen von Azure im Azure-Backbonenetzwerk verbleibt und nicht in das Internet weitergeleitet wird. Wenn Sie diese Route durch eine benutzerdefinierte Route außer Kraft setzen, wird Datenverkehr weitergeleitet, der für Adressen bestimmt ist, die sich nicht innerhalb der Adresspräfixe einer anderen Route in der Routingtabelle befinden. Das Ziel hängt davon ab, ob Sie in der benutzerdefinierten Route eine virtuelle Netzwerk-Appliance oder ein Gateway für ein virtuelles Netzwerk angeben.

Wenn Sie das Adresspräfix 0.0.0.0/0 außer Kraft setzen, wird der ausgehende Datenverkehr aus dem Subnetz über das Gateway des virtuellen Netzwerks oder die virtuelle Appliance geleitet. Außerdem werden die folgenden Änderungen am Azure-Standardrouting vorgenommen:

  • Azure sendet den gesamten Datenverkehr an den Typ des nächsten Hops, der in der Route angegeben ist – einschließlich des Datenverkehrs, der für öffentliche IP-Adressen von Azure-Diensten bestimmt ist. Wenn Internet als Typ des nächsten Hops für die Route mit dem Adresspräfix 0.0.0.0/0 angegeben ist, verlässt Datenverkehr aus dem Subnetz, der für die öffentlichen IP-Adressen von Azure-Diensten bestimmt ist, niemals das Azure-Backbonenetzwerk. Dies gilt unabhängig von der Azure-Region, in der sich das virtuelle Netzwerk oder die Azure-Dienstressource befinden. Aber wenn Sie eine benutzerdefinierte Route oder BGP-Route mit Gateway für virtuelle Netzwerke oder Virtuelles Gerät als nächstem Hop-Typ erstellen, wird der gesamte Datenverkehr (einschließlich des Datenverkehrs, der an öffentliche IP-Adressen von Azure-Diensten gesendet wird, für die Sie keine Dienstendpunkte aktiviert haben) an den Typ des nächsten Hops gesendet, der in der Route angegeben ist. Wenn Sie einen Dienstendpunkt für einen Dienst aktivieren, erstellt Azure eine Route mit Adresspräfixen für den Dienst. Der Datenverkehr an den Dienst wird nicht an den Typ des nächsten Hops in einer Route mit dem Adresspräfix 0.0.0.0/0 weitergeleitet. Die Adresspräfixe für den Dienst sind länger als 0.0.0.0/0.

  • Es ist nicht mehr möglich, aus dem Internet direkt auf Ressourcen im Subnetz zuzugreifen. Sie können indirekt über das Internet auf Ressourcen im Subnetz zugreifen. Das Gerät, das vom Typ des nächsten Hops für eine Route mit dem Adresspräfix 0.0.0.0/0 angegeben wird, muss eingehenden Datenverkehr verarbeiten. Nachdem der Datenverkehr das Gerät durchlaufen hat, erreicht er die Ressource im virtuellen Netzwerk. Wenn die Route die hier angegebenen Werte für den Typ des nächsten Hops enthält, gilt Folgendes:

    • Virtuelles Gerät: Das Gerät muss folgende Anforderungen erfüllen:

      • Erreichbarkeit über das Internet

      • Zugewiesene öffentliche IP-Adresse

      • Keine Zuordnung einer Netzwerksicherheitsgruppen-Regel, die die Kommunikation mit dem Gerät verhindert

      • Keine Verweigerung der Kommunikation

      • Möglichkeit zur Übersetzung der Netzwerkadresse und zur Weiterleitung oder Übergabe des Datenverkehrs an die Zielressource im Subnetz per Proxy und Rückgabe des Datenverkehrs ins Internet

    • Gateway für virtuelle Netzwerke: Wenn es sich beim Gateway um ein ExpressRoute-Gateway für virtuelle Netzwerke handelt, kann ein lokal angeordnetes Gerät mit Internetverbindung die Übersetzung der Netzwerkadresse und die Weiterleitung durchführen oder den Datenverkehr per Proxy an die Zielressource im Subnetz übergeben (per privatem Peering von ExpressRoute).

Wenn Ihr virtuelles Netzwerk mit einem Azure-VPN-Gateway verbunden ist, ordnen Sie dem Gatewaysubnetz keine Routingtabelle zu, die eine Route mit dem Ziel 0.0.0.0/0 enthält. Andernfalls ist die ordnungsgemäße Funktion des Gateways gefährdet. Ausführliche Informationen finden Sie unter Häufig gestellte Fragen zum VPN-Gateway in der Frage Warum werden auf meinem VPN-Gateway bestimmte Ports geöffnet? .

Implementierungsdetails bei Verwendung von Gateways für virtuelle Netzwerke zwischen dem Internet und Azure finden Sie unter DMZ between Azure and your on-premises datacenter (DMZ zwischen Azure und Ihrem lokalen Datencenter).

Routingbeispiel

Zur Erläuterung der Konzepte in diesem Artikel wird in den nächsten Abschnitten Folgendes beschrieben:

  • Szenario mit Anforderungen

  • Erforderliche benutzerdefinierte Routen zur Erfüllung der Anforderungen

  • Routentabelle für ein Subnetz mit den Standardrouten und benutzerdefinierten Routen zur Erfüllung der Anforderungen

Hinweis

Dieses Beispiel ist nicht als empfohlene Implementierung oder bewährte Methode gedacht. Es soll nur dem besseren Verständnis der Konzepte in diesem Artikel dienen.

Requirements (Anforderungen)

  1. Implementieren Sie zwei virtuelle Netzwerke in derselben Azure-Region, und ermöglichen Sie für Ressourcen die Kommunikation zwischen den virtuellen Netzwerken.

  2. Ermöglichen Sie für ein lokales Netzwerk die sichere Kommunikation mit beiden virtuellen Netzwerken per VPN-Tunnel über das Internet. Alternativ hierzu können Sie auch eine ExpressRoute-Verbindung verwenden, aber in diesem Beispiel wird eine VPN-Verbindung genutzt.

  3. Für ein Subnetz in einem virtuellen Netzwerk:

    • Erzwingen Sie für den gesamten ausgehenden Datenverkehr des Subnetzes – mit Ausnahme des Datenverkehrs an Azure Storage und innerhalb des Subnetzes – zur Untersuchung und Protokollierung den Weg über ein virtuelles Netzwerkgerät.

    • Datenverkehr zwischen privaten IP-Adressen innerhalb des Subnetzes sollte nicht untersucht werden. Ermöglichen Sie es, dass Datenverkehr zwischen allen Ressourcen direkt fließen kann.

    • Verwerfen Sie den gesamten ausgehenden Datenverkehr, der für das andere virtuelle Netzwerk bestimmt ist.

    • Lassen Sie ausgehenden Datenverkehr, der für den Azure-Speicher bestimmt ist, direkt in den Speicher fließen, ohne dass der Umweg über ein virtuelles Netzwerkgerät erzwungen wird.

  4. Lassen Sie den gesamten Datenverkehr zwischen allen anderen Subnetzen und virtuellen Netzwerken zu.

Implementierung

In der folgenden Abbildung ist eine Implementierung per Azure Resource Manager-Bereitstellungsmodell dargestellt, für die die obigen Anforderungen erfüllt sind:

Diagram of network.

Mit den Pfeilen ist der Weg des Datenverkehrs angegeben.

Routentabellen

Subnet1

Die Routentabelle für Subnet1 in der Abbildung enthält die folgenden Routen:

id `Source` State Adresspräfixe Typ des nächsten Hops IP-Adresse des nächsten Hops Name der benutzerdefinierten Route
1 Standard Ungültig 10.0.0.0/16 Virtuelles Netzwerk
2 Benutzer Aktiv 10.0.0.0/16 Virtuelles Gerät 10.0.100.4 Within-VNet1
3 Benutzer Aktiv 10.0.0.0/24 Virtuelles Netzwerk Within-Subnet1
4 Standard Ungültig 10.1.0.0/16 VNet-Peering
5 Standard Ungültig 10.2.0.0/16 VNet-Peering
6 Benutzer Aktiv 10.1.0.0/16 Keine ToVNet2-1-Drop
7 Benutzer Aktiv 10.2.0.0/16 Keine ToVNet2-2-Drop
8 Standard Ungültig 10.10.0.0/16 Gateway des virtuellen Netzwerks [X.X.X.X]
9 Benutzer Aktiv 10.10.0.0/16 Virtuelles Gerät 10.0.100.4 To-On-Prem
10 Standard Aktiv [X.X.X.X] VirtualNetworkServiceEndpoint
11 Standard Ungültig 0.0.0.0/0 Internet
12 Benutzer Aktiv 0.0.0.0/0 Virtuelles Gerät 10.0.100.4 Default-NVA

Es folgen Erklärungen der einzelnen Routen-IDs:

  • ID1: Azure hat diese Route automatisch für alle Subnetze in Virtual-network-1 hinzugefügt, da 10.0.0.0/16 der einzige Adressbereich ist, der im Adressraum für das virtuelle Netzwerk definiert ist. Wenn Sie die benutzerdefinierte Route nicht in der Routen-ID 2 erstellen, wird Datenverkehr, der an eine beliebige Adresse zwischen 10.0.0.1 und 10.0.255.254 gesendet wird, innerhalb des virtuellen Netzwerks weitergeleitet. Dieses Verhalten liegt daran, dass das Präfix länger als 0.0.0.0/0 ist und nicht in die Adresspräfixe anderer Routen fällt. Azure hat den Status automatisch von Aktiv in Ungültig geändert, als ID2 (eine benutzerdefinierte Route) hinzugefügt wurde, da sie über das gleiche Präfix wie die Standardroute verfügt und Standardrouten von benutzerdefinierten Routen außer Kraft gesetzt werden. Der Status dieser Route lautet weiterhin Aktiv für Subnet2, da die Routentabelle, in der sich die benutzerdefinierte Route ID2 befindet, Subnet2 nicht zugeordnet ist.

  • ID2: Diese Route wurde von Azure hinzugefügt, als eine benutzerdefinierte Route für das Adresspräfix 10.0.0.0/16 dem Subnetz Subnet1 im virtuellen Netzwerk Virtual-network-1 zugeordnet wurde. Die benutzerdefinierte Route gibt 10.0.100.4 als IP-Adresse des virtuellen Geräts an, da die Adresse die private IP-Adresse ist, die der VM des virtuellen Geräts zugewiesen ist. Die Routentabelle, in der diese Route enthalten ist, ist Subnet2 nicht zugeordnet. Es wird daher in der Routentabelle für Subnet2 auch nicht angezeigt. Diese Route setzt die Standardroute für das Präfix 10.0.0.0/16 (ID1) außer Kraft, über die Datenverkehr, der an 10.0.0.1 und 10.0.255.254 im virtuellen Netzwerk adressiert ist, automatisch über den Typ des nächsten Hops für das virtuelle Netzwerk weitergeleitet wurde. Diese Route ist vorhanden, um Anforderung 3 zu erfüllen und für den gesamten ausgehenden Datenverkehr den Weg über ein virtuelles Gerät zu erzwingen.

  • ID3: Diese Route wurde von Azure hinzugefügt, als eine benutzerdefinierte Route für das Adresspräfix 10.0.0.0/24 dem Subnetz Subnet1 zugeordnet wurde. Der Datenverkehr, der für Adressen zwischen 10.0.0.1 und 10.0.0.254 bestimmt ist, verbleibt im Subnetz und wird nicht an das virtuelle Gerät weitergeleitet, das in der vorherigen Regel (ID2) angegeben ist. Der Grund ist, dass ein längeres Präfix als für die Route ID2 verwendet wird. Diese Route wurde Subnet2 nicht zugeordnet, sodass sie in der Routentabelle für Subnet2 nicht angezeigt wird. Diese Route setzt die Route ID2 für Datenverkehr in Subnet1 effektiv außer Kraft. Diese Route ist vorhanden, um Anforderung 3 zu erfüllen.

  • ID4: Azure hat automatisch die Routen in IDs 4 und 5 für alle Subnetze innerhalb von Virtual-network-1 hinzugefügt, als für dieses virtuelle Netzwerk ein Peering mit Virtual-network-2 durchgeführt wurde. Virtual-network-2 hat zwei Adressbereiche im Adressraum: 10.1.0.0/16 und 10.2.0.0/16, sodass Azure für jeden Bereich eine Route hinzugefügt hat. Wenn Sie die benutzerdefinierten Routen nicht in den Routen-IDs 6 und 7 erstellen, wird Datenverkehr, der an eine beliebige Adresse zwischen 10.1.0.1–10.1.255.254 und 10.2.0.1–10.2.255.254 gesendet wird, an das virtuelle Peering-Netzwerk weitergeleitet. Dieses Verhalten liegt daran, dass das Präfix länger als 0.0.0.0/0 ist und nicht in die Adresspräfixe anderer Routen fällt. Wenn Sie die Routen in den IDs 6 und 7 hinzugefügt haben, hat Azure den Status automatisch von Aktiv in Ungültig geändert. Dieses Verhalten liegt daran, dass sie die gleichen Präfixe wie die Routen in den IDs 4 und 5 haben und benutzerdefinierte Routen Standardrouten außer Kraft setzen. Der Status der Routen in ID 4 und 5 ist immer noch Aktiv für Subnet2, da die Routentabelle, in der sich die benutzerdefinierten Routen in ID 6 und 7 befinden, nicht Subnet2 zugeordnet ist. Ein VNet-Peering wurde erstellt, um Anforderung 1 zu erfüllen.

  • ID5: Hier gilt die gleiche Erklärung wie für ID4.

  • ID6: Azure hat diese Route und die Route unter ID7 hinzugefügt, als die benutzerdefinierten Routen für die Adresspräfixe 10.1.0.0/16 und 10.2.0.0/16 dem Subnetz Subnet1 zugeordnet wurden. Datenverkehr, der für die Adressen von 10.1.0.1 bis 10.1.255.254 und 10.2.0.1 bis 10.2.255.254 bestimmt ist, wird von Azure verworfen und nicht an das virtuelle Peering-Netzwerk weitergeleitet, da Standardrouten von benutzerdefinierten Routen außer Kraft gesetzt werden. Die Routen wurden Subnet2 nicht zugeordnet, sodass sie in der Routentabelle für Subnet2 nicht angezeigt werden. Die Routen setzen die Routen ID4 und ID5 für Datenverkehr außer Kraft, der Subnet1 verlässt. Die Routen ID6 und ID7 sind vorhanden, um Anforderung 3 zum Verwerfen von Datenverkehr zu erfüllen, der für das andere virtuelle Netzwerk bestimmt ist.

  • ID7: Hier gilt die gleiche Erklärung wie für ID6.

  • ID8: Azure hat diese Route automatisch für alle Subnetze in Virtual-network-1 hinzugefügt, als im virtuellen Netzwerk ein Gateway für virtuelle Netzwerke vom Typ VPN erstellt wurde. Azure hat die öffentliche IP-Adresse des Gateways für virtuelle Netzwerke der Routentabelle hinzugefügt. Datenverkehr, der an Adressen zwischen 10.10.0.1 und 10.10.255.254 gesendet wird, wird an das Gateway für virtuelle Netzwerke weitergeleitet. Das Präfix ist länger als 0.0.0.0/0 und liegt nicht innerhalb der Adresspräfixe der anderen Routen. Ein Gateway für virtuelle Netzwerke wurde erstellt, um Anforderung 2 zu erfüllen.

  • ID9: Diese Route wurde von Azure hinzugefügt, als eine benutzerdefinierte Route für das Adresspräfix 10.10.0.0/16 der Routentabelle hinzugefügt wurde, die Subnet1 zugeordnet ist. Diese Route setzt ID8 außer Kraft. Die Route sendet den gesamten Datenverkehr, der für das lokale Netzwerk bestimmt ist, zur Untersuchung an ein virtuelles Netzwerkgerät, anstatt Datenverkehr direkt lokal weiterzuleiten. Diese Route wurde erstellt, um Anforderung 3 zu erfüllen.

  • ID10: Azure hat diese Route automatisch dem Subnetz hinzugefügt, als ein Dienstendpunkt für einen Azure-Dienst für das Subnetz aktiviert wurde. Azure leitet Datenverkehr aus dem Subnetz über das Azure-Infrastrukturnetzwerk an eine öffentliche IP-Adresse des Diensts weiter. Das Präfix ist länger als 0.0.0.0/0 und liegt nicht innerhalb der Adresspräfixe der anderen Routen. Es wurde ein Dienstendpunkt erstellt, um Anforderung 3 zu erfüllen und zu ermöglichen, dass für Azure Storage bestimmter Datenverkehr direkt an Azure Storage geleitet wird.

  • ID11: Azure hat diese Route automatisch der Routentabelle aller Subnetze in Virtual-network-1 und Virtual-network-2 hinzugefügt. Das Adresspräfix 0.0.0.0/0 ist das kürzeste Präfix. Datenverkehr, der an Adressen innerhalb eines längeren Adresspräfix gesendet wird, wird basierend auf anderen Routen weitergeleitet. Standardmäßig leitet Azure den gesamten Datenverkehr, der nicht für die in einer der anderen Routen angegebenen Adressen bestimmt ist, in das Internet weiter. Azure hat den Status für das Subnetz Subnet1 automatisch von Aktiv in Ungültig geändert, als eine benutzerdefinierte Route für das Adresspräfix 0.0.0.0/0 (ID12) dem Subnetz zugeordnet wurde. Der Status dieser Route lautet weiterhin Aktiv für alle anderen Subnetze in beiden virtuellen Netzwerken, da die Route keinen anderen Subnetzen in anderen virtuellen Netzwerken zugeordnet ist.

  • ID12: Diese Route wurde von Azure hinzugefügt, als eine benutzerdefinierte Route für das Adresspräfix 0.0.0.0/0 dem Subnetz Subnet1 zugeordnet wurde. Die benutzerdefinierte Route gibt 10.0.100.4 als IP-Adresse des virtuellen Geräts an. Diese Route wurde Subnet2 nicht zugeordnet, sodass sie in der Routentabelle für Subnet2 nicht angezeigt wird. Der gesamte Datenverkehr für alle Adressen, die nicht in den Adresspräfixen der anderen Routen enthalten sind, wird an das virtuelle Gerät gesendet. Mit dem Hinzufügen dieser Route wurde der Status der Standardroute für Subnet1 für das Adresspräfix 0.0.0.0/0 (ID11) von Aktiv in Ungültig geändert, da eine Standardroute von einer benutzerdefinierten Route außer Kraft gesetzt wird. Diese Route ist vorhanden, um die dritte Anforderung zu erfüllen.

Subnet2

Die Routentabelle für Subnet2 in der Abbildung enthält die folgenden Routen:

`Source` State Adresspräfixe Typ des nächsten Hops IP-Adresse des nächsten Hops
Standard Aktiv 10.0.0.0/16 Virtuelles Netzwerk
Standard Aktiv 10.1.0.0/16 Peering in virtuellen Netzwerken
Standard Aktiv 10.2.0.0/16 Peering in virtuellen Netzwerken
Standard Aktiv 10.10.0.0/16 Gateway des virtuellen Netzwerks [X.X.X.X]
Standard Aktiv 0.0.0.0/0 Internet
Standard Aktiv 10.0.0.0/8 Keine
Standard Aktiv 100.64.0.0/10 Keine
Standard Aktiv 192.168.0.0/16 Keine

Die Routingtabelle für Subnetz2 enthält alle von Azure erstellten Standardrouten und die optionalen Routen für das virtuelle Peering-Netzwerk und das Gateway des virtuellen Netzwerks. Azure hat die optionalen Routen allen Subnetzen im virtuellen Netzwerk hinzugefügt, als das Gateway und das Peering dem virtuellen Netzwerk hinzugefügt wurden. Azure hat die Routen für die Adresspräfixe 10.0.0.0/8, 192.168.0.0/16 und 100.64.0.0/10 aus der Routentabelle für Subnet1 entfernt, als die benutzerdefinierte Route für das Adresspräfix 0.0.0.0/0 Subnet1 hinzugefügt wurde.

Nächste Schritte