Review: storage, DNS servers and a missing record
vm-app can't reach stdata01 and can't find api.corp.internal.
- Get vm-app through to stdata01 on 443
- Make api.corp.internal resolve to 10.1.1.20 from vm-app and answer on 443
- Keep stdata01 denying by defaultbroken
Background
vm-app has two problems since vnet-app moved off the old DNS server. It can't reach stdata01, which only allows subnet-app through its firewall. And it can't find api.corp.internal, the internal API on vm-api at 10.1.1.20. stdata01 keeps denying by default.
- 1See it fail
Prove the problem yourself before you change anything. Reports are often wrong.
VM commands forVMsssh vm-appWhat's this?
Opens a shell on vm-app, 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.
nslookup api.corp.internalWhat's this?
Asks the VM's DNS server what IP address a name points to. Run it on the VM that has the problem, because each VM can get a different answer.
nc -zv api.corp.internal 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 wordsapi.corp.internalwhere to connect443the port to try
Ticks off when the test runs on vm-app.
- 2Find where it stops
- 3Name the cause
- 4Fix it and test again
Sources on Microsoft Learn (3)
?
- 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-app → api.corp.internal:443should work: not working