Azure 應用程式閘道如何運作

已完成

Azure 應用程式閘道 有一系列元件,結合在 Web 伺服器集區之間安全地路由和負載平衡要求。 應用程式閘道包括下列元件:

Diagram that shows Azure Application Gateway components.

  • 前端 IP 位址:用戶端要求是透過前端 IP 位址所接收。 您可以設定讓應用程式閘道擁有公用 IP 位址、私人 IP 位址或兩者。 應用程式閘道無法擁有超過一個公用 IP 位址或私人 IP 位址。
  • 接聽程式:應用程式閘道會使用一或多個接聽程式來接收傳入要求。 接聽會接受以特定通訊協定、連接埠、主機及 IP 位址的組合傳入的流量。 每個接聽程式都會依據您所指定的路由規則,將要求路由至伺服器的後端集區。 接聽程式可以是「基本」或「多網站」。 基本接聽程式只會根據 URL 中的路徑來路由傳送要求。 多網站接聽程式也可以使用 URL 的主機名稱元素來路由傳送要求。 接聽程式也可以處理 TLS/SSL 憑證,在使用者與應用程式閘道之間保護您的應用程式。
  • 路由規則:路由規則會將接聽程式繫結至後端集區。 規則能指定在要求的 URL 中解譯主機名稱和路徑元素的方式,並將要求導向適當的後端集區。 路由規則也有相關聯的 HTTP 設定集合。 這些 HTTP 設定會指出是否 (以及如何) 為應用程式閘道與後端伺服器之間的流量進行加密。 其他設定資訊包括通訊協定、綁定工作階段、清空連線、要求逾時期限與健康狀態探查。

應用程式閘道中的負載平衡

應用程式閘道 會使用迴圈配置資源機制,自動平衡傳送至每個後端集區中伺服器的要求。 負載平衡可搭配由應用程式閘道路由傳送所實作的 OSI 第 7 層路由傳送運作,這代表它會根據應用程式閘道規則所使用的路由傳送參數 (主機名稱和路徑) 來對要求進行負載平衡。 相較之下,其他負載平衡器 (例如 Azure Load Balancer) 會在 OSI 第 4 層運作,並根據要求之目標的 IP 位址分配流量。

如果您需要確保相同工作階段中針對某個用戶端的所有要求都會被路由至某個後端集區中的相同伺服器,您可以設定工作階段黏著度。

Web 應用程式防火牆

「Web 應用程式防火牆」(WAF) 是選擇性的元件,能在傳入要求抵達接聽程式之前先行處理該要求。 Web 應用程式防火牆會根據 Open Web Application Security Project (OWASP) 針對許多常見的威脅檢查每個要求。 常見的威脅包括:SQL 插入、跨網站腳本、命令插入、HTTP 要求走私、HTTP 回應分割、遠端檔案包含、Bot、編目程式和掃描器,以及 HTTP 通訊協定違規和異常。

OWASP 已定義用來偵測攻擊的一系列泛用規則。 這些規則被稱為核心規則集 (CRS)。 該規則集會隨著日漸複雜的攻擊而持續被檢閱。 WAF 支援四個規則集:CRS 3.2、3.1、3.0 和 2.2.9。 CRS 3.1 為預設值。 若有必要,您可以僅選取規則集中的特定規則,以特定威脅為目標。 此外,您可以自訂防火牆以指定要檢查要求中的哪些元素,並限制訊息大小以防止伺服器被大量上傳癱瘓。

後端集區

後端集區是由 Web 伺服器集合組成:一組固定的虛擬機、虛擬機擴展集、Azure App 服務 所裝載的應用程式,或內部部署伺服器的集合。

每個後端集區都具有相關聯的負載平衡器,其能將作業分散到集區上。 設定集區時,您要提供每個網頁伺服器的 IP 位址或名稱。 後端集區中的所有伺服器都應該使用相同方式進行設定,包括其安全性設定。

若您是使用 TLS/SSL,則後端集區中有 HTTP 設定,可參考用來驗證後端伺服器的憑證。 閘道將流量傳送到其中一個後端集區伺服器前,會先使用此憑證重新加密流量。

如果您使用 Azure App Service 來裝載後端應用程式,您不需要在應用程式閘道中安裝任何憑證,即可連線到後端集區。 所有通訊都會自動加密。 應用程式閘道會信任伺服器,因為 Azure 會負責管理它們。

應用程式閘道使用規則,指定如何將傳入連接埠上接收到的訊息導向至後端集區中的伺服器。 若伺服器使用 TLS/SSL,您必須設定規則來指出:

  • 您的伺服器預期會透過 HTTPS 通訊協定的流量。
  • 要使用哪個憑證來加密流量及驗證對伺服器的連線。

應用程式閘道路由

當閘道將用戶端要求路由傳送至後端集區中的 Web 伺服器時,其會使用針對該閘道所設定的規則集來判斷要將該要求路由傳送至何處。 路由此用戶端要求流量有兩種主要方式:路徑式路由與多重站台式路由。

路徑型路由

路徑型路由會將具有不同 URL 路徑的要求,傳送至後端伺服器的不同集區。 例如,您可以將含有路徑 /video/* 的要求導向後端集區,而集區包含已最佳化來處理視訊串流的伺服器,也可以將 /images/* 要求導向負責擷取影像的伺服器集區。

Diagram that depicts path-based routing in Azure Application Gateway.

多站台路由傳送

多站台式路由會在相同的應用程式閘道執行個體上,設定多個 Web 應用程式。 在多網站設定中,您會針對應用程式閘道的 IP 位址註冊多個 DNS 名稱 (CNAME),並指定每個網站的名稱。 應用程式閘道會使用個別的接聽程式來等候針對每個網站的要求。 每個接聽程式都會將要求傳遞至不同的規則,這可以將要求路由至位於不同後端集區中的伺服器。 例如,可以將 http://contoso.com 的所有要求都導向一個後端集區中的伺服器,然後將 http://fabrikam.com 的要求全都導向另一個後端集區。 下圖顯示此設定:

Diagram that depicts multi-site routing in Azure Application Gateway.

多網站組態對於支援多租用戶應用程式很有用,其中每個租使用者都有自己的虛擬機集或其他裝載 Web 應用程式的資源。

應用程式閘道 路由也包含這些功能:

  • 重新導向。 重新導向可用於路由至另一個站台,或是從 HTTP 路由至 HTTPS。
  • 重新撰寫 HTTP 標頭。 用戶端與伺服器能利用 HTTP 標頭,傳遞具有要求或回應的參數資訊。
  • 自訂錯誤頁面。 應用程式閘道可讓您建立自訂的錯誤頁面,而不是顯示預設的錯誤頁面。 您可以使用自訂錯誤頁面來搭配您自己的商標和版面配置。

TLS/SSL 終止

當您終止應用程式網路閘道的 TLS/SSL 連線時,會從您的伺服器卸載 CPU 密集型 TLS/SSL 終止工作負載。 您也不需要安裝憑證和在伺服器上設定 TLS/SSL。

如果您需要端對端加密,應用程式閘道可以使用私密金鑰來解密閘道上的流量,然後使用正在後端集區中執行的服務公開金鑰來重新加密。

流量會透過前端連接埠進入閘道。 您可以開啟多個連接埠,而應用程式閘道可以在任何這些連接埠上接收訊息。 流量透過連接埠進入閘道時首先會遇到接聽程式。 接聽程式會設定為接聽特定主機名,以及特定IP位址上的特定埠。 接聽程式可以使用 TLS/SSL 憑證來解密進入網路閘道的流量。 接聽程式接著會使用您定義的規則將傳入要求導向後端集區。

Diagram that depicts TLS/SSL termination in Azure Application Gateway.

透過應用程式閘道公開網站或 Web 應用程式也表示,伺服器不會直接連線到網路。 您在應用程式閘道上僅公開連接埠 80 或連接埠 443,然後將其轉送至後端集區伺服器。 在此設定中,您的網頁伺服器無法從網際網路直接存取,因此減少基礎結構的受攻擊面。

健康情況探查

健康狀態探查會決定可在後端集區中使用哪些伺服器,進行負載平衡。 應用程式閘道會使用健康狀態探查,將要求傳送至伺服器。 當該伺服器傳回的 HTTP 回應是介於 200 到 399 之間的狀態碼時,即會將該伺服器狀況視為良好。 如果您未設定健康情況探查,應用程式閘道會建立預設探查,它會等候 30 秒再決定伺服器是否不可用。 健康情況探查可確保流量不會導向後端集區中非回應或失敗的Web端點。

自動調整規模

應用程式閘道支援自動調整,並且可根據變動的流量負載模式來相應擴大或相應縮小。 自動調整規模也可讓您在佈建時,無須選擇部署大小或執行個體計數。

WebSocket 和 HTTP/2 流量

應用程式閘道可對 WebSocket 和 HTTP/2 通訊協定提供原生支援。 WebSocket 和 HTTP/2 通訊協定都可透過長時間執行的 TCP 連線,讓伺服器與用戶端之間能進行全雙工通訊。 這種通訊在網頁伺服器與客戶端之間比較互動式,而且可以雙向進行,而不需要在 HTTP 型實作中視需要輪詢。 不同於 HTTP,這些通訊協定的負荷很低,而且可以對多個要求/回應重複使用相同的 TCP 連線,進而提升資源使用效率。 這些通訊協定設計為透過傳統 HTTP 連接埠 80 和 443 進行運作。