虛擬網路的防火牆和 應用程式閘道

若要保護 Azure 應用程式工作負載，您應該在應用程式本身使用防護措施，例如驗證和加密。 您也可以將安全性層級新增至裝載應用程式的虛擬網路 （VNet）。 這些安全性層級可保護應用程式的輸入流程不受非預期的使用率。 它們也會將輸出流量限制為只有應用程式所需的端點。 本文說明 Azure 虛擬網絡 安全性服務，例如 Azure DDoS 保護、Azure 防火牆 和 Azure 應用程式閘道、何時使用每個服務，以及結合這兩者的網路設計選項。

• Azure DDoS 保護 (結合應用程式設計最佳做法) 可提供增強的 DDoS 風險降低功能，以針對 DDoS 攻擊提供更多的防禦。 您應該在任何周邊虛擬網路上啟用 Azure DDOS 保護。
• Azure 防火牆 是提供網路位址轉換（NAT）的受控新一代防火牆。 Azure 防火牆 根據因特網通訊協定 （IP） 位址和傳輸控制通訊協定和使用者數據報通訊協定 （TCP/UDP） 埠，或以應用程式為基礎的 HTTP（S） 或 SQL 屬性進行封包篩選。 Azure 防火牆 也會套用 Microsoft 威脅情報來識別惡意 IP 位址。 如需詳細資訊，請參閱 Azure 防火牆 檔。
• Azure 防火牆 進階版 包括 Azure 防火牆 標準和其他功能的所有功能，例如TLS檢查和入侵檢測和保護系統（IDPS）。
• Azure 應用程式閘道 是受控 Web 流量負載平衡器和 HTTP（S） 完整反向 Proxy，可以執行安全套接字層 （SSL） 加密和解密。 應用程式閘道會在 X-Forwarded-For HTTP 標頭中保留原始用戶端 IP 位址。 應用程式閘道 也會使用 Web 應用程式防火牆 來檢查 Web 流量，並偵測 HTTP 層的攻擊。 如需詳細資訊，請參閱 應用程式閘道 檔。
• Azure Web 應用程式防火牆 （WAF） 是選擇性新增 Azure 應用程式閘道。 它會檢查 HTTP 要求，並防止 Web 層的惡意攻擊，例如 SQL 插入式或跨網站腳本。 如需詳細資訊，請參閱 Web 應用程式防火牆 檔。

這些 Azure 服務是互補的。 一個或另一個可能最適合您的工作負載，或者您可以使用它們在網路和應用層的最佳保護。 使用下列判定樹和本文中的範例來判斷應用程式虛擬網路的最佳安全性選項。

Azure 防火牆 和 Azure 應用程式閘道 使用不同的技術，並支援不同流程的證券化：

根據應用程式所需的網路流程，每個應用程式的設計可能會有所不同。 下圖提供簡化的判定樹，可協助為應用程式選擇建議的方法。 決策取決於應用程式是透過 HTTP（S） 或其他通訊協議發行：

本文將涵蓋流程圖中廣泛建議的設計，以及較不常見案例適用的其他設計：

• 單獨 Azure 防火牆 虛擬網路中沒有任何 Web 應用程式時。 它會控制應用程式和輸出流量的輸入流量。
• 單獨 應用程式閘道，當只有 Web 應用程式位於虛擬網路中，且網路安全組 （NSG） 會提供足夠的輸出篩選。 Azure 防火牆 所提供的功能可以防止許多攻擊案例（例如數據外泄、IDPS 等等）。 基於這個理由，通常不建議 應用程式閘道 單一案例，因此不會記載且不在上述流程圖中。
• Azure 防火牆 和 應用程式閘道 平行，這是最常見的設計之一。 當您想要 Azure 應用程式閘道 來保護 HTTP（S） 應用程式免受 Web 攻擊，並 Azure 防火牆 來保護所有其他工作負載並篩選輸出流量時，請使用這個組合。
• 應用程式閘道 Azure 防火牆 前，當您想要 Azure 防火牆 檢查所有流量、WAF 以保護 Web 流量，以及應用程式知道用戶端的來源 IP 位址時。 透過 Azure 防火牆 進階版和 TLS 檢查，此設計也支援端對端 SSL 案例。
• 當您想要 Azure 防火牆 在到達 應用程式閘道 之前檢查和篩選流量時，Azure 防火牆 應用程式閘道 前面。 因為 Azure 防火牆 不會解密 HTTPS 流量，所以新增至 應用程式閘道 的功能有限。 上述流程圖中並未記載此案例。

在本文中的最後一個部分中，會說明先前基本設計的變化。 這些變化包括：

• 內部部署應用程式用戶端。
• 中樞和輪輻網路。
• Azure Kubernetes Service （AKS） 實作。

您可以新增其他反向 Proxy 服務，例如 API 管理 閘道或 Azure Front Door。 或者，您可以將 Azure 資源取代為第三方 網路虛擬設備。

僅限 Azure 防火牆

如果虛擬網路中沒有可從 WAF 獲益的 Web 型工作負載，您只能使用 Azure 防火牆。 在此情況下，設計很簡單，但檢閱封包流程將有助於瞭解更複雜的設計。 在此設計中，所有輸入流量都會透過使用者定義的路由傳送至 Azure 防火牆，以取得來自內部部署或其他 Azure VNet 的連線。 它會尋址至來自公用因特網之連線的 Azure 防火牆 公用IP位址，如下圖所示。 來自 Azure VNet 的輸出流量會透過 UDR 傳送至防火牆，如下列對話框所示。

下表摘要說明此案例的流量流程：

Azure 防火牆 不會檢查輸入 HTTP（S） 流量。 但它將能夠套用第 3 層和第 4 層規則和 FQDN 型應用程式規則。 Azure 防火牆 會根據 Azure 防火牆 層，以及您是否設定 TLS 檢查，檢查輸出 HTTP（S） 流量：

• Azure 防火牆 Standard 只會檢查網路規則中封包的第 3 層和第 4 層屬性，以及應用程式規則中的主機 HTTP 標頭。
• Azure 防火牆 進階版 新增功能，例如檢查其他 HTTP 標頭（例如 User-Agent），以及啟用 TLS 檢查以進行更深入的封包分析。 Azure 防火牆 不等於 Web 應用程式防火牆。 如果您的 虛擬網絡 中有 Web 工作負載，強烈建議您使用 WAF。

下列封包逐步解說範例示範用戶端如何從公用因特網存取 VM 裝載的應用程式。 為了簡單起見，此圖表只包含一個 VM。 為了獲得更高的可用性和延展性，您會在負載平衡器後方有多個應用程式實例。 在此設計中，Azure 防火牆 會檢查來自公用因特網的連入連線，以及使用 UDR 從應用程式子網 VM 輸出連線。

• Azure 防火牆 服務會部署數個實例，這裡提供前端IP位址192.168.100.4和192.168.100.0/26範圍內的內部位址。 Azure 系統管理員通常看不到這些個別實例。 但注意到差異在某些情況下很有用，例如針對網路問題進行疑難解答時。
• 如果流量來自內部部署虛擬專用網 （VPN） 或 Azure ExpressRoute 閘道，而不是因特網，客戶端會啟動 VM IP 位址的連線。 它不會啟動防火牆 IP 位址的連線，且防火牆預設不會執行來源 NAT。

架構

下圖顯示假設實例IP位址為 192.168.100.7的流量流程。

工作流程

1. 用戶端會啟動與 Azure 防火牆 公用IP位址的連線：
   • 來源IP位址：ClientPIP
   • 目的地 IP 位址：AzFwPIP
2. Azure 防火牆 公用IP的要求會散發至防火牆的後端實例，在此案例中為192.168.100.7。 Azure 防火牆 目的地 NAT （DNAT） 規則會將目的地 IP 位址轉譯為虛擬網路內的應用程式 IP 位址。 Azure 防火牆 也會來源 NAT（SNAT）封包，如果它做DNAT。 如需詳細資訊，請參閱 Azure 防火牆 已知問題。 VM 會在傳入封包中看到下列 IP 位址：
   • 來源IP位址：192.168.100.7
   • 目的地 IP 位址：192.168.1.4
3. VM 會回答應用程式要求、反轉來源和目的地IP位址。 輸入流程不需要使用者定義的路由 （UDR），因為來源 IP 是 Azure 防火牆 的 IP 位址。 圖表中 0.0.0.0.0/0 的 UDR 適用於輸出連線，以確保公用因特網的封包通過 Azure 防火牆。
   • 來源IP位址：192.168.1.4
   • 目的地 IP 位址：192.168.100.7
4. 最後，Azure 防火牆 復原 SNAT 和 DNAT 作業，並將回應傳遞給用戶端：
   • 來源 IP 位址：AzFwPIP
   • 目的地 IP 位址：ClientPIP

僅限 應用程式閘道

此設計涵蓋虛擬網路中只有 Web 應用程式存在的情況，並檢查具有 NSG 的輸出流量足以保護流向因特網的輸出流量。

與先前設計的主要差異只有 Azure 防火牆，在於 應用程式閘道 不會作為具有NAT的路由裝置。 其行為是完整的反向應用程式 Proxy。 也就是說，應用程式閘道 會停止用戶端的 Web 工作階段，並與其中一部後端伺服器建立個別的會話。 來自因特網的輸入 HTTP（S） 連線必須傳送至 應用程式閘道 的公用 IP 位址、從 Azure 或內部部署連線到閘道的私人 IP 位址。 從 Azure VM 傳回流量會遵循標準 VNet 路由回到 應用程式閘道（如需詳細資訊，請參閱封包進一步逐步解說）。 來自 Azure VM 的輸出因特網流程會直接移至因特網。

下表摘要說明流量：

架構

下列封包逐步解說範例示範用戶端如何從公用因特網存取 VM 裝載的應用程式。

工作流程

1. 用戶端會啟動與 Azure 應用程式閘道 公用IP位址的連線：
   • 來源IP位址：ClientPIP
   • 目的地 IP 位址：AppGwPIP
2. 應用程式閘道 公用IP的要求會散發至閘道的後端實例，在此案例中為192.168.200.7。 接收要求的 應用程式閘道 實例會停止來自客戶端的連線，並建立與其中一個後端的新連線。 後端會將 應用程式閘道 實例視為來源IP位址。 應用程式閘道 會插入具有原始用戶端 IP 位址的 X-Forwarded-For HTTP 標頭。
   • 來源 IP 位址：192.168.200.7（應用程式閘道 實例的私人 IP 位址）
   • 目的地 IP 位址：192.168.1.4
   • X-Forwarded-For 標頭：ClientPIP
3. VM 會回答應用程式要求、反轉來源和目的地IP位址。 VM 已經知道如何連線到 應用程式閘道，因此不需要 UDR。
   • 來源IP位址：192.168.1.4
   • 目的地 IP 位址：192.168.200.7
4. 最後，應用程式閘道 實例會回答用戶端：
   • 來源IP位址：AppGwPIP
   • 目的地 IP 位址：ClientPIP

Azure 應用程式閘道 將元數據新增至封包 HTTP 標頭，例如包含原始用戶端 IP 位址的 X-Forwarded-For 標頭。 某些應用程式伺服器需要來源用戶端 IP 位址來提供地理位置特定內容，或用於記錄。 如需詳細資訊，請參閱 應用程式閘道的運作方式。

• IP 位址192.168.200.7是 Azure 應用程式閘道 服務所部署的其中一個實例，這裡具有內部、私人的前端IP位址192.168.200.4。 Azure 系統管理員通常看不到這些個別實例。 但注意到差異在某些情況下很有用，例如針對網路問題進行疑難解答時。

• 如果用戶端透過 VPN 或 ExpressRoute 閘道來自內部部署網路，則流程會類似。 差異在於用戶端會存取 應用程式閘道 的私人IP位址，而不是公用位址。

平行防火牆和 應用程式閘道

由於其簡單性和彈性，因此平行執行 應用程式閘道 和 Azure 防火牆 通常是最佳案例。

如果虛擬網路中混合了 Web 和非 Web 工作負載，請實作此設計。 Azure 應用程式閘道 中的 Azure WAF 可保護 Web 工作負載的輸入流量，而 Azure 防火牆 會檢查其他應用程式的輸入流量。 Azure 防火牆 將涵蓋這兩種工作負載類型的輸出流程。

來自因特網的輸入 HTTP（S） 連線應傳送至來自 Azure 或內部部署的 應用程式閘道、HTTP（S） 連線至其私人 IP 位址的公用 IP 位址。 標準 VNet 路由會將封包從 應用程式閘道 傳送至目的地 VM，以及從目的地 VM 傳回 應用程式閘道（如需詳細數據，請參閱封包逐步解說）。 針對輸入非 HTTP（S） 連線，流量應以 Azure 防火牆 的公用 IP 位址為目標（如果來自公用因特網），否則會透過 UDR 傳送 Azure 防火牆（如果來自其他 Azure VNet 或內部部署網路）。 來自 Azure VM 的所有輸出流程都會由 UDR 轉送至 Azure 防火牆。

下表摘要說明此案例的流量流程：

此設計提供比 NSG 更細微的輸出篩選。 例如，如果應用程式需要連線到特定 Azure 儲存體 帳戶，您可以使用完整功能變數名稱 （FQDN） 型篩選器。 使用 FQDN 型篩選，應用程式不會將數據傳送至流氓記憶體帳戶。 只能使用 NSG 來防止該案例。 此設計通常用於輸出流量需要以 FQDN 為基礎的篩選。 其中一個範例是 限制來自 Azure Kubernetes Services 叢集的輸出流量。

架構

下圖說明來自外部客戶端的輸入 HTTP（S） 連線流量：

下圖說明從網路 VM 到因特網的輸出連線流量流程。 其中一個範例是連線到後端系統或取得作業系統更新：

每個服務的封包流程步驟與先前的獨立設計選項相同。

防火牆前的 應用程式閘道

此設計會在具有 Azure 防火牆 和 應用程式閘道 的 Web 應用程式零信任網路中更詳細地說明，本檔將著重於與其他設計選項的比較。 在此拓撲中，輸入 Web 流量會同時通過 Azure 防火牆 和 WAF。 WAF 會在 Web 應用層提供保護。 Azure 防火牆 做為中央記錄和控制點，它會檢查 應用程式閘道 與後端伺服器之間的流量。 應用程式閘道 和 Azure 防火牆 不是平行的，而是一個接一個。

透過 Azure 防火牆 進階版，此設計可支援端對端案例，其中 Azure 防火牆 會套用 TLS 檢查，以在 應用程式閘道 與 Web 後端之間的加密流量上執行 IDPS。

此設計適用於需要知道連入用戶端來源IP位址的應用程式，例如提供地理位置特定內容或記錄。 應用程式閘道 Azure 防火牆 擷取 X 轉送標頭中傳入封包的來源 IP 位址，讓網頁伺服器可以看到此標頭中的原始 IP 位址。 如需詳細資訊，請參閱 應用程式閘道的運作方式。

來自因特網的輸入 HTTP（S） 連線必須傳送至從 Azure 或內部部署至私人 IP 位址的 應用程式閘道、HTTP（S） 連線的公用 IP 位址。 從 應用程式閘道 UDR 可確保封包會透過 Azure 防火牆 路由傳送（如需詳細資訊，請參閱封包進一步逐步解說）。 針對輸入非 HTTP（S） 連線，流量應以 Azure 防火牆 的公用 IP 位址為目標（如果來自公用因特網），否則會透過 UDR 傳送 Azure 防火牆（如果來自其他 Azure VNet 或內部部署網路）。 來自 Azure VM 的所有輸出流程都會由 UDR 轉送至 Azure 防火牆。

此設計的重要備註是，Azure 防火牆 進階版 會看到來自 應用程式閘道 子網的來源IP位址流量。 如果此子網設定為私人IP位址（在、 192.168.0.0/16172.16.0.0/12 或 100.64.0.0/10中10.0.0.0/8），Azure 防火牆 進階版 會將來自 應用程式閘道的流量視為內部流量，而且不會套用輸入流量的IDPS規則。 您可以在 #DBFF9E68EEC754A32834C78B95200223C IDPS 規則中找到 idPS 規則指示和私人 IP 前置綴 Azure 防火牆 詳細資訊。 因此，建議修改 Azure 防火牆 原則中的IDPS私人前置詞，讓應用程式閘道子網不會被視為內部來源，以將輸入和輸出IDPS簽章套用至流量。

下表摘要說明此案例的流量流程：

針對從內部部署或因特網到 Azure 的 Web 流量，Azure 防火牆 會檢查 WAF 已允許的流程。 根據 應用程式閘道 是否加密後端流量（從 應用程式閘道 到應用程式伺服器的流量），您將有不同的潛在案例：

1. 應用程式閘道 會遵循零信任原則加密流量（端對端 TLS 加密），而 Azure 防火牆 將會收到加密的流量。 不過，Azure 防火牆 Standard 將能夠套用檢查規則，例如網路規則中的第 3 層和第 4 層篩選，或使用 TLS 伺服器名稱指示 （SNI） 標頭在應用程式規則中篩選 FQDN。 Azure 防火牆 進階版 提供 TLS 檢查的更深入可見度，例如 URL 型篩選。
2. 如果 應用程式閘道 將未加密的流量傳送至應用程式伺服器，則 Azure 防火牆 會以純文本顯示輸入流量。 Azure 防火牆 中不需要 TLS 檢查。
3. 如果在 Azure 防火牆 中啟用 IDPS，它會確認 HTTP 主機標頭符合目的地 IP。 如此一來，它將需要主機標頭中指定的 FQDN 名稱解析。 您可以使用 Azure DNS 私人區域和使用 Azure DNS 的預設 Azure 防火牆 DNS 設定來達成此名稱解析。 您也可以使用需要在 Azure 防火牆 設定中設定的自定義 DNS 伺服器來達成。 （如需詳細資訊，請參閱Azure 防火牆 DNS 設定。如果部署 Azure 防火牆 的 虛擬網絡 沒有系統管理存取權，則後者方法是唯一的可能性。 其中一個範例是部署在虛擬 WAN 安全中樞 Azure 防火牆。

架構

針對其餘流量（輸入非 HTTP（S） 流量和任何輸出流量，Azure 防火牆 會在適當時提供IDPS檢查和TLS檢查。 它也根據 DNS 在網路規則中提供 FQDN 型篩選。

工作流程

來自公用因特網的網路流量會遵循此流程：

1. 用戶端會啟動與 Azure 應用程式閘道 公用IP位址的連線：
   • 來源IP位址：ClientPIP
   • 目的地 IP 位址：AppGwPIP
2. 應用程式閘道 公用IP的要求會散發至閘道的後端實例，在此案例中為192.168.200.7。 應用程式閘道 實例會停止來自客戶端的連線，並使用其中一個後端建立新的連線。 應用程式閘道 子網中的 UDR 192.168.1.0/24 會將封包轉送至 Azure 防火牆，同時保留目的地 IP 給 Web 應用程式：
   • 來源 IP 位址：192.168.200.7 （應用程式閘道 實例的私人 IP 位址）
   • 目的地 IP 位址：192.168.1.4
   • X-Forwarded-For 標頭：ClientPIP
3. Azure 防火牆 不會 SNAT 流量，因為流量會移至私人IP位址。 如果規則允許，它會將流量轉送至應用程式 VM。 如需詳細資訊，請參閱 Azure 防火牆 SNAT。 不過，如果流量在防火牆中叫用應用程式規則，則工作負載會看到處理封包的特定防火牆實例的來源IP位址，因為 Azure 防火牆 會 Proxy 連線：
   • 如果 Azure 防火牆 網路規則允許流量，則來源IP位址：192.168.200.7（其中一個應用程式閘道 實例的私人IP位址）。
   • 如果 Azure 防火牆 應用程式規則允許流量，則來源IP位址：192.168.100.7（其中一個Azure 防火牆 實例的私人IP位址）。
   • 目的地 IP 位址：192.168.1.4
   • X-Forwarded-For 標頭：ClientPIP
4. VM 會回答要求、反轉來源和目的地 IP 位址。 UDR 會192.168.200.0/24擷取傳回至 應用程式閘道 的封包，並將它重新導向至 Azure 防火牆，同時將目的地 IP 保留至 應用程式閘道。
   • 來源IP位址：192.168.1.4
   • 目的地 IP 位址：192.168.200.7
5. 同樣地，Azure 防火牆 不會 SNAT 流量，因為它會傳送至私人 IP 位址，並將流量轉送至 應用程式閘道。
   • 來源IP位址：192.168.1.4
   • 目的地 IP 位址：192.168.200.7
6. 最後，應用程式閘道 實例會回答用戶端：
   • 來源IP位址：AppGwPIP
   • 目的地 IP 位址：ClientPIP

從 VM 到公用因特網的輸出流程會經過 Azure 防火牆，如 UDR 所定義的到 0.0.0.0/0。

防火牆后 應用程式閘道

此設計可讓 Azure 防火牆 篩選和捨棄惡意流量，再到達 應用程式閘道。 例如，它可以套用威脅情報型篩選等功能。 另一個優點是，無論通訊協議為何，應用程式都會針對輸入和輸出流量取得相同的公用IP位址。 不過，Azure 防火牆 內送流量的 SNAT，因此應用程式將無法看見 HTTP 要求的原始 IP 位址。 從系統管理的觀點來看，例如，為了進行疑難解答，您可以將特定連線的實際用戶端 IP 與 Azure 防火牆 的 SNAT 記錄相互關聯，以取得特定連線的實際用戶端 IP。

此案例有有限的好處，因為 Azure 防火牆 只會看到 應用程式閘道 的加密流量。 在某些情況下，此設計是慣用的。 其中一個案例是，如果網路稍早有另一個 WAF（例如，使用 Azure Front Door），這可能會擷取 HTTP 標頭中的 X-Forwarded-For 原始來源 IP。 或者，如果需要許多公用IP位址，則建議使用設計。

來自公用因特網的 HTTP（S） 輸入流程應以 Azure 防火牆 的公用 IP 位址為目標，而 Azure 防火牆 會將封包 DNAT （和 SNAT） 封包設為 應用程式閘道 的私人 IP 位址。 從其他 Azure VNet 或內部部署網路，HTTP（S） 流量應傳送至 應用程式閘道 的私人 IP，並使用 UDR 透過 Azure 防火牆 轉送。 標準 VNet 路由可確保從 Azure VM 傳回流量回到 應用程式閘道，並在使用 DNAT 規則時從 應用程式閘道 傳回至 Azure 防火牆。 如需來自 應用程式閘道 子網內部部署或 Azure UDR 的流量，應使用 （如需詳細資訊，請參閱封包逐步解說）。 從 Azure VM 到因特網的所有輸出流量都會透過 UDR 的 Azure 防火牆 傳送。

下表摘要說明此案例的流量流程：

對於輸入 HTTP（S） 流量，Azure 防火牆 通常不會解密流量。 它會改為套用不需要 TLS 檢查的 IDPS 原則，例如 IP 型篩選或使用 HTTP 標頭。

架構

應用程式看不到 Web 流量的原始來源 IP 位址;當封包傳入虛擬網路時，Azure 防火牆 SNAT。 若要避免這個問題，請在防火牆前面使用 Azure Front Door 。 Azure Front Door 會將用戶端的 IP 位址插入為 HTTP 標頭，再進入 Azure 虛擬網路。

工作流程

來自公用因特網的網路流量會遵循此流程：

1. 用戶端會啟動與 Azure 防火牆 公用IP位址的連線：
   • 來源IP位址：ClientPIP
   • 目的地 IP 位址：AzFWPIP
2. Azure 防火牆 公用IP的要求會散發至防火牆的後端實例，在此案例中為192.168.100.7。 Azure 防火牆 WEB 埠通常是 TCP 443 到 應用程式閘道 實例的私人 IP 位址的 DNAT。 執行 DNAT 時，Azure 防火牆 SNAT。 如需詳細資訊，請參閱 Azure 防火牆 已知問題：
   • 來源 IP 位址：192.168.100.7（Azure 防火牆 實例的私人 IP 位址）
   • 目的地 IP 位址：192.168.200.4
3. 應用程式閘道 會在處理連線的實例與其中一部後端伺服器之間建立新的工作階段。 用戶端的原始 IP 位址不在封包中：
   • 來源 IP 位址：192.168.200.7（應用程式閘道 實例的私人 IP 位址）
   • 目的地 IP 位址：192.168.1.4
   • X-Forwarded-For 標頭：192.168.100.7
4. VM 會回答 應用程式閘道，反轉來源和目的地 IP 位址：
   • 來源IP位址：192.168.1.4
   • 目的地 IP 位址：192.168.200.7
5. 應用程式閘道 會回復 Azure 防火牆 實例的 SNAT 來源 IP 位址。 即使連線來自像是 .7的特定 應用程式閘道 實例，Azure 防火牆 仍會將 應用程式閘道 .4 的內部IP位址視為來源IP：
   • 來源IP位址：192.168.200.4
   • 目的地 IP 位址：192.168.100.7
6. 最後，Azure 防火牆 復原 SNAT 和 DNAT 並回答用戶端：
   • 來源 IP 位址：AzFwPIP
   • 目的地 IP 位址：ClientPIP

即使 應用程式閘道 沒有針對應用程式設定的接聽程式，它仍然需要公用IP位址，Microsoft才能管理它。

內部部署用戶端

上述設計全都顯示來自公用因特網的應用程式用戶端。 內部部署網路也會存取應用程式。 上述大部分的資訊和流量都與因特網用戶端相同，但有一些顯著的差異：

• VPN 閘道或 ExpressRoute 閘道位於 Azure 防火牆 或 應用程式閘道 前面。
• WAF 會使用 應用程式閘道 的私人IP位址。
• Azure 防火牆 不支援私人IP位址的DNAT。 這就是為什麼您必須使用 UDR 從 VPN 或 ExpressRoute 閘道將輸入流量傳送至 Azure 防火牆。
• 請務必針對 Azure 應用程式閘道 和 Azure 防火牆 確認強制通道周圍的警告。 即使您的工作負載不需要對公用因特網進行輸出連線，您也無法針對指向內部部署網路的 應用程式閘道 插入預設路由0.0.0.0/0，或是中斷控制流量。 針對 Azure 應用程式閘道，預設路由必須指向公用因特網。

架構

下圖顯示 Azure 應用程式閘道 和 Azure 防火牆 平行設計。 應用程式用戶端來自透過 VPN 或 ExpressRoute 連線至 Azure 的內部部署網路：

即使所有客戶端都位於內部部署或 Azure 中，Azure 應用程式閘道 和 Azure 防火牆 都需要有公用 IP 位址。 公用IP位址可讓 Microsoft 管理服務。

中樞與輪幅拓撲 \(部分機器翻譯\)

本文中的設計仍適用於中 樞和輪輻 拓撲。 中央中樞虛擬網路中的共享資源會透過虛擬網路對等互連連線到不同輪輻虛擬網路中的應用程式。

架構

考量

此拓撲的一些考慮包括：

• Azure 防火牆 部署在中央中樞虛擬網路中。 上圖顯示在中樞部署 應用程式閘道 的做法。 不過，應用程式小組通常會管理 Azure 應用程式閘道 或 Azure API 管理 閘道等元件。 在此情況下，這些元件會部署在輪輻虛擬網路中。
• 特別注意輪輻網路中 UDR：當輪輻中的應用程式伺服器接收來自特定 Azure 防火牆 實例的流量時，例如192.168.100.7先前範例中的位址，它應該會將傳回流量傳回相同的實例。 如果輪輻中的 UDR 將尋址至中樞的下一個流量躍點設定為 Azure 防火牆 IP 位址（192.168.100.4在上圖中），則傳回封包最終可能會位於不同的 Azure 防火牆 實例上，導致非對稱路由。 請確定您在輪輻 VNet 中有 UDR 可透過 Azure 防火牆 將流量傳送至中樞中的共用服務，這些 UDR 不會包含 Azure 防火牆 子網的前置詞。
• 先前的建議同樣適用於 應用程式閘道 子網，以及可能部署在中樞 VNet 中的任何其他網路虛擬設備或反向 Proxy。
• 您無法透過具有下一個躍點類型的Virtual Network靜態路由，為 應用程式閘道 或 Azure 防火牆 子網設定下一個躍點。 這個下一個躍點類型只在本機 VNet 中有效，而且不適用於 VNet 對等互連。 如需使用者定義路由和下一個躍點類型的詳細資訊，請參閱 虛擬網路流量路由。

非對稱路由

下圖顯示輪輻如何將 SNATted 流量傳回至 Azure 防火牆 的 ALB。 此設定會導致非對稱路由：

若要解決此問題，請在輪輻中定義沒有 Azure 防火牆 子網的 UDR，但只定義共用服務所在的子網。 在此範例中，輪輻中的正確 UDR 應該只包含 192.168.1.0/24。 它不應該包含整個 192.168.0.0/16，如紅色標示。

與其他 Azure 產品整合

您可以將 Azure 防火牆 和 Azure 應用程式閘道 與其他 Azure 產品和服務整合。

API 管理 閘道

將反向 Proxy 服務，例如 API 管理 閘道整合到先前的設計中，以提供 API 節流或驗證 Proxy 等功能。 整合 API 管理 閘道並不會大幅改變設計。 主要差異在於，除了單一 應用程式閘道 反向 Proxy 之外，還有兩個反向 Proxy 彼此鏈結。

如需詳細資訊，請參閱在虛擬網路中整合 API 管理 和 應用程式閘道 的設計指南，以及微服務的應用程式模式 API 閘道。

Azure Kubernetes Service

針對在 AKS 叢集上執行的工作負載，您可以部署 Azure 應用程式閘道 與叢集無關。 或者，您可以使用 Azure 應用程式閘道 輸入控制器，將其與 AKS 叢集整合。 在 Kubernetes 層級設定特定物件時，應用程式閘道 會自動調整，而不需要額外的手動步驟。

Azure 防火牆 在 AKS 叢集安全性中扮演著重要的角色。 它提供必要功能，以根據 FQDN 篩選來自 AKS 叢集的輸出流量，而不只是 IP 位址。 如需詳細資訊，請參閱 控制 AKS 叢集節點的輸出流量。

當您結合 應用程式閘道 和 Azure 防火牆 來保護 AKS 叢集時，最好使用平行設計選項。 使用 WAF 的 應用程式閘道 會處理叢集中 Web 應用程式的輸入連線要求。 Azure 防火牆 只允許明確允許的輸出連線。 如需平行設計選項的範例，請參閱 Azure Kubernetes Service （AKS） 叢集 的基準架構。

Azure Front Door

Azure Front Door 功能部分與 Azure 應用程式閘道 重疊。 例如，這兩項服務都提供 Web 應用程式防火牆、SSL 卸除和 URL 型路由。 其中一個主要差異是，雖然 Azure 應用程式閘道 位於虛擬網路內，但 Azure Front Door 是全域分散式服務。

您有時可以藉由以分散式 Azure Front Door 取代 應用程式閘道 來簡化虛擬網路設計。 此處所述的大多數設計仍然有效，除了將 Azure 防火牆 放在 Azure Front Door 前面的選項之外。

有趣的使用案例是在虛擬網路中 應用程式閘道 前面使用 Azure 防火牆。 如先前所述，X-Forwarded-For應用程式閘道 插入的標頭會包含防火牆實例的IP位址，而不是用戶端的IP位址。 因應措施是使用防火牆前方的 Azure Front Door，在流量進入虛擬網路並叫用 Azure 防火牆 之前，將用戶端的 IP 位址X-Forwarded-For插入標頭。 第二個選項是在 Azure Front Door 進階版 中使用 Private Link 保護您的原始來源。

如需兩個服務之間差異的詳細資訊，或何時使用每個服務，請參閱 Azure Front Door 的常見問題。

其他網路虛擬設備

Microsoft 產品並不是在 Azure 中實作 Web 應用程式防火牆或新一代防火牆功能的唯一選擇。 廣泛的 Microsoft 合作夥伴提供網路虛擬設備（NVA）。 概念和設計基本上與本文相同，但有一些重要的考慮：

• 適用於新一代防火牆的合作夥伴 NVA 可能會為 Azure 防火牆 不支援的 NAT 設定提供更多的控制和彈性。 範例包括來自內部部署的DNAT，或來自因特網不含SNAT的DNAT。
• Azure 管理的 NVA（例如 應用程式閘道 和 Azure 防火牆）相較於使用者需要處理許多應用裝置的延展性和復原能力，AZURE 管理的 NVA 可降低複雜性。
• 在 Azure 中使用 NVA 時，請使用 主動-主動 和 自動調整 設定，因此這些設備對於在虛擬網路中執行的應用程式並不是瓶頸。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主體作者：

• 何塞·莫雷諾 |首席客戶工程師

下一步

深入瞭解元件技術：

• 什麼是 Azure 應用程式閘道?
• Azure 防火牆是什麼？
• Azure Front Door 是什麼？
• Azure Kubernetes Service
• 什麼是 Azure 虛擬網路？
• 什麼是 Azure Web 應用程式防火牆？

相關資源

探索相關的架構：

• 實作安全的混合式網路
• 安全管理的 Web 應用程式
• 保護您的 Microsoft Teams 頻道 Bot 和防火牆後方的 Web 應用程式
• Azure 上的取用者健康情況入口網站
• Azure 中高度敏感 IaaS 應用程式的安全性考慮
• Azure 上的多租使用者 SaaS
• 使用 App Services 環境進行企業部署
• 使用 App Services 環境進行高可用性企業部署
• Azure Kubernetes Service (AKS) 叢集的基準架構