KO | EN

GitLite

Minimalist Open Source Repository Search Engine

gitlite — search

#dsh #dsh-plugin #developer-tools #ai-agent #claude-code #codex #typescript #ai-agents #deepseek-harness #mcp #cli #rust

azure

★ 6 Open GitHub ↗

Azure Networking Workshop

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Azure Workshop Demo Script

This repository contains demos used in [Microsoft Azure Networking Workshop](https://www.ipspace.net/Microsoft_Azure_Networking_(Workshop)) and [webinar](https://www.ipspace.net/Microsoft_Azure_Networking).

You will need an Azure subscription (account) to work through them.

To recreate the demos, follow this script:

## Prepare the environment

* Start Azure shell by opening a browser window and logging into [online Azure shell](https://shell.azure.com/)
* 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**

## List the available Azure locations

```
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.

## Create a resource group and start a VM

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](https://portal.azure.com/#home) 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 another VM in the same subnet

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.

## Cleanup

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
```

## Create application environments with two subnets

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
```

## Create Network Security Groups

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.

### Test 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.

### Fixing the NSG

If you can't fix the NSG for the *DB* subnet yourself, use this command to fix it:

```
nsg/fix-db-nsg
```

### Cleanup

Don't forget to delete the resource group after completing the demo.

```
setup/delete-rg
```

## Application Security Groups Demo

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
```

## Route table demo

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.

## Peering demo

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.

### Create network peering

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.

### Troubleshooting

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
```

### Enable virtual network access

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.

## Cleanup

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.

azure

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README