This repository contains demos used in Microsoft Azure Networking Workshop and webinar.
You will need an Azure subscription (account) to work through them.
To recreate the demos, follow this script:
- Start Azure shell by opening a browser window and logging into online Azure shell
- Create a set of SSH keys with ssh-keygen
- Clone the demo repository with git clone https://github.com/ipspace/azure
- Change working directory to azure
- Log into Azure (if needed) with az login and configure Azure CLI with az configure
simple/list-locations
The script executes az account list-locations command. You can execute various versions of this command, for example using -o table option to create a table output.
Note: all demos use scripts with one or several az commands. The first command in every script enables bash command tracing so you'll be able to see the exact commands being executed.
The first demo creates a resource group in East US location (hardcoded in the script) and starts a VM to demonstrate the variety of objects needed to support a single VM. Note that all those objects are created automatically.
The create-rg script creates a resource group and saves the resource group name into ~/.rg file. All subsequent scripts read the resource group name from that file.
setup/create-rg Simple
simple/create-vm-a
After the VM is created, the Azure CLI prints a JSON object describing the VM. Find the public IP address in that data and log into the VM using ssh azure@public-ip-address. Use Azure Portal to explore various objects created to support the VM.
Note: You can also use . setup/get-public vm-name command (for example, . setup/get-public A) to get the public IP address of a VM from Azure and set a corresponding bash environment variable (that's why you need . in front of the command). After using the above command you could SSH into A using ssh azure@$A.
Create the second VM in the same resorce group:
simple/create-vm-b
Note that while Azure CLI created a new VM, new disk, new public IP address, and new network security group (NSG) it did not create a new virtual network (VNet) or subnet.
Destroy all objects used in this demo by deleting the resource group with delete-rg script or with az group delete command.
setup/delete-rg
This demo creates:
- A new resource group
- Virtual network AppNet with IP address space 172.16.0.0/16 and two subnets: AppSubnet (172.16.1.0/24) and DBSubnet
- Create a virtual machine in each subnet.
setup/create-rg Net
network/create-vnet
network/create-vm
After the virtual machines have been created you can log into the Web virtual machine but not in the DB virtual machine as it has no permanent public IP address. You can, however, ping the private IP address of DB virtual machine from Web virtual machine, or reach external destinations from DB over TCP or UDP (use curl or wget from DB to download a few public web pages).
Don't forget to clean up afterwards:
setup/delete-rg
This demo creates:
- Virtual network AppNet with the same subnets as the previous demo
- Unprotected VMs in the virtual network (with no per-VM Network Security Group). Web VM is reachable from the Internet, DB VM has no public IP address and is thus reachable only from within the virtual network
setup/create-rg NSG
network/create-vnet
nsg/create-vm
After creating the virtual machines, log into the Web VM and verify that you can ping DB VM and reach it over SSH (you won't be able to log in unless you fix the SSH keys)
Next, create Web and DB Network Security Groups and apply them to the Web and DB subnets:
nsg/create-web-nsg
nsg/create-db-nsg
nsg/apply-nsg
Use az network nsg list -o table command to list the contents of the newly-created NSG.
Log into Web VM and check whether you can reach DB VM over SSH, ping, or TCP port 80 (using curl http://db or telnet db 80). Please note that when the attempts to connect to web server on port 80 return an error it's generated by the host (because there's no web server running on the host) not by the Azure virtual network (which quietly drops the packets).
If your NSG doesn't work as expected use the following commands to figure out what the problem might be:
az network nsg rule list -g NSG --nsg-name DB-NSG -o table
az network nic list-effective-nsg --resource-group NSG --name DBVMNic -o table
az network nsg rule list -g NSG --nsg-name DB-NSG -o table --include-default
Remove SSH entry from DB-NSG using portal. Recheck the connectivity with SSH.
If you can't fix the NSG for the DB subnet yourself, use this command to fix it:
nsg/fix-db-nsg
Don't forget to delete the resource group after completing the demo.
setup/delete-rg
In the Application Security Groups (ASG) demo we'll repeat the steps from the NSG demo but replace the subnet prefixes used in previous demo with ASG objects. The initial steps are almost identical to the previous demo:
- Create a resource group;
- Create a virtual network with two subnets;
- Create an application security group (ASG);
- Create two VMs (one in each ASG)
setup/create-rg ASG
network/create-vnet
asg/create-asg
asg/create-vm
When creating NSG rules we'll use ASG objects instead of subnet prefixes:
asg/create-db-nsg
asg/create-web-nsg
nsg/apply-nsg
After setting up the demo, connect to Web VM and explore which TCP ports on DB VM you can reach. Also, try to figure out which IP addresses belong to a particular ASG (az network nic list-effective-nsg -g ASG -n DBVMNic doesn't seem to return usable information).
Don't forget to delete the resource group after completing the demo.
setup/delete-rg
This demo will replace the default route table in database subnet with a custom route table where the system default route (pointing to Internet) is replaced with a custom default route with drop next hop (effectively blocking Internet access for DB VM).
We'll reuse the steps from virtual networking demo to create the virtual network, the two subnets, and the DB and Web VMs.
setup/create-rg rt
network/create-vnet
network/create-vm
To test the outbound connectivity from DB VM you have to be able to log into it, and you can only do it from the Web VM, so you have to copy your private SSH key to the Web VM (never do that in production).
. setup/get-public Web
scp ~/.ssh/id_rsa azure@$Web:.ssh/
Now you can use Web VM as a SSH jump host to get to the DB VM and test outbound Internet connectivity.
ssh azure@$Web
Web> ssh azure@172.16.2.4
DB> curl www.example.com
You can display routing table in DBSubnet to verify that it includes the default route pointing toward the Internet.
az network nic show-effective-route-table -g rt -n DBVMNic -o table
Next, create a custom route table and apply it to DBSubnet
rt/create-rt
rt/apply-rt
Check whether the routing table applied to DBVMNic has been modified:
az network nic show-effective-route-table -g Net -n DBVMNic -o table
Finally, log into DB VM and try to fetch a web page from the public Internet.
In the VNet Peering demo we'll create two virtual networks and three VMs (two in network A, one in network B).
setup/create-rg peer
peer/create-net-a
peer/create-net-b
peer/create-vm
Display private and public VM IP address with these commands:
az network nic list -g peer --query "[ [*].name,[*].ipConfigurations[*].privateIpAddress ]" -o table
az vm list -g peer -d -o table
Log into A1, try to ping A2 and B1. You should be able to ping A2, but not B1.
Use these commands to create and verify VNet peering between A and B.
peer/create-peer
az network vnet peering list -g peer --vnet-name Net-A -o table
az network vnet peering show --name A2B --vnet-name Net-A --resource-group peer
Log into A1, try to ping A2 and B1. You should not be able to ping B1 even though the VNet peering has been successfully established.
Check the routing tables on A1 and B1 NICs:
az network nic show-effective-route-table -g peer -n A1VMNic -o table
az network nic show-effective-route-table -g peer -n B1VMNic -o table
You'll notice that the routing tables include prefixes from the peered network. Try to figure out why the traffic is not exchanged between A1 and B1 (for example, using IP Flow Verify feature in GUI portal).
Check the effective NSG applied to VM NICs, in particular the actual prefixes used in packet filters. You'll notice that the VirtualNetwork service tag does not include prefixes from the peered virtual network.
az network nic list-effective-nsg -g peer -n A1VMNic
az network nic list-effective-nsg -g peer -n B1VMNic
Fix the NSG by setting the allowVirtualNetworkAccess flag on VNet peering.
az network vnet peering update --name A2B --vnet-name Net-A --set allowVirtualNetworkAccess=true --resource-group peer
az network vnet peering update --name B2A --vnet-name Net-B --set allowVirtualNetworkAccess=true --resource-group peer
az network nic list-effective-nsg -g peer -n A1VMNic
az network nic list-effective-nsg -g peer -n B1VMNic
You might want to change the flag on one side of the peering and check effective NSG on VM NIC before changing the flag on the other side of the peering.
Congratulations, you completed the last demo. Don't forget to clean up all resources and resource groups you created - Microsoft will happily bill you if you keep them running.