Skip to content

Latest commit

 

History

History
131 lines (118 loc) · 5.72 KB

6.1. Networking - Virtual Network (VNet).md

File metadata and controls

131 lines (118 loc) · 5.72 KB
Raw

Virtual Network (VNet)

  • Communications and security boundary
    • Provides network isolation and segmentations
    • Enables Azure resources to communicate with each other securely
      • E.g. VMs, storage accounts, App Service apps, Azure SQL database instances
  • Uses Azure network backbone
    • Communications are internal by default unless you explicitly make it external
  • Name resolution
    • Azure-provided DNS
    • DNS service
  • Traffic filtering
    • NSGs
    • Network Virtual Appliances
  • ❗ 1000 VNets allowed per region per subscription
  • ❗ A resource can only be created in a virtual network that exists in the same region and subscription as the resource.
  • Why multiple VNets?
    • Saving money
      • Service chaining: Share a network virtual appliance among several VNets
    • Segmenting workloads
      • NSGs and UDRs give you routing and traffic control
      • E.g. hub and spokes
    • Securing traffic
      • Private connectivity that uses the Microsoft backbone network
  • Moving a VNet
    • ❗ When moving a virtual network, you must also move its dependent resources
      • For VPN Gateways
        • You must move IP addresses, virtual network gateways, and all associated connection resources.
      • 💡 Local network gateways can be in a different resource group.
    • To move a peered virtual network, you must first disable the virtual network peering
    • ❗ You can't move a virtual network to a different subscription if the virtual network contains a subnet with resource navigation links
      • For example, if an Azure Cache for Redis resource is deployed into a subnet, that subnet has a resource navigation link.

Role of VNet

  • You can link app services, storage accounts, VMs
  • Provides traffic isolation and segmentation
  • Runs on Azure backbone network
  • Configure communication with Internet
    • 💡 Ensure only VMs that need public IP addresses get one.
  • You need to link VNets together to allow communication
  • Control traffic flows into the VNET, within the VNET, and between VNets.
  • Have IPv4 address space
    • Uses CIDR block of private RFC 1918 addresses that are not publicy/internet routable themselves
  • VNets are divided into subnets
    • E.g. in multi-tiered application, web-tier, business-tier, data-tier
      • Good for protecting access using NSGs
      • Good for having jumpbox and protecting who can connect to jump-box

VNet Design Best Practices

  • Create subnets based on workloads
    • E.g. all of your web front-ends will have similar access requirements, then you can bind NSGs on subnet level.
  • Bind NSGs at the subnet level
    • Not good to bind at VNet level for better troubleshooting
  • Deploy a network virtual appliance (NVA) and user-defined routes (UDRs) to further customize traffic.
    • Virtual appliance (NVA)
      • E.g. enterprise grade firewall appliance, load balancer appliance
      • They exist in Azure marketplace
      • They'll be installed in VNet as a VM
    • User defined routes (UDRs)
      • Customize and control routing in a VNet
  • Implement site-to-site or point-to-site VPN tunnels with on-premises environment

Deploying a VNet

  • You can use ARM templates e.g. from Github.
    • Visual Studio is recommended for editing templates
  • During deployment:
    • Name: Must be unique
    • Subnet: Default gives you one subnet, for more you can use ARM template or PowerShell/CLI
    • DDoS protection
      • Microsoft publishes their datacenter public IP address
      • Bad actors run port-scanners on those IP addresses all the time
    • Service endpoints
      • Allows you to integrate Azure PaaS services
  • After deployment:
    • Address space
      • You cannot edit
      • You need to create new and delete old one.
    • Subnets
      • You can always add new subnets & deploy gateway subnet that'll be used by an Azure gateway.
    • DNS server
      • Default is azure provided
      • You can use custom by additional DNS servers
        • Affect all VMs
        • Still uses Azure DNS when necessary
        • Used when e.g. site-to-site or point-to-site connections, it'll affect all VMs.
    • Diagram
      • You can enable Network Watcher here.
      • You then load in subscription or RG and enable.
      • It shows topology

Network Security Groups (NSG)

  • Stateful firewall for inbound and outbound traffic
    • Stateful = 5-tuple hash
      • Source + destination IP and ports
      • Protocol
  • Has default rules
  • Augmented rules
    • Allow you specify list of IP-addresses
    • No need to create several rules for same list
  • Service tags
    • Azure defined named IP address endpoints
    • E.g. Internet, VirtualNetwork, AzureLoadBalancer, AzureTrafficManager, Storage, SQL, AzureCosmosDB, AzureKeyVault.
    • Allows you to use names instead of IP addresses
  • Application Security Groups (ASGs)
    • Custom (user-defined) logical identifiers
    • You can associate IP ranges and then use it as source/destination in NSGs.
    • E.g. WebServer, WappServers, DbServers
  • Can be bound to VNets, subnets or NICs
    • 💡 Bind to subnets
  • Security rules
    • Priority: Lower the number, higher the priority of the rules

IP Addressing Best Practices

  • If a VM doesn't need a public IP address (PIP), then don't assign one and use an Azure load balancer instead.
  • Plan your VNet private address space to avoid overlap.
    • Different from on-premises
    • Different from other VNets in Azure
  • Never configure networking from within the VM
    • Do it on Azure instead using Azure abstractions

Network Interfaces

  • Assigned to a single subnet.
  • Have a public or private IP that's dynamic or static.
  • IP forwarding
    • E.g. if you have network appliance and you want to give it ability to forwar traffic that's not destined for itself