Introduction to Azure Virtual Networks Flashcards
Azure Virtual Networks
- When you are creating a VNet, use address ranges enumerated in RFC 1918.
- Azure reserves the first four and last IP address for a total of five IP addresses within each subnet. These addresses are x.x.x.0-x.x.x.3 and the last address of the subnet.
192.168.1.0
192.168.1.1 (Reserved by Azure for the default gateway.)
192.168.1.2, 192.168.1.3 (Reserved by Azure to map the Azure DNS IPs to the VNet space.)
192.168.1.255 (Network broadcast address.) - Ensure nonoverlapping address spaces. Make sure your VNet address space (CIDR block) doesn’t overlap with your organization’s other network ranges.
Subnets
A subnet is a range of IP address in the VNet. You can segment VNets into different size subnets, creating as many subnets as you require for organization and security within the subscription limit. You can then deploy Azure resources in a specific subnet.
When planning to implement subnets:
* Each subnet must have a unique address range
* Certain Azure services require their own subnet.
* Subnets can be used for traffic management. For example, you can create subnets to route traffic through a network virtual appliance.
* You can limit access to Azure resources to specific subnets with a virtual network service endpoint. You can create multiple subnets, and enable a service endpoint for some subnets, but not others.
Azure Availability Zones
An Azure Availability Zone enables you to define unique physical locations within a region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking.
Azure services that support Availability Zones fall into three categories:
* Zonal services. Resources can be pinned to a specific zone.
* Zone-redundant services. Resources are replicated or distributed across zones automatically
* Nonregional services. Service is available from Azure geographies and is resilient to zone-wide outages.
Dynamic and Static public IP addresses
Public IP addresses are created with an IPv4 or IPv6 address, which can be either static or dynamic.
- A dynamic public IP address is an assigned address that can change over the lifespan of the Azure resource. The dynamic IP address is allocated when you create or start a virtual machine (VM). The IP address is released when you stop or delete the VM. In each Azure region, public IP addresses are assigned from a unique pool of addresses. The default allocation method is dynamic.
- A static public IP address is an assigned address that doesn’t change over the lifespan of the Azure resource. To ensure that the IP address for the resource remains the same, set the allocation method explicitly to static. The IP address is released only when you delete the resource or change the IP allocation method to dynamic.
SKUs for public IP addresses: Standard & Basic
Allocation Method:
* Standard: Static.
* Basic: IPv4 can be dynamic or static; IPv6 is dynamic only.
Idle Timeout:
* Both allow an adjustable inbound flow idle timeout of 4-30 minutes (default 4 minutes) and have a fixed outbound flow idle timeout of 4 minutes.
Security:
* Standard: Secure by default, closed to inbound traffic. Requires NSG to allow traffic.
* Basic: Open by default, NSG is optional for restricting traffic.
Availability Zones:
* Standard: Supported (Non-zonal, Zonal, or Zone-redundant). Zone-redundant IPs require regions with at least three availability zones.
* Basic: Not supported.
Routing Preference:
* Standard: Supported, allowing granular control over traffic routing between Azure and the Internet.
* Basic: Not supported.
Global Tier:
* Standard: Supported via cross-region load balancers.
* Basic: Not supported.
Public IP address prefix
Public IP prefixes are assigned from a pool of addresses in each Azure region. You create a public IP address prefix in an Azure region and subscription by specifying a name and prefix size. Public IP address prefixes consist of IPv4 or IPv6 addresses. In regions with Availability Zones, Public IP address prefixes can be created as zone-redundant or associated with a specific availability zone. After the public IP prefix is created, you can create public IP addresses.
Public DNS services
Public DNS services resolve names and IP addresses for resources and services accessible over the internet such as web servers. Azure DNS is a hosting service for DNS domain that provides name resolution by using Microsoft Azure infrastructure. DNS domains in Azure DNS are hosted on Azure’s global network of DNS name servers. Azure DNS uses anycast networking. Each DNS query is directed to the closest available DNS server.
- In Azure DNS, you can create address records manually within relevant zones.
- Azure DNS provides a reliable, secure DNS service to manage and resolve domain names in a virtual network without needing to add a custom DNS solution.
- A DNS zone hosts the DNS records for a domain. So, to start hosting your domain in Azure DNS, you need to create a DNS zone for that domain name. Each DNS record for your domain is then created inside this DNS zone.
Considerations
* The name of the zone must be unique within the resource group, and the zone must not exist already.
* The same zone name can be reused in a different resource group or a different Azure subscription.
* Where multiple zones share the same name, each instance is assigned different name server addresses.
* Root/Parent domain is registered at the registrar and pointed to Azure NS.
* Child domains are registered in AzureDNS directly.
You do not have to own a domain name to create a DNS zone with that domain name in Azure DNS. However, you do need to own the domain to configure the domain.
Delegate DNS Domains
Azure DNS allows you to host a DNS zone and manage the DNS records for a domain in Azure. In order for DNS queries for a domain to reach Azure DNS, the domain has to be delegated to Azure DNS from the parent domain. Keep in mind Azure DNS isn’t the domain registrar.
To delegate your domain to Azure DNS, you first need to know the name server names for your zone. Each time a DNS zone is created Azure DNS allocates name servers from a pool. Once the Name Servers are assigned, Azure DNS automatically creates authoritative NS records in your zone.
Once the DNS zone is created, and you have the name servers, you need to update the parent domain. Each registrar has their own DNS management tools to change the name server records for a domain. In the registrar’s DNS management page, edit the NS records and replace the NS records with the ones Azure DNS created.
Child Domains
If you want to set up a separate child zone, you can delegate a subdomain in Azure DNS. For example, after configuring contoso.com in Azure DNS, you could configure a separate child zone for partners.contoso.com.
Setting up a subdomain follows the same process as typical delegation. The only difference is that NS records must be created in the parent zone contoso.com in Azure DNS, rather than in the domain registrar.
- A record set is a collection of records in a zone that have the same name and are the same type.
Private DNS services
Private DNS services resolve names and IP addresses for resources and services
When resources deployed in virtual networks need to resolve domain names to internal IP addresses, they can use one the three methods:
* Azure DNS Private Zones
* Azure-provided name resolution
* Name resolution that uses your own DNS server
The type of name resolution you use depends on how your resources need to communicate with each other.
- DNS forwarding enables DNS resolution between virtual networks and allows your on-premises machines to resolve Azure-provided host names. In order to resolve a VM’s host name, the DNS server VM must reside in the same virtual network and be configured to forward host name queries to Azure. Because the DNS suffix is different in each virtual network, you can use conditional forwarding rules to send DNS queries to the correct virtual network for resolution.
Azure provided DNS
Azure provides its own free default internal DNS. Azure provided name resolution provides only basic authoritative DNS capabilities. If you use this option, the DNS zone names and records are automatically managed by Azure.
- Internal DNS defines a namespace as follows: .internal.cloudapp.net.
Limitations of Internal DNS
* Can’t resolve across different VNets.
* Registers resource names, not guest OS names.
* Doesn’t allow manual record creation.
Azure Private DNS Zones
Private DNS zones in Azure are available to internal resources only. They’re global in scope, so you can access them from any region, any subscription, any VNet, and any tenant. If you have permission to read the zone, you can use it for name resolution.
- Private DNS zones are highly resilient, being replicated to regions all throughout the world.
- They aren’t available to resources on the internet.
For scenarios which require more flexibility than Internal DNS allows, you can create your own private DNS zones. These zones enable you to:
* Configure a specific DNS name for a zone.
* Create records manually when necessary.
* Resolve names and IP addresses across different zones.
* Resolve names and IP addresses across different VNets.
- When the new DNS zone is deployed, you can manually create resource records, or use autoregistration. Autoregistration creates resource records based on the Azure resource name.
Link VNets to private DNS zones
At the VNet level, default DNS configuration is part of the DHCP assignments made by Azure, specifying the special address 168.63.129.16 to use Azure DNS services. If necessary, you can override the default configuration by configuring an alternate DNS server at the VM NIC.
Two ways to link VNets to a private zone:
* Registration: Each VNet can link to one private DNS zone for registration. However, up to 100 VNets can link to the same private DNS zone for registration.
* Resolution: There may be many other private DNS zones for different namespaces. You can link a VNet to each of those zones for name resolution. Each VNet can link to up to 1000 private DNS Zones for name resolution.
Integrating on-premises DNS with Azure VNets
If you have an external DNS server, for example an on-premises server, you can use custom DNS configuration on your VNet to integrate the two.
Organizations often use an internal Azure private DNS zone for auto registration, and then use a custom configuration to forward queries external zones from an external DNS server.
Forwarding takes two forms:
* Forwarding - specifies another DNS server (SOA for a zone) to resolve the query if the initial server can’t.
* Conditional forwarding - specifies a DNS server for a named zone, so that all queries for that zone are routed to the specified DNS server.
Enable cross-virtual network connectivity with peering
Virtual network peering enables you to seamlessly connect separate VNets with optimal network performance, whether they are in the same Azure region (VNet peering) or in different regions (Global VNet peering).
- Network traffic between peered virtual networks is private.
- The traffic between virtual machines in peered virtual networks uses the Microsoft backbone infrastructure, and no public Internet, gateways, or encryption is required in the communication between the virtual networks.
Gateway Transit and Connectivity
When virtual networks are peered, you configure a VPN gateway in the peered virtual network as a transit point. In this case, a peered virtual network uses the remote gateway to gain access to other resources. A virtual network can have only one gateway. Gateway transit is supported for both VNet Peering and Global VNet Peering.
When you Allow Gateway Transit the virtual network can communicate to resources outside the peering. For example, the subnet gateway could:
- Use a site-to-site VPN to connect to an on-premises network.
- Use a VNet-to-VNet connection to another virtual network.
- Use a point-to-site VPN to connect to a client.
Use service chaining to direct traffic to a gateway
To enable service chaining, add user-defined routes pointing to virtual machines in the peered virtual network as the next hop IP address. User-defined routes can also point to virtual network gateways.
Virtual Network traffic routing
Azure automatically creates a route table for each subnet within an Azure virtual network and adds system default routes to the table. You can override some of Azure’s system routes with custom routes, and add more custom routes to route tables. Azure routes outbound traffic from a subnet based on the routes in a subnet’s route table.
**System routes = **Azure automatically creates system routes and assigns the routes to each subnet in a virtual network. You can’t create or remove system routes, but you can override some system routes with custom routes
- Default routes = Each route contains an address prefix and next hop type. When traffic leaving a subnet is sent to an IP address within the address prefix of a route, the route that contains the prefix is the route Azure uses.
- In routing terms, a hop is a waypoint on the overall route. Therefore, the next hop is the next waypoint that the traffic is directed to on its journey to its ultimate destination.
- When you create a virtual network peering between two virtual networks, a route is added for each address range within the address space of each virtual network.
- When you add a virtual network gateway to a virtual network, Azure adds one or more routes with Virtual network gateway as the next hop type
- Azure adds the public IP addresses for certain services to the route table when you enable a service endpoint to the service. Service endpoints are enabled for individual subnets within a virtual network, so the route is only added to the route table of a subnet a service endpoint is enabled for.
Custom routes = To control the way network traffic is routed more precisely, you can override the default routes that Azure creates by using your own user-defined routes (UDR).
- User-defined routes = You can create custom, or user-defined(static), routes in Azure to override Azure’s default system routes, or to add other routes to a subnet’s route table.
- In Azure, each subnet can have zero or one associated route table. When you create a route table and associate it to a subnet, the routes within it are combined with, or override, the default routes Azure adds to a subnet.
Secure a VNet by using forced tunneling
Forced tunneling lets you redirect or “force” all Internet-bound traffic back to your on-premises location via a Site-to-Site VPN tunnel for inspection and auditing. If you don’t configure forced tunneling, Internet-bound traffic from your VMs in Azure always traverses from the Azure network infrastructure directly out to the Internet, without the option to allow you to inspect or audit the traffic.
- Forced tunneling can be configured by using Azure PowerShell. It can’t be configured using the Azure portal.
To configure forced tunneling, you must:
* Create a routing table.
* Add a user-defined default route to the VPN Gateway.
* Associate the routing table to the appropriate VNet subnet.
Forced tunneling must be associated with a VNet that has a route-based VPN gateway.
* You must set a default site connection among the cross-premises local sites connected to the virtual network.
* The on-premises VPN device must be configured using 0.0.0.0/0 as traffic selectors.
Using forced tunneling allows you to restrict and inspect Internet access from your VMs and cloud services in Azure.
Configure Azure Route Server
Azure Route Server is a fully managed service that simplifies dynamic routing between your network virtual appliance (NVA) and your virtual network.
- You no longer need to manually update the routing table on your NVA whenever your virtual network addresses are updated.
- You no longer need to update User-Defined Routes manually whenever your NVA announces new routes or withdraw old ones.
- You can peer multiple instances of your NVA with Azure Route Server.
- The interface between NVA and Azure Route Server is based on a common standard protocol. As long as your NVA supports BGP, you can peer it with Azure Route Server.
- You can deploy Azure Route Server in any of your new or existing virtual network.
Diagnose a routing problem
You can diagnose a routing problem by viewing the routes that are effective for a network interface in a VM.
Configure internet access with Azure Virtual NAT
Globally, IPv4 address ranges are in short supply, and can be an expensive way to grant access to Internet resources. Network Address Translation (NAT) arose out of this need for internal resources on a private network to share routable IPv4 addresses to gain access to external resources on a public network.
Rather than purchasing an IPv4 address for each resource that requires internet access, you can use a NAT service to map outgoing requests from internal resources to an external IP address, so that communication can take place.
- NAT services provide mappings for a single IP address, a range of IP addresses defined by an IP Prefix, and a range of ports associated with an IP address.
- NAT is compatible with standard SKU public IP address resources or public IP prefix resources or a combination of both.
- NAT allows flows to be created from the virtual network to the Internet. Return traffic from the Internet is only allowed in response to an active flow.
- You define the NAT configuration for each subnet within a VNet to enable outbound connectivity by specifying which NAT gateway resource to use.
- NAT scales to support dynamic workloads. By using port network address translation (PNAT or PAT), NAT provides up to 64,000 concurrent flows for UDP and TCP respectively, for each attached public IP address. NAT can support up to 16 public IP addresses.
NAT gateway resource:
* Create regional or zonal (zone-isolated) NAT gateway resource,
* Assign IP addresses,
* If necessary, modify TCP idle timeout (optional).
NAT is compatible with the following standard SKU resources:
* Load balancer
* Public IP address
* Public IP prefix
Limitations of NAT
- NAT is compatible with standard SKU public IP, public IP prefix, and load balancer resources. Basic resources (for example basic load balancer) and any products derived from them aren’t compatible with NAT. Basic resources must be placed on a subnet not configured with NAT.
- IPv4 address family is supported. NAT doesn’t interact with IPv6 address family. NAT can’t be deployed on a subnet with an IPv6 prefix.
- NAT can’t span multiple virtual networks.
- IP fragmentation isn’t supported.
