Module 12: Virtual Network Peering | AZ-104

Lý Thuyết Cốt Lõi

1. VNet Peering — Kết Nối Giữa Các Virtual Network

VNet Peering cho phép hai Azure Virtual Network kết nối trực tiếp với nhau qua backbone Microsoft (không đi qua Internet, không cần VPN Gateway). Traffic đi qua đường truyền tốc độ cao, độ trễ thấp, được mã hóa ở tầng data link.

VNet Peering (cùng region)

• Kết nối hai VNet trong cùng Azure region
• Không cần Gateway — kết nối trực tiếp qua backbone
• Băng thông không giới hạn về mặt lý thuyết (giới hạn bởi VM NIC)
• Độ trễ tương đương như trong cùng VNet
• Không tính phí egress nội region (chỉ tính ingress/egress)

Global VNet Peering (khác region)

• Kết nối VNet ở hai region khác nhau (VD: Southeast Asia ↔ East Asia)
• Vẫn đi qua Microsoft backbone — không phải Internet công cộng
• Có tính phí cross-region data transfer
• Hỗ trợ kết nối cross-subscription và cross-tenant
• Độ trễ phụ thuộc khoảng cách địa lý giữa hai region

Điều kiện & Giới hạn

• Không được phép chồng chéo địa chỉ IP (CIDR overlap)
• Peering không có tính bắc cầu: A↔B, B↔C không có nghĩa A↔C
• Cần quyền Network Contributor trên cả hai VNet
• Có thể peering cross-subscription — cần authorization
• Mỗi VNet hỗ trợ tối đa 500 peering connections

Trạng thái Peering

• Initiated: một phía đã tạo peering, chờ phía kia xác nhận
• Connected: cả hai phía đã tạo peering, đang hoạt động
• Disconnected: một phía đã xóa peering
• Peering phải ở trạng thái Connected mới thông traffic

Quan trọng: Peering là kết nối hai chiều nhưng phải tạo riêng ở mỗi phía. Khi tạo peering từ VNet-A sang VNet-B, bạn phải tạo thêm peering từ VNet-B sang VNet-A. Azure Portal có thể tự động tạo cả hai nếu bạn có quyền trên cả hai VNet.

2. Gateway Transit & Connectivity

Gateway Transit cho phép VNet spoke (không có Gateway) sử dụng chung VPN Gateway hoặc ExpressRoute Gateway của VNet hub. Đây là tính năng then chốt trong kiến trúc hub-spoke để tiết kiệm chi phí Gateway.

Hub VNet

Chứa VPN Gateway hoặc ExpressRoute Gateway. Bật Allow gateway transit trên peering connection từ Hub sang Spoke.

Spoke VNet

Không có Gateway riêng. Bật Use remote gateways trên peering connection từ Spoke sang Hub để dùng nhờ Gateway của Hub.

On-Prem

Kết nối vào Hub qua VPN/ExpressRoute, tự động thấy được tất cả Spoke thông qua Gateway Transit.

Cài đặt Peering	Đặt ở đâu	Tác dụng
Allow gateway transit	Hub → Spoke peering	Cho phép Spoke dùng Gateway của Hub
Use remote gateways	Spoke → Hub peering	Spoke sử dụng nhờ Gateway từ remote VNet
Allow forwarded traffic	Cả hai chiều	Cho phép forward traffic không originate từ VNet này
Allow virtual network access	Cả hai chiều	Bật/tắt quyền truy cập giữa hai VNet (mặc định bật)

3. Tạo VNet Peering — Quy Trình & Lưu Ý

Peering có thể tạo qua Azure Portal, Azure CLI, PowerShell, hoặc ARM Template. Dưới đây là luồng tạo peering chuẩn giữa hai VNet trong cùng subscription.

Quy trình Portal

Mở VNet nguồn → Peerings → + Add
Điền tên peering link (VNet A → VNet B)
Chọn VNet đích (cùng/khác subscription)
Cấu hình traffic settings (forwarded, gateway)
Azure tự tạo peering chiều ngược lại nếu có quyền
Chờ status chuyển sang Connected

Cross-Subscription Peering

Người dùng A tạo peering từ VNet-A (Sub-A) → chỉ định Resource ID của VNet-B
Trạng thái: Initiated (chưa được xác nhận)
Người dùng B tạo peering từ VNet-B (Sub-B) → VNet-A
Cả hai peering chuyển sang Connected
Cần lấy Resource ID của VNet-B: az network vnet show

4. Mở Rộng Peering — UDR & Service Chaining

Vì peering không có tính bắc cầu, để định tuyến traffic giữa các spoke qua hub (NVA — Network Virtual Appliance), cần kết hợp UDR (User-Defined Routes) với service chaining.

Service Chaining

Cho phép traffic đi qua NVA (firewall, router VM) trong Hub VNet trước khi đến đích. Spoke → Hub (NVA) → Spoke khác.

• NVA nhận và forward traffic giữa các Spoke
• Cần bật IP Forwarding trên NIC của NVA VM
• Bật Allow forwarded traffic trên peering

User-Defined Routes (UDR)

Route table tùy chỉnh gắn vào subnet để override system routes. Định tuyến traffic theo ý muốn.

• Next hop: Virtual appliance (IP của NVA)
• Next hop: VNet gateway (cho on-prem traffic)
• Next hop: None (drop traffic — blackhole)
• Gắn route table vào subnet bằng az network vnet subnet update

Kiến trúc Hub-Spoke hoàn chỉnh

On-Premises ←→ VPN Gateway (Hub VNet: 10.0.0.0/16)

├── NVA (Firewall VM: 10.0.1.4) — IP Forwarding bật

├── Peering → Spoke-A (10.1.0.0/16) [Allow forwarded traffic]

└── Peering → Spoke-B (10.2.0.0/16) [Allow forwarded traffic]

Route Table gắn vào Spoke-A/subnet:

└── 10.2.0.0/16 → Next hop: Virtual Appliance (10.0.1.4)

Azure Firewall thay NVA: Trong môi trường production, dùng Azure Firewall (managed NVA) trong Hub thay vì tự dựng NVA VM. Azure Firewall tự xử lý IP Forwarding, hỗ trợ FQDN filtering, threat intelligence và tích hợp tốt với UDR.

Bài Tập Thực Hành (Lab)

Lab 12-A: Tạo VNet & Peering Lab 12-B: Gateway Transit Lab 12-C: UDR & Service Chaining Lab 12-D: Verify Connectivity

Tạo Resource Group và ba VNet (Hub + 2 Spoke)

Azure CLI— Chạy được trên PowerShell, CMD, Bash hoặc Azure Cloud Shell

# Tạo Resource Group
az group create \
  --name rg-az104-m12 \
  --location southeastasia

# Tạo Hub VNet (10.0.0.0/16)
az network vnet create \
  --name vnet-hub \
  --resource-group rg-az104-m12 \
  --location southeastasia \
  --address-prefix 10.0.0.0/16 \
  --subnet-name subnet-hub \
  --subnet-prefix 10.0.1.0/24

# Tạo Spoke-A VNet (10.1.0.0/16)
az network vnet create \
  --name vnet-spoke-a \
  --resource-group rg-az104-m12 \
  --location southeastasia \
  --address-prefix 10.1.0.0/16 \
  --subnet-name subnet-spoke-a \
  --subnet-prefix 10.1.1.0/24

# Tạo Spoke-B VNet (10.2.0.0/16)
az network vnet create \
  --name vnet-spoke-b \
  --resource-group rg-az104-m12 \
  --location southeastasia \
  --address-prefix 10.2.0.0/16 \
  --subnet-name subnet-spoke-b \
  --subnet-prefix 10.2.1.0/24

echo "Ba VNet đã được tạo thành công."

Verify Portal: Azure Portal → Virtual networks → lọc theo rg-az104-m12 → xác nhận 3 VNet: vnet-hub (10.0.0.0/16), vnet-spoke-a (10.1.0.0/16), vnet-spoke-b (10.2.0.0/16) đều hiển thị trạng thái Succeeded.

Tạo VNet Peering giữa Hub và hai Spoke

Azure CLI— Chạy được trên PowerShell, CMD, Bash hoặc Azure Cloud Shell

# Peering Hub → Spoke-A (bật Allow gateway transit)
az network vnet peering create \
  --name hub-to-spoke-a \
  --resource-group rg-az104-m12 \
  --vnet-name vnet-hub \
  --remote-vnet vnet-spoke-a \
  --allow-vnet-access true \
  --allow-forwarded-traffic true \
  --allow-gateway-transit false

# Peering Spoke-A → Hub (bật Use remote gateways nếu Hub có Gateway)
az network vnet peering create \
  --name spoke-a-to-hub \
  --resource-group rg-az104-m12 \
  --vnet-name vnet-spoke-a \
  --remote-vnet vnet-hub \
  --allow-vnet-access true \
  --allow-forwarded-traffic true \
  --use-remote-gateways false

# Peering Hub → Spoke-B
az network vnet peering create \
  --name hub-to-spoke-b \
  --resource-group rg-az104-m12 \
  --vnet-name vnet-hub \
  --remote-vnet vnet-spoke-b \
  --allow-vnet-access true \
  --allow-forwarded-traffic true \
  --allow-gateway-transit false

# Peering Spoke-B → Hub
az network vnet peering create \
  --name spoke-b-to-hub \
  --resource-group rg-az104-m12 \
  --vnet-name vnet-spoke-b \
  --remote-vnet vnet-hub \
  --allow-vnet-access true \
  --allow-forwarded-traffic true \
  --use-remote-gateways false

# Kiểm tra trạng thái peering
az network vnet peering list \
  --resource-group rg-az104-m12 \
  --vnet-name vnet-hub \
  --output table

Verify Portal: Vào vnet-hub → Peerings → xác nhận hub-to-spoke-a và hub-to-spoke-b đều có Peering status = Connected. Cột "Traffic to remote virtual network" và "Traffic forwarded from remote virtual network" = Allowed.

Tạo NVA VM trong Hub và bật IP Forwarding

Bash— Linux/macOS/Cloud Shell, KHÔNG chạy CMD

# Tạo VM làm NVA (Network Virtual Appliance) trong Hub VNet
az vm create \
  --resource-group rg-az104-m12 \
  --name vm-nva-hub \
  --image Ubuntu2204 \
  --size Standard_B1s \
  --vnet-name vnet-hub \
  --subnet subnet-hub \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard \
  --nsg-rule SSH \
  --no-wait

# Lấy NIC ID của NVA VM
NIC_ID=$(az vm show \
  --resource-group rg-az104-m12 \
  --name vm-nva-hub \
  --query 'networkProfile.networkInterfaces[0].id' \
  --output tsv)

NIC_NAME=$(basename $NIC_ID)

# Bật IP Forwarding trên NIC của NVA — bắt buộc để forward traffic
az network nic update \
  --resource-group rg-az104-m12 \
  --name $NIC_NAME \
  --ip-forwarding true

# Lấy Private IP của NVA để dùng làm next hop trong UDR
NVA_IP=$(az vm show \
  --resource-group rg-az104-m12 \
  --name vm-nva-hub \
  --show-details \
  --query privateIps \
  --output tsv)

echo "NVA Private IP: $NVA_IP"

Verify Portal: vm-nva-hub → Networking → Network Interface → IP configurations → xác nhận IP forwarding: Enabled. Ghi lại Private IP (ví dụ: 10.0.1.4) để dùng ở bước tiếp theo.

Tạo UDR và gắn vào Spoke subnet — Service Chaining qua NVA

Azure CLI— Chạy được trên PowerShell, CMD, Bash hoặc Azure Cloud Shell

# Thay NVA_IP bằng IP thực từ bước 3 (VD: 10.0.1.4)
NVA_IP="10.0.1.4"

# Tạo Route Table cho Spoke-A
az network route-table create \
  --resource-group rg-az104-m12 \
  --name rt-spoke-a \
  --location southeastasia \
  --disable-bgp-route-propagation false

# Thêm route: traffic từ Spoke-A đến Spoke-B phải đi qua NVA
az network route-table route create \
  --resource-group rg-az104-m12 \
  --route-table-name rt-spoke-a \
  --name route-to-spoke-b \
  --address-prefix 10.2.0.0/16 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address $NVA_IP

# Gắn Route Table vào subnet của Spoke-A
az network vnet subnet update \
  --resource-group rg-az104-m12 \
  --vnet-name vnet-spoke-a \
  --name subnet-spoke-a \
  --route-table rt-spoke-a

# Tạo Route Table cho Spoke-B (ngược lại)
az network route-table create \
  --resource-group rg-az104-m12 \
  --name rt-spoke-b \
  --location southeastasia

az network route-table route create \
  --resource-group rg-az104-m12 \
  --route-table-name rt-spoke-b \
  --name route-to-spoke-a \
  --address-prefix 10.1.0.0/16 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address $NVA_IP

az network vnet subnet update \
  --resource-group rg-az104-m12 \
  --vnet-name vnet-spoke-b \
  --name subnet-spoke-b \
  --route-table rt-spoke-b

echo "UDR đã được gắn. Traffic Spoke-A ↔ Spoke-B sẽ đi qua NVA."

Verify Portal: subnet-spoke-a → Route table = rt-spoke-a. rt-spoke-a → Routes → xác nhận route 10.2.0.0/16 với Next hop = Virtual appliance (10.0.1.4). Tương tự cho rt-spoke-b.

Cleanup — Dọn dẹp tài nguyên để tránh phát sinh chi phí

Azure CLI— Chạy được trên PowerShell, CMD, Bash hoặc Azure Cloud Shell

# Xóa toàn bộ Resource Group — kéo theo tất cả VNet, Peering, VM, Route Table
az group delete --name rg-az104-m12 --yes --no-wait

echo "Cleanup đã được gửi. RG sẽ bị xóa trong vài phút."

Kết Quả Đầu Ra

Tạo VNet Peering thành công

Tạo peering cùng region và cross-subscription, xác nhận trạng thái Connected

Cấu hình Gateway Transit

Hiểu và cấu hình Allow gateway transit / Use remote gateways trong kiến trúc hub-spoke

Triển khai kiến trúc Hub-Spoke

Xây dựng mô hình Hub-Spoke với Hub VNet kết nối nhiều Spoke, traffic đi qua NVA

Tạo và gắn UDR vào subnet

Tạo Route Table với custom routes, gắn vào subnet để override system routes

IP Forwarding trên NVA

Bật IP Forwarding trên NIC của VM để VM đóng vai trò NVA forward traffic giữa các mạng

Hiểu giới hạn Non-Transitive

Giải thích tại sao peering không bắc cầu và cách UDR + NVA giải quyết vấn đề này

Ứng Dụng Thực Tế

Tình huống 1: Tập đoàn sản xuất — Phân tách môi trường Dev/Staging/Prod

Ba môi trường trong ba VNet riêng biệt, cần kết nối với Hub chứa AD DS và file server dùng chung, nhưng Dev không được thấy Prod.

Giải pháp

Hub-Spoke: Hub VNet chứa AD DS (10.0.0.0/16). Spoke-Dev (10.1.0.0/16), Spoke-Staging (10.2.0.0/16), Spoke-Prod (10.3.0.0/16) đều peering với Hub. NSG chặn traffic trực tiếp giữa các Spoke.

Triển khai

Peering Hub↔Spoke-Dev/Staging/Prod với Allow forwarded traffic. Azure Firewall trong Hub làm NVA. UDR gắn vào mỗi Spoke subnet định tuyến traffic qua Firewall. Gateway Transit qua VPN Gateway đến on-prem nhà máy.

Lợi ích

Dev không thể truy cập dữ liệu Prod. Mỗi Spoke dùng chung 1 VPN Gateway (tiết kiệm ~$200/tháng/gateway). Firewall log đầy đủ traffic giữa các môi trường cho audit.

Tình huống 2: Công ty Fintech — Kết nối multi-region DR

Primary tại Southeast Asia (Singapore), DR tại East Asia (Hong Kong). Cần replication database và failover nhanh khi sự cố.

Giải pháp

Global VNet Peering giữa vnet-primary (10.10.0.0/16, southeastasia) và vnet-dr (10.20.0.0/16, eastasia). Traffic replication đi qua Microsoft backbone — không phải Internet.

Triển khai

Global Peering với Allow forwarded traffic = true. SQL Always-On AG replication qua peering. Azure Site Recovery replication traffic đi qua Private Endpoint, không ra Internet. NSG chỉ mở port SQL (1433) giữa hai VNet.

Lợi ích

RTO <15 phút, RPO <5 phút. Replication traffic không đi qua Internet — bảo mật và ổn định hơn VPN. Chi phí cross-region peering thấp hơn ExpressRoute cho workload DR.

Tình huống 3: Hệ thống bệnh viện — Kết nối cơ sở y tế vùng sâu

Bệnh viện trung tâm tại TP.HCM cần kết nối với 10 phòng khám vệ tinh tại các tỉnh, chia sẻ HIS (Hospital Information System) và PACS (hình ảnh y tế).

Giải pháp

Hub VNet (bệnh viện trung tâm) peering với 10 Spoke VNet (phòng khám). HIS và PACS server trong Hub. Mỗi Spoke có VNet riêng với NSG chặt chẽ, chỉ mở port cụ thể đến Hub.

Triển khai

Gateway Transit: 10 Spoke dùng chung VPN Gateway của Hub để kết nối on-prem thiết bị y tế tại các tỉnh. UDR đảm bảo traffic giữa phòng khám không đi trực tiếp. Azure Private DNS cho FQDN nội bộ HIS.

Lợi ích

Tiết kiệm 90% chi phí Gateway (dùng chung thay vì mỗi nơi 1 cái). Dữ liệu bệnh nhân không ra Internet. Bác sĩ phòng khám vệ tinh xem được kết quả PACS từ trung tâm trong <2 giây.

Module 11: Azure DNS Module 13: Routing & Endpoints