Monitoring lost both app servers
The dashboards show both app servers as down.
- Get vm-monitor reaching vm-app1 and vm-app2 on 9100
- Keep vm-user blocked from 9100 on both serversbroken
- Keep UFW running on both serversbroken
- Change only what is actually brokenbroken
Background
"Since the security team's hardening run on Monday, the dashboards show vm-app1 and vm-app2 as down. Users say the app itself works fine." vm-monitor in subnet-monitor collects metrics from both servers on port 9100. Only the monitoring subnet should reach that port. The security baseline stays in place.
- 1See it fail
Prove the problem yourself before you change anything. Reports are often wrong.
VM commands forVMs: Linuxssh vm-monitorWhat's this?
Opens a shell on vm-monitor, so the next commands run on that VM. In this lab it's a shortcut. In real Azure you'd connect through something like Azure Bastion, or SSH to an address you can reach.
nc -zv 10.1.1.4 9100What's this?
netcat, a standard Linux tool. Tries to open a TCP connection and reports whether it worked.
-zonly check whether the port answers. Send no data-vprint the result in words10.1.1.4where to connect9100the port to try
Ticks off when the test runs on vm-monitor.
- 2Find where it stops
- 3Name the cause
- 4Fix it and test again
?
- Resource group, the outer dashed frame
- Virtual network, with its address space top right
- Subnet, with range and usable IPs (5 reserved)
- Network security group. A small shield on a VM's NIC means the NIC has one too
- Route table on the subnet
- VM Appliance Private endpoint
- Peering Connected Initiated or access off
- Goal working Goal broken, X marks where it stops
- Private DNS zone, dotted lines go to linked VNets
- Orange pulse: what your last command changed. Drag to pan, Ctrl and scroll to zoom.
vm-monitor → vm-app1:9100should work: not workingvm-monitor → vm-app2:9100should work: not workingvm-user → vm-app1:9100should stay blocked: blocked