Überprüfen des VPN-Durchsatzes zu einem virtuellen Netzwerk

Achtung

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution, die sich dem End-of-Life-Status (EOL) nähert. Sie sollten Ihre Nutzung entsprechend planen. Weitere Informationen finden Sie im CentOS-Leitfaden für das Lebensende.

Mit einer VPN-Gateway-Verbindung sorgen Sie für sichere, standortübergreifende Konnektivität in Ihrem virtuellen Netzwerk innerhalb der Azure-Infrastruktur und Ihrer lokalen IT-Infrastruktur.

In diesem Artikel wird die Überprüfung des Netzwerkdurchsatzes von lokalen Ressourcen zu einem virtuellen Azure-Computer (VM) beschrieben.

Hinweis

Dieser Artikel ist dazu gedacht, bei der Diagnose und beim Beheben von häufigen Problemen zu helfen. Wenn Sie das Problem nicht mithilfe der folgenden Informationen beheben können, wenden Sie sich an den Support.

Übersicht

Die VPN-Gateway-Verbindung umfasst die folgenden Komponenten:

• Lokales VPN-Gerät (eine Liste überprüfter VPN-Geräte anzeigen)
• Öffentliches Internet
• Azure VPN Gateway
• Azure VM

Das folgende Diagramm zeigt die logische Verbindung von einem lokalen Netzwerk mit einem Azure Virtual Network über VPN.

Berechnen des maximal erwarteten Eingangs/Ausgangs

1. Bestimmen Sie die Grundvoraussetzungen für den Durchsatz Ihrer Anwendung.
2. Bestimmen Sie die Durchsatzlimits für Ihr Azure VPN Gateway. Wenn Sie Hilfe benötigen, lesen Sie den Abschnitt „Gateway-SKUs“ von Informationen zu VPN Gateway.
3. Bestimmen Sie die Durchsatzanleitung des virtuellen Azure-Computers für die Größe Ihres virtuellen Computers.
4. Bestimmen Sie die Bandbreite Ihres Internetdienstanbieters.
5. Berechnen Sie Ihren erwarteten Durchsatz, indem Sie die geringste Bandbreite entweder der VM, des VPN-Gateways oder des ISP verwenden. Diese wird in Megabit pro Sekunde (/) geteilt durch acht (8) gemessen. Mit dieser Berechnung erhalten Sie Megabyte pro Sekunde.

Wenn der berechnete Durchsatz nicht die Grundvoraussetzungen für den Durchsatz Ihrer Anwendung erfüllt, müssen Sie die Bandbreite der Ressource erhöhen, die Sie als Engpass identifiziert haben. Informationen zum Ändern der Größe für ein Azure VPN Gateway finden Sie unter Ändern einer Gateway-SKU. Informationen zum Ändern der Größe eines virtuellen Computers finden Sie unter Ändern der Größe eines virtuellen Computers. Wenn Sie nicht die erwartete Internetbandbreite erhalten, sollten Sie sich auch an Ihren Internetdienstanbieter wenden.

Hinweis

Der Durchsatz des VPN-Gateways ist eine Summe aller Site-to-Site-\VNET-to-VNET- oder Point-to-Site-Verbindungen.

Überprüfen des Netzwerkdurchsatzes mithilfe von Leistungstools

Diese Überprüfung sollte nicht während der Spitzenlastzeiten ausgeführt werden, da die Durchsatzausnutzung des VPN-Tunnels während der Tests keine präzisen Ergebnisse liefert.

Für diesen Test verwenden wir das Tool „iPerf“, das sowohl unter Windows als auch unter Linux funktioniert und Client- und Servermodi bietet. Bei virtuellen Windows-Computern ist es auf 3 GBit/s begrenzt.

Dieses Tool führt keine Lese-/Schreibvorgänge auf den Datenträger aus. Es erzeugt ausschließlich selbstgenerierten TCP-Datenverkehr von einem Ende zum anderen. Es hat Statistiken auf Basis von Versuchen generiert, die die verfügbare Bandbreite zwischen Client- und Server-Knoten messen. Beim Testen zwischen zwei Knoten dient ein Knoten als Server und der andere Knoten als Client. Nachdem dieser Test abgeschlossen ist, wird empfohlen, dass Sie die Rollen der Knoten tauschen, um den Durchsatz sowohl beim Upload als auch beim Download auf beiden Knoten zu testen.

Herunterladen von iPerf

Laden Sie iPerf herunter. Ausführliche Informationen finden Sie in der iPerf-Dokumentation.

Hinweis

Die in diesem Artikel beschriebenen Drittanbieterprodukte werden von Unternehmen hergestellt, die von Microsoft unabhängig sind. Microsoft übernimmt keine Garantie, weder ausdrücklich noch konkludent, für die Leistungsfähigkeit oder Zuverlässigkeit dieser Produkte.

Ausführen von iPerf (iperf3.exe)

1. Aktivieren Sie eine NSG/ACL-Regel, die den Datenverkehr gestattet (zum öffentlichen Testen der IP-Adresse auf dem virtuellen Azure-Computer).

2. Aktivieren Sie auf beiden Knoten eine Firewallausnahme für Port 5001.

   Windows: Führen Sie den folgenden Befehl als Administrator aus:

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

   Führen Sie den folgenden Befehl aus, um die Regel nach Abschluss der Tests zu entfernen:

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

   Azure Linux: Azure Linux-Images besitzen tolerante Firewalls. Wenn eine Anwendung einen Port überwacht, wird der Datenverkehr durchgelassen. Für benutzerdefinierte Images, die gesichert sind, müssen die Ports möglicherweise explizit geöffnet werden. Allgemeine Firewalls der Linux-Betriebssystemebene enthalten iptables, ufw oder firewalld.

3. Wechseln Sie auf dem Serverknoten in das Verzeichnis, in dem „iperf3.exe“ extrahiert wird. Führen Sie dann iPerf im Modus „Server“ aus, und legen Sie die Überwachung von Port 5001 mit den folgenden Befehlen fest:

   cd c:\iperf-3.1.2-win65
   
   iperf3.exe -s -p 5001
   

   Hinweis

   Port 5001 ist anpassbar, um bestimmte Firewalleinschränkungen in Ihrer Umgebung zu berücksichtigen.

4. Wechseln Sie auf dem Clientknoten in das Verzeichnis, in dem das Tool „iPerf“ exportiert wurde, und führen Sie dann den folgenden Befehl aus:

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

   Der Client leitet 30 Sekunden Datenverkehr auf Port 5001 zum Server weiter. Das Flag „-P“ gibt an, dass 32 gleichzeitige Verbindungen mit dem Serverknoten verwendet werden.

   Der folgende Bildschirm zeigt die Ausgabe dieses Beispiels:

   

5. (OPTIONAL) Führen Sie diesen Befehl aus, um die Testergebnisse beizubehalten:

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

6. Führen Sie nach Abschluss der vorherigen Schritte dieselben Schritte mit den vertauschten Rollen aus, damit der Serverknoten jetzt zum Clientknoten wird und umgekehrt.

Hinweis

Iperf ist nicht das einzige Tool. NTTTCP ist eine alternative Lösung für Tests.

Testen von virtuellen Computern unter Windows

Laden von „Latte.exe“ auf die virtuellen Computer

Laden Sie die neueste Version von Latte.exe herunter.

Erwägen Sie, „Latte.exe“ in einem separaten Ordner abzulegen, z. B. c:\tools.

Zulassen von „Latte.exe“ durch die Windows-Firewall

Erstellen Sie auf dem Empfänger eine „Zulassen“-Regel für die Windows-Firewall, damit der „Latte.exe“-Datenstrom empfangen werden kann. Am einfachsten ist es, das gesamte „Latte.exe“-Programm nach Name anstatt nach bestimmten eingehenden TCP-Ports zuzulassen.

Zulassen von „Latte.exe“ durch die Windows-Firewall

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

Angenommen, Sie haben „latte.exe“ in den Ordner „C:\tools“ kopiert, dann wäre dies der Befehl:

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

Durchführen von Latenztests

Starten Sie „latte.exe“ auf dem EMPFÄNGER (Ausführen über CMD, nicht über PowerShell):

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

Etwa 65.000 Iterationen sollten repräsentative Ergebnisse liefern.

Jede verfügbare Portnummer ist in Ordnung.

Wenn der virtuelle Computer die IP-Adresse 10.0.0.4 aufweist, würde es folgendermaßen aussehen:

latte -c -a 10.0.0.4:5005 -i 65100

Starten Sie „latte.exe“ auf dem SENDER (Ausführen über CMD, nicht über PowerShell):

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

Der resultierende Befehl ist derselbe wie beim Empfänger, abgesehen davon, dass er den Zusatz „-c“ enthält, um anzuzeigen, dass es sich um den „Client“ oder Sender handelt.

latte -c -a 10.0.0.4:5005 -i 65100

Warten Sie auf die Ergebnisse. Je nachdem, wie weit die VMs voneinander entfernt sind, kann es einige Minuten dauern, bis der Vorgang abgeschlossen ist. Erwägen Sie, mit weniger Iterationen zu beginnen, um den Erfolg zu testen, bevor Sie längere Tests durchführen.

Testen von virtuellen Computern unter Linux

Verwenden Sie SockPerf, um virtuelle Computer zu testen.

Installieren von SockPerf auf den virtuellen Computern

Führen Sie diese Befehle zum Vorbereiten von SockPerf auf Ihren virtuellen Computern (jeweils SENDER und EMPFÄNGER) auf den Linux-VMs aus:

CentOS/RHEL: Installieren von Git und anderen nützlichen Tools

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: Installieren von Git und anderen nützlichen Tools

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: alle

Von der bash-Befehlszeile (sofern Git installiert ist)

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

„make“ ist langsamer und kann mehrere Minuten dauern.

make

„make install“ ist schnell.

sudo make install

Ausführen von SockPerf auf den virtuellen Computern

Beispielsbefehle nach der Installation. Server/Empfänger: IP-Adresse des Servers wird als „10.0.0.4“ angenommen

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

Client: IP-Adresse des Servers wird als „10.0.0.4“ angenommen

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

Hinweis

Stellen Sie sicher, dass es während des Durchsatztests zwischen VM und Gateway keine Zwischenhops (z. B. virtuelle Geräte) gibt. Wenn die Ergebnisse der obigen iPERF/NTTTCP-Tests (in Bezug auf den Gesamtdurchsatz) nicht zufriedenstellend sind, lesen Sie diesen Artikel, um die Schlüsselfaktoren hinter den möglichen Ursachen des Problems zu verstehen:

Insbesondere die Analyse von Paketerfassungsverfolgungen (Wireshark/Netzwerkmonitor), die während dieser Tests parallel vom Client und Server gesammelt werden, wird bei der Beurteilung schlechter Leistung helfen. Diese Ablaufverfolgungen können Paketverlust, hohe Latenzzeiten, MTU-Größe, Fragmentierung, TCP 0 Window, Fragmente in falscher Reihenfolge usw. beinhalten.

Behandeln von Problemen durch langsames Kopieren von Dateien

Auch wenn der Gesamtdurchsatz, der in den vorherigen Schritten (iPERF/NTTTCP/usw.) ermittelt wurde, gut war, kann es bei der Verwendung des Windows Explorers oder beim Drag & Drop durch eine RDP-Sitzung zu einer langsamen Dateibewältigung kommen. Dieses Problem ergibt sich normalerweise aufgrund eines oder der beiden folgenden Faktoren:

• Anwendungen zum Kopieren von Dateien, z. B. Windows-Explorer und RDP, verwenden beim Kopieren von Dateien nicht mehrere Threads. Verwenden Sie eine Anwendung mit mehreren Threads zum Kopieren von Dateien, z. B. Richcopy, damit Dateien mithilfe von 16 oder 32 Threads kopiert werden. Um die Threadanzahl für das Kopieren von Dateien in Richcopy zu ändern, klicken Sie auf Action>Copy options>File copy.

  
  

  Hinweis

  Nicht alle Anwendungen funktionieren gleich, und nicht alle Anwendungen/Prozesse nutzen alle Threads. Wenn Sie den Test ausführen, können Sie sehen, dass einige Threads leer sind und keine genauen Durchsatzergebnisse liefern. Um die Leistung Ihrer Anwendungsdateiübertragung zu überprüfen, verwenden Sie Multithread, indem Sie die Anzahl der Threads nacheinander erhöhen oder verringern, um den optimalen Durchsatz der Anwendung oder der Dateiübertragung zu ermitteln.

• Unzureichende Lese-/Schreibgeschwindigkeiten des Datenträgers des virtuellen Computers. Weitere Informationen finden Sie unter Problembehandlung für Azure Storage.

Nach außen gerichtete Schnittstelle für lokale Geräte

Es wurden die Subnetze der lokalen Bereiche erwähnt, die Azure über VPN am lokalen Netzwerkgateway erreichen soll. Definieren Sie gleichzeitig den VNET-Adressraum in Azure für das lokale Gerät.

• Routenbasiertes Gateway: Die Richtlinie bzw. der Datenverkehrselektor für routenbasierte VPNs werden im Any-to-Any-Format (bzw. als Platzhalter) konfiguriert.

• Richtlinienbasiertes Gateway: Bei richtlinienbasierten VPNs werden Pakete verschlüsselt und durch IPsec-Tunnel geleitet. Grundlage hierfür sind Kombinationen aus Adresspräfixen zwischen Ihrem lokalen Netzwerk und dem Azure-VNet. Die Richtlinie (auch Datenverkehrsselektor genannt) wird in der Regel als Zugriffsliste in der VPN-Konfiguration definiert.

• UsePolicyBasedTrafficSelector-Verbindungen: Wenn „UsePolicyBasedTrafficSelectors“ für eine Verbindung auf „$True“ festgelegt wird, wird das Azure-VPN-Gateway zum Herstellen einer Verbindung mit einer richtlinienbasierten VPN-Firewall an einem lokalen Standort konfiguriert. Wenn Sie „PolicyBasedTrafficSelectors“ aktivieren, müssen für Ihr VPN-Gerät die entsprechenden Datenverkehrsselektoren mit allen Präfixkombinationen zwischen Ihrem lokalen Netzwerk (lokalen Netzwerkgateway) und den Präfixen des virtuellen Azure-Netzwerks definiert sein (anstelle von Any-to-Any).

Eine ungeeignete Konfiguration kann zu häufigen Verbindungsabbrüchen innerhalb des Tunnels, Paketausfällen, schlechtem Durchsatz und Latenzzeiten führen.

Überprüfen der Latenzzeit

Sie können die Latenzzeit mithilfe der folgenden Tools überprüfen:

• WinMTR
• TCPTraceroute
• ping und psping (Diese Tools können eine gute Einschätzung der RTT liefern, aber sie können nicht in allen Fällen verwendet werden.)

Wenn Sie eine hohe Latenzspitzenbildung bei einem der Hops feststellen, bevor der Netzwerkbackbone von Microsoft erreicht wird, sollten Sie eventuell weitere Untersuchungen bei Ihrem Internetanbieter durchführen.

Wenn innerhalb von „msn.net“ ein großer, ungewöhnlicher Latenzanstieg von Hops erkannt wird, wenden Sie sich bitte an den MS-Support für weitere Untersuchungen.

Nächste Schritte

Weitere Informationen oder Hilfe finden Sie über den folgenden Link:

• Microsoft-Support