Du musst sehen, warum Datenverkehr blockiert wird? Werte effektive NSG-Regeln aus

Eine konfigurierte NSG-Regel erklärt nicht immer das endgültige Ergebnis. Eine NSG auf Subnetzebene, eine NSG auf NIC-Ebene, Standardregeln und zentral angewendete Sicherheitsadministratorregeln können gemeinsam bestimmen, ob Datenverkehr erlaubt oder verweigert wird.

Verwende effektive Sicherheitsregeln, um die kombinierten Regeln zu sehen, die Azure auf eine Netzwerkschnittstelle anwendet. Damit lassen sich Fragen wie die folgende beantworten: Warum ist Port 443 erlaubt, während Port 22 blockiert bleibt?

Dieser Trip baut auf folgendem Trip auf: Regel soll nur App-Server ansprechen? Erstelle eine Application Security Group.

Warum eine temporäre VM erforderlich ist

Azure berechnet effektive Sicherheitsregeln nur für eine NIC, die mit einer laufenden VM verbunden ist. nic-cloudtrips-vm-test-weu ist derzeit eigenständig und kann deshalb noch kein Ergebnis für effektive Regeln liefern.

Erstelle eine kleine temporäre Linux-VM mit der vorhandenen NIC. Die VM wird nur für diese Diagnoseübung benötigt und ersetzt nicht den späteren Compute-Trip, der die VM-Konfiguration ausführlich behandelt.

Die VM verursacht Compute-Kosten, solange sie ausgeführt wird. Der folgende Befehl konfiguriert, dass ihr Betriebssystemdatenträger zusammen mit der VM gelöscht und die vorhandene NIC getrennt und beibehalten wird.

Temporäre VM erstellen

Öffne Cloud Shell, wähle Bash und führe aus:

az vm create \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-nsg-test-weu \
  --location westeurope \
  --zone 3 \
  --nics nic-cloudtrips-vm-test-weu \
  --image Canonical:0001-com-ubuntu-server-jammy:22_04-lts-gen2:latest \
  --size Standard_D2s_v3 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --os-disk-name osdisk-cloudtrips-nsg-test-weu \
  --os-disk-size-gb 30 \
  --storage-sku Standard_LRS \
  --os-disk-delete-option Delete \
  --nic-delete-option Detach

Standard_D2s_v3 ist für diese Subscription in Verfügbarkeitszone 3 verfügbar. Deshalb platziert --zone 3 die VM ausdrücklich dort. Die monatliche Schätzung im Portal geht von einem durchgehenden Betrieb aus; lösche die VM nach dem Test, damit sie nur so lange wie nötig läuft. --generate-ssh-keys erstellt oder verwendet einen SSH-Schlüssel in Cloud Shell. SSH bleibt dennoch blockiert, da die NSG keine eingehende Zulassungsregel für Port 22 enthält.

Bestätige, dass die VM ausgeführt wird:

az vm get-instance-view \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-nsg-test-weu \
  --query "instanceView.statuses[?starts_with(code, 'PowerState/')].displayStatus" \
  --output tsv

Fahre fort, wenn das Ergebnis VM running lautet.

Effektive Sicherheitsregeln öffnen

Suche im Azure-Portal nach Network Watcher und öffne:

Network diagnostic tools > Effective security rules

Wähle:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Virtual machine: vm-cloudtrips-nsg-test-weu
Network interface: nic-cloudtrips-vm-test-weu

Die NSG ist mit snet-app verbunden. Deshalb stammen die hier angezeigten Regeln von diesem Subnetz. Eine NSG kann stattdessen direkt mit einer NIC oder auf beiden Ebenen verbunden werden. Wenn NSGs auf beiden Ebenen vorhanden sind, müssen beide den Datenverkehr zulassen.

Eingehendes Ergebnis interpretieren

Suche unter Inbound rules nach:

Allow-HTTPS-Internet: priority 100, TCP 443, Allow
AllowVNetInBound: priority 65000, Allow
AllowAzureLoadBalancerInBound: priority 65001, Allow
DenyAllInBound: priority 65500, Deny

Die HTTPS-Regel gilt, weil Ipv4config zu asg-cloudtrips-app-test-weu gehört. Internetverkehr zu TCP-Port 443 entspricht der benutzerdefinierten Regel mit Priorität 100 und wird erlaubt, bevor Azure die Standard-Verweigerungsregel erreicht.

Internetverkehr zu Port 22 entspricht nicht der HTTPS-Regel. Da keine andere passende Zulassungsregel vorhanden ist, erreicht die Auswertung DenyAllInBound. Das erklärt, warum SSH blockiert ist. Ein Zulassungsergebnis auf Netzwerkebene garantiert außerdem nicht, dass eine Anwendung antwortet; auch die Betriebssystem-Firewall und der lauschende Prozess spielen eine Rolle.

Temporäre VM entfernen

Lösche die temporäre VM sofort nach dem Sammeln der Nachweise:

az vm delete \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-nsg-test-weu \
  --yes

Aufgrund der beim Erstellen gesetzten Löschoptionen löscht Azure osdisk-cloudtrips-nsg-test-weu und trennt die vorhandene NIC. Bestätige, dass die NIC weiterhin vorhanden und wieder eigenständig ist:

az network nic show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name nic-cloudtrips-vm-test-weu \
  --query "{Name:name,AttachedVM:virtualMachine.id}" \
  --output yaml

Name sollte die NIC anzeigen und AttachedVM sollte leer sein. NIC, öffentliche IP, NSG, ASG und Subnetz bleiben für spätere Netzwerk-Trips erhalten. Die öffentliche IP kann weiterhin Kosten verursachen, solange sie existiert.