Freigeben über

Routing von Datenverkehr für virtuelle Netzwerke

  • Artikel

In diesem Artikel erfahren Sie, wie Azure Datenverkehr zwischen lokalen, Azure- 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 der Systemrouten von Azure durch benutzerdefinierte Routen außer Kraft setzen und den Routingtabellen 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 zwar keine Systemrouten erstellen oder entfernen, aber 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, die das Präfix enthält, die von Azure verwendete Route. Erfahren Sie mehr darüber, wie Azure eine Route auswählt, wenn mehrere Routen die gleichen 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. Nachfolgend finden Sie 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 standardmäßig Datenverkehr zwischen Subnetzen weiter. Es ist nicht erforderlich, dass Sie Routentabellen oder Gateways für Azure definieren, um Datenverkehr zwischen Subnetzen weiterzuleiten. Azure erstellt 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, an 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 eines Azure-Diensts ist, leitet Azure den Datenverkehr direkt über das Azure-Backbonenetzwerk an den Dienst weiter und nicht an 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.

  • Keiner: Datenverkehr, der an den Typ Keiner 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. In der folgenden Tabelle 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:

Quelle 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 Peering in virtuellen Netzwerken Alle
Gateway des virtuellen Netzwerks Präfixe, die lokal per Border Gateway Protocol (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: 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 ein Gateway für virtuelle Netzwerke, da das Gateway die Routen dem Subnetz hinzufügt. Wenn das Gateway des lokalen Netzwerks BGP-Routen 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. Weitere Informationen finden Sie unter Azure-Grenzwerte.

  • VirtualNetworkServiceEndpoint: Azure fügt die öffentlichen IP-Adressen für bestimmte Dienste Routingtabelle hinzu, 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 Routingtabelle 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 Dienstendpunkten in virtuellen Netzwerken und zu den Diensten, für die Sie Dienstendpunkte erstellen können.

    Hinweis

    Die Typen Peering virtueller Netzwerke und VirtualNetworkServiceEndpoint des nächsten Hops werden nur Routingtabellen 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

Zum Anpassen von Routen können Sie entweder benutzerdefinierte Routen erstellen oder BGP-Routen zwischen dem Gateway Ihres lokalen Netzwerks und dem Gateway eines virtuellen Azure-Netzwerks austauschen.

Benutzerdefiniert

Um Ihre Datenverkehrsrouten anzupassen, sollten Sie nicht die Standardrouten ändern. Erstellen Sie stattdessen benutzerdefinierte (statische) Routen, die die Azure-Standardsystemrouten außer Kraft setzen. In Azure erstellen Sie eine Routingtabelle und ordnen diese Tabelle dann keinem oder mehreren Subnetzen des virtuellen Netzwerks zu. Jedem Subnetz können null oder mehr Routentabellen zugeordnet sein. Informationen zur maximalen Anzahl von Routen, die Sie einer Routingtabelle hinzufügen können, und zur maximalen Anzahl von Tabellen für benutzerdefinierte Routen, die Sie pro Azure-Abonnement erstellen können, finden Sie im Artikel zu den Einschränkungen für Azure-Abonnements.

Standardmäßig kann eine Routingtabelle bis zu 400 benutzerdefinierte Routen enthalten. Mit der Routingkonfiguration von Azure Virtual Network Manager kann dieser Wert auf 1.000 benutzerdefinierte Routen pro Routingtabelle erhöht werden. Dieser höhere Grenzwert ermöglicht komplexere Routingkonfigurationen, z. B. das Weiterleiten von Datenverkehr von lokalen Rechenzentren über eine Firewall an alle virtuellen Spoke-Netzwerke in einer Hub-and-Spoke-Topologie, wenn Sie über viele virtuelle Spoke-Netzwerke verfügen.

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 Netzwerkappliances, die Sie in einem virtuellen Netzwerk bereitstellen können, finden Sie in Azure Marketplace. Wenn Sie eine Route mit dem Hop-Typ Virtuelle Appliance 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. Aktivieren der IP-Weiterleitung ist eine Azure-Einstellung.

      Sie müssen möglicherweise die IP-Weiterleitung auch im Betriebssystem des virtuellen Computers aktivieren, damit das Gerät Datenverkehr zwischen privaten IP-Adressen, die Azure-Netzwerkschnittstellen zugewiesen sind, weiterleitet. 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 der virtuellen Appliance im selben Subnetz und das anschließende Anwenden einer Routingtabelle in dem Subnetz, aus dem Datenverkehr über die virtuelle Appliance 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 Azure ExpressRoute-Gateway oder ein Azure Virtual WAN verfügen. Wenn der nächste Hop auf eine IP-Adresse ohne direkte Verbindung festgelegt wird, wird die Konfiguration für die benutzerdefinierte Route ungültig.

    • Die private IP-Adresse eines internen Lastenausgleichs von Azure. Ein Lastenausgleich wird häufig im Rahmen einer Hochverfügbarkeitsstrategie für virtuelle Netzwerkappliances 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 ebenfalls keine Gateways für virtuelle Netzwerke 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 BGP für ein Gateway für virtuelle Netzwerke (VPN) aktiviert ist.

  • Keine: Geben Sie an, wenn Datenverkehr für ein Adresspräfix verworfen und nicht an ein Ziel weitergeleitet werden soll. Azure zeigt für einige der optionalen Systemrouten möglicherweise Keine an, wenn eine Funktion nicht konfiguriert ist. Wenn als IP-Adresse für nächsten Hop beispielsweise Keine und für Typ des nächsten Hops entweder VNET-Gateway oder Virtuelle Appliance angezeigt wird, kann dies möglicherweise 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 Hoptyp Virtual Network 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. Sie können diese Option auch verwenden, wenn Datenverkehr, der für Azure-Dienste mit öffentlichen IP-Adressen bestimmt ist, im Azure-Backbonenetzwerk verbleiben soll.

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

Diensttags für benutzerdefinierte Routen

Sie können jetzt anstelle eines expliziten IP-Adressbereichs ein Diensttag als Adresspräfix für eine benutzerdefinierte Route angeben. Ein Diensttag stellt eine Gruppe von IP-Adresspräfixen eines bestimmten Azure-Diensts dar. Microsoft verwaltet die Adresspräfixe, für die das Diensttag gilt, und aktualisiert das Diensttag automatisch, wenn sich die Adressen ändern. Hierdurch wird die Komplexität der häufigen Aktualisierungen benutzerdefinierter Routen minimiert und die Anzahl der zu erstellenden Routen reduziert. Sie können derzeit maximal 25 Routen mit Diensttags in jeder Routingtabelle 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 oder AppService.AustraliaCentral

  2. Tags der obersten Ebene, z. B. Storage oder AppService

  3. Regionale AzureCloud-Tags, z. B. AzureCloud.canadacentral oder AzureCloud.eastasia

  4. Das AzureCloud-Tag

Um dieses Feature zu verwenden, geben Sie einen Diensttagnamen für den Adresspräfixparameter in Routingtabellenbefehlen an. In PowerShell können Sie z. B. eine neue Route erstellen, um den an ein Azure Storage-IP-Präfix gesendeten Datenverkehr an eine virtuelle Appliance weiterzuleiten, indem Sie folgenden Befehl verwenden:

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

Für die Azure CLI führen Sie diesen Befehl aus:

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 sowie für das klassische und das Azure Resource Manager-Bereitstellungsmodell. 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 (nicht in der klassischen CLI im klassischen Bereitstellungsmodellmodus verfügbar)
Internet Internet Internet (nicht im klassischen CLI im klassischen Bereitstellungsmodellmodus verfügbar)
Virtuelles Gerät VirtualAppliance VirtualAppliance
Keine Keine Null (nicht in der klassischen CLI im klassischen Bereitstellungsmodellmodus verfügbar)
Peering in virtuellen Netzwerken Peering in virtuellen Netzwerken Nicht zutreffend
VNET-Dienstendpunkt VirtualNetworkServiceEndpoint Nicht zutreffend

Border Gateway Protocol

Ein Gateway des lokalen Netzwerks kann Routen mit einem Gateway des virtuellen Azure-Netzwerks austauschen, indem das 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 an eine virtuelle Netzwerkappliance verwenden.
  • VPN: Optional können Sie BGP verwenden. Weitere Informationen finden Sie unter BGP mit Site-to-Site-VPN-Verbindungen.

Wenn Sie Routen mit Azure per BGP austauschen, wird der Routingtabelle 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.

Sie können die ExpressRoute- und Azure VPN Gateway-Routenverteilung in einem Subnetz deaktivieren, indem Sie eine Eigenschaft in einer Routingtabelle verwenden. 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 VNET-Gateway als Typ des nächsten Hops erreicht. Weitere Informationen finden Sie unter Deaktivieren der Routenverteilung des Gateways für virtuelle Netzwerke.

Hinweis

Die Routenverteilung sollte nicht auf GatewaySubnet deaktiviert werden. Das Gateway funktioniert nicht, wenn diese Einstellung deaktiviert ist.

Auswahl einer Route durch Azure

Wenn ausgehender Datenverkehr 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 Routingtabelle 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 basierend auf der folgenden Priorität aus:

  1. Benutzerdefinierte Route

  2. BGP-Route

  3. Systemroute

Hinweis

Systemrouten für Datenverkehr im Zusammenhang mit virtuellen Netzwerken, Peerings virtueller Netzwerke oder VNET-Dienstendpunkten sind die bevorzugten Routen, auch wenn BGP-Routen spezifischer sind. Routen mit einem VNET-Dienstendpunkt als Typ des nächsten Hops können nicht außer Kraft gesetzt werden, auch wenn Sie eine Routingtabelle verwenden.

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 Routingtabelle 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 Routingtabelle 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, an das Internet weiter.

Die Ausnahme besteht darin, dass Datenverkehr an die öffentlichen IP-Adressen von Azure-Diensten im Azure-Backbonenetzwerk verbleibt und nicht an 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 Präfix 0.0.0.0/0 außer Kraft setzen, fließt ausgehender Datenverkehr aus dem Subnetz über das VNET-Gateway oder die virtuelle Appliance. Die folgenden Änderungen treten auch beim Azure-Standardrouting auf:

  • 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, das 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 befindet.

    Wenn Sie eine benutzerdefinierte Route oder BGP-Route mit VNET-Gateway oder Virtual Appliance als Typ des nächsten Hops erstellen, wird der gesamte Datenverkehr an den Typ des nächsten Hops gesendet, der in der Route angegeben ist. Dazu gehört Datenverkehr, der an öffentliche IP-Adressen von Azure-Diensten gesendet wird, für die Sie keine Dienstendpunkte aktiviert haben.

    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

    • VNET-Gateway: Wenn es sich beim Gateway um ein ExpressRoute-Gateway für virtuelle Netzwerke handelt, kann ein lokales 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. Weitere Informationen finden Sie unter 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 zwischen Azure und Ihrem lokalen Rechenzentrum.

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
  • Routingtabelle 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.

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 können Sie auch eine ExpressRoute-Verbindung verwenden. In diesem Beispiel wird jedoch eine VPN-Verbindung verwendet.

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

    • Leiten Sie den gesamten ausgehenden Datenverkehr vom Subnetz über eine virtuelle Netzwerk-Appliance zur Überprüfung und Protokollierung weiter. Schließen Sie Datenverkehr zu Azure Storage und innerhalb des Subnetzes von diesem Routing aus.
    • 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 Azure Storage bestimmt ist, direkt in den Speicher fließen, ohne dass ein Umweg über eine virtuelle Netzwerkappliance erzwungen wird.

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

Implementierung

Im folgenden Diagramm ist eine Implementierung per Azure Resource Manager-Bereitstellungsmodell dargestellt, für die die oben genannten Anforderungen erfüllt sind.

Diagramm einer Netzwerkimplementierung

Mit den Pfeilen ist der Weg des Datenverkehrs angegeben.

Routentabellen

Nachfolgend finden Sie die Routingtabellen für das vorherige Routingbeispiel.

Subnet1

Die Routingtabelle für Subnet1 im vorherigen Diagramm enthält die folgenden Routen:

Kennung `Source` State Adresspräfixe Typ des nächsten Hops IP-Adresse des nächsten Hops Name der benutzerdefinierten Regel
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 Peering in virtuellen Netzwerken
5 Standard Ungültig 10.2.0.0/16 Peering in virtuellen Netzwerken
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

Nachfolgend finden Sie die Erklärungen der 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 in der Routen ID2 nicht 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 tritt auf, da 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, wenn die benutzerdefinierte Route ID2 hinzugefügt wurde. Diese hat das gleiche Präfix wie die Standardroute, und benutzerdefinierte Routen setzen Standardrouten außer Kraft. Der Status dieser Route lautet weiterhin Aktiv für Subnet2, da die Routingtabelle, 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 der virtuellen Appliance an, da die Adresse die private IP-Adresse ist, die der VM der virtuellen Appliance zugewiesen ist. Die Routingtabelle, in der diese Route enthalten ist, ist Subnet2 nicht zugeordnet. Die Route wird daher in der Routingtabelle für Subnet2 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 eine virtuelle Appliance 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. Datenverkehr, der für Adressen zwischen 10.0.0.1 und 10.0.0.254 bestimmt ist, verbleibt innerhalb des Subnetzes. Der Datenverkehr wird nicht an die virtuelle Appliance weitergeleitet, die in der vorherigen Regel (ID2) angegeben ist, da sie ein längeres Präfix als die ID2-Route aufweist.

    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 die Routen unter den IDs 4 und 5 für alle Subnetze in Virtual-network-1 automatisch hinzugefügt, als für das virtuelle Netzwerk das Peering mit Virtual-network-2 durchgeführt wurde. Virtual-network-2 enthält in seinem Adressraum zwei Adressbereiche: 10.1.0.0/16 und 10.2.0.0/16. Daher wurde von Azure eine Route für jeden Bereich hinzugefügt. Wenn Sie die benutzerdefinierten Routen in den Routen-IDs 6 und 7 nicht erstellen, wird Datenverkehr, der an eine beliebige Adresse von 10.1.0.1 bis 10.1.255.254 und von 10.2.0.1 bis 10.2.255.254 gesendet wird, an das virtuelle Peeringnetzwerk weitergeleitet. Dieses Verhalten tritt auf, da 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 tritt auf, da 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 den IDs 4 und 5 ist weiterhin Aktiv für Subnet2, da die Routingtabelle, in der sich die benutzerdefinierten Routen in den IDs 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: Diese Route und die Route unter ID7 wurden von Azure 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 von 10.2.0.1 bis 10.2.255.254 bestimmt ist, wird von Azure verworfen und nicht an das virtuelle Peeringnetzwerk 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 Routingtabelle 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 eine virtuelle Netzwerkappliance, 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, an 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 der virtuellen Appliance 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 Anforderung 3 zu erfüllen.

Subnet2

Die Routingtabelle für Subnet2 im vorherigen Diagramm enthält die folgenden Routen:

Quelle 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 Routingtabelle für Subnet1 entfernt, als die benutzerdefinierte Route für das Adresspräfix 0.0.0.0/0 Subnet1 hinzugefügt wurde.

Zugehöriger Inhalt