☰

Wireguard es lento pero solo para carga en Windows

tag-icon • tag-icon windows-10 upload slow-connection wireguard
Wireguard es lento pero solo para carga en Windows

Tenemos el problema de que la conexión desde múltiples redes de clientes a través de Wireguard Tunnel a un recurso compartido Samba en un servidor es lenta, pero curiosamente solo afecta a Windows 10 y solo a las cargas.

Un host Linux puede cargar hasta 120 MB/s, mientras que Windows solo puede cargar entre 10 y 50 MB/s (varía según las diferentes redes que tengamos). No se limita a alguien, obtengo exactamente los mismos resultados de prueba con Iperf (udp y tcp).

Por curiosidad probé si Windows 11 también se ve afectado y esno! ¿Qué podría ser esto y cómo puedo solucionarlo?

Respuesta1

El controlador del kernel experimental que agregaron en la versión 0.4.8 rompió la velocidad de carga de Windows. Simplemente ejecute una versión anterior hasta que lo solucionen.

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

Respuesta2

Parece ser el mismo problema o al menos similar al descrito por Dropbox (https://dropbox.tech/infrastructure/boosting-dropbox-upload-speed). Hasta donde tengo entendido (¡corríjame!), cuando Linux Gateway usa NIC multi-cola con Wireguard, se produce una gran cantidad de reordenamiento de paquetes y aparentemente Windows 10 no puede manejar eso muy bien. El reordenamiento de paquetes de alguna manera hace que Windows 10 ralentice la velocidad de envío al esperar una confirmación después de casi cada paquete de datos enviado en lugar de enviar varios paquetes y aceptar confirmaciones selectivas.

Lamentablemente, olvidé hacer capturas de pantalla de las sesiones de Wireshark que analicé, pero se vio muy bien que al descargar, el host de Windows generalmente recibía entre 10 y 20 paquetes de datos tcp antes de enviar un reconocimiento. Pero al cargar recibí un reconocimiento TCP por cada paquete de datos enviado.

La solución para solucionar este problema es desactivar las colas múltiples en el host Linux.

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

Para ver si se aplicó se puede usar

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

La última línea debe ser 1. El comando anterior solo configura esto temporalmente; para hacerlo persistente, se deben usar herramientas específicas de la distribución. Para Debian podría ser algo como esto:

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

Esto puede crear un cuello de botella si la puerta de enlace no tiene una CPU potente. Usamos procesadores AMD EPYC 7262 de 8 núcleos y obtenemos la carga y descarga completa de 1 Gbit con aproximadamente un 70 % de uso de un núcleo.

información relacionada