Azure Hub and Spoke VNets - Private Endpoints and Private DNS Zones

Azure makes it simple to access Azure Cloud Services from your processes in Azure over the public network.  Things become a little more complicated when you implement the best practice of restricting access to your Azure Services to only your Azure networks (VNets).  This simple action drags in Private Link Endpoints and Private DNS Zones. 

Enterprises typically then layer on multiple Virtual Networks (VNets) for management and control purposes. This VNET Hub and Spoke architecture is pretty common though Microsoft has recently been advising customers to implement HUB and Spoke more through subnets than VNets. This reduces VNet sprawl and the amount of peering and other network magic required  

See YouTube video links below

Private Endpoints / Private DNS Zones 

Azure Standard Sevices can be restricted from the Public Internet to your private Virtual Network (VNet) through the use of Private Link Endpoints (PLE). The PLEs essentially create private connections from a Network Interface Card (NIC) in your VNet to the Azure Service.  
  • Each service asset has its own Private Link Endpoint and corresponding NIC.
  • A DNS entry is created for that NIC using an Azure standard domain name.  
  • The DNS entry is managed through a Private DNS Zone.  
  • The Private DNS Zone is joined to your VNet through a Virtual Network Link. A Private DNS Zone's Virtual Network Links can be managed in the Azure Portal.
  • Processes in that VNET can access the resource PLE via DNS name using the standard Azure VNet DNS service available on the well-known address in each VNET.
Each Azure service type has its own domain naming standard and corresponding Private DNS Zone.



This VNet also includes a Point to Site (P2S) VPN on the VNet Gateway. Remote processes communicate with Azure resources over the VPN tunnel.  A DNS forwarder is provisioned in the VNET and attached to the VPN Gateway.  The downloaded VPN configuration files include references to the DNS Forwarder.  External processes then use that DNS Forwarder as their DNS server when looking up Azure names. 

Private Link Endpoint / DNS / Hub and Spoke VNets

This same behavior can be extended across peered VNets. It is pretty standard in the networking world to organize networks around a hub and spoke topology.  There is typically a hub VNet that contains management resources and gateways or peerings off to any resources outside this grouping.  Worker or Spoke VNets connect to the hub.  Resources in the spoke VNets talk to resources in other VNets by transiting through the hub. The current Landing Zone pattern is an extension of this.   
  • Peering relationships are set up between the Hub Vnet and each connected Spoke.
  • Private DNS Zone resources are declared in a centralized resource group rather than in one of the Resource Groups dedicated to Spoke assets.
  • Azure services are exposed in a given Spoke using the same pattern used for a single VNet with Private Endpoints and Private DNS Zones that are connected to the Spoke VNet DNS via Virtual Network Links.
  • Private Link NIC DNS entries from all the Spokes are stored in the same share Private DNS Zones.
  • The Private DNS Zones are linked to all the VNets.  Really to all the VNets where that asset may be accessed from.


The DNS Forwarder presented to VPN Clients is linked to the standard VNet Azure DNS Server.  That server knows about the Private DNS Zone severs.  This means the programs on the VPN have access to the DNS entries for all of the Private Endpoints or other resources in all the Spoke VNets.


Videos

Example Project on GitHub

This picture comes from the README of https://github.com/freemansoft/vnet-p2s-vpn-bastion-azure. It shows multiple Private DNS Zones, one for each type of Azure Service resource that exists in this project.  Each Zone is exposed to the Spoke VNet over a Virtual Network Link, as described in the Azure Portal. 

The Spoke VNet contains multiple subnets.  Some of those subnets have Private Link Endpoints terminating in them.  Those PLEs DNS entries are registered with the corresponding Private DNS Zones.  This means compute and other resources in that VNET can find the resource by name.  

The same DNS is linked to the Hub VNet.  This means processes on the hub VNet can also see the PLE DNS names. 


The screenshots in the rest of this blog are from Infrastructure configured via this GitHub Project https://github.com/freemansoft/vnet-p2s-vpn-bastion-azure

Hub and Spoke VNets

Our sample network has two VNets.  One Hub and one Spoke.



Subnets on the two VNets

Each VNet has its own subnet.  Our Hub VNet has 3 network management and governance subnets. 




The Spoke Vnet has compute, data, and secrets subnets.  The data and CredentialsSecrets subnets will contain Private Link Endpoints for our data and Key Vault Azure services


DNS Forwarders

The Hub VNet contains a VPN gateway.  This means it needs a DNS Forwarder to provide internal Azure DNS IP address resolution for processes across the VNet.



Spoke VNets use standard Azure DNS services.


Private Endpoints

We don't have any Private Endpoints in the Hub VNet.  A real network would have Key Vault, Storage or other services used for management and governance.




The Spoke VNet contains Private Endpoints for Storage Accounts and Key Vaults.


Private DNS Zones

Private DNS Zones are created for each of the Azure Service types, and associated DNS Zone, we expect to provision access via Private Endpoints.  All of the Private DNS Zones are put in the same Resource Group to ensure that we don't end up with disjoint Private DNS Zones for the same domain.



The project has a core Resource Group that contains our VNET, DNS Forwarder VPN Gatway and all the Private DNS Zones.


Private DNS Zone Links to VNETs

Private DNS Zones are exposed into VNets via Virtual Network Links.  A link is created from the DNS Zone to each VNet where the resource may need to be accessed via DNS name.  In this example, we create a link to every VNet, hub, and spoke.

Private DNS Zone DNS Private Link Entries

A DNS entry is created for every Private Endpoint.  Microsoft has standardized the domain name for Private Links by Azure resource types.  All of the Azure Storage blob resources end up in the blob.core.windows.net domain.  The sample has a single blob resource so there is only one DNS entry in the Private DNS Zone DNS server for that domain.


We've exposed both blob and file for this Storage Account. This means we created Private Endpoints for both file and blob.  There will be two DNS entries each in its associated zone.

Conclusion

This was a short description of how VNets, peering, Private Endpoints, and multi-VNet DNS work.  Leave feedback if you think one of these sections could use more explanation.

Created 2022 04

Comments

Post a Comment

Popular posts from this blog

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

Image
I do a lot of my development and configuration via ssh into my Raspberry Pi Zero over the RNDIS connection. Some models of the Raspberry PIs can be configured with  gadget drivers  that let the Raspberry pi emulate different devices when plugged into computers via USB. My favorite gadget  is the network profile that makes a Raspberry Pi look like an RNDIS-attached network device.  All types of network services travel over an RNDIS device without knowing it is a USB hardware connection. A Raspberry Pi shows up as a Remote NDIS (RNDIS) device when you plug the Pi into a PC or Mac via a USB cable. The gadget  in the Windows Device Manager picture shows this RNDIS Gadget connectivity between a Windows machine and a Raspberry Pi. The Problem Windows 11 and Windows 10 no longer auto-installs the RNDIS driver that makes magic happen. Windows recognizes that the Raspberry Pi is some type of generic USB COM device. Manually running W indows Update  or  Update Driver  does  not  install the RNDI
Read more

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Image
The Windows Subsystem for Linux operates as a virtual machine that can dynamically grow the amount of RAM to a maximum set at startup time.  Microsoft sets a default maximum RAM available to 50% of the physical memory and a swap-space that is 1/4 of the maximum WSL RAM.  You can scale those numbers up or down to allocate more or less RAM to the Linux instance. The first drawing shows the default WSL memory and swap space sizing. The images below show a developer machine that is running a dev environment in WSL2 and Docker Desktop.  Docker Desktop has two of its own WSL modules that need to be accounted for.  You can see that the memory would actually be oversubscribed, 3 x 50% if every VM used its maximum memory.  The actual amount of memory used is significantly smaller allowing every piece to fit. Click to Enlarge The second drawing shows the memory allocation on my 64GB laptop. WSL Linux defaults to a maximum RAM size of 5
Read more

Almost PaaS Document Parsing with Tika and AWS Elastic Beanstalk

Image
The Apache Tika project provides a  library capable of parsing and extracting data and meta data from over 1000 file types.  Tika is available as a single jar file that can be included inside applications or as a deployable jar file that runs Tika as a standalone service. This blog describes deploying the Tika jar as an auto-scale service in Amazon AWS Elastic Beanstalk.  I selected Elastic Beanstalk because it supports jar based deployments without any real Infrastructure configuration. Elastic Beanstalk auto-scale should take care of scaling up and down for for the number of requests you get. Tika parses documents and extracts their text completely in memory. Tika was deployed for this blog using EC2 t2.micro instances available in the AWS free tier. t2.micro VMs are 1GB which means that you are restricted in document complexity and size. You would size your instances appropriately for your largest documents.   Preconditions An AWS account. AWS access id and secret key.
Read more