☰

Wireguard langsam, aber nur für Windows-Upload

tag-icon • tag-icon windows-10 upload slow-connection wireguard
Wireguard langsam, aber nur für Windows-Upload

Wir haben das Problem, dass die Verbindung von mehreren Clientnetzwerken über den Wireguard-Tunnel zu einer Samba-Freigabe auf einem Server langsam ist, was aber komischerweise nur Windows 10 und nur Uploads betrifft.

Ein Linux-Host kann mit bis zu 120 MB/s hochladen, während Windows nur mit 10-50 MB/s hochladen kann (das variiert je nach Netzwerk). Es ist nicht auf SMB beschränkt, ich erhalte mit Iperf (UDP und TCP) genau die gleichen Testergebnisse.

Aus Neugier habe ich getestet, ob auch Windows 11 betroffen ist und es istnicht! Was könnte das sein und wie kann ich es beheben?

Antwort1

Der experimentelle Kerneltreiber, den sie in der Version 0.4.8 hinzugefügt haben, hat die Upload-Geschwindigkeit von Windows beeinträchtigt. Führen Sie einfach eine ältere Version aus, bis das Problem behoben ist.

https://download.wireguard.com/windows-client/wireguard-amd64-0.4.7.msi

Antwort2

Es scheint sich um dasselbe oder zumindest ein ähnliches Problem zu handeln, wie es Dropbox beschreibt (https://dropbox.tech/infrastructure/boosting-dropbox-upload-speed). Soweit ich es verstehe (bitte korrigieren Sie mich!), kommt es bei Verwendung von NIC Multi-Queue mit Wireguard durch das Linux Gateway zu vielen Paketneuordnungen, und anscheinend kann Windows 10 damit nicht so gut umgehen. Die Paketneuordnung führt irgendwie dazu, dass Windows 10 die Sendegeschwindigkeit verlangsamt, indem es nach fast jedem gesendeten Datenpaket auf eine Bestätigung wartet, anstatt mehrere Pakete zu senden und ausgewählte Bestätigungen zu akzeptieren.

Leider habe ich vergessen, Screenshots der Wireshark-Sitzungen zu machen, die ich analysiert habe. Es war jedoch sehr gut zu erkennen, dass der Windows-Host beim Herunterladen normalerweise etwa 10 bis 20 TCP-Datenpakete erhielt, bevor er eine Bestätigung sendete. Beim Hochladen erhielt ich jedoch für jedes gesendete Datenpaket eine TCP-Bestätigung.

Die Lösung zur Behebung dieses Problems besteht darin, Multiqueuing auf dem Linux-Host zu deaktivieren.

ethtool -L PHYSICAL_LOCAL_INTERFACE combined 1
ethtool -L PHYSICAL_NETWORK_INTERFACE combined 1

Um zu sehen, ob es angewendet wurde, kann man verwenden

ethtool -l INTERFACENAME
Channel parameters for INTERFACENAME:
Pre-set maximums:
RX:             0
TX:             0
Other:          1
Combined:       63
Current hardware settings:
RX:             0
TX:             0
Other:          1
Combined:       1

Die letzte Zeile sollte 1 sein. Der obige Befehl setzt dies nur vorübergehend. Um es dauerhaft zu machen, müssen distributionsspezifische Tools verwendet werden. Für Debian könnte es etwa so aussehen:

cat /etc/network/interfaces
auto INTERFACE
iface INTERFACE inet static
    address IPADDR
    netmask NETMASK
    gateway GATEWAY
    # This is the relevant line
    post-up ethtool -L INTERFACE combined 1

Dies kann zu einem Engpass führen, wenn das Gateway keine leistungsstarke CPU hat. Wir verwenden AMD EPYC 7262 8-Core-Prozessoren und erreichen den vollen 1-GBit-Up- und Download mit ~70 % Auslastung eines Kerns.

verwandte Informationen