雲端正在變更基礎結構的設計方式，包括防火牆的設計，因為網路不再是實體或虛擬 LAN。 並非所有實體網路的功能都可以在虛擬網路 （VNet） 中使用。 這包括使用浮動IP位址或廣播流量，並影響HA架構的實作。 網路虛擬設備 （NVA） 的負載平衡器可以/必須以特定方式實作，以達到虛擬網路內的高可用性 （HA） 架構。 本指南提供使用第三方虛擬設備在 Azure 中設計 HA 防火牆 （FW） 的結構化方法。
設計高可用性 NVA 的選項
部署HA架構時，有幾個選項可提供故障轉移：
- Azure API 管理的路由表： 此選項會使用兩個路由表，一個主動、一個被動，針對在 VNet/子網上執行的所有服務切換主動網關 IP。
- Azure API 管理的浮動 IP： 此選項會在 FW 上使用次要 IP 位址，可在作用中與待用 FW 之間移動。
- 負載平衡器受控： 此選項會使用 Azure Load Balancer 作為子網的閘道 IP，然後將流量轉送至作用中的 FW。 甚至可能會轉送主動-主動流量以提供真正的負載平衡。
前兩個選項的問題在於故障轉移本身的速度很慢。 FW 必須指示故障轉移，這基本上是透過新的部署重新設定 Azure 服務的。 根據部署完成的速度而定，流量會關閉幾分鐘。 此外，它不允許同時運作這兩個防火牆的作用中-主動設定。
這就是為什麼第三個選項最慣用的原因。 停機時間最小化，因為負載平衡器幾乎可以立即故障轉移到待用防火牆（主動-被動），或只是從失敗的防火牆中移除負載（主動-主動）。 但是，您不能只使用負載平衡器作為「預設網關」，因為它們會影響流量流量，而 TCP 封包必須具狀態。
雙腿防火牆
下圖開頭為兩個 FW（FW-1 和 FW-2），具有外部負載平衡器和後端伺服器 S1。
此架構是簡單的設定，用於輸入流量。 封包會叫用負載平衡器，從其組態中選擇目的地 FW。 選擇的防火牆接著會將流量傳送至後端 （web） 伺服器。 如果 FW-1 已啟用 SNAT，伺服器 S1 將會看到來自 FW-1 內部 IP 的流量，因此也會將回覆傳送至 FW-1。 在此案例中，故障轉移可能會快速發生至 FW-2。 針對輸出流量，我們可以在內部端新增另一個負載平衡器。 當伺服器 S1 啟動流量時，會套用相同的原則。 流量會叫用內部 LB （iLB），其會選擇防火牆，然後轉譯 NAT 以進行外部解析：
三腿防火牆
當我們將另一個介面新增至防火牆，而且您需要停用內部區域之間的 NAT 轉譯時，就會發生問題。 在此情況下，請參閱 Subnet-B 和 Subnet-C：
內部區域 （Subnet-B 和 Subnet-C） 之間的 L3 路由將會在沒有 NAT 的情況下進行負載平衡。 此設定會更清楚查看流量流程，包括不同檢視中的負載平衡器。 下圖顯示內部 Load Balancer [iLB] 連結到 FW 上特定 NIC 的檢視：
使用 L3 流量（不含 NAT），S2 會將 S1 IP 位址視為來源位址。 S2 接著會將子網 B 的傳回流量（S1-IP 所屬）傳送至 Subnet-C 中的 iLB。 當 Subnet-B 中的 iLB 和 Subnet-C 中的 iLB 不會同步處理其會話狀態時，根據負載平衡演算法流量可能會最終出現在 FW-2 上。 根據預設，FW-2 並不知道初始 （綠色） 封包的任何專案，因此它會卸除連線。
有些防火牆廠商會嘗試在防火牆之間保留連線狀態，但幾乎需要立即同步處理，才能在聯機狀態上保持最新狀態。 如果防火牆廠商建議進行此設定，請洽詢您的防火牆廠商。
解決這個問題的最佳方式是消除這個問題。 在上述範例中，此解決方案表示消除 Subnet-C，這可讓我們發揮虛擬化 VNet 的優點。
使用網路安全組隔離子網中的主機
當單一子網中有兩部 VM 時，您可以套用 NSG 來隔離兩者之間的流量。 根據預設，完全允許 VNet 內的流量。 在 NSG 上新增 [拒絕所有規則]，將所有 VM 彼此隔離。
VNet 使用相同的後端 （虛擬） 路由器
VNet/子網使用來自 Azure 的單一後端路由器系統，因此不需要為每個子網指定路由器 IP。 路由目的地可以是相同 VNET 或甚至外部的任何位置。
透過虛擬化網路，您可以控制每個子網中的路由。 這些路由也可以指向另一個子網中的單一IP。 在上圖中，這會是 Subnet-D 中的 iLB，這會平衡兩個防火牆的負載平衡。 由於 S1 會啟動流量 （綠色），因此會負載平衡至 FW-1。 FW-1 接著會連線到 S2 （仍然為綠色）。 S2 會將回應流量傳送至 S1 的 IP（因為 NAT 已停用）。 由於路由表，S2 會使用與其閘道相同的 iLB IP。 iLB 可能會比對流量到初始會話，因此一律會將此流量指向 FW-1。 FW-1 接著會將它傳送至 S1，以建立同步流量流程。
若要讓此設定運作，FW 必須有路由表（內部）將 Subnet-B 和 Subnet-C 指向其預設子網 GW。 該子網 GW 是該 VNET 中子網範圍中第一個邏輯上可用的 IP。
對反向 Proxy 服務的影響
當您部署反向 Proxy 服務時， 通常會 位於 FW 後方。 您可以改為將它 與 FW 對齊 ，並實際透過 FW 路由傳送流量。 此設定的優點是反向 Proxy 服務會看到連線用戶端的原始 IP：
針對此設定，Subnet-E 上的路由表必須透過內部負載平衡器來指向 Subnet-B 和 Subnet-C。 某些反向 Proxy 服務具有內建防火牆，可讓您在此網路流程中一起移除 FW。 內建防火牆會從反向 Proxy 直接指向 Subnet-B/C 伺服器。
在此案例中，反向 Proxy 上也需要 SNAT，以避免傳回流量流經 FW 並遭到子網 A 拒絕。
VPN/ER
Azure 透過 Azure 虛擬網絡 閘道提供 BGP 啟用/高可用性 VPN/ER 服務。 大部分的架構設計人員都會針對後端或非因特網對向連線保留這些專案。 此設定表示路由表也需要容納這些連線背後的子網。 雖然子網 B/C 連線沒有太大差異，但傳回流量的設計中卻完成圖片：
在此架構中，來自 FW 的流量，例如 Subnet-B 到 Subnet-X 的流量會傳送至 iLB，進而將它傳送至任一防火牆。 FW 內部路由會將流量傳回 Subnet-GW（Subnet-D 中的第一個可用 IP）。 您不需要將流量直接傳送至網關設備本身，因為 Subnet-D 上的另一個路由會有子網 X 的路由，將它指向 虛擬網絡 閘道。 Azure 網路會負責實際路由。
傳回來自 Subnet-X 的流量將會轉送至 Subnet-D 中的 iLB。 GatewaySubnet 也會有將 Subnet-B-C 指向 iLB 的自定義路由。 子網 D 不是透過 iLB。 這將會被視為 一般 VNET 間路由。
雖然不在繪圖中，但子網 B/C/D/閘道也會包含子網 A 的路由，以指向 iLB。 這種安排可避免「一般」VNET 路由略過 FW。 這作為 Subnet-A 只是 VNET 中根據 Azure 網路堆疊的另一個子網。 它不會將 Subnet-A 視為不同，不過您會將其視為 DMZ、因特網等等。
摘要
簡言之，您在內部部署（實體/VLAN 型）網路中處理防火牆的方式與 Azure 中的介面（虛擬或實體）不同。 如有必要，您仍然可以（在某種程度上），但有更好的方法可以確保您可以將故障轉移停機時間降到最低：具有主動-主動實作和 乾淨的 路由表。
如需使用負載平衡器作為 所有流量閘道 的詳細資訊，請參閱 高可用性埠概觀。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Roelf Zomerman |資深雲端解決方案架構師
下一步
深入瞭解元件技術：
相關資源
探索相關的架構：