共用方式為

如何驗證傳輸到虛擬網路的 VPN 輸送量

  • 發行項

VPN 閘道連線可讓您在 Azure 內的虛擬網路和內部部署 IT 基礎結構之間建立安全的跨單位連線。

本文章說明如何驗證從內部部署資源到 Azure 虛擬機器 (VM) 的網路輸送量。

注意

本文章旨在協助診斷和修正常見的問題。 如果您在使用下列資訊後仍無法解決問題，請連絡支援人員。

概觀

VPN 閘道連線涉及下列元件：

  • 內部部署 VPN 裝置 (檢視已驗證 VPN 裝置的清單)。
  • 公用網際網路
  • Azure VPN 閘道
  • Azure VM

下圖顯示內部部署網路透過 VPN 到 Azure 虛擬網路的邏輯連線能力。

客戶網路使用 VPN 到 MSFT 網路的邏輯連線能力

計算最大預期輸入/輸出

  1. 判斷您應用程式的基準輸送量需求。
  2. 判斷您的 Azure VPN 閘道輸送量限制。 如需協助，請參閱關於 VPN 閘道的「閘道 SKU」一節。
  3. 判斷 VM 大小的 Azure VM 輸送量指引。
  4. 決定您網際網路服務提供者 (ISP) 的頻寬。
  5. 藉由使用 VM、VPN 閘道或 ISP 的最小頻寬來計算您預期的輸送量；這是以每秒百萬位元 (/) 除以八 (8) 來測量。 此計算提供每秒 MB 的 MB。

如果您計算出的輸送量不符合您應用程式的基準輸送量需求，您必須增加發現已成為瓶頸的資源頻寬。 如果要調整 Azure VPN 閘道的大小，請參閱 變更閘道 SKU。 如果調整虛擬機器的大小，請參閱 調整 VM 的大小。 如果您未能享有預期的網際網路頻寬，您也可以連絡您的 ISP。

注意

VPN 閘道輸送量是所有站對站\VNET 對 VNET 或點對站連線的匯總。

使用效能工具驗證網路輸送量

由於測試時的 VPN 通道輸送量飽和情況無法呈現準確的結果，因此應在非尖峰時段執行此驗證。

iPerf 是我們用於此測試的工作，分別在 Windows 與 Linux 上工作，並具有用戶端與伺服器模式。 Windows VM 限制在 3 Gbps。

此工具不會對磁碟執行任何讀取/寫入作業。 此工具只會產生從一端到另一端自我產生的 TCP 流量。 系統會根據測量用戶端與伺服器節點之間的可用頻寬實驗來產生統計資料。 在兩個節點之間測試時，一個節點作為伺服器，另一個節點作為用戶端。 一旦完成此項測試後，我們建議您對調節點的角色，以測試雙方節點的上傳和下載輸送量。

下載 iPerf

下載 iPerf。 如需詳細資訊，請參閱 iPerf 文件。

注意

本文中討論的協力廠商產品是由獨立於 Microsoft 的公司製造。 Microsoft 不以默示或其他方式，提供與這些產品的效能或可靠性有關的擔保。

執行 iPerf (iperf3.exe)

  1. 啟用允許流量的 NSG/ACL 規則 (適用於 Azure VM 上的公用 IP 位址測試)。

  2. 在這兩個節點上，啟用連接埠 5001 的防火牆例外狀況。

    Windows：以系統管理員身分執行下列命令。

    netsh advfirewall firewall add rule name="Open Port 5001" dir=in action=allow protocol=TCP localport=5001

    如果要在測試完成時移除規則，請執行此命令：

    netsh advfirewall firewall delete rule name="Open Port 5001" protocol=TCP localport=5001

    Azure Linux：Azure Linux 映像有寬鬆的防火牆。 如果有應用程式接聽連接埠，則允許通過流量。 受保護的自訂映像可能需要明確開啟連接埠。 常見的 Linux OS 層防火牆包括 iptables、ufw 或 firewalld。

  3. 在伺服器節點上，請變更至將 iperf3.exe 解壓縮的目錄。 然後在伺服器模式中執行 iPerf，並以下列命令設為接聽連接埠 5001︰

    cd c:\iperf-3.1.2-win65

iperf3.exe -s -p 5001

    注意

    您可以自訂連接埠 5001，以考慮環境中特定的防火牆限制。

  4. 在用戶端節點上，變更至將 iperf 工具解壓縮的目錄，然後執行下列命令：

    iperf3.exe -c <IP of the iperf Server> -t 30 -p 5001 -P 32

    用戶端會將連接埠 5001 上的 30 秒流量導向至伺服器。 旗標「-P」指出我們正在對伺服器節點使用 32 條同時連線。

    下列畫面顯示此範例的輸出：

    輸出

  5. (選用) 如果要保留測試結果，請執行此命令：

    iperf3.exe -c IPofTheServerToReach -t 30 -p 5001 -P 32  >> output.txt

  6. 完成先前的步驟後，請在對調角色後執行相同的步驟，因此伺服器節點現在將是用戶端節點，反之亦然。

注意

Iperf 不是唯一的工具。 NTTTCP 是測試的替代方案。

測試執行 Windows 的 VM

將 Latte.exe 載入至 VM

下載最新版本的 Latte.exe。

請考慮將 Latte.exe 放在不同的資料夾中，例如 c:\tools。

允許 Latte.exe 透過 Windows 防火牆

在接收端的 Windows 防火牆上建立一個「允許」規則，以允許 Latte.exe 流量到達。 最簡單的方式是依名稱允許整個 Latte.exe 程式，而不是允許特定的輸入 TCP 連接埠。

允許 Latte.exe 透過 Windows 防火牆，類似於

netsh advfirewall firewall add rule program=<PATH>\latte.exe name="Latte" protocol=any dir=in action=allow enable=yes profile=ANY

例如，如果您將 Latte.exe 複製到「c:\tools」資料夾，則命令會是這樣

netsh advfirewall firewall add rule program=c:\tools\latte.exe name="Latte" protocol=any dir=in action=allow enable=yes profile=ANY

執行延遲測試

啟動「接收端」上的 Latte.exe (從 CMD 執行，而非從 PowerShell)：

latte -a <Receiver IP address>:<port> -i <iterations>

大約 65,000 次反覆運算的時間長度足以傳回代表性結果。

任何可用的連接埠號碼均可。

如果 VM 的 IP 位址為 10.0.0.4，則看起來會像這樣：

latte -c -a 10.0.0.4:5005 -i 65100

啟動「傳送端」上的 Latte.exe (從 CMD 執行，而非從 PowerShell)：

latte -c -a <Receiver IP address>:<port> -i <iterations>

產生的命令與接收端的命令相同，但加上「-c」表示這是「用戶端」或傳送端

latte -c -a 10.0.0.4:5005 -i 65100

等候結果。 根據 VM 之間的距離，測試可能需要幾分鐘的時間才能完成。 請考慮先使用較少的反覆運算來測試是否成功，然後再執行較長的測試。

測試執行 Linux 的 VM

使用 SockPerf 來測試 VM。

在 VM 上安裝 SockPerf

在 Linux VM (「傳送端」和「接收端」兩者) 上，執行下列命令以在 VM 上準備 SockPerf：

RHEL - 安裝 GIT 和其他實用的工具

sudo yum install gcc -y -q sudo yum install git -y -q sudo yum install gcc-c++ -y sudo yum install ncurses-devel -y sudo yum install -y automake

Ubuntu - 安裝 GIT 和其他實用的工具

sudo apt-get install build-essential -y sudo apt-get install git -y -q sudo apt-get install -y autotools-dev sudo apt-get install -y automake

Bash - 全部

從 Bash 命令列 (假設已安裝 Git)

git clone https://github.com/mellanox/sockperf cd sockperf/ ./autogen.sh ./configure --prefix=

Make 速度較慢，可能需要幾分鐘的時間

make

Make install 較快

sudo make install

在 VM 上執行 SockPerf

安裝後的範例命令。 伺服器/接收端 - 假設伺服器的 IP 為 10.0.0.4

sudo sockperf sr --tcp -i 10.0.0.4 -p 12345 --full-rtt

用戶端 - 假設伺服器的 IP 為 10.0.0.4

sockperf ping-pong -i 10.0.0.4 --tcp -m 1400 -t 101 -p 12345 --full-rtt

注意

請確定在 VM 與閘道之間的輸送量測試期間沒有中繼躍點 (例如虛擬裝置)。 如果不良結果 (整體輸送量方面) 來自上述的 iPERF/NTTTCP 測試，請參閱這篇文章以瞭解問題可能根本原因背後的主要因素：

尤其是，在這些測試期間，從用戶端和伺服器並行收集的封包擷取追蹤 (Wireshark/網路監視器) 會協助評估不良的效能。 這些追蹤可能包括封包遺失、高延遲、MTU 大小。 分散、TCP 0 視窗、順序片段不足等。

處理檔案複製變慢的問題

即使使用先前步驟評估的整體輸送量 (iPERF/NTTTCP/等) 良好，但當您使用 Windows Explorer 或透過 RDP 工作階段卸除時，可能會遇到檔案通訊緩慢的問題。 此問題一般是因為下列一個或多個因素造成︰

  • 如 Windows 檔案總管與 RDP 的檔案應用程式，並未在複製檔案時使用多執行緒。 為了提升效能，請使用如 Richcopy 等多執行緒的檔案複製應用程式，以 16 或 32 條執行緒複製檔案。 如果要在 Richcopy 內變更用於檔案複製的執行緒數量，請按一下 [動作] > [複製選項] > [檔案複製] 。

    檔案複製變慢的問題

    注意

    並非所有應用程式都以相同方式運作，且並非所有的應用程式/處理程序都會利用所有執行緒。 如果您執行測試，您可能會看到部分執行緒是空的，且不會提供精確的輸送量結果。 若要檢查您的應用程式檔案傳輸效能，請連續或減少增加執行緒的編號來使用多執行緒，以找出應用程式或檔案傳輸的最佳輸送量。

  • VM 磁碟讀取/寫入速度不足。 如需詳細資訊，請參閱 Azure 儲存體疑難排解。

內部部署裝置的外部對應介面

提及您希望 Azure 透過區域網路閘道上 VPN 到達的內部部署範圍子網路。 同時，將 Azure 中的 VNET 位址空間定義為內部部署裝置。

  • 路由式閘道：路由式 VPN 的原則或流量選取器會設定為任意對任意 (或萬用字元)。

  • 原則式閘道：原則式 VPN 會根據內部部署網路與 Azure VNet 之間的位址首碼組合，透過 IPsec 通道加密和直接封包。 原則 (或流量選取器) 通常定義為 VPN 組態中的存取清單。

  • UsePolicyBasedTrafficSelector 連線：在連線上將 "UsePolicyBasedTrafficSelectors" 設定為 $True，會設定 Azure VPN 閘道連線至內部部署的原則式 VPN 防火牆。 如果您啟用 PolicyBasedTrafficSelectors，則必須確定 VPN 裝置的流量選取器已定義內部部署網路 (區域網路閘道) 前置詞往返於 Azure 虛擬網路前置詞的所有組合，而不是任意對任意的組合。

不適當的設定可能會導致通道內頻繁地中斷連線、封包捨棄、輸送量不良和延遲等。

檢查延遲

您可以使用下列工具來檢查延遲：

  • WinMTR
  • TCPTraceroute
  • ping 與 psping (這些工具可以提供較好的 RTT 評估，但無法在所有情況下使用。)

檢查延遲

如果您在進入 MS 網路骨幹之前發現任何躍點有高延遲的尖峰，您可能會想要繼續進一步調查您的網際網路服務提供者。

如果從 "msn.net" 內的躍點發現大量且異常的延遲尖峰，請聯絡 MS 支援以進行進一步調查。

下一步

如需詳細資訊或協助，請造訪下列連結：