☰

Wireguard lento, mas apenas para upload do Windows

tag-icon • tag-icon windows-10 upload slow-connection wireguard
Wireguard lento, mas apenas para upload do Windows

Temos o problema de que a conexão de várias redes de clientes via Wireguard Tunnel para um compartilhamento Samba em um servidor é lenta, mas estranhamente afeta apenas o Windows 10 e apenas uploads.

Um host Linux pode fazer upload com até 120 MB/s, enquanto o Windows só pode fazer upload com 10-50 MB/s (isso varia de acordo com as diferentes redes que temos). Não se limita a pequenas e médias empresas, obtenho exatamente os mesmos resultados de teste com Iperf (udp e tcp).

Por curiosidade testei se o Windows 11 também foi afetado e énão! O que poderia ser isso e como posso consertar?

Responder1

O driver experimental do kernel adicionado na versão 0.4.8 quebrou a velocidade de upload do Windows. Basta executar uma versão mais antiga até que eles consertem.

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

Responder2

Parece ser o mesmo ou pelo menos um problema semelhante descrito pelo Dropbox (https://dropbox.tech/infraestrutura/boosting-dropbox-upload-speed). Pelo que entendi (por favor, corrija-me!) Quando o Linux Gateway usa NIC multi-queue com Wireguard, ocorre muita reordenação de pacotes e, aparentemente, o Windows 10 não consegue lidar com isso muito bem. A reordenação do pacote de alguma forma faz com que o Windows 10 diminua a velocidade de envio, aguardando uma confirmação após quase todos os pacotes de dados enviados, em vez de enviar vários pacotes e aceitar confirmações seletivas.

Infelizmente, esqueci de fazer capturas de tela das sessões do Wireshark que analisei, mas ficou muito claro que, durante o download, o host do Windows geralmente recebia cerca de 10 a 20 pacotes de dados TCP antes de enviar uma confirmação. Mas ao fazer o upload recebi uma confirmação TCP para cada pacote de dados enviado.

A solução para corrigir isso é desabilitar o multiqueuing no host Linux.

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

Para ver se foi aplicado pode-se 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

A última linha deve ser 1. O comando acima define isso apenas temporariamente, para torná-lo persistente, as ferramentas específicas da distribuição precisam ser usadas. Para o Debian poderia ser algo assim:

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

Isto pode criar um gargalo se o gateway não tiver uma CPU forte. Usamos processadores AMD EPYC 7262 de 8 núcleos e obtemos upload e download completos de 1 Gbit com aproximadamente 70% de uso de um núcleo.

informação relacionada