Azure的網路設計

如果公司的業務業務擴及全球範圍，我們 將使用多個 Azure Regions來託管其應用程式。這些應用程式中的大多數都依賴於基礎架構和資料服務，這些服務也將放在 Azure 中。遷移到 Azure 的內部應用程式必須仍然可供公司內部使用者存去。遷移到 Azure 對外網站必須可供任何外部客戶訪問。

透過本文，我們可以學習到如下目標：

• 根據工作負載需求建議其網路架構方案
• 設計用於與 Azure Virtual Networks(以下簡稱vNet)的地端機房連接
• 設計Azure 網路連接服務
• 設計程式交付服務( application delivery services)
• 設計 程式保護服務(application protection services)

根據工作負載需求建議其網路架構方案

在本節中，我們將了解 Azure 中的網路服務如何提供可以一起或單獨使用來滿足我們要求的各種網路功能。

• Connectivity services — 使用 Azure 中的任何網路服務或這些網路服務的組合連接 Azure 資源和地端資源 。如VNet, Virtual WAN, ExpressRoute, VPN Gateway, Virtual network NAT Gateway, Azure DNS, Peering service, and Azure Bastion.。
• Application protection services — 在 Azure 中使用這些網路服務中的任何一個或組合來保護我們的應用程式 。如Load Balancer, Private Link, DDoS protection, Firewall, Network Security Groups, Web Application Firewall, and Virtual Network Endpoints.。
• Application delivery services — 在 Azure 網路中使用這些網路服務中的任何一個或組合交付服務。如Content Delivery Network (CDN), Azure Front Door Service, Traffic Manager, Application Gateway, Internet Analyzer, and Load Balancer。

收集網路需求

1.命名

所有 Azure resources都有一個名稱。 該名稱在一個範圍內必須是唯一值，這可能因每種資源類型而異。 例如，vNet的名稱在resource group中必須是唯一的，但可以在subscription 或Azure region有重複名稱。 隨著時間的推移管理多個網路資源時，需要定義可以在命名資源時一致使用的命名規則。

2.Regions(地區)

所有 Azure resources都是在 Azure regions和subscription中建立的。 只能在是位於同一regions和subscription的vNet中才能建立resources。 但是，我們可以連接存在於不同subscriptions和regions中的vNet。

• 我們通常希望我們在使用Azure resources具有最低的network latency。
• 是否有data residency, sovereignty, compliance,或resiliency的要求？ 如果是這樣，選擇符合要求的Azure region至關重要。
• 對於部署的resource，是否需要跨同一 Azure region內的 Azure AZ？ 您可以將resoruce（例如VM）部署到同一vNet中的不同AZ。 但是，並非所有 Azure region都有AZ。

3. Subscriptions

可以根據需要在每個Subscriptions中部署任意數量的 vNet，直至達到限制。 例如，一些企業對不同的部門有不同的Subscriptions。

Segmentation

我們可以為每個Subscriptions和每個地區建立多個vNet。可以在每個vNet中創建多個subnet。以下注意事項可幫助我們確定需要多少vNet 與 subnets：

vNet是 Azure public network的虛擬隔離部分。每個vNet都under在Subscriptions之下。在決定是在Subscriptions中建立一個vNet還是多個vNet時要考慮的事項：

• 是否存在要將流量隔離到單獨的vNet的任何資安要求？我們可以選擇是否連接vNet。如果連接vNet，則可以放network virtual appliance（例如防火牆）來控制vNet之間的流量。
• 將vNet隔離到單獨的Subscriptions或regions是否存在任何公司的要求？
• Network interface使 VM 能夠與其他資源進行通訊。每個network interface都分配有一個或多個private IP 。在vNet中需要多少個network interface和private IP ？我們可以在vNet中使用的network interface和private IP 的數量是存在限制的。
• 是否要將vNet連接到另一個vNet或地端機房？我們可以選擇將一些vNet相互連接或連接到地端機房，而不是其他網路。連接到另一個vNet或地端機房的每個vNet都必須具有唯一的地址空間，也就是兩邊的網段不可以相衝突。每個vNet都有一個或多個分配給其地址空間的public or private ip address space。地址範圍以CIDR 格式指定，例如 10.0.0.0/16。
• 我們對不同vNet中的資源是否有任何公司管理要求？如果是這樣，我們可以將資源分離到單獨的vNet中，以簡化對公司中個人的權限分配或將不同的政策分配給不同的vNet。

Subnet 一個virtual network可以分割成一個或多個subnet。 在決定是在Subscriptions中創建一個subnet還是多個vNet時要考慮的事項：

• 每個subnet必須在Virtual network的地址空間內具有以 CIDR 格式指定的唯一地址範圍。地址範圍不能與vNet中的其他subnet重疊。
• 如果我們計劃將某些 Azure service resources部署到vNet中，它們可能需要或建立自己的subnet，因此必須有足夠的未分配IP以供它們這樣做。例如，如果我們使用 Azure VPN Gateway將vNet連接到地端機房，則Virtual network必須具有gateway的專用subnet。
• 預設情況下，Azure 在vNet中的所有subnet之間網路流量是自由流通的。但是我們可以overwrite Azure 的預設路由以防止subnet之間的內部流量，或通過Virtual network appliance在subnet之間控制流量。如果我們需要同一vNet中的資源之間的流量流經network virtual appliance(NVA)，就要將資源部署到不同的subnet。
• 我們可以將對 Azure resources（例如 Azure storage account or Azure SQL Database）的存取限制為具有Virtual Network service endpoint的特定subnet。此外，我們可以拒絕從 Internet 來的client來存取資源。我們可以建立多個subnet，並為某些subnet啟用service endpoint，但不能為其他subnet使用。
• 我們可以將一個NSG(或不要)關聯到vNet中的每個subnet。我們可以將相同或不同的NSG關聯到每個subnet。每個NSG都包含規則，這些規則允許或拒絕進出source和destinations的流量。

資安

我們可以使用NSG 與NAV過濾進出Virtual Network中資源的網路流量。 我們可以控制如何路由來自subnet的流量。 我們還可以限制公司中的哪些人可以使用Virtual Network中的資源。

流量過濾

• 使用NSG和(或)過濾網路流量的 NVA 來過濾Virtual network中資源之間的網路流量。若要部署 NVA（例如防火牆）來過濾網路流量，可以到 Azure marketplace。使用 NVA 時，我們還可以建立自定義路由以將流量從subnet由到 NVA。
• NSG包含多個預設安全規則，允許或拒絕進出資源的流量。NSG可以與network interface還有network interface所在的subnet或兩者關聯起來。為了簡化安全規則的管理，需要盡可能將NSG關聯到各個subnet，而不是subnet中的各個network interface。
• 如果subnet內的不同VM需要應用不同的安全規則，我們可以將 VM中的network interface關聯到一個或多個application security groups(ASG)。安全規則可以在其source、destination或兩者中指定ASG。然後，該規則僅適用於作為ASG成員的network interface。
• Azure 在每個NSG中建立多個預設安全規則。一個預設規則允許所有流量在Virtual Network中的所有資源之間流動。如果要改，請使用NSG、自定義路由將流量導到 NVA，或同時使用兩者。

Azure 為來自subnet的出站流量建立多個預設路由。 我們可以通過建立路由表並將其關聯到subnet來overwrite Azure 的預設路由。 overwrite Azure 的預設路由的常見原因是：

• 希望subnet之間的流量流經 NVA。
• 希望來自Internet的流量全部通過 NVA 或地端機房經 Azure VPN gateway。 強制Internet流量經過地端機房網路進行檢查和記錄通常稱為forced tunneling。

規劃IP網段的最佳實踐

在遷移過程中創建virtual networks時，規劃virtual networks IP 地址空間非常重要。

我們應該為每個vNet分配一個不大於 /16 的 CIDR 範圍的空間。vNet允許使用 65,536 個 IP 地址。 分配比 /16 更小的prefix，例如具有 131,072 個地址的 /15，將導致多餘的 IP 地址在其他地方無法使用。 重要的是不要浪費 IP 地址，即使它們在 RFC 1918 定義的私有範圍內。

其他規劃技巧是：

• vNet地址空間不應與地端網路範圍重疊。
• 地址重疊會導致網路無法連接，路由無法正常工作。
• 如果網路重疊，需要重新設計網路。
• 如果絕對無法重新設計網路，用NAT會有幫助，但應盡可能避免。

實作 一個hub and spoken 網路拓樸的最佳實踐

hub and spoken網路拓撲在共享identity 與security等服務的同時隔離工作負載。Hub是充當連接中心點的網路。spoken是使用peering連接到Hub 網路的virtual network。 Shared services部署在hub，而單個工作負載部署在spoken。

考量要點如下：

• 在 Azure 中實施hub and spoke topology可集中共享服務，例如與地端機房、防火牆的連接以及Virtual network之間的隔離。Hub網路提供了與地端機房的連接中心點，以及一個託管spoke網路中託管的工作負載所使用的服務位置。
• 大型企業通常使用hub and spoke topology。較小的網路可能會考慮採用更簡單的設計來節省成本和複雜性。
• 我們可以使用hub and spoke來隔離工作負載，每個spoke vNet與其他spoken vNet分開管理。每個工作負載可以包括多個tier，以及與 Azure load balancers連接的多個subnet。
• 可以在不同的resource group，甚至在不同的subscriptions中實現hub and spoke vNet。在不同subscriptions中peer vNet時，subscriptions可以關聯到相同或不同的 Azure AD tenants。這允許對每個工作負載進行分散管理，同時共享hub network中的shared services。

設計subnets的最佳實踐

為了在virtual network中提供隔離，我們將其劃分為一個或多個subnet，並將vNet的一部分地址空間分配給每個subnet。

• 可以在每個vNet中創建多個subnet。
• 預設情況下，Azure 在vNet中的所有subnet之間路由網路流量。
• Subnet決策基於我們的技術和公司要求。
• 可以使用 CIDR notation建立subnet。

在決定subnet的網路範圍時，請注意 Azure 會保留來自每個subnet的五個無法使用的 IP address。 例如，如果建立最小的可用subnet /29（具有八個 IP 地址），Azure 將保留五個地址。 在這種情況下，只有三個可用地址可以分配給subnet上的主機。 所以大多數情況下，我們使用 /28 作為最小的subnet。

範例：

下表顯示了一個virtual network範例，其地址空間為 10.245.16.0/20，被分段為subnet。

設計用於與 Azure vNet的地端機房網路連接

為了成功遷移到Azure，將地端網路連接到 Azure 至關重要。 這稱為為混合雲網路，其中服務從 Azure cloud提供給企業用戶。

這部分介紹提供 Azure resource之間的連接、從地端網路到 Azure resource的連接以及 Azure 中的branch to branch connectivity的服務 — vNet、ExpressRoute、VPN Gateway, Virtual WAN, Virtual network NAT Gateway, Azure DNS, Azure Peering service,與 Azure Bastion.。

讓我們比較將地端網路連接到 VNet 的選項。 對於每個選項，都提供了更詳細的參考架構。

VPN Connection

VPN gateway 是一種virtual network gateway，可在 Azure virtual network 和地端網路之間建立VPN tunnel。 流量會通過Internet。 VPN gateway連接有不同的配置，例如site-to-site, point-to-site, 或vNet-to-vNet。

此架構適用於地端網路設備和 Azure之間的流量沒哪麼大的應用程式，或者公司願意以稍微延長的network latency來換取雲端的靈活性和處理能力。

效益：

• 配置簡單。
• 可用頻寬更高； 高達 10 Gbps，具體取決於 VPN Gateway SKU。

挑戰:

• 需要地端網路設備。

參考架構Hybrid network with VPN gateway

Azure ExpressRoute connection

ExpressRoute connections 使用ISP的專用線路連接。 就是網路專線。 流量不會通過Internet。 專線將地端網路擴展到 Azure。

此架構適用於運行需要高度可擴展性的大規模關鍵任務工作負載的混合雲。

效益：

• 穩定且大頻寬； 高達 10 Gbps，具體取決於ISP。
• 支持頻寬的動態擴展，以幫助降低需求期間的成本。 但是，並非所有ISP都有此選項。

挑戰：

• 設置起來可能很複雜。 創建 ExpressRoute 連接需要與ISP合作。 提供者負責提供網路連接。
• 需要大台的地端網路設備。

參考架構Hybrid network with ExpressRoute

ExpressRoute with VPN failover

此選項結合了前兩個選項，在正常情況下使用 ExpressRoute，但如果 ExpressRoute 線路掛了，則故障轉移到 VPN connection。

這個架構適用於需要更高頻寬的 ExpressRoute 並且還需要高可用性網路連。

效益：

• ExpressRoute 線路出現故障時的高可用性，儘管VPN的網路效能不太好．但網路還是活著。

挑戰:

• 配置複雜。 需要設定 VPN 連接和 ExpressRoute 線路。
• 需要多餘的網路 設備和需要付費的 redundant Azure VPN Gateway connection。

參考架構Hybrid network with ExpressRoute and VPN failover

Hub-spoke network topology

hub-spoke network topology是一種在共享身份和安全等服務的同時隔離工作負載的方法。 Hub是 Azure 中的VNet，充當連接到地端網路的中心點。 spoken是與hub peer的 vNet。 共享服務部署在中心，而單個工作負載部署為spoken。

參考架構Hub-spoke topology

Azure Virtual WAN的 Hub-spoken network topology

可以通過兩種方式實現hub-spoke架構：我們自行管理的hub infrastructure或 Microsoft 管理的hub infrastructure。在任何一種情況下，spoken都使用vNet peer連接到hub。

Hub是 Azure 中的vNet，充當連接到地端機房的中心點。spoken是與hub peer的vNet，可用於隔離工作負載。流量通過 ExpressRoute 或 VPN gateway connection在地端機房和中心點之間流動。這種方法的主要區別在於使用 Azure Virtual WAN(VWAN) 將Hub替換為託管服務。

Azure Virtual WAN是一種網路服務，是優化公司總部與分公司的網路連接。 Azure region用作我們可以選擇將分公司連接到的Hub。我們還可以利用 Azure backbone連接分公司 並用branch-to-VNet connectivity。 Azure Virtual WAN 將許多 Azure cloud connectivity services（例如site-to-site VPN, ExpressRoute, point-to-site user VPN）整合到一個操作界面中。與 VNet 的連接是使用vNet connectivity建立的。

此架構包括標準hub-spoke network topology的優勢並有新的效益：

• 通過用全託管的 VWAN 服務替換現有Hub來減少operational overhead。
• 通過使用託管服務和去除NAV的必要性達到節省成本。
• 導入具有 Azure Firewall和 VWAN 的集中管理的secured Hubs來提高安全性，以最大限度地減少與錯誤配置相關的安全風險。
• 分離中央集權式的 IT（SecOps、InfraOps）和工作負載（DevOps）之間的扯不清的權責問題。

此架構的典型用途包括以下情況：

• 工作負載之間的連接需要集中控管和存取共享服務。
• 企業需要對資安方面（例如防火牆）進行集中控管，並且需要對每個spoken中的工作負載進行隔離管理。

上圖說明了此架構可以提供的一些優勢：

• A full meshed hubs among Azure Virtual Networks
• Branch to Azure connectivity
• Branch to Branch connectivity
• Mixed use of VPN and Express Route
• Mixed use of user VPN to the site
• VNET to VNET connectivity

設計Azure 網路連接服務

VNet

VNet 是 Azure 中專用網路的基本單位。我們可以使用 VNet 來：

• Azure resources之間的通訊：可以將 VM 和其他幾種類型的 Azure 資源部署到VNet，例如 Azure App Service Environments, AKS, 與Azure Virtual Machine Scale Sets。
• Communicate between each other：我們可以將VNet相互連接，使任一VNet中的資源能夠使用vNet peering相互通訊。我們連接的VNet可以位於相同或不同的 Azure Region。
• Communicate to the internet：預設情況下，vNet 中的所有資源都可以連到Internet。我們可以通過分配public IP 或public Load Balancer來與資源進行與Internet的通訊。我們還可以使用public IP 或public Load Balancer來管理我們的outbound connections。
• Communicate with on-premises networks：我們可以使用 VPN Gateway或 ExpressRoute 將地端網路連接到VNet。

當我們自下而上設計網路時，我們會收集到一些基本資訊。這些資料可以是主機數量、網路設備、subnet數量、subnet之間的路由、VLAN。這些資訊有助於確定網路和資安設備的大小，以及建立支援應用程式和服務的架構。

當我們計劃在 Azure 中部署應用程式和服務時，我們將首先在 Azure 中建立一個稱為vNet的邏輯邊界。這個vNet類似於物理網路邊界(我們可以把它當成一個虛擬機房)。由於它是一個虛擬網路，因此我們不需要實體設備，但仍需要 IP address、IP subnets、路由和政策等邏輯進行規劃。

在 Azure 中建立vNet時，它會預先配置一個 IP 範圍 (10.0.0.0/16)。我們可以定義自己的 IP 範圍。可以定義 IPv4 和 IPv6 範圍。我們可以從我們的 IP 範圍創建多個subnets。這些subnets將用於將 IP address分配給virtual network interfaces (vNIC)。每個subnet的前四個 IP address被保留，不能用於 IP 分配。公有雲中沒有 VLAN 的概念。但是，我們可以根據定義的subnet在虛擬網路中建立邏輯上的隔離。

我們可以建立一個包含所有vNet地址空間的大型subnet，也可以選擇建立多個subnet。但是，如果我們使用的是virtual network gateway，Azure 會要求我們建立一個名為“gateway subnet”的subnet。 Azure 將使用這個subnets將 IP address分配給virtual network gateway。

vNet是 Azure Public network的虛擬隔離部分。每個vNet都在我們的subscription之下。在決定是在sunscription中建立一個vNet還是多個vNet時要考慮的事項：

• 是否存在將流量隔離到單獨的VNet的公司資安要求？我們可以選擇是否連接VNet。如果連接VNet，則可以實施NVA（例如防火牆）來控制VNet之間的流量。
• 將VNet隔離到單獨的subscription或region是否存在公司的要求？
• network interface使 VM 能夠與其他資源進行通訊。每個network interface都分配有一個或多個 private IP 。在VNet中需要多少個network interface和Private IP ？您可以在VNet中擁有的network interface和Private IP 的數量存在限制。

這篇文件是設計 Azure Virtual Network時要考慮的更多問題

設計 Network Segmentation

Segmentation是一種模型，我們可以在其中使用Azure 提供的工具使用網路空間並建立software defined perimeters。然後，我們可以設置規則來管理進出這些perimeters的流量，以便我們可以為網路的各個部分設置不同的security postures。當我們將不同的應用程式放入這些perimeters時，我們可以管理這些segmented entities之間的通訊。如果我們的application stack的一部分受資安威脅，我們將能夠更好地控制這種安全漏洞的影響，並防止它橫向傳播到我們網路的其餘部分。這種能力是與 Microsoft 發布的 Zero Trust model相關的關鍵原則，更多的Zero Trust 資訊可參考本部落格的零信任的IT環境架構。

在 Azure 上進行操作時，我們可以使用一組廣泛而多樣的segmentation options來保護我們Azure上的安全。

1. Subscription:：Subscriptions是一種high-level construct，它提供了entities之間的platform powered separation。主要在劃分公司內大型部門之間的界限(例如各分公司需要不同的subscriptions)。需要明確提供不同Subscriptions中資源之間的通訊。
2. vNet：這是是在private address space的subscriptions中建立的。網路提供network-level containment的資源，預設情況下不允許任何兩個VNet之間的流量流通。與Subscriptions一樣，vNet之間的任何通訊都需要人為主動設定。
3. Network Security Groups (NSG)：NSG 是一種access control機制，用於控制vNet內資源之間的流量。 NSG 還控制與外部網路的流量，例如Internet、其他VNet等。 NSG 可以為subnets、VM groups甚至單一VM建立perimeters，細緻化我們的的segmentation strategy。
4. Application Security Groups (ASGs)：ASG 允許我們將 VM group 分配到一個application tag下。建立 ASG 並為其分配 VM 後，ASG 可用作 NSG 中的source 或destination來簡化管理。
5. Azure Firewall：Azure 防火牆是一種雲原生 stateful Firewall as a service。此防火牆可以部署在我們的VNet或 Azure Vritual WAN Hub 中，用在過濾在雲端資源、Internet 和地端之間網路的流量。我們可以使用L3 -L7控制allow/deny網路流量（使用 Azure Firewall 或Azure Firewall Manager）。我們還可以使用 Azure Firewall和第三方的產品過濾進入 Internet 的流量。

在從網路角度建立Azure 中的工作負載時，以下三種模式很常見。這些模式中的每一個都提供了不同類型的網路隔離和連接。我們應該對公司的需求決定哪一種比較適合我們。對於這些模型中的每一個，我們都描述了如何使用上述 Azure 網路服務進行segmentation。

模式一: 單一Virtual Network

在此模式中，我們的工作負載的所有組件，或者在某些情況下，我們的整個 IT 運作都放在一個VNet中。 如果我們僅在單一Region中操作，則此模式是可能的，因為vNet不能跨多個Region(這個問題在GCP不會出現，而AWS也是一樣)。

我們最有可能用於在此VNet中建立segments的entities是 NSG，可能會使用 ASG 來簡化管理。 下圖是這樣一個segmented vNet的架構範例。

在此設置中，我們有放置DB工作負載的 Subnet1 和放置 Web 工作負載的 Subnet2。 我們可以設定 NSG，指定 Subnet1 只能與 Subnet2 通訊，而 Subnet2 可以與 Internet 通信。 在存在許多工作負載的情況下，我們還可以進一步採用此概念。 例如，劃分不允許一個工作負載與另一個工作負載的backend 通訊的子網段。

雖然我們使用 NSG 來說明如何管理子網段流量，但我們也可以使用 Azure Marketplace or Azure Firewall中的Network Virtualized Appliance來執行這個segmentation。

模式二: 多個vNet，它們之間互相Peering

此模式是上個模式的擴展，在這個模式中，我們有多個需要Peering的VNet。 我們可以選擇這種模式來將應用程式分組到單獨的VNet中，或者我們可能需要在部署我們的服務/平台在多個 Azure Region。 我們可以通過VNet獲得內建的segmentation，因為我們手動執行vNet之間的peering，以便它們進行通訊。 （virtual network peering不是transitive。）要以類似於模式 1 的方式在VNet中進一步segment，請在vNet中使用 NSG。

所謂不能transitive。以下圖為例，我們無法透過vNet 3讓VNet 1與VNet 2之間互連。也就是Azure不會讓你把它的網路當成是一座橋來路過。

模式三: 多個VNet之間使用hub and spoke模式

這種模式是一種advanced virtual network架構，我們可以在其中選擇特定Region中的VNet作為該region中所有其他VNet的中心。 Hub vNet與其spoke vNet之間的連接是通過使用 Azure virtual network peering實現的。 所有流量都通過Hub VNet，它可以充當不同region其他hub的gateway。 我們可以在Hub 上設置security posture，以便它們以可擴展的方式對VNet之間的流量進行segment和管理。 這種模式的一個好處是。 隨著網路拓撲的成長，security posture overhead不會增加（除非我們擴展到new regions）。

Azure推薦的cloud native segmentation是 Azure Firewall控制的。 Azure Firewall 可以跨vNet和subscription作業，以使用L3 — L7來管理流量。 我們可以定義我們的communication rules（例如，vNext A不能與VNet B通訊，但可以與vNet C通訊，vNet A除了access *.github.com 不能去其他Internet網站，等等 ) 。 借助 Azure Firewall Manager，我們可以跨多個 Azure Firewall集中控管，並使 DevOps 團隊能夠進一步自定義local policies。

Virtual network NAT gateway

Virtual Network NAT簡化了vNet只需要 Internet outbound的流量 。 在設定subnet時，所有outbound traffic都使用我們指定的static public IP。 無需LB或直接附加到VM的static public IP。 NAT 是全託管的並且具有很高的彈性。

以下狀況是我們需要用Virtual Network NAT gateway的狀況:

• 我們需要on-demand outbound to internet connectivity而無需預先配置
• 我們需要一個或多個static public IP以進行擴展
• 我們需要configurable idle timeout
• 我們需要為無法識別的TCP connection

路由(Routing)

建立virtual network時，Azure 會為我們的網路建立一個路由表。此路由表包含以下類型的路由。

• System routes
• Subnet default routes
• Routes from other virtual networks
• BGP routes
• Service endpoint routes
• User Defined Routes (UDR)

首次建立vNet而不定義任何子網段時，Azure 會在路由表中建立routing entries。這些路由稱為system routes。 system routes不能修改。但是，我們可以通過配置 UDR 來overwrite system routes。

在vNet中建立一個或多個子網段時，Azure 會在路由表中建立default entries(也就是Subnet default routes)，以啟用VNet中這些子網段之間的通訊。我們也可以使用UDR來overwrite。

在兩個vNet之間建立 peering時，將建立peering的每個vNet的address space內的每個address range添加一筆路由。

如果地端的network gateway與 Azure virtual network gatewayg使用BGP，則會為從地端的network gateway的每個路由添加一個routes entries。這些路由在路由表中顯示為 BGP routes。

當我們為服務啟用service endpoint時，Azure 會將某些服務的public IP 添加到路由表中。為vNet中的各個subnet啟用service endpoint。當啟用service endpoint時，路由只會添加到屬於這個服務的subnet路由表中。當地址更改時，Azure 會自動管理路由表中的地址。

User-defined routes也稱為Custom routes。在 Azure 中建立 UDR 以overwrite Azure 的default system routes，或將其他路由添加到子網段的路由表。

當路由表中有competing entries時，Azure 會根據與傳統路由器類似的longest prefix match來選擇next hop。但是，如果有多個具有相同address prefix的next hop entries，則 Azure 會按以下順序選擇路由。

1. User-defined routes (UDR)
2. BGP routes
3. System routes

Overwrite Azure 的default routing的常見原因是：

• 希望子網段之間的流量流經 NVA。了解有關如何配置路由表以強制流量通過 NVA 的更多資訊，請參閱此文件。
• 希望通過 NVA 或地端網路檢查所有 Internet 流量。強制地端網路(Internet)流量進行檢查和記錄通常稱為forced tunneling。

System routes

• 需要在同一virtual network 或peered virtual networks中的VM之間路由流量時
• 需要使用 vNet to vNet VPN 在 VM 之間進行通訊
• 需要通過 ExpressRoute 或 VPN gateway進行site-to-site communication

User defined routes (UDRs)

• 希望通過 Azure Firewall 或 forced tunneling啟用對 Internet 流量的filtering。
• 希望子網段之間的流量流經 NVA。
• 需要建立路由以指定應如何在VNet中路由網路封包。
• 需要建建可控制的網路流量路由並指定流量中的 next hop。

設計 Application delivery services

本部分介紹 Azure 中有助於交付應用程式的網路服務 — Content Delivery Network, Azure Front Door Service, Traffic Manager, Load Balancer, and Application Gateway.

Content Delivery Network (CDN)

這是一種將資料暫存在Azure全球網路節點上的快取技術，目的是加速客戶端取得資料。

Azure Front Door Service

Azure Front Door Service通過優化最佳效能和即時global failover以實現高可用性，它使我們能夠定義、管理和監控 Web 流量的global routing。

以下狀況適合使用 front door:

• 需要確保將request發送到lowest latency backends（low latency）
• 有主要和次要backend（priority）
• 想使用weight coefficients (weighted)分配流量
• 希望確保來自同一個end user的request被發送到同一個backend（affinity）
• 流量是基於 HTTP(s) 的，需要 WAF 和/或 CDN 整合

Traffic Manager

Azure Traffic Manager是一個DNS-based traffic load balancer，它使我們能夠以最佳方式將流量分配給全球 Azure region的服務，同時提供高可用性和回應能力。 Traffic Manager提供了一系列流量路由方法來分配流量，例如priority/weighted/ performance/geographic/multi-value 或subnet。

下圖顯示了使用Traffic Manager的endpoint priority-based routing：

以下狀況適合使用Traffic Manager:

• 需要提高應用程式的HA
• 需要提高應用程式的效能
• 需要結合混合多個應用程式
• 需要為複雜的部署分配流量

Load balancer

Azure Load Balancer為所有 UDP 和 TCP protocol提供高效能、低延遲的 Layer 4 LB。 它管理inbound and outbound connections。 我們可以配置public and internal LB endpoints。 我們可以定義規則以使用 TCP 和 HTTP 健health-probing將inbound connections map 到back-end pool destinations，以管理服務可用性。

下圖顯示了一個 Internet 的multi-tier application，它同時利用了external and internal LB：

當我們要使用LB時，以下流程圖可以協助我們選擇不同LB的組合。

Application Gateway

Azure Application Gateway是一個 Web traffic LB，可讓我們管理 Web application的流量。 它是一種Application Delivery Controller (ADC) as a service，可為我們的應用提供各種L7 的LB。

路由流量有兩種主要方法，path-based routing 與 multiple site routing。

Path-based routing

使用 path-based routing 將具有不同 URL path的request發送到不同的backend pool的server.

Multiple site routing

使用 multiple-site routing將具有不同 Domian 的request發送到不同的backend pool的server.

Load balancer方案的選擇

Azure 提供各種load-balancing services，我們可以使用這些服務在運算資源 —Azure Front Door/Traffic Manager/ Load Balancer/Application Gateway 。

這裡將介紹如何確定適合我們業務需求的load-balancing solution。

Azure load-balancing services可以按照兩個維度進行分類：global VS. regional，以及 HTTP(S) 與非 HTTP(S)。

選擇load-balancing選項時，在 Azure load-balancing中選擇“Help me choose” tab時會考慮以下因素：

Traffic type。它是 Web (HTTP/HTTPS) applications嗎？它是面向一般大眾的application還是公司內用的？

Global VS. regional。是否需要在vNet中對VM或容器進行load balance，或者across regions對 scale unit/deployments進行load balance，還是兩個都要？

Availability。Service SLA是甚麼？

Cost。請參閱 Azure pricing。除了服務本身的成本之外，還要考慮管理基於該服務構建的解決方案的營運成本。

Features and limits。每項服務的整體限制是什麼？請參閱服務限制。

以下流程圖將協助我們的Application選擇load-balancing solution。該流程圖將引導我們通過一系列關鍵決策標準來的到建議。

將此流程圖視為起點。每個Application都有獨特的要求，因此請使用建議作為起點。然後進行更詳細的評估。

如果我們的Application包含多個工作負載，請分別評估每個工作負載。一個完整的解決方案可能包含兩個或多個load-balancing solutions。

設計 application protection services

這部分介紹 Azure 中有助於保護我們的網路資源的服務 — 在 Azure 中使用這些服務中的任何一個或組合來保護我們的Application — DDoS protection/Private Link, Firewall/Web Application Firewall(WAF)/Network Security Groups(NSG)/Virtual Network Service Endpoints。

Azure DDoS Protection

Azure DDoS Protection 提供了針對最複雜的 DDoS 威脅的對策。 該服務為部署在VNet中的application和資源提供enhanced DDoS mitigation capabilities。 此外，使用 Azure DDoS protection的客戶可以有DDoS Rapid Response support，以便在攻擊期間尋求 Azure DDoS 專家的協助(不過這也是很貴的服務，三大雲都在這一塊收取很高的服務費)。

當有以下需求時可以使用DDoS protection Standard：

• Always-on traffic monitoring
• Adaptive tuning
• Multi-layered protection
• Mitigation scale
• Attack analytics and metrics
• Attack alerting
• DDoS rapid response team

Azure Private Link

Azure Private Link 使我們能夠通過VNet中的private endpoint access Azure PaaS 服務。 我們的VNet和服務之間的流量通過 Microsoft backbone network傳輸。 不再需要將我們的服務暴露在Internet上。 您可以在VNet中建立自己的 private link service並將其交付給我們的客戶。 private link 用於access PaaS 服務，例如Azure Storage , SQL Database、應用服務等，如下圖所示。

在以下情況下建議使用private link 或 private endpoints：

• 需要與 Azure 上的服務建立private connectivity
• 需要與地端和peered networks整合
• 需要流量保持在 Microsoft 網路上，不需要 Internet access

Azure Firewall

Azure Firewall是一種託管的、cloud-based network security service，可保護我們的 Azure Virtual Network resources。 它是一種fully statefull firewall as a service，具內建的高可用性和不受限制的cloud scalability。 使用 Azure Firewall，我們可以跨subscriptions與virtual networks集中建立、實施和記錄application和network connectivity policies。 Azure Firewall為我們的VNet資源使用static public ip，允許外部防火牆識別源自我們的VNet的流量。 Azure Firewall是非 HTTP/S protocol（例如，RDP、SSH、FTP）提供inbound protection，為所有ports和protocol提供outbound network-level protection，為outbound HTTP/S 提供application-level protection。

Web Application Firewall(WAF)

Azure Web Application Firewall (WAF) 為我們的 Web application提供保護，例如 SQL injection 與 cross site scripting。 Azure WAF 通過託管規則提供針對 OWASP Top 10 個漏洞的out of box protection。此外，我們還可以配置自定義規則，這些規則是我們資安管理的規則，可根據source IP range和request attributes（例如header、cookie、form data fields 或query string parameters）提供額外的保護。在Application code中補上這一個資安漏洞可能是一個麻煩或是緩不濟急。它可能需要在application topology的多個layer進行嚴格的維護、修補和監控。集中式 Web application firewall有助於簡化安全管理。 WAF 還為Application管理員提供了更好的保護，以抵禦威脅和入侵。

WAF 解決方案可以通過集中修補已知漏洞來更快地對安全威脅做出反應，而不是保護每個單獨的 Web application。

WAF 可以與 Microsoft 的 Azure Application Gateway, Azure Front Door, and Azure Content Delivery Network (CDN) service一起部署。 Azure CDN 上的 WAF 目前處於public preview階段。 WAF 具有針對每個特定服務定制的功能。

Network security groups(NSG)

可以在具有NSG的 Azure VNet中篩選進出 Azure resource的網路流量。我們還可以使用NVA，例如 Azure Firewall或其他第三方的防火牆。我們可以控制 Azure 如何路由來自子網段的流量。我們還可以限制公司中的哪些人可以使用virtual network中的資源。

NSG包含Access Control List(ACL) 規則列表，這些規則允許或拒絕到子網斷、NIC 或兩者的網路流量。 NSG 可以與子網段或連接到子網段的單個 NIC 相關聯。當 NSG 與子網段關聯起來時，ACL 規則將應用於該子網段中的所有 VM。此外，可以通過將 NSG 直接關聯到 NIC 來限製到單個 NIC 的流量。

NSG 包含兩組規則：inbound 與 outbound。規則的優先級在每個set中必須是唯一的。每個規則都要有protocol/source/destination port ranges/address prefixes/ direction of traffic /priority /access type.。所有 NSG 都包含一組預設規則。預設規則無法刪除，但由於它們被分配了最低priority，它們可以被我們建立的規則overwrite。

Service endpoints

VNet service endpoints通過直接連接將virtual network private和 VNet identity到 Azure 服務。 Endpoints允許我們將重要的 Azure service resource只有保護到我們的VNet。 從 VNet 到 Azure service的流量始終保留在 Microsoft Azure backbone network上。

主要效益在於：

• 提高 Azure service resource的安全性
• 來自VNet的 Azure 服務流量的最佳路由
• 設置簡單，較少的management overhead

Azure Bastion(堡壘機/跳板機)

Azure Bastion 服務是 PaaS 服務，我們可以在VNet中預先配置。 它通過 TLS 直接在 Azure portal中提供與VM的安全的 RDP/SSH 連接。 通過 Azure Bastion 連接時，我們的VM不需要public ip。

以下時機可以使用 Azure Bastion：

• 從 Azure portal到 Azure VM 的Secure remote connections
• 消除內部VM的暴露 RDP /SSH port或public IP

主要的安全功能：

• 從 Azure Bastion 發起到目標VM的流量保留在VNet內或對peered virtual networks之間。
• 無需將 NSG 套用到 Azure Bastion 子網段，因為它在內部進行了強化。 為了提高安全性，可以將 NSG 配置為只允許從 Azure Bastion 主機遠端連接到目標VM。
• Azure Bastion 有助於防止port scanning。 RDP port、SSH port和public IP不會讓我們的 VM 公開在Internet上。
• Azure Bastion 有助於防止zero-day exploits。 它位於VNet的外圍。 因此，無需擔心強化VNet中的每個VM。 Azure 平台使 Azure Bastion 保持最新的update。
• 該服務與 Azure VNet的native security appliances整合，例如 Azure Firewall。
• 可以使用該服務來監控和管理遠端連線。

Just in time (JIT) network access

借助 JIT，我們可以鎖住 VM 的inbound traffic，從而減少遭受攻擊的風險，同時在需要時提供VM的連接。

當我們啟用JIT Vm access時，我們可以選擇這個VM的哪個port的inbound traffic要被關起來。這可確保NSG和 Azure Firewall規則中的選到的這個port存在“deny all inbound traffic”規則。這些規則限制對 Azure VM 的management ports的access並保護它們免受攻擊。

如果所選到的port已經存在其他規則，則這些現有規則優先於新的“deny all inbound traffic”規則。如果所選選到的port沒有現有規則，則新規則在 NSG 和 Azure 防火牆中具有最高的priority。

當user requests access VM 時， Security Center會檢查User是否擁有該 VM 的 Azure role-based access control (Azure RBAC) permissions。如果requests獲得批准，NSG 和 Azure Firewall允許在指定的時間內從相關 IP 地址（或範圍）這個被選到的port 的inbound traffic。時間到後，NSG 將返回到它們之前的狀態。但已經建立的connection不會中斷。