App can't reach its database
vm-api can't reach the database on vm-db at 1433.
- Get vm-api reaching vm-db on 1433
- Keep SSH (22) from vm-api to vm-db blockedbroken
Background
The app on vm-api (10.1.2.4, in subnet-api) stores its data in SQL Server on vm-db (10.1.3.4, in subnet-db), port 1433. Today it can't connect. The DBA swears nothing changed on the database side, and subnet-db has no NSG at all. Someone did tighten security on vm-api last week. Working means 1433 connects while vm-api still can't SSH (22) to vm-db.
- 1See it fail
Prove the problem yourself before you change anything. Reports are often wrong.
VM commands forVMsssh vm-apiWhat's this?
Opens a shell on vm-api, 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.3.4 1433What'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.3.4where to connect1433the port to try
Ticks off when the test runs on vm-api.
- 2Find where it stops
- 3Name the cause
- 4Fix it and test again
- 5Explain it
Sources on Microsoft Learn (2)
?
- 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-api → vm-db:1433should work: not workingvm-api → vm-db:22should stay blocked: blocked