應用程式閘道整合
Azure App Service 的三種變化與 Azure 應用程式閘道整合時所需的設定略有不同。 這些變化包含:一般 App Service (又稱為多租用戶)、內部負載平衡器 (ILB) App Service 環境,以及外部 App Service 環境。
本文逐步解說如何使用服務端點來保護流量,進而透過 App Service 設定應用程式閘道 (多租用戶)。 本文也將探討使用私人端點、整合 ILB 以及外部 App Service 環境等考量。 最後,本文說明如何在原始檔控制管理員 (SCM) 網站上設定存取限制。
與 App Service (多租用戶) 整合
App Service (多租用戶) 具有面向公用網際網路的端點。 您可以使用服務端點,僅允許來自 Azure 虛擬網路內特定子網路的流量,並封鎖其他所有流量。 在下列案例中,我們將使用這項功能來確保 App Service 執行個體僅能接收特定應用程式閘道的流量。
除了建立 App Service 執行個體和應用程式閘道,此設定還有兩個部分。 第一部分是在應用程式閘道所部署的虛擬網路子網路中,啟用服務端點。 服務端點可確保從子網路到 App Service 的所有網路流量皆會標記特定的子網路識別碼。
第二部分是設定特定 Web 應用程式的存取限制,以確保僅允許具有此特定子網路識別碼標記的流量。 您可以依您的喜好設定,使用不同工具來設定存取限制。
使用 Azure 入口網站設定服務
透過 Azure 入口網站,您可以遵循四個步驟來建立和設定 App Service 和應用程式閘道的設定。 若有現有資源,便可跳過前面的步驟。
- 使用 App Service 文件中的快速入門之一建立 App Service 執行個體。 其中一個範例是 .NET Core 快速入門。
- 使用入口網站快速入門來建立應用程式閘道,但跳過有關新增後端目標的部分。
- 設定 App Service 做為應用程式閘道後端,但跳過有關限制存取的部分。
- 使用服務端點建立存取限制。
您現在可以透過應用程式閘道存取 App Service。 如果您嘗試直接存取 App Service,您應該會收到 403 HTTP 錯誤,指出 Web 應用程式已封鎖您的存取。
使用 Azure Resource Manager 範本設定服務
Azure Resource Manager 部署範本會建立完整的案例。 該案例包含使用服務端點對 App Service 執行個體進行鎖定,以及僅接收應用程式閘道流量的存取限制。 此範本包含許多智慧型預設值,並已新增資源名稱的唯一後置詞,以使其保持簡潔。 若要覆寫,必須複製存放庫,或下載並編輯範本。
若要套用範本,您可以使用範本描述中的 [部署至 Azure] 按鈕。 或者,您可以使用適當的 PowerShell 或 Azure CLI 程式碼。
使用 Azure CLI 設定服務
Azure CLI 範例會建立一個 App Service 執行個體:使用服務端點進行鎖定,並且存在存取限制,因此僅能接收應用程式閘道流量。 若只需隔離現有 App Service 執行個體與現有應用程式閘道的流量,請使用下列命令:
az webapp config access-restriction add --resource-group myRG --name myWebApp --rule-name AppGwSubnet --priority 200 --subnet mySubNetName --vnet-name myVnetName
在預設設定中,該命令可確實設定子網路中的服務端點設定,以及 App Service 中的存取限制。
使用私人端點時的考量
您可以使用私人端點來替代服務端點,以保護應用程式閘道與 App Service (多租用戶) 間的流量。 您必須確保應用程式閘道可以使用 DNS 來解析 App Service 應用程式的私人 IP 位址。 或者,您可以使用後端集區中的私人 IP 位址,並在 HTTP 設定中覆寫主機名稱。
應用程式閘道會快取 DNS 查閱結果。 如果您使用完整網域名稱 (FQDN) 並依賴 DNS 查閱來取得私人 IP 位址,當您在設定後端集區後發生 DNS 更新或 Azure 私人 DNS 區域的連結時,您可能需要重新啟動應用程式閘道。
若要重新啟動應用程式閘道,請使用 Azure CLI 將其停止再啟動:
az network application-gateway stop --resource-group myRG --name myAppGw
az network application-gateway start --resource-group myRG --name myAppGw
ILB App Service 環境的考量
ILB App Service 環境不會向網際網路公開。 執行個體與應用程式閘道間的流量已與虛擬網路隔開。 若要使用 Azure 入口網站設定 ILB App Service 環境並與應用程式閘道進行整合,請參閱操作指南。
若要確保 App Service 環境僅接收應用程式閘道子網路的流量,您可以設定對 App Service 環境中的所有 Web 應用程式都有影響的網路安全性群組 (NSG)。 針對 NSG,您可以指定子網路 IP 範圍,並選擇性地指定連接埠 (80/443)。 若要讓 App Service 環境正常運作,請確定您未覆寫必要的 NSG 規則。
若要隔離個別 Web 應用程式的流量,由於服務端點不適用於 App Service 環境,您必須使用以 IP 為基礎的存取限制。 IP 位址應為應用程式閘道的私人 IP。
外部 App Service 環境的考量
外部 App Service 環境具有公開的負載平衡器,例如多租用戶的 App Service。 服務端點不適用於 App Service 環境。 正因如此,您必須使用應用程式閘道的公用 IP 位址來使用 IP 型存取限制。 若要使用 Azure 入口網站建立外部 App Service 環境,請遵循本快速入門。
Kudu/SCM 網站的考量
SCM 網站是存在於每個 Web 應用程式的管理網站,又稱為 Kudu。 對於 SCM 網站無法使用反向 Proxy。 您很可能也想將其限定於個別 IP 位址或特定子網路。
若要使用與主要網站相同的存取限制,可以使用下列命令繼承設定:
az webapp config access-restriction set --resource-group myRG --name myWebApp --use-same-restrictions-for-scm-site
如果您想要新增 SCM 網站的個別存取限制,您可以使用 --scm-site
旗標:
az webapp config access-restriction add --resource-group myRG --name myWebApp --scm-site --rule-name KudoAccess --priority 200 --ip-address 208.130.0.0/16
使用預設網域的考量
若要設定整合,最簡單的方式是設定應用程式閘道以覆寫主機名稱,並使用 App Service 的預設網域 (通常是 azurewebsites.net
)。 這種方式不需要在 App Service 中設定自訂網域和憑證。
本文討論覆寫原始主機名稱的一般考量。 在 App Service 中,有兩種情況需要注意此設定。
驗證
當您使用 App Service (以前稱為 Easy Auth) 中的驗證功能時,您的應用程式通常會重新導向至登入頁面。 因為 App Service 不知道要求的原始主機名稱,因此會對預設網域名稱執行重新導向,且通常會導致錯誤。
若要解決預設重新導向問題,您可以設定驗證來檢查轉送的標頭,並將重新導向網域調整為原始網域。 應用程式閘道會使用名為 X-Original-Host
的標頭。 藉由使用檔案型設定來設定驗證,您可以設定 App Service 以因應原始主機名稱。 將此設定新增至您的組態檔:
{
...
"httpSettings": {
"forwardProxy": {
"convention": "Custom",
"customHostHeaderName": "X-Original-Host"
}
}
...
}
ARR 親和性
在多執行個體部署中,ARR 親和性可確保用戶端要求在工作階段期間路由傳送至相同的執行個體。 ARR 親和性不適用於主機名稱覆寫。 若要讓工作階段親和性能夠運作,您必須在 App Service 和應用程式閘道中設定相同的自訂網域和憑證,且不得覆寫主機名稱。
下一步
如需 App Service 環境的詳細資訊,請參閱 App Service 環境文件。
若要進一步保護 Web 應用程式,您可在 Azure Web 應用程式防火牆文件中找到應用程式閘道的 Azure Web 應用程式防火牆相關資訊。
若要使用 Azure Front Door 或應用程式閘道在 App Service 上部署具有自訂網域且安全而可復原的網站,請參閱本教學課程。