應用程式閘道基礎結構設定
Azure 應用程式閘道基礎結構包括虛擬網路、子網路、網路安全性群組 (NSG) 和使用者定義的路由 (URD)。
虛擬網路和專用子網路
應用程式閘道是您虛擬網路中專用的部署。 在您的虛擬網路中，應用程式閘道需要專用子網路。 子網路中可以有多個特定應用程式閘道部署的執行個體。 您可以在子網路中部署其他應用程式閘道。 但您無法在應用程式閘道子網路中部署任何其他資源。 您無法在相同的子網路上混合使用 v1 和 v2 應用程式閘道 SKU。
注意
應用程式閘道子網路中目前不支援虛擬網路服務端點原則。
子網路的大小
應用程式閘道會針對每個執行個體使用一個私人 IP 位址，如果已設定私人前端 IP，則會再使用另一個私人 IP 位址。
Azure 也會在每個子網路中保留五個 IP 位址以供內部使用。 這是前四個位址和最後一個 IP 位址。 例如，假設有 15 個應用程式閘道執行個體，且沒有私人前端 IP。 此子網路至少需要 20 個 IP 位址。 您需要 5 個供內部使用，而應用程式閘道執行個體需要 15 個。
假設子網路有 27 個應用程式閘道執行個體，以及一個用於私人前端 IP 的 IP 位址。 在此情況下，您需要 33 個 IP 位址。 您需要 27 個用於應用程式閘道執行個體、1 個用於私人前端，而 5 個用於內部使用。
應用程式閘道 (標準或 WAF SKU) 最多可支援 32 個執行個體 (32 個執行個體 IP 位址 + 1 個私人前端 IP 設定 + 5 個 Azure 保留)。 我們建議使用的最低子網路大小為 /26。
應用程式閘道 (Standard_v2 或 WAF_v2 SKU) 最多可支援 125 個執行個體 (125 個執行個體 IP 位址 + 1 個私人前端 IP 組態 + 5 個 Azure 保留)。 我們建議使用的最低子網路大小為 /24。
若要判斷已佈建現有應用程式閘道的子網路可用容量，取得子網路大小，並減去平台所保留之子網路的五個保留 IP 位址。 接下來，取得每個閘道，並減去最大執行個體計數。 對於每個具有私人前端 IP 設定的閘道，減去每個閘道一個的更多 IP 位址。
例如，以下說明如何計算三個不同大小閘道的子網路可用位址：
- 網路閘道 1：最多 10 個執行個體。 使用私人前端 IP 設定。
- 網路閘道 2：最多 2 個執行個體。 沒有私人前端 IP 設定。
- 網路閘道 3：最多 15 個執行個體。 使用私人前端 IP 設定。
- 子網路大小：/24
- 子網大小 /24 = 256 個 IP 位址 - 平台保留的 5 個位址 = 251 個可用位址
- 251：網路閘道 1 (10) - 1 私人前端 IP 設定 = 240
- 240：網路閘道 2 (2) = 238
- 238：網路閘道 3 (15) - 1 私人前端 IP 設定 = 222
重要
雖然不是每個應用程式閘道 v2 SKU 部署都需要 /24 子網路，但我們強烈建議您這麼做。 A /24 子網路為了確保應用程式閘道 v2 有足夠的空間可自動調整擴充和維護升級。
您應該確定應用程式閘道 v2 子網路有足夠的位址空間，可容納處理最大預期流量所需的執行個體數目。 如果您指定執行個體計數上限，子網路至少應具有該數目位址的容量。 如需有關執行個體計數的容量規劃，請參閱執行個體計數詳細資料。
名為 GatewaySubnet 的子網路會保留給 VPN 閘道。 使用 GatewaySubnet 子網路的應用程式應用程式閘道 v1 資源必須移至不同的子網路，或在 2023 年 9 月 30 日之前移轉至 v2 SKU，以避免控制平面失敗和平台不一致。 如需變更現有應用程式閘道執行個體子網路的詳細資訊，請參閱有關應用程式閘道的常見問題。
提示
IP 位址會從閘道執行個體的已定義子網路空間的開頭配置。 由於執行個體會因為建立閘道或調整事件而建立和移除，所以很難了解子網路中的下一個可用位址。 若要判斷未來閘道要使用的下一個位址，並使前端 IP 有連續定址主題，請考慮從所定義子集空間的上半部指派前端 IP 位址。
例如，如果子網路位址空間是 10.5.5.0/24，請考慮從 10.5.5.254 開始設定閘道的私人前端 IP 設定，然後後面的閘道依次是 10.5.5.253、10.5.5.252、10.5.5.251 等等，以此類推。
您可以變更相同虛擬網路內現有應用程式閘道執行個體的子網路。 若要進行這項變更，請使用 Azure PowerShell 或 Azure CLI。 如需詳細資訊，請參閱應用程式閘道的常見問題集。
用於名稱解析的 DNS 伺服器
虛擬網路資源支援 DNS 伺服器組態，可讓您在 Azure 提供的預設或自訂 DNS 伺服器之間進行選擇。 應用程式閘道的執行個體也會接受此 DNS 設定，以進行任何名稱解析。 變更此設定之後，您必須重新啟動應用程式閘道 (停止並啟動)，這些變更才會對執行個體生效。
當 應用程式閘道 實例發出 DNS 查詢時，它會使用第一個回應的伺服器值。
注意
如果您在應用程式閘道虛擬網路中使用自訂 DNS 伺服器，DNS 伺服器必須能夠解析公用網際網路名稱。 應用程式閘道需要有這項功能。
虛擬網路權限
應用程式閘道 資源部署在虛擬網路內，因此也會執行檢查來驗證虛擬網路資源的許可權。 此驗證會在建立和管理作業期間執行，也適用於 應用程式閘道 輸入控制器的受控識別。
檢查您的 Azure 角色型存取控制 ，確認操作應用程式閘道的使用者和服務主體至少具有虛擬網路或子網的下列權限：
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
您可以使用內建角色，例如 已支援這些許可權的網路參與者。 如果內建角色未提供正確的權限，您可以建立並指派自訂角色。 深入了解管理子網路權限。
權限
視您要建立新資源或使用現有資源而定，請從下列清單中新增適當的許可權：
| 資源 | 資源狀態 | 必要的 Azure 權限 |
|---|---|---|
| 子網路 | 新建 | Microsoft.Network/virtualNetworks/subnets/write Microsoft.Network/virtualNetworks/subnets/join/action |
| 子網路 | 使用現有的 | Microsoft.Network/virtualNetworks/subnets/read Microsoft.Network/virtualNetworks/subnets/join/action |
| IP 位址 | 新建 | Microsoft.Network/publicIPAddresses/write Microsoft.Network/publicIPAddresses/join/action |
| IP 位址 | 使用現有的 | Microsoft.Network/publicIPAddresses/read Microsoft.Network/publicIPAddresses/join/action |
| ApplicationGatewayWebApplicationFirewallPolicies | 建立新的 /更新現有的 | Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/write Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/join/action |
如需詳細資訊，請參閱 網路 和 虛擬網路許可權的 Azure 許可權。
角色範圍
在自定義角色定義的過程中，您可以在四個層級指定角色指派範圍：管理群組、訂用帳戶、資源群組和資源。 若要授與存取權，您可以將角色指派給特定範圍的使用者、群組、服務主體或受控識別。 這些範圍會以父子式關聯性建構，每個階層層級都會讓範圍更明確。 您可以在這些範圍的任一層級指派角色，而您選取的層級會決定角色套用的程度。 例如，在訂用帳戶層級指派的角色可以串聯至該訂用帳戶內的所有資源，而在資源群組層級指派的角色只會套用至該特定群組內的資源。 深入瞭解範圍層級 如需詳細資訊，請參閱 範圍層級。
注意
在角色指派變更之後，您可能需要提供 Azure Resource Manager 快取重新整理足夠的時間。
識別您訂用帳戶上受影響的使用者或服務主體
藉由瀏覽您帳戶的 Azure Advisor，您可以確認您的訂用帳戶是否有任何使用者或服務主體權限不足。 該建議的詳細數據如下：
標題：更新應用程式閘道使用者的 VNet 權限
類別：可靠性
影響：高
使用暫時的 Azure 功能公開控制 (AFEC) 旗標
作為暫時擴充功能，我們引進了訂用帳戶層級 Azure 功能曝光控制 (AFEC)。 您可以註冊並使用 AFEC，直到您修正所有使用者和服務主體的權限為止。 遵循與 Azure 訂用帳戶的預覽功能註冊相同的步驟，即可註冊功能。
名稱：Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck
描述：停用應用程式應用程式閘道子網路權限檢查
ProviderNamespace：Microsoft.Network
EnrollmentType：AutoApprove
注意
我們建議您只使用 AFEC 佈建作為暫時緩和措施，直到您指派正確的權限為止。 您必須優先修正所有適用使用者的權限 (和服務主體)，然後取消註冊此 AFEC 旗標，以重新引入虛擬網路資源的權限驗證。 建議您不要永久依賴這個 AFEC 方法，因為未來將會移除。
Azure Virtual Network Manager
Azure Virtual Network Manager 是管理服務，可允許您跨訂用帳戶全域分組、設定、部署及管理虛擬網路。 使用 Virtual Network Manager，您可以定義網路群組，以識別並邏輯分割虛擬網路。 之後，您可以決定想要的連線能力及安全性設定，並同時套用至網路群組中所有選取的虛擬網路。
Azure Virtual Network Manager 中的安全性管理員規則設定可讓您大規模定義安全策略，並一次套用至多個虛擬網路。
網路安全性群組
您可以將 NSG 用於應用程式閘道子網路，但請注意一些關鍵點和限制。
重要
當您使用私人應用程式閘道部署 (預覽) 時，這些 NSG 限制會放寬。
必要的安全性規則
若要搭配應用程式閘道使用 NSG，您必須建立或保留一些基本的安全性規則。 您可以依相同順序設定其優先順序。
輸入規則
用戶端流量：允許來自預期用戶端的連入流量 (作為來源 IP 或 IP 範圍)，以及作為目的地作為應用程式閘道的整個子網路 IP 前綴和輸入存取埠。 例如，如果您已針對連接埠 80 和 443 設定接聽程式，則必須允許這些連接埠。 您也可以將此規則設定為 Any。
| 來源 | 來源連接埠 | Destination | 目的地連接埠 | 通訊協定 | Access |
|---|---|---|---|---|---|
<as per need> |
任意 | <Subnet IP Prefix> |
<listener ports> |
TCP | 允許 |
在您搭配相同連接埠號碼設定作用中的公共和和私人接聽程式 (具有規則) 後，您的應用程式閘道就會將所有輸入流程的目的地變更為閘道前端 IP。 即使未共用任何連接埠的接聽程式也會發生這項變更。 當您使用相同的連接埠組態時，必須在輸入規則的目的地中包含網路閘道的前端公用和私人 IP 位址。
| 來源 | 來源連接埠 | Destination | 目的地連接埠 | 通訊協定 | Access |
|---|---|---|---|---|---|
<as per need> |
任意 | <Public and Private frontend IPs> |
<listener ports> |
TCP | 允許 |
基礎結構連接埠：允許來自來源的連入要求作為 GatewayManager 服務標籤和任何目的地。 目的地連接埠範圍會根據 SKU 而有所不同，而且需要通訊後端健全狀態。 這些連接埠由 Azure 憑證驗證保護/鎖定。 若沒有適當的憑證，外部實體就無法在這些端點上起始變更。
- V2：連接埠 65200-65535
- V1：連接埠 65503-65534
| 來源 | 來源連接埠 | Destination | 目的地連接埠 | 通訊協定 | Access |
|---|---|---|---|---|---|
| GatewayManager | 任意 | 任意 | <as per SKU given above> |
TCP | 允許 |
Azure Load Balancer 探查：允許來自來源的連入流量作為 AzureLoadBalancer 服務標籤。 此規則預設會針對 NSG 建立。 您無法使用手動拒絕規則來覆寫，以確保應用程式閘道的順利作業。
| 來源 | 來源連接埠 | Destination | 目的地連接埠 | 通訊協定 | Access |
|---|---|---|---|---|---|
| AzureLoadBalancer | 任意 | 任意 | 任意 | 任意 | 允許 |
您可使用全部拒絕規則封鎖所有其他傳入流量。
輸出規則
網路輸出：允許所有目的地對網際網路的輸出流量。 此規則預設會針對 NSG 建立。 您無法使用手動拒絕規則來覆寫，以確保應用程式閘道的順利作業。 不得建立拒絕任何輸出連線的 NSG 輸出規則。
| 來源 | 來源連接埠 | Destination | 目的地連接埠 | 通訊協定 | Access |
|---|---|---|---|---|---|
| 任意 | 任意 | 網際網路 | 任意 | 任意 | 允許 |
注意
沒有 應用程式閘道啟用的網路隔離不允許在停用允許流向遠端虛擬網路的流量時，在對等互連 VNet 之間傳送流量。
支援的使用者定義路由
在公開預覽中，可以透過路由表規則對應用程式閘道子網路進行更細微的控制。 如需詳細資訊，請參閱私人應用程式閘道部署 (預覽)。
使用目前的功能時，有一些限制：
重要
在應用程式閘道子網路上使用 UDR 可能會導致後端健康情況檢視中的健全狀態顯示為 [未知]。 這也可能會導致應用程式閘道的記錄和計量產生失敗。 建議不要在應用程式閘道子網路上使用 UDR，以便檢視後端健康情況、記錄和計量。
v1：對於 v1 SKU，如果 UDR 未改變端對端要求/回應通訊，即可在應用程式閘道子網路上受到支援。 例如，您可以在應用程式閘道子網路中設定指向防火牆設備以進行封包檢查的 UDR。 但是，您必須確定封包在檢查之後可以到達其預定目的地。 若未這麼做，可能會導致不正確的健全狀態探查或流量路由行為。 也包括學習到的路由，或是 Azure ExpressRoute 或 VPN 閘道在虛擬網路中傳播的預設 0.0.0.0/0 路由。
v2：v2 SKU 支援和不支援的案例如下。
v2 支援的案例
警告
路由表的設定不正確可能會導致應用程式閘道 v2 中發生非對稱路由。 請確定所有管理/控制平面流量都會直接傳送至網際網路，而不是透過虛擬設備傳送。 記錄、計量和 CRL 檢查也可能受到影響。
案例 1：使用 UDR 停用對應用程式閘道子網路的邊界閘道協定 (BGP) 路由傳播
有時候，預設閘道路由 (0.0.0.0/0) 會透過與應用程式閘道虛擬網路相關聯的 ExpressRoute 或 VPN 閘道公告。 此行為會中斷管理平面流量，進而需要網際網路的直接路徑。 在這種情況下，您可使用 UDR 來停用 BGP 路由傳播。
若要停用 BGP 路由傳播：
- 在 Azure 中建立路由表資源。
- 停用虛擬網路閘道路由傳播參數。
- 將路由表與適當的子網路產生關聯。
為此案例啟用 UDR 應該不會中斷任何現有的設定。
案例 2：使用 UDR 將 0.0.0.0/0 導向至網際網路
您可以建立 UDR，直接將 0.0.0.0/0 流量傳送至網際網路。
案例 3：將 UDR 用於 Azure Kubernetes Service (AKS) 與 kubenet
如果您使用 kubenet 搭配 AKS 和應用程式閘道輸入控制器，您將需要路由表，才能允許從應用程式閘道傳送至 Pod 的流量路由至正確的節點。 如果您使用 Azure 容器網路介面，就不需要使用路由表。
若要使用路由表來允許 kubenet 運作：
前往 AKS 所建立的資源群組。 資源群組名稱應以
MC_為開頭。尋找該資源群組中 AKS 所建立的路由表。 路由表應該填入下列資訊：
- 位址前置詞應該是您想要在 AKS 中觸達的 Pod IP 範圍。
- 下一個躍點類型應該是虛擬設備。
- 下一個躍點位址應該是 Pod 裝載所在節點的 IP 位址。
將此路由表與應用程式閘道子網路產生關聯。
v2 不支援的案例
案例 1：虛擬設備 UDR
對於 v2 SKU，不支援任何必須透過任何虛擬裝置、中樞/輪輻虛擬網路或內部部署 (強制通道) 將 0.0.0.0/0 重新導向的情況。
其他服務
若要檢視其他服務的角色和許可權，請參閱下列連結：