Review: outbound, load balancer and an old rule
vm-app can't download updates, and clients time out on lb-app.
- Get vm-app reaching updates.example.org through nat-gw
- Get vm-client reaching lb-app on 443
- Don't give vm-app a public IP of its ownbroken
- Keep SSH from vm-client to the web servers blockedbroken
Background
Two complaints came in together. vm-app in the private subnet-app can't download from updates.example.org, though nat-gw exists. And clients like vm-client in subnet-client time out on lb-app at 10.1.2.10 since the app on vm-web1 and vm-web2 moved to 443. vm-app must not get a public IP, and SSH from clients to the web servers stays blocked.
- 1See it fail
Prove the problem yourself before you change anything. Reports are often wrong.
VM commands forVMsssh vm-clientWhat's this?
Opens a shell on vm-client, 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.2.10 443What'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.2.10where to connect443the port to try
Ticks off when the test runs on vm-client.
- 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-client → lb-app-fe:443should work: not workingvm-client → vm-web1:22should stay blocked: blocked