Last night, I burned the midnight oil over Implementing Virtual Networking in Azure. Here’s some of the fun that I had while working through some labs:
1 — I restricted communication between two Azure Virtual Machines that resided on the same subnet by creating a new subnet on their virtual network. I created and applied Network Security Group rules to these subnets to restrict communication based on source and destination IP subnets. I then moved one of the VMs to a new subnet where the NSG had been applied. These NSGs allow us to filter or control the flow of traffic through the vNET by defining rules. These rules are based on a priority precedence. Therefore, we must create rules with a lower priority than the higher priority system-defined rules so that we can override those. Lower is better because once a match is found on a rule, the system will stop searching through the remaining rules. Finally, the NSG must be associated with either a subnet or a nic to have any effect for us.
2 — I created and configured a virtual network with multiple new subnets. I deployed some Azure Virtual Machines into the different subnets of the virtual network by using an ARM template. ARM templates are JSON files that define the infrastructure and configuration of the resource that we want to deploy. These are very useful because they allow us to automate deployments by implementing infrastructure as code.
2a- I configured both private and public IP addresses (Standard SKU) on these VMs. I also had to configure and apply Network Security Groups on these VMs in order to allow for inbound connectivity to them. This is because the Standard SKU Public IP addresses are not accessible by default. So, the configuration and application the NSGs to allow inbound public connectivity from the Internet to the VMs.
3 — Created an Application Security Group for two web servers and associated the ASG with a Network Security group. I created inbound security rules to allow inbound Internet traffic to the servers on destination ports 80 (HTTP) or 443 (HTTPS). No outbound rules had to be created because NSGs are stateful. If the traffic is allowed inbound, then it’s also going to be allowed outbound with the return traffic.
4 — Finally, I used Azure DNS to configure internal DNS name resolution within a virtual network by using Azure private DNS zones. I then did the same for external DNS name resolution by creating a public DNS zone in Azure. I was able to use nslookup tool to confirm that resolution was working for me as expected. This wasn’t my first rodeo with Azure DNS because I recently used this service for DNS delegation of my custom domain when I completed part 1 of the #cloudresumechallenge project. So, this was a great review!
Up next, Azure Firewall, Intersite Connectivity, and Traffic Management!! Maybe tomorrow….cause I’m still tired from last night.
