Beheben von Verbindungsproblemen zwischen virtuellen Azure-Computern

Zusammenfassung

Möglicherweise treten Verbindungsprobleme zwischen Azure virtuellen Computern (VMs) auf. Dieser Artikel enthält Schritte zur Problembehandlung, mit denen Sie dieses Problem beheben können.

Symptom

Eine Azure VM kann keine Verbindung mit einer anderen Azure VM herstellen.

Überblick über die Anleitung zur Problembehandlung

1. Überprüfen, ob die NIC falsch konfiguriert ist
2. Überprüfen, ob Netzwerkverkehr durch NSGs oder UDRs blockiert wird
3. Überprüfen, ob der Netzwerkdatenverkehr durch die VM-Firewall blockiert wird
4. Überprüfen, ob die VM-App oder der Dienst den Port überwacht
5. Überprüfen Sie, ob das Problem durch die Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT) verursacht wird.
6. Überprüfen, ob Datenverkehr von ACLs für den klassischen virtuellen Computer blockiert wird
7. Überprüfen, ob der Endpunkt für den klassischen virtuellen Computer erstellt wird
8. Versuchen Sie, eine Verbindung mit einer VM-Netzwerkfreigabe herzustellen
9. Überprüfen Inter-VNet Konnektivität

Schritte zur Fehlersuche

Führen Sie die folgenden Schritte aus, um das Problem zu beheben. Überprüfen Sie nach Abschluss der einzelnen Schritte, ob das Problem behoben ist.

Schritt 1: Überprüfen, ob NIC falsch konfiguriert ist

Führen Sie die Schritte in Anleitung zum Zurücksetzen der Netzwerkschnittstelle für Azure Windows-VM aus.

Wenn das Problem auftritt, nachdem Sie die Netzwerkschnittstelle (NIC) geändert haben, führen Sie die folgenden Schritte aus:

Multi-NIC-VMs

1. Fügen Sie eine Netzwerkkarte (NIC) hinzu.
2. Beheben Sie die Probleme in der fehlerhaften NIC, oder entfernen Sie die schlechte NIC. Fügen Sie dann die NIC erneut hinzu.

Weitere Informationen finden Sie unter Hinzufügen von Netzwerkschnittstellen zu virtuellen Computern oder zum Entfernen von virtuellen Computern.

Single-NIC VM

• Erneutes Bereitstellen eines virtuellen Windows-Computers
• Erneutes Bereitstellen von virtuellen Linux-Computern

Schritt 2: Überprüfen, ob der Netzwerkdatenverkehr durch NSGs oder UDRs blockiert wird

Netzwerksicherheitsgruppen (NSGs) und User-Defined Routen (UDRs) können den Datenverkehrsfluss zwischen virtuellen Computern beeinträchtigen. Wenden Sie NSGs auf Subnetzebene und netzwerkschnittstellenebene (NIC) an. Der Datenverkehr muss durch beide Komponenten passieren. Verwenden Sie die folgenden Unterschritte, um NSG- oder UDR-bezogene Blockierung zu diagnostizieren.

Verwenden Sie die IP-Flow-Überprüfung in Network Watcher.

Ip Flow Verify identifiziert schnell, welche NSG-Regel Datenverkehr zu oder von einem virtuellen Computer zulässt oder verweigert.

1. Im Azure-Portal, gehen Sie zu Network Watcher>IP-Flussüberprüfung.
2. Wählen Sie das Abonnement und die Ressourcengruppe der Quell-VM aus.
3. Eintreten:
   • Richtung: Eingehend oder ausgehend.
   • Protokoll: TCP (Transmission Control Protocol) oder UDP (User Datagram Protocol).
   • Lokaler Port: Der Zielport auf der VM (z. B. 3389 für Remotedesktopprotokoll (RDP), 22 für Secure Shell (SSH)).
   • Remote-IP-Adresse: Die IP der verbindenden VM.
   • Remoteport: Der Quellport (oder * für beliebige).
4. Aktivieren Sie "Überprüfen ", um zu sehen, welche NSG-Regel den Datenverkehr zulässt oder verweigert.

Sie können auch Azure CLI oder Azure PowerShell verwenden:

az network watcher test-ip-flow \
  --direction Inbound \
  --protocol TCP \
  --local 10.0.0.4:3389 \
  --remote 10.0.1.4:* \
  --vm <vm-resource-id> \
  --nic <nic-name>

Test-AzNetworkWatcherIPFlow `
  -NetworkWatcher $networkWatcher `
  -Direction Inbound `
  -Protocol TCP `
  -LocalIPAddress 10.0.0.4 `
  -LocalPort 3389 `
  -RemoteIPAddress 10.0.1.4 `
  -RemotePort * `
  -TargetVirtualMachineId <vm-resource-id>

Weitere Informationen finden Sie unter Network Watcher IP Flow Verify overview.

Verwenden der Verbindungsproblembehandlung

Verbindungsproblembehandlung testet die Verbindung zwischen einer Quell-VM und einem Ziel. Es gibt an, ob die Verbindung erfolgreich ist oder fehlschlägt und welche NSG-Regel oder -Konfiguration das Problem verursacht.

1. Wechsle im Azure-Portal zu Network Watcher>Connection troubleshoot.
2. Wählen Sie die Quell-VM und das Ziel (VM, Uniform Resource Identifier (URI), vollständig qualifizierter Domänenname (FQDN) oder IP-Adresse) aus.
3. Geben Sie den Zielport und das Protokoll an.
4. Aktivieren Sie "Überprüfen ", um die Ergebnisse anzuzeigen, einschließlich der spezifischen NSG-Regeln, die entlang des Pfads ausgewertet werden.

Anzeigen effektiver Sicherheitsregeln

In der Ansicht "Effektive Sicherheitsregeln" werden alle NSG-Regeln angezeigt, die auf eine Netzwerkschnittstelle angewendet werden, einschließlich regeln, die von der Subnetzebene NSG geerbt wurden.

1. Wechseln Sie im Azure-Portal zu den Netzwerkeinstellungen des virtuellen Computers.
2. Wählen Sie die Netzwerkschnittstelle aus.
3. Wählen Sie "Effektive Sicherheitsregeln " aus, um die kombinierten Regeln sowohl aus der NIC-Ebene als auch aus den NSGs auf Subnetzebene anzuzeigen.

Sie können auch Azure CLI verwenden:

az network nic list-effective-nsg --resource-group <resource-group> --name <nic-name>

Weitere Informationen finden Sie unter Diagnose eines Problems mit einem VM-Netzwerkdatenverkehrsfilter.

Überprüfen von NSG-Regeln auf Subnetz- und NIC-Ebene

Der Datenverkehr zwischen VMs muss sowohl die Subnetzebene NSG als auch die NIC-Ebene NSG durchlaufen. Eine Regel, die Datenverkehr auf Subnetzebene zulässt, kann weiterhin auf NIC-Ebene blockiert werden und umgekehrt. So überprüfen Sie Regeln auf beiden Ebenen:

1. Wechseln Sie im Azure-Portal zu den Netzwerkeinstellungen des virtuellen Computers, um NIC-Level-NSG-Regeln anzuzeigen.
2. Wechseln Sie zur Subnetzkonfiguration im virtuellen Netzwerk, um NSG-Regeln auf Subnetzebene anzuzeigen.
3. Stellen Sie sicher, dass beide NSGs über Zulassungsregeln für das erforderliche Protokoll und den erforderlichen Port verfügen.

Häufige NSG-Fehlkonfigurationen

• Prioritätskonflikte: Eine Verweigerungsregel mit höherer Priorität (niedrigere Zahl) überstimmt eine Zulassungsregel mit niedrigerer Priorität. Überprüfen Sie die Regelprioritäten, um sicherzustellen, dass Freigaberegeln nicht abgeschattet werden.
• Fehlende eingehende Regeln für beide NSGs: Möglicherweise benötigen Sie eingehende Zulassungsregeln sowohl auf der Subnetzebene als auch auf der NIC-Ebene NSG.
• Quell-IP-Einschränkungen: Regeln, die Quell-IP-Adressen einschränken, blockieren versehentlich datenverkehr von VMs in verschiedenen Subnetzen oder virtuellen Netzwerken. Überprüfen Sie die Quell-IP, oder verwenden Sie entsprechende Diensttags.
• Standardverweigerungsregeln: Die Standardregel DenyAllInbound (priority 65500) blockiert den gesamten eingehenden Datenverkehr, der nicht explizit zulässig ist. Fügen Sie explizite Zulassungsregeln mit einer niedrigeren Prioritätsnummer hinzu.
• Servicetag-Missverständnisse: Servicetags wie VirtualNetwork beinhalten den virtuellen Netzwerkadressraum, Peered-Netzwerke und lokale Netzwerke, die über Gateways verbunden sind. Stellen Sie sicher, dass der Service-Tag in Ihren Regeln der erwarteten Verkehrsquelle entspricht.

Analysieren des Datenverkehrs mithilfe von Ablaufprotokollen

Wenn das Problem zeitweise oder schwierig zu reproduzieren ist, verwenden Sie Ablaufprotokolle, um Datenverkehrsmuster zu analysieren.

• VNet-Flussprotokolle ( empfohlen): VNet-Flussprotokolle stellen Status- und Durchsatzdaten auf VNet-Ebene bereit, wobei Datenverkehr für alle Workloads erfasst wird. Weitere Informationen finden Sie in der Übersicht über VNet-Ablaufprotokolle.

• NSG-Ablaufprotokolle: NSG-Flussprotokolle erfassen Informationen über IP-Datenverkehr, die über eine NSG fließen. Weitere Informationen finden Sie in der Übersicht über NSG-Ablaufprotokolle.

  Von Bedeutung

  NSG-Ablaufprotokolle werden am 30. September 2027 eingestellt. Im Zuge dieser Außerkraftsetzung können Sie nach dem 30. Juni 2025 keine neuen NSG-Flowprotokolle erstellen. Stellen Sie sicher, dass Sie zu virtuellen Netzwerkflussprotokollen migrieren.

Verwenden Sie Traffic Analytics , um Flussprotokolldaten zu visualisieren und blockierte Datenverkehrsmuster zu identifizieren.

UDRs überprüfen

Wenn die NSG-Regeln korrekt erscheinen, überprüfen Sie, ob ein UDR den Datenverkehr an einen unerwarteten nächsten Hop umleitet (z. B. ein Netzwerkvirtualisierungsgerät), der möglicherweise den Datenverkehr verwirft oder filtert.

1. Wechseln Sie im Azure-Portal zu den Netzwerkeinstellungen des virtuellen Computers.
2. Wählen Sie die Netzwerkschnittstelle und dann "Effektive Routen" aus.
3. Suchen Sie nach Routen, die Datenverkehr an eine virtuelle Netzwerkanwendung (Network Virtual Appliance, NVA) oder einen unerwarteten nächsten Hop senden.

Weitere Informationen finden Sie unter Routing von Datenverkehr für virtuelle Netzwerke.

Schritt 3: Überprüfen, ob die VM-Firewall den Netzwerkdatenverkehr blockiert

Deaktivieren Sie die Firewall, und testen Sie dann das Ergebnis. Wenn das Problem behoben ist, überprüfen Sie die Firewalleinstellungen, und aktivieren Sie dann die Firewall erneut.

Schritt 4: Überprüfen, ob die VM-App oder der -Dienst auf den Port hört

Verwenden Sie eine der folgenden Methoden, um zu überprüfen, ob die VM-App oder der Dienst auf den Port lauscht.

• Führen Sie die folgenden Befehle aus, um zu überprüfen, ob der Server auf diesen Port lauscht.

Windows-VM

netstat –ano

Linux-VM

netstat -l

• Führen Sie den Telnet-Befehl auf dem virtuellen Computer selbst aus, um den Port zu testen. Wenn der Test fehlschlägt, ist die Anwendung oder der Dienst nicht für die Überwachung dieses Ports konfiguriert.

Schritt 5: Überprüfen, ob die Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT) das Problem verursacht

In einigen Szenarien platzieren Sie den virtuellen Computer hinter einer Lastenausgleichslösung, die von Ressourcen außerhalb von Azure abhängt. In diesen Szenarien kann die SNAT-Portausschöpfung das Problem verursachen, wenn zeitweilig Verbindungsprobleme auftreten. Um das Problem zu beheben, verwenden Sie einen der folgenden Ansätze:

• Zuordnen eines NAT-Gateways zum Subnetz (empfohlen).
• Weisen Sie der VM eine öffentliche IP-Adresse direkt zu.
• Konfigurieren Sie ausgehende Regeln auf einem Standard-Load-Balancer.

Sichern Sie öffentlich zugängliche VMs mit NSG-Regeln, um den eingehenden Zugriff einzuschränken.

Schritt 6: Überprüfen, ob Datenverkehr von ACLs für den klassischen virtuellen Computer blockiert wird

Eine Zugriffssteuerungsliste (Access Control List, ACL) bietet die Möglichkeit, den Datenverkehr für einen Endpunkt eines virtuellen Computers selektiv zuzulassen oder zu verweigern. Weitere Informationen finden Sie unter Verwalten der ACL auf einem Endpunkt.

Schritt 7: Überprüfen, ob der Endpunkt für den klassischen virtuellen Computer erstellt wird

Alle virtuellen Computer, die Sie in Azure mithilfe des klassischen Bereitstellungsmodells erstellen, können automatisch über einen privaten Netzwerkkanal mit anderen virtuellen Computern im selben Clouddienst oder virtuellen Netzwerk kommunizieren. Computer in anderen virtuellen Netzwerken erfordern jedoch Endpunkte, um den eingehenden Netzwerkdatenverkehr an einen virtuellen Computer zu leiten. Weitere Informationen finden Sie unter Einrichten von Endpunkten.

Schritt 8: Versuchen Sie, eine Verbindung zu einer VM-Netzwerkfreigabe herzustellen

Wenn Sie keine Verbindung mit einer VM-Netzwerkfreigabe herstellen können, kann das Problem durch nicht verfügbare NICs auf dem virtuellen Computer verursacht werden. Informationen zum Löschen der nicht verfügbaren NICs finden Sie unter "Löschen der nicht verfügbaren NICs".

Schritt 9: Überprüfen Inter-VNet Konnektivität

Verwenden Sie Network Watcher IP Flow Verify, um festzustellen, ob ein NSG oder UDR den Datenverkehrsfluss stört. Verwenden Sie VNet-Flussprotokolle (empfohlen) oder NSG-Flussprotokolle , um Datenverkehrsmuster zwischen virtuellen Netzwerken zu analysieren. Sie können Ihre VNet- oder VPN-Verbindungen auch überprüfen, indem Sie die VPN-Gatewaytopologie und die Entwurfsdokumentation überprüfen.