Probleme mit virtuellem Netzwerk-Peering beheben

Zusammenfassung

Dieses Handbuch zur Problembehandlung enthält Schritte, mit denen Sie die meisten Probleme mit virtuellen Netzwerk-Peering beheben können.

Konfigurieren des virtuellen Netzwerk-Peerings zwischen zwei virtuellen Netzwerken

Befinden sich die virtuellen Netzwerke im selben Abonnement oder in verschiedenen Abonnements?

Die virtuellen Netzwerke befinden sich im selben Abonnement

Verwenden Sie die Methoden in den folgenden Artikeln, um virtuelle Netzwerk-Peering für die virtuellen Netzwerke zu konfigurieren, die sich im selben Abonnement befinden:

• Wenn sich die virtuellen Netzwerke in derselben Region befinden, siehe Erstellen eines Peerings.
• Wenn sich die virtuellen Netzwerke in den verschiedenen Regionen befinden, lesen Sie virtual network peering.

Die virtuellen Netzwerke sind in verschiedenen Abonnements oder Microsoft Entra-Mandanten vorhanden.

Informationen zum Konfigurieren des virtuellen Netzwerk-Peerings für virtuelle Netzwerke in verschiedenen Abonnements oder Microsoft Entra-Mandanten finden Sie unter Erstellen eines virtuellen Netzwerk-Peerings zwischen verschiedenen Abonnements.

Konfiguration des virtuellen Netzwerk-Peerings mit einer Hub-Spoke-Topologie, die vor Ort befindliche Ressourcen verwendet.

Für eine Standort-zu-Standort-Verbindung oder eine ExpressRoute-Verbindung

Führen Sie die Schritte in VPN Gateway-Transit für virtuelles Netzwerk-Peering konfigurieren aus.

Für Point-to-Site-Verbindungen

1. Führen Sie die Schritte in Konfigurieren des VPN-Gateway-Transits für virtuelles Netzwerkpeering aus.
2. Nachdem Sie das virtuelle Netzwerk-Peering festgelegt oder geändert haben, laden Sie das Point-to-Site-Paket herunter, und installieren Sie es erneut, damit die Point-to-Site-Clients die aktualisierten Routen an das virtuelle Speichennetzwerk erhalten.

Konfigurieren von virtuellem Netzwerk-Peering mit einem virtuellen Hub-und-Spoke-Topologie-Netzwerk

Die virtuellen Netzwerke befinden sich in derselben Region

1. Konfigurieren Sie im virtuellen Hubnetzwerk eine virtuelle Netzwerkanwendung (Network Virtual Appliance, NVA).
2. In den spoke-virtuellen Netzwerken benutzerdefinierte Routen mit der nächsten Hop-Art Netzwerk-Virtuelle-Appliance anwenden.

Weitere Informationen finden Sie unter Service chaining.

Hilfe zur Problembehandlung beim Einrichten und Routing von NVA-Geräten finden Sie unter Probleme mit der virtuellen Netzwerkanwendung in Azure.

Die virtuellen Netzwerke befinden sich in verschiedenen Regionen.

Die Übertragung des Datenverkehrs über globales virtuelles Netzwerk-Peering wird nun unterstützt.

Beheben eines Verbindungsproblems zwischen zwei virtuellen Peernetzwerken

Melden Sie sich beim portal Azure mit einem Konto an, das über die erforderlichen roles und Berechtigungen verfügt. Wählen Sie das virtuelle Netzwerk aus, wählen Sie "Peering" aus, und aktivieren Sie dann das Feld "Status" . Was ist der Status?

Der Peeringstatus ist verbunden.

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

1. Überprüfen Sie die Netzwerkdatenverkehrflüsse:

   Verwenden Sie Verbindungsproblembehandlung und IP-Flussüberprüfung, um von der Quell-VM zur Ziel-VM festzustellen, ob ein NSG oder UDR den Datenverkehr stört.

   Wenn Sie eine Firewall oder NVA verwenden:

   1. Dokumentieren Sie die UDR-Parameter, damit Sie sie nach Abschluss dieses Schritts wiederherstellen können.
   2. Entfernen Sie den UDR aus dem Subnetz oder der NIC der Quell-VM, die als Next Hop auf den NVA verweist. Überprüfen Sie die Konnektivität direkt vom Quell-VM zum Ziel, wobei die NVA umgangen wird. Wenn dieser Schritt nicht funktioniert, konsultieren Sie die NVA-Problembehandlung.

2. Führen Sie eine Netzwerkablaufverfolgung aus:

   1. Starten Sie eine Netzwerkablaufverfolgung auf der Ziel-VM. Für Windows können Sie Netsh verwenden. Verwenden Sie für Linux TCPDump.

   2. Führen Sie TcpPing oder PsPing von der Quelle zur Ziel-IP aus.

      Dieser Befehl ist ein Beispiel für einen TcpPing-Befehl : tcping64.exe -t <destination VM address> 3389

   3. Beenden Sie nach Abschluss des TcpPings die Netzwerkablaufverfolgung am Zielort.

   4. Wenn Pakete von der Quelle stammen, gibt es kein Netzwerkproblem. Überprüfen Sie sowohl die VM-Firewall als auch die Anwendung, die auf diesen Port lauscht, um das Konfigurationsproblem zu finden.

Der Verbindungsstatus ist unterbrochen.

Ein Peering-Status "Getrennt" bedeutet, dass einer der beiden Peeringlinks gelöscht ist. Der Datenverkehr kann erst zwischen den virtuellen Netzwerken fließen, wenn Peering wieder hergestellt wird.

Häufige Ursachen

• Manuelles Löschen: Sie haben einen Peering-Link von einer Seite gelöscht, aber nicht von der anderen. Wenn Sie einen Link entfernen, wechselt der verbleibende Link zu "Getrennt".
• Adressraumänderungen: Sie haben den Adressraum eines gepaarten virtuellen Netzwerks geändert, das Peering wurde jedoch nicht synchronisiert. Diese Änderung kann dazu führen, dass das Peering in einen getrennten Zustand wechselt. Informationen zur Synchronisierung nach Änderungen am Adressraum finden Sie unter Aktualisieren des Adressraums für ein virtuelles Peer-Netzwerk.
• Abonnement- oder Mandantenänderungen: Sie haben ein virtuelles Netzwerk in ein anderes Abonnement oder einen anderen Mandanten verschoben. Diese Änderung kann bestehende Peeringverbindungen unterbrechen.
• Erzwingung von Azure-Richtlinien: Eine Azure-Richtlinie schränkt Peering- oder Netzwerkkonfigurationen ein. Diese Richtlinie kann dazu führen, dass Peering entfernt oder blockiert wird.

Asymmetrische Peeringzustände diagnostizieren

Der Peeringstatus kann zwischen den beiden virtuellen Netzwerken asymmetrisch werden. Beispielsweise zeigt eine Seite "Verbunden" an, während die andere " Initiiert" oder "Getrennt" anzeigt. So überprüfen Sie den Peering-Status auf beiden Seiten:

1. Wechseln Sie im Azure-Portal zu jedem virtuellen Netzwerk, und wählen Sie "Peering" aus.

2. Vergleichen Sie das Feld "Status" für das Peering auf beiden Seiten.

3. Um die Verwendung von Azure CLI zu überprüfen, führen Sie den folgenden Befehl für jedes virtuelle Netzwerk aus:

   az network vnet peering show --resource-group <resource-group> --vnet-name <vnet-name> --name <peering-name> --query peeringState
   

Die möglichen Peeringzustände sind:

Resolution

1. Löschen Sie den verbleibenden Peeringlink aus beiden virtuellen Netzwerken. Wechseln Sie im Azure-Portal zu jedem virtuellen Netzwerk, wählen Sie "Peering" aus, und löschen Sie den Peeringeintrag.

   Um mit Azure CLI zu löschen:

   az network vnet peering delete --resource-group <resource-group> --vnet-name <vnet-name> --name <peering-name>
   

2. Erstellen Sie das Peering bei beiden virtuellen Netzwerken erneut. Stellen Sie sicher, dass Sie die richtigen Einstellungen für "Weiterleitung von Datenverkehr zulassen", "Gatewaytransit zulassen" und "Remote-Gateways zulassen" auf jeder Seite konfigurieren.

3. Vergewissern Sie sich, dass der Peeringstatus nach der erneuten Erstellung auf beiden Seiten verbunden angezeigt wird.

Beheben Sie ein Konnektivitätsproblem zwischen einem virtuellen Hub-and-Spoke-Netzwerk und einer lokalen Ressource.

Verwendet Ihr Netzwerk ein Drittanbieter-NVA- oder VPN-Gateway?

Mein Netzwerk verwendet ein Drittanbieter-NVA- oder VPN-Gateway

Informationen zur Behandlung von Verbindungsproblemen, die sich auf ein Drittanbieter-NVA- oder VPN-Gateway auswirken, finden Sie in den folgenden Artikeln:

• NVA-Problembehandlung
• Dienstketten

Mein Netzwerk verwendet kein Drittanbieter-NVA- oder VPN-Gateway

Verfügen das virtuelle Hubnetzwerk und das virtuelle Speichennetzwerk über ein VPN-Gateway?

Sowohl das virtuelle Hubnetzwerk als auch das virtuelle Speichennetzwerk verfügen über ein VPN-Gateway.

Die Verwendung eines Remotegateways wird nicht unterstützt.

Wenn das virtuelle Speichennetzwerk bereits über ein VPN-Gateway verfügt, wird die Option "Remotegateway verwenden " im virtuellen Speichennetzwerk nicht unterstützt. Diese Einschränkung ist aufgrund eines virtuellen Netzwerk-Peerings vorhanden.

Sowohl das virtuelle Hubnetzwerk als auch das virtuelle Speichennetzwerk verfügen nicht über ein VPN-Gateway.

Überprüfen Sie bei Standort-zu-Standort- oder Azure ExpressRoute-Verbindungen die folgenden primären Ursachen für Konnektivitätsprobleme mit dem virtuellen Remotenetzwerk von der lokalen Bereitstellung aus:

• Überprüfen Sie im virtuellen Netzwerk mit einem Gateway, ob das Kontrollkästchen "Weitergeleiteten Datenverkehr zulassen " aktiviert ist.
• Überprüfen Sie im virtuellen Netzwerk, für das kein Gateway vorhanden ist, ob das Kontrollkästchen "Remotegateway verwenden " aktiviert ist.
• Lassen Sie Ihren Netzwerkadministrator Ihre lokalen Geräte überprüfen, um sicherzustellen, dass alle über den Remote-Adressraum für virtuelle Netzwerke verfügen.

Für Point-to-Site-Verbindungen:

• Überprüfen Sie im virtuellen Netzwerk mit einem Gateway, ob das Kontrollkästchen "Weitergeleiteten Datenverkehr zulassen " aktiviert ist.
• Überprüfen Sie im virtuellen Netzwerk, für das kein Gateway vorhanden ist, ob das Kontrollkästchen "Remotegateway verwenden " aktiviert ist.
• Laden Sie das Point-to-Site-Clientpaket herunter, und installieren Sie es erneut. Virtuelle Netzwerkrouten, die neu peered sind, fügen keine Routen automatisch zu Point-to-Site-Clients hinzu.

Behebung von Peering-Synchronisierungsfehlern

Wenn Sie den Adressraum eines verbundenen virtuellen Netzwerks ändern, müssen Sie anschließend das Peering für jedes verbundene Remotenetzwerk synchronisieren, um die Änderungen zu übernehmen. Wenn Sie die Synchronisierung nicht ausführen, wird der Datenverkehr möglicherweise nicht ordnungsgemäß zwischen den virtuellen Peernetzwerken weitergeleitet.

Überprüfen des Peeringzustands auf beiden Seiten

1. Wechseln Sie im Azure-Portal zu jedem virtuellen Netzwerk, und wählen Sie "Peering" aus. Vergewissern Sie sich, dass der Status für beide Seiten verbunden angezeigt wird.

2. Verwenden Sie Azure CLI, um den Peeringstatus und die Adresspräfixe zu überprüfen:

   az network vnet peering show \
     --resource-group <resource-group> \
     --vnet-name <vnet-name> \
     --name <peering-name> \
     --query "{state:peeringState, remoteAddressSpace:remoteAddressSpace.addressPrefixes}"
   

3. Verwenden Sie Azure PowerShell, um den Peeringstatus und die Adresspräfixe zu überprüfen:

   Get-AzVirtualNetworkPeering -ResourceGroupName <resource-group> -VirtualNetworkName <vnet-name> | Select-Object Name, PeeringState, RemoteVirtualNetworkAddressSpace
   

Häufige Synchronisierungsprobleme

Synchronisieren Sie das Peering nach einer Änderung des Adressraums

Nachdem Sie Adressbereiche in einem virtuellen Peered-Netzwerk hinzugefügt, geändert oder gelöscht haben, synchronisieren Sie den Peering:

1. Wechseln Sie im Azure-Portal zum virtuellen Netzwerk, in dem Sie den Adressraum geändert haben.
2. Wählen Sie Peering aus, und aktivieren Sie dann das Kontrollkästchen für die Peeringverbindung.
3. Wählen Sie Synchronisieren aus.
4. Wiederholen Sie diesen Vorgang für jedes virtuelle Peering-Remotenetzwerk.

Um mit der Azure CLI zu synchronisieren:

az network vnet peering sync --resource-group <resource-group> --vnet-name <vnet-name> --name <peering-name>

Behebung von Konflikten in Routentabellen bei gekoppelten virtuellen Netzwerken

Benutzerdefinierte Routen (USER-Defined Routes, UDRs) können die Standardsystemrouten außer Kraft setzen, die Azure für virtuelle Peer-Netzwerke erstellt. Diese Außerkraftsetzung kann zu asymmetrischem Routing oder verworfenem Datenverkehr in Hub-Spoke-Topologien führen.

Wie UDRs mit Peering-Routen interagieren

Wenn Sie ein virtuelles Netzwerk-Peering erstellen, fügt Azure automatisch Systemrouten mit dem nächsten Hoptyp "Virtual Network Peering " für jeden Adressraum im virtuellen Peering hinzu. Wenn ein UDR in einer Routentabelle das gleiche Adresspräfix wie eine Peeringroute aufweist, hat udR Vorrang und überschreibt die Peeringsystemroute. Dieses Verhalten kann dazu führen, dass Datenverkehr an eine NVA weitergeleitet oder verworfen wird, anstatt direkt an das virtuelle Peernetzwerk zu fließen.

Weitere Informationen zur Priorität der Routenauswahl finden Sie unter How Azure selects a route.

Diagnose von asymmetrischem Routing in Hub-Spoke-Topologien

In Hub-Spoke-Topologien, bei denen ein NVA im Hub Datenverkehr prüft, verwenden Sie in der Regel UDRs in den Speichensubnetzen, um den Datenverkehr über die NVA weiterzuleiten. Wenn der Rückweg vom Ziel nicht denselben Weg über die NVA nimmt, führt dies zu einer asymmetrischen Routenführung, die Verbindungsfehler verursachen kann.

So diagnostizieren Sie asymmetrisches Routing:

1. Überprüfen Sie die effektiven Routen auf der Netzwerkschnittstelle einer VM im Spoke-Subnetz: a. Wechseln Sie im Azure-Portal zum virtuellen Computer, wählen Sie "Netzwerk" aus, wählen Sie die Netzwerkschnittstelle und dann " Effektive Routen" aus. b. Suchen Sie nach Routen mit dem nächsten Hoptyp VNet-Peering , und vergleichen Sie sie mit allen UDR-Einträgen, die sie überschreiben können.

2. Verwenden Sie Azure CLI, um effektive Routen anzuzeigen:

   az network nic show-effective-route-table --resource-group <resource-group> --name <nic-name> --output table
   

3. Stellen Sie sicher, dass UDRs in den Quell- und Zielsubnetzen einen symmetrischen Pfad durch die NVA erstellen. Wenn der NVA nur Datenverkehr in einer Richtung sieht, kann die zustandsbehaftete Firewall den Rückgabedatenverkehr verwerfen.

Häufige Konfliktszenarien für Routentabellen

Problembehandlung bei überlappenden Adressräumen in virtuellen Peernetzwerken

Azure lässt das Peering virtueller Netzwerke zwischen zwei virtuellen Netzwerken mit überlappenden Adressräumen nicht zu. Wenn Sie versuchen, ein Peering mit überlappenden Classless Inter-Domain-Routing (CIDR)-Bereichen zu erstellen, schlägt der Vorgang fehl.

Häufig auftretende Fehlermeldungen

Wenn Sie versuchen, ein Peering mit überlappenden Adressräumen zu erstellen, werden möglicherweise Fehler wie die folgenden Meldungen angezeigt:

• Der Adressraum <> des virtuellen Netzwerks überschneidet sich mit dem Adressraum des bereits gekoppelten virtuellen Netzwerks.
• Peering kann nicht erstellt oder aktualisiert werden, da sich der Adressraum virtueller Netzwerke überlappen.

Identifizieren überlappender CIDR-Bereiche

So identifizieren Sie überlappende Adressräume:

1. Wechseln Sie im Azure-Portal zu jedem virtuellen Netzwerk, und wählen Sie unter "Einstellungen" den Adressraum aus.

2. Vergleichen Sie die Adressbereiche zwischen den beiden virtuellen Netzwerken, um alle CIDR-Bereiche zu finden, die sich überlappen.

3. Verwenden Sie Azure CLI zum Auflisten von Adressräumen:

   az network vnet show --resource-group <resource-group> --name <vnet-name> --query "addressSpace.addressPrefixes"
   

Zwei CIDR-Bereiche überlappen sich, wenn sich ein Teil der IP-Adressbereiche überschneidet. Beispielsweise überlappen 10.0.0.0/16 und 10.0.1.0/24, weil 10.0.1.0/24 eine Teilmenge von 10.0.0.0/16 ist.

Resolution

Wenn Sie überlappende Adressräume auflösen möchten, wählen Sie einen der folgenden Ansätze aus:

• Ändern Sie die Größe eines der virtuellen Netzwerke: Entfernen oder ändern Sie den überlappenden Adressbereich, sodass die beiden virtuellen Netzwerke keine CIDR-Bereiche freigeben. Weitere Informationen finden Sie unter Aktualisieren des Adressraums für ein virtuelles Peer-Netzwerk.

  Von Bedeutung

  Stellen Sie vor dem Entfernen eines Adressbereichs sicher, dass keine Subnetze oder Ressourcen innerhalb dieses Bereichs bereitgestellt werden.

• Verwenden Sie Azure Virtual Network Manager: Wenn Sie mehrere virtuelle Peer-Netzwerke verwalten, verwenden Sie Azure Virtual Network Manager , wobei die ConnectedGroupAddressOverlap Eigenschaft auf "Nicht zulässig" festgelegt ist , um überlappende Adressräume in Gittertopologien zu verhindern.

• Planen Sie Adressräume vor Peering: Überprüfen Sie die Adresszuweisung aller virtuellen Netzwerke, die am Peering beteiligt sind. Verwenden Sie eine zentrale IP-Adressverwaltungslösung (IPAM), um zukünftige Konflikte zu vermeiden.

Behandeln eines Problems mit einer Hub-Spoke-Netzwerkkonnektivität zwischen virtuellen Speichennetzwerken in derselben Region

Ein Hubnetzwerk muss eine NVA enthalten. Konfigurieren Sie UDRs in Speichen, bei denen eine NVA als nächster Hop festgelegt ist, und aktivieren Sie den weitergeleiteten Datenverkehr zulassen im virtuellen Hubnetzwerk.

Weitere Informationen finden Sie unter Service chaining und besprechen diese Anforderungen mit dem NVA-Anbieter Ihrer Wahl.

Beheben eines Hub-Spoke-Netzwerkkonnektivitätsproblems zwischen Spoke-virtuellen Netzwerken in unterschiedlichen Regionen

Die Übertragung des Datenverkehrs über globales virtuelles Netzwerk-Peering wird nun unterstützt.

Weitere Informationen finden Sie unter "Verschiedene VPN-Topologien".

Behandeln eines Problems mit einer Hub-Spoke-Netzwerkkonnektivität zwischen einer Web-App und dem virtuellen Speichennetzwerk

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

1. Melden Sie sich beim Azure-Portal an.
2. Wählen Sie in der Web-App "Netzwerk" und dann " VNet-Integration" aus.
3. Überprüfen Sie, ob das virtuelle Remotenetzwerk angezeigt werden kann. Geben Sie den Remote-Adressraum für virtuelle Netzwerke manuell ein (Synchronisierungsnetzwerk und Hinzufügen von Routen).

Weitere Informationen finden Sie in den folgenden Artikeln:

• Integrieren Sie Ihre App mit einem Azure virtuellen Netzwerk
• Informationen zum Point-to-Site-VPN-Routing

Problembehandlung bei einer Fehlermeldung zur Konfiguration eines virtuellen Netzwerks mit Peering

Der aktuelle Mandant <TENANT ID> ist nicht berechtigt, auf verknüpftes Abonnement zuzugreifen.

Informationen zum Beheben dieses Problems finden Sie unter Erstellen eines virtuellen Netzwerk-Peerings zwischen verschiedenen Abonnements.

Nicht verbunden

Um dieses Problem zu beheben, löschen Sie das Peering aus beiden virtuellen Netzwerken, und erstellen Sie sie dann neu.

Fehler beim Peeren eines virtuellen Databricks-Netzwerks

Um dieses Problem zu beheben, konfigurieren Sie das virtuelle Netzwerk-Peering unter Azure Databricks, und geben Sie dann das virtuelle Zielnetzwerk mithilfe der Ressourcen-ID an. Weitere Informationen finden Sie unter Eine Databricks-Virtual-Network mit einem Remote-Virtual-Network verbinden.

Das virtuelle Remotenetzwerk verfügt nicht über ein Gateway.

Dieses Problem tritt auf, wenn Sie virtuelle Netzwerke aus verschiedenen Mandanten peeren und später Use Remote Gateways konfigurieren möchten. Das Azure-Portal kann nicht überprüfen, ob ein virtuelles Netzwerkgateway im virtuellen Netzwerk eines anderen Mandanten vorhanden ist.

Um dieses Problem zu beheben, haben Sie folgende Möglichkeiten:

• Löschen Sie die Peerings, und wählen Sie beim Erstellen eines neuen Peerings die Use Remote Gateways Option aus.
• Verwenden Sie PowerShell oder CLI anstelle des Azure-Portals, um dies zu aktivieren Use Remote Gateways.

Nächste Schritte

• Fehlersuche bei Verbindungsproblemen zwischen Azure-VMs
• Übersicht über die Netzwerküberwachung – Verwenden Sie die Verbindungsproblembehebung, IP-Fluss-Überprüfung, nächster Hop und effektive Routen, um Peering-Konnektivitätsprobleme zu diagnostizieren.