本文說明在 Azure 中部署一組網路虛擬裝置 （NVA） 以取得高可用性的最常見選項。 NVA 通常用來控制以不同安全性層級分類的網路區段之間的流量，例如，在 De-Militarized 區域 （DMZ） 虛擬網路與公用因特網之間，或將外部位置連線到 Azure，例如 VPN 或 SDWAN（Software-Defined WAN） 設備。
有許多設計模式會使用 NVA 來檢查不同安全性區域之間的流量，例如：
- 檢查虛擬機到因特網的輸出流量，並防止數據外流。
- 檢查從因特網到虛擬機的輸入流量，並防止攻擊。
- 若要篩選 Azure 中虛擬機之間的流量，以避免橫向移動遭入侵的系統。
- 若要篩選內部部署系統與 Azure 虛擬機之間的流量，如果它們被視為屬於不同的安全性層級。 （例如，如果 Azure 裝載 DMZ，以及內部部署應用程式。）
- 若要從外部位置終止 VPN 或 SDWAN 通道，例如內部部署網路或其他公用雲端。
NVA 有許多範例，包括下列專案：
- 網路防火牆
- 第 4 層反向 Proxy
- IPsec VPN 端點
- SDWAN 設備
- 具有 Web 應用程式防火牆功能的 Web 型反向 Proxy
- 因特網 Proxy 限制可從 Azure 存取哪些因特網頁面
- 第 7 層負載平衡器
所有這些 NVA 都可以在 Azure 設計中插入本文所述的模式。 即使是 Azure 第一方網路虛擬設備，例如 Azure 防火牆 和 Azure 應用程式閘道， 使用本文稍後說明的設計。 從設計觀點和針對網路問題進行疑難解答時，了解這些選項非常重要。
要回答的第一個問題是為什麼需要網路虛擬設備高可用性。 原因是這些裝置控制網路區段之間的通訊。 如果無法使用，網路流量就無法流動，而且應用程式會停止運作。 排程和未排程的中斷偶爾會關閉 NVA 實例（如同 Azure 或任何其他雲端的任何其他虛擬機）。 即使這些 NVA 已設定為進階受控磁碟，以在 Azure 中提供單一實例 SLA，也會關閉這些實例。 因此，高可用性應用程式至少需要第二個 NVA，以確保連線能力。
必要條件：本文假設對 Azure 網路、Azure Load Balancers，以及 虛擬網路流量路由 （UDR） 有基本瞭解。
選擇將網路虛擬設備部署到 Azure VNet 的最佳選項時，最重要的層面是 NVA 廠商是否已審查並驗證該特定設計。 廠商也必須提供在 Azure 中整合 NVA 所需的必要 NVA 組態。 如果 NVA 廠商提供不同的替代方案作為 NVA 支援的設計選項，這些因素可能會影響決策：
- 聚合時間：每個設計需要多久的時間才能將流量從失敗的 NVA 實例移開？
- 拓撲支援：每個設計選項都支援哪些 NVA 設定？ 主動/主動、主動/待命、具有 n+1 備援的向外延展 NVA 叢集？
- 流量對稱：特定設計是否強制 NVA 在封包上執行來源網路位址轉換 （SNAT），以避免非對稱路由？ 還是以其他方式強制執行流量對稱？
檔中的下列各節說明將 NVA 整合到中樞和輪輻網路的最常見架構。
備註
本文著重於 Hub & 輪輻設計。 虛擬 WAN 並未涵蓋，因為虛擬 WAN 對於 NVA 的部署方式更為規範，視虛擬 WAN 中樞是否支援特定的 NVA 而定。 如需詳細資訊，請參閱虛擬 WAN 中樞 網路虛擬設備。
HA 架構概觀
下列架構描述高可用性 NVA 所需的資源和設定：
| 解決方法 | 優點 | 考慮事項 |
|---|---|---|
| Azure Load Balancer | 支持主動/主動、主動/待命，以及具有良好聚合時間的向外延展 NVA | NVA 必須提供健康情況探查的埠，特別是作用中/待命部署。 針對需要流量對稱的防火牆等具狀態設備，流量流向因特網需要 SNAT |
| Azure 路由伺服器 | NVA 需要支援 BGP。 支持主動/主動、主動/待命，以及向外延展 NVA。 | 流量對稱也需要 SNAT |
| 閘道負載平衡器 | 保證沒有 SNAT 的流量對稱性。 NVA 可以跨租用戶共用。 良好的聚合時間。 支持主動/主動、主動/待命，以及向外延展 NVA。 | 支援來自因特網的流程，不 East-West 流程 |
| 變更 PIP/UDR | NVA 不需要特殊功能。 保證對稱流量 | 僅適用於主動/被動設計。 1-2 分鐘的高聚合時間 |
Load Balancer 設計
此設計會使用兩個 Azure Load Balancer 將 NVA 叢集公開至網路的其餘部分。 此方法經常用於具狀態和無狀態 NVA：
- 內部 Load Balancer 可用來將內部流量從 Azure 和內部部署重新導向至 NVA。 此內部負載平衡器會設定 HA 連接埠規則，讓每個 TCP/UDP 埠都重新導向至 NVA 實例。
- 公用 Load Balancer 會將 NVA 公開至因特網。 由於 HA 埠 適用於輸入流量，因此必須在專用負載平衡規則中開啟每個個別的 TCP/UDP 埠。
下圖描述從因特網到輪輻 VNet 中應用程式伺服器封包的躍點順序，會遵循周遊防火牆 NVA 來控制公用因特網的流量（也稱為南北流量）：
使用 Azure Load Balancer 整合 
下載此架構的 Visio 檔案。
透過 NVA 將輪輻的流量傳送至公用因特網的機制，是 User-Defined Route for 0.0.0.0/0，其下一個躍點是內部 Load Balancer IP 位址的下一個躍點。
針對 Azure 與公用因特網之間的流量，流量的每個方向都會跨越不同的 Azure Load Balancer。 即使防火牆 NVA 同時有公用和內部網路的單一 NIC，也會發生這種情況，因為輸入封包會通過公用 ALB，而輸出封包會通過內部 ALB。 由於流經不同負載平衡器的兩個方向，因此如果需要流量對稱，如同在大部分防火牆中的情況一樣，NVA 實例必須執行來源網路位址轉譯（SNAT），以吸引傳回流量並避免流量不對稱。
與負載平衡器相同的設計也可以用來檢查 Azure 與內部部署網路 （East/West） 之間的流量，其中只涉及內部負載平衡器：
使用 Azure Load Balancer 整合ALB Onpremises內部部署流量
透過 NVA 在輪輻之間傳送流量的機制完全相同，因此不會提供其他圖表。 在上述範例圖表中，由於 spoke1 不知道 spoke2 的範圍，0.0.0.0/0 UDR 會將尋址至輪輻2 的流量傳送至 NVA 的內部 Azure Load Balancer。
針對內部部署網路與 Azure 之間或 Azure 虛擬機之間的流量，內部 Azure Load Balancer 會保證單一 NIC NVA 中的流量對稱：當流量流程的兩個方向周遊相同的 Azure Load Balancer 時，負載平衡器會選擇相同的 NVA 實例。 在具有內部負載平衡器的雙 NIC NVA 中，每個通訊感知都有內部負載平衡器的情況量對稱必須透過 SNAT 提供，如上述北/南範例所示。
在此設計中，雙 NIC NVA 面臨的另一個挑戰是將回復傳回給負載平衡器健康情況檢查的位置。 Azure Load Balancer 一律使用與健康情況檢查來源相同的 IP 位址（168.63.129.16）。 NVA 必須能夠在收到的相同介面上，將回應傳送至健康情況檢查的來源此 IP 位址。 這通常需要作系統中的多個路由表，因為目的地型路由會一律透過相同的 NIC 將回復傳送至健康情況檢查。
Azure Load Balancer 在個別 NVA 中斷中具有良好的聚合時間。 由於 健康情況探查 可以每隔 5 秒傳送一次，而且需要 3 個失敗的探查才能將後端實例宣告出服務，因此 Azure Load Balancer 通常需要 10-15 秒的時間，才能將流量聚合至不同的 NVA 實例。
此設定同時支持主動/主動和主動/待命組態。 針對作用中/待命組態，NVA 實例必須提供 TCP/UDP 埠或 HTTP 端點，而該端點只會回應作用中角色中實例的 Load Balancer 健康情況探查。
使用 L7 負載平衡器
針對安全性應用裝置，此設計的特定案例是將 Azure 公用 Load Balancer 取代為第 7 層負載平衡器，例如 Azure 應用程式閘道（這可視為自己的 NVA）。 在此情況下，NVA 只需要內部 Load Balancer 才能從工作負載系統傳來的流量。 雙 NIC 裝置有時會使用此機制，以避免上一節所述的 Azure Load Balancer 健康情況檢查路由問題。 此設計的限制之一是它只支援第 7 層負載平衡器支援的 Layer-7 通訊協定，通常是 HTTP（S）。
NVA 應該針對第 7 層負載平衡器不支援的通訊協議採用輸入流量，以及可能所有的輸出流量。 如需使用 Azure 防火牆作為 NVA 和 Azure 應用程式閘道作為第 7 層 Web 反向 Proxy 時，此組態的進一步詳細數據，請參閱 虛擬網路的防火牆和應用程式閘道。
Azure 路由伺服器
Azure 路由伺服器 是一項服務，可讓 NVA 透過邊界閘道通訊協定 （BGP） 與 Azure SDN 互動。 NVA 不僅瞭解 Azure VNet 中存在哪些 IP 前置綴，而且能夠在 Azure 中虛擬機器的有效路由表中插入路由。
使用 Azure 路由伺服器整合ARS 因特網因特網流量
在上圖中，每個 NVA 實例都會透過 BGP 與 Azure 路由伺服器對等互連。 輪輻子網中不需要路由表，因為 Azure 路由伺服器會程式化 NVA 所公告的路由。 如果 Azure 虛擬機器中有兩個或多個路由進行程式設計，則會使用等價多重路徑 （ECMP） 為每個流量選擇其中一個 NVA 實例。 因此，如果流量對稱是需求，SNAT 就是此設計中必須的 。
此插入方法同時支援主動/主動（所有 NVA 都會向 Azure 路由伺服器公告相同的路由），以及作用中/待命（一個 NVA 會公告具有比另一個路徑較短的 AS 路徑的路由）。 Azure 路由伺服器最多支援 8 個 BGP 相鄰。 因此，如果使用主動 NVA 的向外延展叢集，此設計最多支援 8 個 NVA 實例。
此設定中的聚合時間很快，而且會受到 BGP 相鄰的 keepalive 和 holdtime 定時器影響。 雖然 Azure 路由伺服器具有預設 keepalive 和 holdtime 定時器（分別 60 秒和 180 秒），但 NVA 可以在 BGP 相鄰建立期間交涉較低的定時器。 設定這些定時器太低可能會導致 BGP 不穩定。
此設計是需要與 Azure 路由互動的 NVA 最常見的選項，例如 SDWAN 或 IPsec NVA，這些 NVA 通常具有良好的 BGP 支援，且需要瞭解在 Azure VNet 中設定的前置詞，或透過 ExpressRoute 私人對等互連公告特定路由。 這種類型的設備通常是無狀態的，因此流量對稱不是問題，因此不需要 SNAT。
閘道負載平衡器
Azure 閘道負載平衡器 是將數據路徑中插入 NVA 的新方式，而不需要引導具有 User-Defined 路由的流量。 對於透過 Azure Load Balancer 或公用 IP 位址公開其工作負載的虛擬機，輸入和輸出流量可以透明地重新導向至位於不同 VNet 中的 NVA 叢集。 下圖說明當工作負載透過 Azure Load Balancer 公開應用程式時，封包針對來自公用因特網的輸入流量所遵循的路徑：
使用閘道負載平衡器整合 
此 NVA 插入方法的主要優點之一是來源網路位址轉換 （SNAT） 不需要保證流量對稱性。 此設計選項的另一個優點是，相同的 NVA 可用來檢查不同 VNet 的流量，從而從 NVA 的觀點達成多租使用者。 NVA VNet 與工作負載 VNet 之間不需要 VNet 對等互連，而且工作負載 VNet 中不需要 User-Defined 路由，這可大幅簡化設定。
網關 Load Balancer 的服務插入可用於達到 Azure 公用 Load Balancer 的輸入流量（及其傳回流量），以及源自 Azure 的輸出流程。 East-West Azure 虛擬機之間的流量無法利用閘道負載平衡器進行 NVA 插入。
在 NVA 叢集中，Azure Load Balancer 健康情況檢查探查可用來偵測個別 NVA 實例失敗，達到快速聚合時間（10-15 秒）。
變更 PIP-UDR
此設計背後的概念是具有不需要 NVA 備援的設定，並在 NVA 發生停機時加以修改。 下圖顯示 Azure 公用 IP 位址如何與作用中的 NVA （NVA1） 相關聯，而輪輻中的 User-Defined 路由會將作用中的 NVA IP 位址作為下一個躍點（10.0.0.37）。
使用行動 PIP/UDRPIP/UDR 因特網因特網流量
如果作用中的 NVA 變得無法使用，待命 NVA 會呼叫 Azure API 來重新對應公用 IP 位址，而輪輻 User-Defined 路由本身（或移動私人 IP 位址也）。 這些 API 呼叫可能需要幾分鐘的時間才能生效，這就是為什麼此設計提供本檔中所有選項最差的聚合時間。
此設計的另一個限制是只支援作用中/待命組態，這可能會導致延展性問題：如果您需要增加 NVA 支援的頻寬，此設計的唯一選項就是相應增加這兩個實例。
此設計的優點之一是不需要來源網路位址轉譯 （SNAT） 保證流量對稱性，因為在任何指定的時間點只有一個 NVA 作用中。
貢獻者們
本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。
主要作者：
- Keith Mayer |主要雲端解決方案架構師
- Telmo Sampaio |Principal Service Engineering Manager
- 何塞·莫雷諾 |首席工程師
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。
後續步驟
- 瞭解如何使用 Azure 防火牆 實作安全的混合式網路。
- 周邊網路 - 雲端採用架構
- Cloud DMZ - 雲端採用架構