共用方式為

針對 Azure NAT 閘道連線進行疑難排解

  • 發行項

本文提供如何疑難排解及解決 NAT 閘道常見輸出連線問題的指引。 本文也提供了設計應用程式的最佳做法，讓您能以有效率的方式使用輸出連線。

由於連線失敗 NAT 閘道上的資料路徑可用性下降

案例

您觀察到 NAT 閘道的資料路徑可用性下降，這與連線失敗一致。

可能的原因

  • 來源網路位址轉譯 (SNAT) 連接埠耗盡。

  • 同時 SNAT 連線限制。

  • 連線逾時。

疑難排解步驟

SNAT 連接埠耗盡或達到同時連線限制的可能解決方案

  • 將公用 IP 位址新增至 NAT 閘道，總共最多 16 個，以調整輸出連線能力。 每個公用 IP 提供 64,512 個 SNAT 連接埠埠，並支援 NAT 閘道的每個唯一目的地端點最多 50,000 個同時連線。

  • 將您的應用程式環境分散於多個子網路，並為每個子網路提供 NAT 閘道資源。

  • 將 TCP 閒置逾時計時器減少至較低的值，以釋出 SNAT 連接埠庫存。 TCP 閒置逾時計時器無法設定低於 4 分鐘。

  • 考慮使用非同步輪詢模式以釋出連線資源供其他作業使用。

  • 使用 Private Link，透過 Azure 骨幹連線到 Azure PaaS 服務。 私人連結會釋出 SNAT 連接埠，以進行網際網路的輸出連線。

  • 如果您的調查沒有明確結果，請開啟支援案例以進一步疑難排解。

注意

請務必了解發生 SNAT 連接埠耗盡的原因。 確定您將正確的模式用於可調整且可靠的案例。 在不了解需求原因的情況下，將更多 SNAT 連接埠新增至案例，應該是最後的手段。 如果您不了解為何案例會對 SNAT 連接埠庫存造成壓力，藉由增加更多 IP 位址來新增更多 SNAT 連接埠，只會在您的應用程式調整規模時，延遲相同耗盡失敗的發生。 您可能會遮掩其他效率不佳情形和反模式。 如需詳細資訊，請參閱有效使用輸出連線的最佳做法。

TCP 連線逾時的可能解決方案

使用 TCP Keepalive 或應用程式層 Keepalive，重新整理閒置流程和重設閒置逾時計時器。 如需範例，請參閱 .NET 範例。

TCP Keepalive 僅需從連線一段啟用，即可讓兩端的連線保持運作。 TCP Keepalive 從連線一端傳送時，另一端會自動傳送認可 (ACK) 封包。 然後，閒置逾時計時器會在連線的兩端重設。

注意

增加 TCP 閒置逾時是最後手段，而且可能無法解決問題的根本原因。 長逾時可能會在逾時到期時引進延遲和低速率失敗。

使用者資料包通訊協定 (UDP) 連線逾時的可能解決方案

UDP 閒置逾時計時器會設為 4 分鐘且無法設定。 針對連線流程中的兩個方向啟用 UDP Keepalive，以維持長時間連線。 UDP Keepalive 啟用時，連線中只有一個方向作用中。 連線仍可能在連線的另一端閒置和逾時。 若要防止 UDP 連線閒置逾時，應該針對連線流程中的雙向啟用 UDP Keepalive。

應用程式層 Keepalive 也可用來重新整理閒置流程和重設閒置逾時。 請檢查伺服器端以了解應用程式特定存留有哪些選項存在。

NAT 閘道上的資料路徑可用性下降，但沒有連線失敗

案例

NAT 閘道的資料路徑可用性下降，但觀察到沒有失敗的連線。

可能的原因

資料路徑可用性中的暫時性下降是由資料路徑中的雜訊所造成。

疑難排解步驟

如果您注意到資料路徑可用性下降，而不會影響到輸出連線，可能是因為 NAT 閘道在資料路徑中收到暫時性雜訊。

設定資料路徑可用性下降的警示，或使用 Azure 資源健康狀態來警示 NAT 閘道健康情況事件。

網際網路沒有輸出連線能力

案例

您觀察到 NAT 閘道上沒有輸出連線。

可能的原因

  • NAT 閘道設定錯誤。

  • 網際網路流量從 NAT 閘道重新導向，並使用 VPN 或 ExpressRoute 強制透過通道流向虛擬設備或內部部署目的地。

  • 設定了封鎖網際網路流量的網路安全性群組 (NSG) 規則。

  • NAT 閘道資料路徑可用性已降級。

  • 網域名稱系統 (DNS) 設定錯誤。

疑難排解步驟

  • 檢查 NAT 閘道是否已設定為至少有一個公用 IP 位址或前置詞，並連結至子網路。 在連結公用 IP 和子網路之前，NAT 閘道無法操作。 如需詳細資訊，請參閱 NAT 閘道設定基本概念。

  • 檢查連結至 NAT 閘道的子網路路由表。 任何強制透過通道流向網路虛擬設備 (NVA)、ExpressRoute 或 VPN 閘道的 0.0.0.0/0 流量，都會優先於 NAT 閘道。 如需詳細資訊，請參閱 Azure 如何選取路由。

  • 檢查虛擬機器上是否有針對網路介面設定的任何 NSG 規則，以封鎖網際網路存取。

  • 檢查 NAT 閘道的資料路徑可用性是否處於降級狀態。 如果 NAT 閘道處於降級狀態，請參閱連線失敗疑難排解指引。

  • 如果 DNS 未正確解析，請檢查您的 DNS 設定。

遺失輸出連線的可能解決方案

  • 將公用 IP 位址或前置詞附加至 NAT 閘道。 亦請確定 NAT 閘道已連結至來自相同虛擬網路的子網路。 驗證 NAT 閘道是否可以對外連線。

  • 請先仔細考慮您的流量路由需求，再對虛擬網路的流量路由進行任何變更。 將 0.0.0.0/0 流量傳送至虛擬設備或虛擬網路閘道的使用者定義路由 (UDR) 會覆寫 NAT 閘道。 若要深入了解自訂路由如何影響網路流量的路由，請參閱自訂路由。

    若要探索在子網路路由表上更新流量路由的選項，請參閱：

  • 更新 NSG 安全性規則，以封鎖透過網際網路存取您的任何 VM。 如需詳細資訊，請參閱管理網路安全性群組。

  • DNS 無法正確解析的原因有很多。 請參閱 DNS 疑難排解指南，以協助調查 DNS 解析失敗的原因。

未使用 NAT 閘道公用 IP 對外連線

案例

NAT 閘道部署在 Azure 虛擬網路中，但非預期的 IP 位址用於對外連線。

可能的原因

  • NAT 閘道設定錯誤。

  • 使用另一個 Azure 輸出連線方法的作用中連線，例如虛擬機器上的 Azure Load Balancer 或執行個體層級公用 IP。 作用中連線流程會繼續使用先前建立連線時指派的公用 IP 位址。 部署 NAT 閘道後，新的連線會立即開始使用 NAT 閘道。

  • 私人 IP 用來透過服務端點或 Private Link 連線到 Azure 服務。

  • 儲存體帳戶的連線來自與您從中建立虛擬機器連線的同一區域。

  • 網際網路流量正在從 NAT 閘道重新導向，並強制透過通道流向 NVA 或防火牆。

如何進行疑難排解

  • 檢查您的 NAT 閘道是否具有至少一個公用 IP 位址或相關聯的前置詞，以及至少一個子網路。

  • 驗證是否有任何先前的輸出連線方法，例如公用負載平衡器，在部署 NAT 閘道之後仍處於作用中狀態。

  • 檢查與其他 Azure 服務的連線是否來自 Azure 虛擬網路中的私人 IP 位址。

  • 檢查您是否已啟用 Private Link 或服務端點，以連線到其他 Azure 服務。

  • 確定您的虛擬機器位於建立儲存體連線時 Azure 儲存體所在的同一區域。

  • 驗證用於連線的公用 IP 位址是否源自 Azure 虛擬網路內的另一個 Azure 服務，例如網路虛擬設備 (NVA)。

未使用 NAT 閘道公用 IP 對外連線的可能解決方案

  • 將公用 IP 位址或前置詞附加至 NAT 閘道。 確定 NAT 閘道已連結至來自相同虛擬網路的子網路。 驗證 NAT 閘道是否可以對外連線。

  • 測試並解決 VM 保存舊 SNAT IP 位址 (來自另一個輸出連線方法) 的問題，方法為：

    • 確定您建立新的連線，且現有的連線不會在 OS 中重複使用，或瀏覽器正在快取連線而重複使用。 例如，在 PowerShell 中使用 curl 時，請務必指定 -DisableKeepalive 參數來強制執行新的連線。 如果您使用的是瀏覽器，也可以將連線集區化。

    • 不需要在設定為 NAT 閘道的子網路中重新啟動虛擬機器。 不過，如果重新啟動虛擬機器，則連線狀態會是已排清。 將連線狀態排清後，所有連線都會開始使用 NAT 閘道資源的一個或多個 IP 位址。 此行為是重新啟動虛擬機器的副作用，不是需要重新啟動的指標。

    • 如果您仍然遇到問題，請開啟支援案例以取得進一步的疑難排解。

  • 將 0.0.0.0/0 流量導向至 NVA 的自訂路由優先於 NAT 閘道，以將流量路由傳送至網際網路。 若要讓 NAT 閘道將流量路由傳送至網際網路，而不是 NVA，請為移至虛擬設備的 0.0.0.0/0 流量移除自訂路由。 0.0.0.0/0 流量會繼續使用網際網路的預設路由，並改用 NAT 閘道。

重要

在對流量路由方式進行任何變更之前，請仔細考慮雲端架構的路由需求。

  • 與 Azure 儲存體帳戶部署在相同區域中的服務會使用私人 Azure IP 位址進行通訊。 您無法根據其公用輸出 IP 位址範圍來限制對特定 Azure 服務的存取。 如需詳細資訊，請參閱 IP 網路規則的限制。
  • Private Link 和服務端點會使用虛擬網路中虛擬機器執行個體的私人 IP 位址，而不是 NAT 閘道的公用 IP，連線到 Azure 平台服務。 使用 Azure Private Link，透過 Azure 骨幹 (而不是透過網際網路搭配 NAT 閘道) 連線到其他 Azure 服務。

注意

Private Link 是私人存取 Azure 託管服務的服務端點所建議的選項。

公用網際網路目的地的連線失敗

案例

網際網路目的地的 NAT 閘道連線失敗或逾時。

可能的原因

  • 目的地的防火牆或其他流量管理元件。

  • 目的地端加諸的 API 速率限制。

  • 大量 DDoS 緩和措施或傳輸層流量成形。

  • 目的地端點以片段化的封包回應。

如何進行疑難排解

  • 驗證相同區域或其他位置中端點的連線能力，以進行比較。

  • 從來源和目的地端進行封包擷取。

  • 查看來源和目的地 (如果有的話) 的封包計數，以判斷所進行的連線嘗試次數。

  • 查看已卸除的封包，以查看 NAT 閘道已卸除的封包數目。

  • 分析封包。 具有片段化 IP 通訊協定封包的 TCP 封包表示 IP 片段。 NAT 閘道不支援 IP 片段，因此與片段化封包的連線會失敗。

  • 確定 NAT 閘道公用 IP 在具有防火牆或其他流量管理元件的合作夥伴目的地中列為允許。

網際網路目的地連線失敗的可能解決方案

  • 驗證 NAT 閘道公用 IP 是否已在目的地中列為允許。

  • 如果您要建立大量或交易速率測試，請探索降低速率是否可減少發生失敗的情況。

  • 如果降低連線速率會減少失敗發生的次數，請檢查目的地是否已達到其 API 速率限制或其他條件約束。

主動或被動模式的 FTP 伺服器連線失敗

案例

搭配主動或被動 FTP 模式使用 NAT 閘道時，您在 FTP 伺服器看到連線失敗。

可能的原因

  • 主動 FTP 模式已啟用。

  • 被動 FTP 模式已啟用，且 NAT 閘道正在使用多個公用 IP 位址。

主動 FTP 模式的可能解決方案

FTP 會在用戶端與伺服器之間使用兩個不同的通道：命令和資料通道。 每個通道都會在個別的 TCP 連線上通訊，一個用於傳送命令，另一個用於傳輸資料。

在主動 FTP 模式中，用戶端會建立命令通道，而伺服器則會建立資料通道。

NAT 閘道與主動 FTP 模式不相容，。 主動 FTP 會從 FTP 用戶端使用 PORT 命令，告訴 FTP 伺服器要用於資料通道的伺服器 IP 位址和連接埠，以連回用戶端。 PORT 命令會使用無法變更的用戶端私人位址。 用戶端流量透過 NAT 閘道執行 SNAT，以進行網際網路型通訊，因此 FTP 伺服器會將 PORT 命令視為無效。

主動 FTP 模式的替代解決方案是改用被動 FTP 模式。 不過，若要在被動 FTP 模式中使用 NAT 閘道，必須做出一些考量。

被動 FTP 模式的可能解決方案

在被動 FTP 模式中，用戶端會同時在命令和資料通道上建立連線。 用戶端要求伺服器在連接埠上回應，而不是嘗試建立回到用戶端的連線。

輸出被動 FTP 不適用於具有多個公用 IP 位址的 NAT 閘道，取決於您的 FTP 伺服器設定。 當具有多個公用 IP 位址的 NAT 閘道傳送流量輸出時，會為來源 IP 位址隨機選取其中一個公用 IP 位址。 當資料和控制通道使用不同的來源 IP 位址時，FTP 會失敗，取決於您的 FTP 伺服器設定。

若要防止可能的被動 FTP 連線失敗，請執行下列步驟：

  1. 檢查 NAT 閘道是否已連結至單一公用 IP 位址，而不是多個 IP 位址或前置詞。

  2. 確定允許來自 NAT 閘道的被動連接埠範圍，以通過位於目的地端點的任何防火牆。

注意

減少 NAT 閘道上的公用 IP 位址數量，即會減少可用於進行輸出連線的 SNAT 連接埠庫存，並可能會增加 SNAT 連接埠耗盡的風險。 從 NAT 閘道移除公用 IP 位址之前，請考慮您的 SNAT 連線需求。 不建議變更 FTP 伺服器設定，以接受來自不同來源 IP 位址的控制和資料平面流量。

連接埠 25 上的輸出連線遭到封鎖

案例

無法在連接埠 25 上與 NAT 閘道進行輸出連線，以取得簡易郵件傳輸通訊協定 (SMTP) 流量。

原因

Azure 平台會針對已部署的 VM，封鎖 TCP 通訊埠 25 上的輸出 SMTP 連線。 此封鎖是要確保 Microsoft 合作夥伴和客戶有更好的安全性、保護 Microsoft 的 Azure 平台，以及符合業界標準。

使用已驗證的 SMTP 轉送服務，從 Azure VM 或 Azure App Service 傳送電子郵件。 如需詳細資訊，請參閱針對輸出 SMTP 連線問題進行疑難排解。

更多疑難排解指引

額外的網路擷取

如果您的調查不具包容性，請開啟支援案例進一步疑難排解，並收集下列資訊以獲得更快速的解決方案。 選擇 NAT 閘道所設定子網路中的單一虛擬機器，並執行下列測試：

  • 從虛擬網路內的其中一部後端 VM 中使用 ps ping 來測試探查連接埠回應，並記錄結果 (範例：ps ping 10.0.0.4:3389)。

  • 如果這些 ping 測試沒有收到任何回應，請在執行 PsPing 時，同時在後端虛擬機器和虛擬網路測試虛擬機器上執行 netsh 追蹤，然後停止 netsh 追蹤。

輸出連線最佳做法

Azure 會非常小心地監視並操作其基礎結構。 不過，已部署的應用程式仍可能會發生暫時性失敗，而且不保證傳輸不失真。 NAT 閘道是偏好的選項，用於從 Azure 部署建立高度可靠且具有復原性的輸出連線。 如需最佳化應用程式連線效率，請參閱本文稍後的指引。

使用連接共用

當您共用連線時，請避免開啟新的網路連線呼叫同一組位址和連接埠。 您可以在應用程式中實作連線共用配置，此時要求會在內部分配到一組固定的連線，並盡可能地重複使用。 此設定會限制使用中的 SNAT 連接埠數目，建立可預測的環境。 連線共用有助於降低延遲和資源使用率，最終可改善應用程式的效能。

若要深入了解共用 HTTP 連線，請參閱使用 HttpClientFactory 共用 HTTP 連線。

重複使用連線

請設定應用程式重複使用連線，而不是為每個要求產生個別且不可部分完成的 TCP 連線。 連線重複使用會產生效能更高的 TCP 交易，且對於 HTTP/1.1 之類的通訊協定格外重要 (因為依預設會重複使用連線)。 這種重複使用適用於以 HTTP 作為傳輸方式的其他通訊協定，例如 REST。

使用較不積極的重試邏輯

當 SNAT 連接埠耗盡或發生應用程式失敗時，不含衰減和降速邏輯的積極或暴力重試會造成耗盡的情況發生或持續存在。 您可以使用較不積極的重試邏輯，以降低對 SNAT 連接埠的需求。

根據設定的閒置逾時，如果重試頻率太高，連線沒有足夠的時間關閉並釋出 SNAT 連接埠以供重複使用。

如需額外指引和範例，請參閱重試模式。

使用 Keepalive 來重設輸出閒置逾時

如需 Keepalive 的詳細資訊，請參閱 TCP 閒置逾時。

如可能，建議使用 Private Link 直接從虛擬網路連線到 Azure 平台服務，以減少 SNAT 連接埠的需求。 降低 SNAT 連接埠的需求有助於降低 SNAT 連接埠耗盡的風險。

若要建立 Private Link，請參閱下列快速入門指南以開始使用：

下一步

我們一直努力提升客戶體驗。 如果您遇到本文未提及或解決的 NAT 閘道問題，請透過此頁面底部的 GitHub 提供意見反應。

深入了解 NAT 閘道計量，請參閱：