Review: firewall, DNS and Bastion
vm-spoke1 can't reach vm-spoke2, can't resolve stlogs01 privately, and Bastion can't reach it.
- Get vm-spoke1 reaching vm-spoke2 on 443 through azfw-hub
- Make stlogs01.blob.core.windows.net resolve to 10.0.3.4 from vm-spoke1
- Get bas-hub reaching vm-spoke1 on 22
- Keep SSH between the spokes blockedbroken
Background
Three complaints arrived at once, all about vnet-spoke1. vm-spoke1 can't reach the API on vm-spoke2 through azfw-hub. It can't resolve stlogs01 to its private endpoint through the company DNS server dns-hub. And admins can't get to vm-spoke1 through Bastion bas-hub. SSH between the spokes stays blocked.
- 1See it fail
Prove the problem yourself before you change anything. Reports are often wrong.
VM commands forVMsssh vm-spoke1What's this?
Opens a shell on vm-spoke1, 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.2.1.4 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.2.1.4where to connect443the port to try
Ticks off when the test runs on vm-spoke1.
- 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-spoke1 → vm-spoke2:443should work: not workingvm-spoke1 → stlogs01.blob.core.windows.net:443should work: not workingbas-hub → vm-spoke1:22should work: not working