Ein Netzwerkproblem muss diagnostiziert werden? Verwende Network Watcher

Eine fehlgeschlagene Verbindung zeigt nicht, ob eine Route, eine Network Security Group, das Gastbetriebssystem oder eine nicht lauschende Anwendung die Ursache ist. Mehrere Kontrollen gleichzeitig zu ändern kann die wirkliche Ursache verdecken und das Netzwerk unnötig öffnen.

Verwende Azure Network Watcher, um einen kontrollierten CloudTrips-Fehler zu diagnostizieren. Erstelle eine temporäre NSG-Regel, die HTTP zu WEB01 blockiert, reproduziere das Problem, identifiziere mit der NSG-Diagnose die exakte Regel und entferne anschließend nur diese Regel.

WEB02 Testclient
       |
       | TCP 80
       v
NSG-Regel verweigert Traffic
       |
       v
WEB01 Webdienst

Dieser Trip verwendet vm-cloudtrips-web01-test-weu, vm-cloudtrips-web02-test-weu, vnet-cloudtrips-test-weu, snet-app und nsg-cloudtrips-app-test-weu aus den früheren Load-Balancer-Labs. Starte beide VMs und lasse den Python-HTTP-Dienst auf WEB01 laufen.

Network Watcher ist ein regionaler Diagnosedienst. Azure aktiviert ihn normalerweise automatisch, wenn ein virtuelles Netzwerk erstellt oder aktualisiert wird. Die bedarfsgesteuerten Diagnosewerkzeuge unterscheiden sich von fortlaufendem Connection Monitor, Flow Logs und Packet Capture, die Agents, Speicher oder Monitoring-Kosten verursachen können.

Funktionierende Basis bestätigen

Lies die private IP-Adresse von WEB01:

WEB01_IP=$(az vm list-ip-addresses \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-web01-test-weu \
  --query '[0].virtualMachine.network.privateIpAddresses[0]' \
  --output tsv)

printf 'WEB01 private IP: %s\n' "$WEB01_IP"

Rufe WEB01 direkt von WEB02 auf:

az vm run-command invoke \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-web02-test-weu \
  --command-id RunShellScript \
  --scripts "curl --silent --show-error --connect-timeout 5 http://${WEB01_IP}/"

Die Ausgabe sollte CloudTrips response from WEB01 enthalten. Diese Basis beweist vor dem kontrollierten Fehler, dass Routing, NSG und HTTP-Dienst die Verbindung erlauben.

Einen kontrollierten Fehler einführen

Öffne nsg-cloudtrips-app-test-weu und wähle Inbound security rules > Add. Konfiguriere:

Source: IP Addresses
Source IP addresses/CIDR ranges: 10.20.1.0/24
Source port ranges: *
Destination: IP Addresses
Destination IP addresses/CIDR ranges: WEB01_IP mit /32
Service: HTTP
Destination port ranges: 80
Protocol: TCP
Action: Deny
Priority: 104
Name: Deny-HTTP-WEB01-Diagnostic-Test
Description: Temporary rule for the Network Watcher diagnostic lab

Verwendet WEB01 beispielsweise 10.20.1.4, gib 10.20.1.4/32 ein. Priorität 104 wird vor der vorhandenen Regel Allow-HTTP-ApplicationGateway mit Priorität 105 und der Load-Balancer-HTTP-Allow-Regel mit Priorität 110 ausgewertet. Das /32-Ziel begrenzt den absichtlichen Fehler auf eine VM.

Wiederhole die WEB02-Anfrage mit Zeitlimit:

az vm run-command invoke \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-web02-test-weu \
  --command-id RunShellScript \
  --scripts "curl --verbose --max-time 5 http://${WEB01_IP}/"

Die Anfrage sollte ein Timeout erreichen. Ändere Webdienst, Route Table oder andere NSG-Regeln noch nicht. Der erhaltene Fehlerzustand erlaubt Network Watcher, die tatsächliche Konfiguration zu untersuchen.

Netzwerktopologie untersuchen

Suche nach Network Watcher. Öffne Monitoring > Topology, wähle das Abonnement CloudTrips TEST und West Europe und erweitere vnet-cloudtrips-test-weu.

Bestätige, dass WEB01 und WEB02 über snet-app verbunden sind und nsg-cloudtrips-app-test-weu dem Pfad zugeordnet ist. Die Topologie erklärt die beteiligten Azure-Ressourcen, beweist aber allein noch nicht, welche Regel diesen TCP-Fluss blockiert.

NSG-Entscheidung diagnostizieren

Wähle unter Network diagnostic tools die Option NSG diagnostics und konfiguriere:

Target resource type: Virtual machine
Virtual machine: vm-cloudtrips-web01-test-weu
Protocol: TCP
Direction: Inbound
Source type: IPv4 address/CIDR
Source: Private IP von WEB02 mit /32
Destination type: IPv4 address/CIDR
Destination: WEB01_IP mit /32
Destination port: 80

Wähle Run NSG diagnostics. Das Ergebnis sollte Denied sein und Deny-HTTP-WEB01-Diagnostic-Test als zutreffende Security Rule nennen. Das ist ein stärkerer Beleg als nur das Vorhandensein einer Deny-Regel: Die Diagnose bewertet die effektive Konfiguration für genau diese Richtung, dieses Protokoll, diese Adressen und diesen Port.

Nennt das Ergebnis eine andere Regel, verwende dieses Resultat, statt die temporäre Regel als Ursache anzunehmen. Regelpriorität, NSGs an Subnetz und NIC sowie Security Admin Rules von Azure Virtual Network Manager können die effektive Entscheidung beeinflussen.

Ende-zu-Ende-Verbindung prüfen

Öffne Network diagnostic tools > Connection troubleshoot und setze:

Source type: Virtual machine
Source virtual machine: vm-cloudtrips-web02-test-weu
Destination type: Virtual machine
Destination virtual machine: vm-cloudtrips-web01-test-weu
Preferred IP version: IPv4
Protocol: TCP
Destination port: 80
Diagnostics tests: Connectivity, NSG diagnostic, Next hop

Wähle Run diagnostic tests. Das Ergebnis sollte die Verbindung als nicht erreichbar und die NSG als blockierende Komponente zeigen. Connection Troubleshoot kombiniert Erreichbarkeit mit NSG- und Routing-Belegen und kann auch DNS-Fehler, fehlende Routen, eine Gast-Firewall oder einen nicht lauschenden Server anzeigen.

Nur die bewiesene Ursache beheben

Kehre zu nsg-cloudtrips-app-test-weu > Inbound security rules zurück und lösche nur Deny-HTTP-WEB01-Diagnostic-Test. Diese temporäre Ressource wurde für das Lab erstellt. Behalte die legitime HTTP-Allow-Regel und die Azure- Standardregeln.

Führe NSG diagnostics mit denselben Eingaben erneut aus. Das Ergebnis sollte jetzt Allowed sein und die zutreffende Allow-Regel nennen. Wiederhole Connection Troubleshoot oder die Anfrage von WEB02:

az vm run-command invoke \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-web02-test-weu \
  --command-id RunShellScript \
  --scripts "curl --silent --show-error --connect-timeout 5 http://${WEB01_IP}/"

CloudTrips response from WEB01 beweist, dass derselbe Fluss nach dem Entfernen der spezifischen Blockierregel funktioniert. Deallokiere beide VMs, wenn du nicht sofort fortfährst. Network Watcher selbst muss nicht gelöscht werden. Entferne separat konfigurierte Monitore, Captures oder Logs, wenn sie nicht mehr benötigt werden.

Fahre mit Belege auf Paketebene werden benötigt? Zeichne Pakete auf fort. Behalte beide Web-VMs und den funktionierenden HTTP-Dienst auf WEB01.