App Service 環境的網路考量
重要
本文說明隔離式 App Service 方案搭配使用的 App Service 環境 v2 相關資訊。 App Service 環境 v1 和 v2 自 2024 年 8 月 31 日起已淘汰 (英文)。 有較新版本的 App Service 環境，其更易於使用，並且是在更強大的基礎結構上執行。 若要深入了解新版本，請從 App Service 環境簡介開始。 如果您目前使用 App Service 環境 v1，請遵循此文章中的步驟來移轉至新版本。
自 2024 年 8 月 31 日起，服務等級協定 (SLA) 和服務點數 (英文) 將不再適用於繼續在生產環境中的 App Service 環境 v1 和 v2 工作負載，因為其是已淘汰的產品。 App Service 環境 v1 和 v2 硬體的解除委任已經開始，而這可能會影響您的應用程式和資料的可用性和效能。
您必須立即完成移轉至 App Service 環境 v3，否則您的應用程式和資源可能會遭到刪除。 我們會嘗試使用就地移轉功能，自動移轉任何剩餘的 App Service Environment v1 和 v2，但 Microsoft 並未就自動移轉後的相關應用程式可用性提供聲明或保證。 您可能需要執行手動設定來完成移轉，並最佳化您的 App Service 方案 SKU 選擇，以符合您的需求。 如果自動移轉不可行，您的資源和相關聯的應用程式資料將遭到刪除。 我們強烈敦促您立即採取行動，以避免上述任一極端案例。
如果您需要額外的時間，我們可以提供一次性 30 天的寬限期，讓您完成移轉。 如需詳細資訊和申請寬限期，請檢閱寬限期概觀 (英文)，然後移至 Azure 入口網站，造訪每個 App Service 環境的窗格。
如需 App Service 環境 v1/v2 淘汰的最新資訊，請參閱 App Service 環境 v1 和 v2 淘汰更新。
App Service 環境是指將 Azure App Service 部署至您 Azure 虛擬網路中的子網路。 App Service Environment 有兩種部署類型：
- 外部：這種類型的部署會使用網際網路上可存取的 IP 位址來公開裝載的應用程式。 如需詳細資訊，請參閱建立外部 App Service Environment。
- 內部負載平衡器：這種類型的部署會在虛擬網路內的 IP 位址上公開裝載的應用程式。 內部端點是內部負載平衡器。 如需詳細資訊，請參閱建立及使用內部負載平衡器 App Service 環境。
注意
本文是關於與隔離式 App Service 方案搭配使用的 App Service 環境 v2。
不論部署類型為何，所有的 App Service 環境都具有公用虛擬 IP (VIP)。 此 VIP 用於輸入管理流量，並作為您從 App Service 環境向網際網路進行呼叫時的位址。 這類呼叫會透過指派給 App Service 環境的 VIP 離開虛擬網路。
如果應用程式呼叫位於虛擬網路中或跨 VPN 的資源，則來源 IP 就會是子網路中的其中一個 IP。 由於 App Service 環境位於虛擬網路內，因此也可以存取虛擬網路內的資源，而不需要其他任何設定。 如果虛擬網路連線至您的內部部署網路，應用程式也擁有該處資源的存取權，不需其他設定。
如果您有具備外部部署的 App Service 環境，公用 VIP 也是應用程式針對下列項目解析的端點：
- HTTP/S
- FTP/S
- Web 部署
- 遠端偵錯
如果您有具備內部負載平衡器部署的 App Service 環境，內部位址的位址是 HTTP/S、FTP/S、Web 部署和遠端偵錯的端點。
子網路大小
部署 App Service 環境之後，您無法改變用來裝載它的子網路大小。 App Service 環境會針對每個基礎結構角色以及每個隔離的 App Service 方案執行個體使用一個位址。 此外，Azure 網路功能會針對所建立的每個子網路使用五個位址。
完全沒有 App Service 方案的 App Service 環境會在您建立應用程式之前使用 12 個位址。 如果您使用內部負載平衡器部署，則會在建立應用程式之前使用 13 個位址。 在您擴增時請注意，您的 App Service 方案執行個體在每 15 和 20 的倍數時便會新增基礎結構角色。
重要
除了 App Service 環境以外，其他項目都不能存在於子網路中。 請務必選擇預留未來成長空間的位址空間。 您之後無法變更此設定。 我們建議使用包含 256 個位址的 /24 大小。
當您擴大或縮小時，即會新增適當大小的新角色，然後將您的工作負載從目前大小移轉為目標大小。 只有在工作負載移轉之後，才會移除原始 VM。 例如，如果您有一個具有 100 個 App Service 方案執行個體的 App Service 環境，則您會有一段時間需要兩倍的 VM 數目。
輸入和輸出相依性
下列各節涵蓋需留意的 App Service 環境相依性。 另一節會探討 DNS 設定。
輸入相依性
為了讓 App Service 環境運作，必須開啟下列連接埠：
| 使用 | 從 | 至 |
|---|---|---|
| 管理 | App Service 管理位址 | App Service 環境子網路：454、455 |
| App Service 環境內部通訊 | App Service 環境子網路：所有連接埠 | App Service 環境子網路：所有連接埠 |
| 允許 Azure Load Balancer 輸入 | Azure Load Balancer | App Service 環境子網路：16001 |
連接埠 7564 和 1221 可以在連接埠掃描中顯示為開啟。 這些連接埠只會以 IP 位址回覆。 您可以自行封鎖這些連接埠。
除了系統監視之外，連入管理流量也提供 App Service 環境的命令與控制。 此流量的來源位址列於 App Service 環境管理位址中。 網路安全性設定必須在連接埠 454 和 455 上允許來自 App Service 環境管理位址的存取。 如果您封鎖來自那些位址的存取，則您的 Azure App Service 環境將變成狀況不良，然後便會遭到暫止。 在連接埠 454 與 455 傳入的 TCP 流量必須從相同的 VIP 返回，否則會發生非對稱式路由的問題。
子網路中有許多用於內部元件通訊的連接埠，您可以變更這些連接埠。 這會需要子網路中所有的連接埠都能從子網路存取。
您至少須開啟連接埠 454、455 和 16001，才能在 Azure Load Balancer 與 App Service 環境子網路之間進行通訊。 如果您使用內部負載平衡器部署，則可以將流量鎖定在 454、455、16001 連接埠。 如果您使用外部部署，則需要考慮一般應用程式存取連接埠。 具體而言，這些是：
| 使用 | 連接埠 |
|---|---|
| HTTP/HTTPS | 80、443 |
| FTP/FTPS | 21、990、10001-10020 |
| Visual Studio 遠端偵錯 | 4020、4022、4024 |
| Web Deploy 服務 | 8172 |
如果您封鎖應用程式連接埠，您的 App Service 環境仍然可以運作，但您的應用程式則可能無法運作。 如果您對於外部部署使用應用程式指派的 IP 位址，則需要允許將來自指派給應用程式之 IP 的流量傳送至子網路。 從 App Service 環境入口網站，移至 [IP 位址]，並查看您需要允許流量的連接埠。
輸出相依性
對於輸出存取，App Service 環境取決於多個外部系統。 那些系統相依性中有許多都會以 DNS 名稱定義，且不會對應至一組固定的 IP 位址。 因此，App Service 環境需要跨越各種連接埠，從子網路至所有外部 IP 的輸出存取。
App Service 環境會與下列連接埠上的網際網路可存取位址進行通訊：
| 使用 | 連接埠 |
|---|---|
| DNS | 53 |
| NTP | 123 |
| CRL、Windows 更新、Linux 相依性、Azure 服務 | 80/443 |
| Azure SQL | 1433 |
| 監視 | 12000 |
鎖定 App Service 環境一文中表列了輸出相依性。 如果 App Service 環境失去對其相依性的存取，就會停止運作。 發生的時間夠長時，就會遭到暫止。
客戶 DNS
如果已經使用客戶定義的 DNS 伺服器設定虛擬網路，租用戶工作負載就會使用該虛擬網路。 App Service 環境會針對管理用途使用 Azure DNS。 如果虛擬網路使用客戶選取的 DNS 伺服器進行設定，則 DNS 伺服器必須能夠從子網路進行連線。
注意
App Service 環境 v2 中的儲存體掛接或容器映像提取無法在虛擬網路中使用客戶定義的 DNS，也無法透過 WEBSITE_DNS_SERVER 應用程式來設定。
若要從 Web 應用程式測試 DNS 解析，可以使用主控台命令 nameresolver。 移至應用程式 scm 網站中的偵錯視窗，或移至入口網站中的應用程式，然後選取主控台。 從殼層提示字元中，可以發出命令 nameresolver，以及您想要查閱的 DNS 名稱。 您取得的結果會與您應用程式在進行相同查閱時所取得的結果一樣。 如果使用 nslookup，便可以改用 Azure DNS 進行查閱。
如果您對於 App Service 環境所在的虛擬網路變更 DNS 設定，就必須重新啟動。 為了避免重新開機，最好先設定虛擬網路的 DNS 設定，再建立 App Service 環境。
入口網站相依性
除了上一節所述的相依性之外，您也應該注意一些與入口網站體驗相關的額外考量。 Azure 入口網站的部分功能需要能夠直接存取原始檔控制管理員 (SCM) 網站。 Azure App Service 中的每個應用程式都有兩個 URL。 第一個 URL 是用來存取您的應用程式。 第二個 URL 則是用來存取 SCM 網站，也稱為「Kudu 主控台」。 使用 SCM 網站的功能包括：
- Web 工作
- 函式
- 記錄串流
- Kudu
- 擴充
- 處理序總管
- 主控台
使用內部負載平衡器時，無法從虛擬網路外部存取 SCM 網站。 某些功能無法從應用程式入口網站執行，因為它們需要存取應用程式的 SCM 網站。 您可以直接連線到 SCM 網站，而非透過入口網站。
如果您的內部負載平衡器是網域名稱 contoso.appserviceenvironment.net，而您的應用程式名稱是 testapp，便可透過 testapp.contoso.appserviceenvironment.net 連至應用程式。 與其搭配的 SCM 網站則可以透過 testapp.scm.contoso.appserviceenvironment.net 連線。
IP 位址
App Service 環境有一些需要注意的 IP 位址。 畫面如下：
- 公用輸入 IP 位址：用於外部部署中的應用程式流量，以及內部和外部部署中的管理流量。
- 輸出公用 IP：作為離開虛擬網路的輸出連線所用的「來源」IP。 這些連線不會透過 VPN 路由傳送。
- 內部負載平衡器 IP 位址：此位址只存在於內部部署中。
- 應用程式指派的 IP 型 TLS/SSL 位址：只有在外部部署，以及設定 IP 型 TLS/SSL 繫結時，才可以使用這些位址。
所有這些 IP 位址都可以在 Azure 入口網站中，從 App Service 環境 UI 中看到。 如果您有內部部署，則會列出內部負載平衡器的 IP。
注意
只要您的 App Service 環境正在執行，這些 IP 位址就不會變更。 如果您的 App Service 環境遭到暫止並在之後還原，則所使用的位址將會變更。 暫止的一般原因是您封鎖連入管理存取，或封鎖對相依性的存取。
應用程式指派的 IP 位址
在外部部署的情況下，您可以將 IP 位址指派給個別的應用程式。 您無法使用內部部署來執行此動作。 如需如何將應用程式設定為具有本身 IP 位址的詳細資訊，請參閱在 Azure App Service 中使用 TLS/SSL 繫結保護自訂的 DNS 名稱。
應用程式有自己的 IP 型 SSL 位址時，App Service 環境會保留兩個連接埠以對應至該 IP 位址。 一個連接埠供 HTTP 流量使用，另一個連接埠則供 HTTPS 使用。 這些連接埠會列在您 App Service 環境入口網站的 [IP 位址] 區段中。 流量必須能夠從 VIP 連至那些連接埠。 否則會無法存取應用程式。 在您設定網路安全性群組 (NSG) 時，請務必記住這項重要需求。
網路安全性群組
NSG 提供控制虛擬網路內網路存取的功能。 使用入口網站時，會有一個會拒絕一切內容的最低優先順序隱含「拒絕規則」。 您所建立的是您的「允許規則」。
您無法存取用來裝載 App Service 環境本身的 VM。 這些 VM 位於 Microsoft 管理的訂閱中。 如要限制對應用程式的存取，請在子網路上設定 NSG。 在這樣做時，請特別注意相依性。 如果您封鎖任何相依性，App Service 環境會停止運作。
您可以透過 Azure 入口網站或 PowerShell 設定 NSG。 這裡的資訊僅針對 Azure 入口網站說明。 您會在入口網站中的 [網路] 底下，以最上層資源的形式建立及管理 NSG。
NSG 中的必要項目是允許流量：
連入
- 連接埠 454、455 上來自 IP 服務標籤
AppServiceManagement的 TCP - 連接埠 16001 上來自負載平衡器的 TCP
- 全部連接埠上從 App Service 環境子網路到 App Service 環境子網路
輸出
- 連接埠 53 上 UDP 到所有 IP
- 連接埠 123 上 UDP 到所有 IP
- 連接埠 80、443 上 TCP 至所有 IP
- 連接埠 1433 上 TCP 至 IP 服務標籤
Sql - 連接埠 12000 上 TCP 至全部 IP
- 所有連接埠上至 App Service 環境子網路
這些連接埠不包含讓您的應用程式順利使用所需的連接埠。 例如，假設您的應用程式需要在連接埠 3306 上呼叫 MySQL 伺服器。 連接埠 123 上的網路時間通訊協定 (NTP) 是作業系統所使用的預設時間同步通訊協定。 NTP 端點並非專屬於 App Service，可能依作業系統而有所不同，而且不在定義完整的位址清單中。 若要防止時間同步處理問題，您必須允許連接埠 123 上 UDP 至全部位址的流量。 輸出 TCP 到連接埠 12000 的流量適用於系統支援和分析。 端點是動態的，而且不在定義完整的位址集中。
一般的應用程式存取連接埠為：
| 使用 | 連接埠 |
|---|---|
| HTTP/HTTPS | 80、443 |
| FTP/FTPS | 21、990、10001-10020 |
| Visual Studio 遠端偵錯 | 4020、4022、4024 |
| Web Deploy 服務 | 8172 |
預設規則可讓虛擬網路中的 IP 與子網路進行通訊。 另一個預設規則可讓負載平衡器 (也稱為公用 VIP) 和 App Service 環境進行通訊。 您可以選取新增圖示旁的 [預設規則] 來查看預設規則。
如果您在預設規則之前加入「拒絕其他任何內容」規則，便可以防止 VIP 和 App Service 環境之間的流量。 若要防止來自虛擬網路內部的流量，請新增您自己的規則來允許輸入。 使用等於 AzureLoadBalancer 的來源，而且目的地是 Any，連接埠範圍是 *。 由於 NSG 規則是套用至子網路，因此不需要具體指定目的地。
如果指派 IP 位址給應用程式，請確定維持開啟連接埠。 若要查看連接埠，請選取 [App Service Environment]>[IP 位址]。
定義 NSG 之後，請將其指派給子網路。 如果您不記得虛擬網路或子網路，您可以在 App Service 環境入口網站看到。 若要將 NSG 指派給子網路，請移至子網路 UI 並選取 NSG。
路由
強制通道是指您在虛擬網路中設定路由，讓輸出流量不會直接進入網際網路。 流量會改而轉向其他位置，例如 Azure ExpressRoute 閘道或虛擬裝置。 如果需要以此方式設定 App Service 環境，請參閱使用強制通道設定 App Service 環境。
當您在入口網站中建立 App Service 環境時，子網路上會自動建立一組路由表。 這些路由只單純指示直接將輸出流量傳送至網際網路。
若要手動建立路由，請依照下列步驟執行︰
前往 Azure 入口網站，並選取 [網路]>[路由表]。
在和虛擬網路相同的區域內建立一個新的路由表。
從您的路由表 UI 內，選取 [路由]>[新增]。
將 [下一個躍點類型] 設為 [網際網路]，將 [位址首碼] 設為 0.0.0.0/0。 選取 [儲存]。
您就會看到類似以下的畫面：
建立新的路由表之後，請移至子網路。 從在入口網站取得的清單中選取您的路由表。 儲存變更之後，應該就會看見 NSG 和路由已註明了您的子網路。
服務端點
服務端點可讓您將多租用戶服務的存取權限制於一組 Azure 虛擬網路和子網路。 如需詳細資訊，請參閱虛擬網路服務端點。
當您在資源上啟用服務端點時，所建立的路由具有高於所有其他路由的優先順序。 如果您在任何 Azure 服務上使用服務端點搭配強制通道 App Service 環境，則這些服務的流量不會遭到強制傳輸。
當服務端點透過 Azure SQL 的執行個體在子網路上啟用時，與該子網路連線的所有 Azure SQL 執行個體，都必須啟用服務端點。 如果您想要從相同的子網路存取多個 Azure SQL 執行個體，您就不能在一個 Azure SQL 執行個體上啟用服務端點，並且也不能在另一個執行個體上啟用。 就服務端點來說，其他 Azure 服務的行為皆與 Azure SQL 不同。 在您啟用 Azure 儲存體的服務端點時，便是鎖定子網路至該資源的存取。 但即使尚未啟用其他 Azure 儲存體帳戶的服務端點，您仍然可以存取該帳戶。
