Skip to content

Latest commit

 

History

History
86 lines (69 loc) · 3.42 KB

2.5.1. Virtual Networks - Virtual Network Connectivity.md

File metadata and controls

86 lines (69 loc) · 3.42 KB
Raw

Virtual Network Connectivity

Communicate between Azure resources

  • Through virtual network service endpoints
    • Endpoints allow you to secure your critical Azure service resources to only your virtual networks.
    • Available for: • Azure Storage • Azure SQL • PostgreSQL • MySQL • Cosmos DB • Key Vault • Service Bus • Event Hubs
  • Through a virtual network
    • Some resources can be deployed directly to a virtual network.
      • E.g. Redis, Azure Kubernetes Service, App Service Environment...

Communicate with on-premises resources or intersite connectivity

VPN Gateway Connections

  • Gateway to gateway connections.
  • Requires shared key that both parts know.
  • Azure VPN gateways provide secure tunnel using IPSec/IKE.
  • You can see & verify established connections in VNet → Gateway → Connections blade as "Status: Connected"

VNet <=> VNet

  • Works across regions, subscriptions, deployment models, cloud/on-prem.
  • 💡 Use one VNet as gateway and peer other ones on Azure. Gateways on every VNet is costly & slow!
  • On Azure the connection does not go over the internet.
  • Deploy Gateway on each VNet.
    • Set-up connection in VNet1 gateway to VNet2
    • Set-up connection in VNet2 gateway to VNet1
Site-to-site (S2S)
  • If one VNet is on-prem it's called Site-to-site (S2S)
  • On-premises VPN device <=> Azure VPN Gateway
  • The local gateway is configured manually
  • Problem: All users download VPN client to connect Azure.
    • Easier: Have a hardware device as jumpbox and use it as gateway through secure ip tunneling.
    • Even easier: ExpressRoute.

VNet <=> Device (with VPN Gateway)

  • Or Point-to-site virtual private network (VPN)
  • Configure =>
    • IP address space for clients.
    • Configure virtual gateway
    • Create root and client certificates & upload to azure
    • Install VPN client configuration created by Azure
    • Connect to VPN

Azure ExpressRoute

  • Private connection that does not go over the internet.
  • BDP is the only routing way.
  • Reliable => Circuits consist of two connection to Microsoft Enterprise Edge.
  • Facilitated by a connectivity provider (e.g. Telia, Tele2)

Virtual Network peering

  • The virtual networks you connect are across subscriptions and regions.
  • All traffic is routed over Azure internal networks, handled by Azure infrastructure.
  • Faster & easer to setup than VPN
  • No public IP required
  • No downtime when creating/configuring peering.
  • Regional network peering => In same VNet
  • Global network peering => Cross region VNets (in preview)
  • Requirements:
    • Public clouds (not Azure national clouds)
    • Resources in one VNet cannot communicate with load balancer in the peered VNet. Load balancer and resources that communicate with it must be in same VNet.
  • ❗ Limitations:
    • Not transitive.
      • E.g.: VNet1<=>VNet2 and VNet2<=>VNet3 does not mean VNet1<=>VNet3
    • No overlapping address spaces
    • Any address space changing => Destroy peering re-deploy

Virtual Network peering settings

  • Allow forwarded traffic
    • Allows traffic not originated from within peer VNet to VNet.
  • Allow gateway transit
    • Peer VNet uses your network gateway.
    • Allows you to have single gateway, instead of gateway per VNet (called hub-spoke topology)
    • Examples:
      • Site-to-site VPN <=> On-prem network
      • VNet-to-VNet <=> Another VNet
      • Point-to-site VPN <=> Connect client
  • Use remote gateways
    • Uses peer's virtual gateway.