☰

Wireguard медленный, но только для загрузки Windows

tag-icon • tag-icon windows-10 upload slow-connection wireguard
Wireguard медленный, но только для загрузки Windows

У нас возникла проблема: подключение из нескольких клиентских сетей через туннель Wireguard к общему ресурсу Samba на сервере происходит медленно, но, как ни странно, это касается только Windows 10 и только загрузок.

Linux Host может загружать со скоростью до 120 МБ/с, в то время как Windows может загружать только со скоростью 10-50 МБ/с (это зависит от разных сетей, которые у нас есть). Это не ограничивается smb, я получаю точно такие же результаты теста с Iperf (udp и tcp).

Из любопытства я проверил, затронута ли эта проблема и Windows 11, и это так.нет! Что это может быть и как это исправить?

решение1

Экспериментальный драйвер ядра, который они добавили в релизе 0.4.8, сломал скорость загрузки Windows. Просто запустите старую версию, пока они это не исправят.

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

решение2

Похоже, это та же самая или, по крайней мере, похожая проблема, которую описал Dropbox (https://dropbox.tech/infrastructure/boosting-dropbox-upload-speed). Насколько я понимаю (поправьте меня, пожалуйста!), когда Linux Gateway использует многоочередность сетевых карт с Wireguard, происходит много переупорядочивания пакетов, и, по-видимому, Windows 10 не может с этим справиться. Переупорядочивание пакетов каким-то образом заставляет Windows 10 замедлять скорость отправки, ожидая подтверждения почти после каждого отправленного пакета данных вместо отправки нескольких пакетов и принятия выборочных подтверждений.

К сожалению, я забыл сделать скриншоты сессий Wireshark, которые я анализировал, но было очень хорошо видно, что при загрузке хост Windows обычно получал около 10-20 пакетов данных TCP, прежде чем отправить подтверждение. Но при загрузке я получал подтверждение TCP на каждый отправленный пакет данных.

Решением этой проблемы является отключение многоочередности на хосте Linux.

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

Чтобы увидеть, было ли оно применено, можно использовать

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

Последняя строка должна быть 1. Приведенная выше команда устанавливает это только временно, чтобы сделать это постоянным, необходимо использовать специфические для дистрибутива инструменты. Для Debian это может быть что-то вроде этого:

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

Это может создать узкое место, если шлюз не имеет мощного ЦП. Мы используем 8-ядерные процессоры AMD EPYC 7262 и получаем полный 1 Гбит up- & download с ~70% использованием одного ядра.

Связанный контент