Internet de baixa largura de banda por VPN

Acabei de configurar um NAS com VPN com o meu Raspberry Pi Modelo B recém-adquirido e com overclock e encontrei algo que não consigo encontrar resposta para outro lugar.

A largura de banda da Internet, conforme determinado usando

wget --output-document = / dev / null http://speedtest.wdc01.softlayer.com/downloads/test500.zip

é muito mais lento do que o que eu esperaria obter. Estou com 1,34 MBps no Pi pela Ethernet quando estou chegando a 7 MBps quando a Ethernet está conectada diretamente no meu laptop.

O problema está no OpenVPN, mas não consigo descobrir exatamente o que é. Aqui está como eu sei disso.

Comparei as taxas de download no Pi com a VPN desligada e ligada - era 5,03 MBPS vs 1,34 MBPS.

Então eu tentei no meu laptop (com fio) - era 6,9 MBPS (perfeito) vs 6,7 MBPS (quase perfeito).

Portanto, a falha não está totalmente no meu serviço VPN (PrivateInternetAccess), que oferece uma redução de 3% na largura de banda no meu laptop - mas tem a ver com a maneira como o OpenVPN é executado no Pi, com uma redução de 74% na largura de banda.

Alguma idéia de por que o OpenVPN no Raspbian está sendo tão terrível?

ATUALIZAÇÃO: A maior parte dessa redução de 6,9MBPS no laptop sem VPN para 5,03 MBPS no Pi sem VPN parece ser da velocidade de gravação do cartão SD, que eu determinei em torno de 4,9MBPS. É essa enorme redução de 5,03 MPBS no Pi sem VPN para 1,3 MBPS com VPN que precisa ser explicada.

ATUALIZAÇÃO 2: Mais algumas dicas das sugestões dos comentários: 1) O OpenVPN utiliza 70% da CPU quando está em execução e o wget está em segundo plano 2) No Pi, recebo 1,34 MBPS de um servidor VPN dos EUA e cerca de 500 600 KBPS de TODOS os servidores VPN europeus, MAS no meu laptop, recebo 6.7MBPS do servidor VPN dos EUA e 6.6MBPS muito semelhantes de alguns servidores europeus como o da Holanda. O que estou dizendo é que a distância do servidor parece afetar desproporcionalmente o Pi e não o meu laptop.

raspbian ethernet-port

— dbrane
fonte

Pode ser uma combinação de baixa velocidade de gravação e sobrecarga de VPN. Eu nunca gostei de usar VPNs, porque eles eram lentos pela Internet e o encapsulamento SSH era sempre o mais rápido. Existem opções para ativar a compactação no OpenVPN? Possivelmente brinque com isso, talvez a criptografia instantânea cause problemas. É uma boa pergunta. Também estou interessado nas respostas em relação ao Pi

— Piotr Kula

Observe a carga da CPU topdurante o teste, que deve dizer algo sobre a sobrecarga de criptografia.

— Frepa

Excelente sugestão! Quando a VPN está ativada, o OpenVPN utiliza 70% da CPU. Você acha que isso está causando a enorme diferença nas taxas de transferência?

— D-Brana

@dbrane, parece que a CPU é o fator limitante. Para onde vão os 30% restantes da CPU? Ocioso? A partir da atualização 2, parece que a latência da rede (ou seja, não apenas a taxa de transferência) é importante para o desempenho. Talvez haja algum aperto de mão acontecendo na VPN.

— Frepa

@ Frepa A maior parte do tempo restante da CPU é usada pelo próprio wget, que é o comando que eu uso para testar a taxa de transferência. Todo o resto da lista usa menos de 1% cada. Estou usando um certificado CA com a VPN, se essas informações ajudarem. Talvez eu devesse tentar fazer overclock e ver se isso ajuda?

— D-Brana

Em dispositivos de baixa potência, pelo menos ao usar o SSH, tive uma boa experiência usando a cifra RC4 para melhorar o desempenho, uma vez que é computacionalmente mais rápida, portanto, usa menos CPU para a largura de banda / permite maiores larguras de banda para o mesmo uso da CPU. Este guia explica como alterar a cifra para qualquer uma suportada pelo OpenSSL - como RC4:

http://openvpn.net/index.php/open-source/documentation/howto.html#security

Observe que o RC4 não é o algoritmo mais seguro disponível, mas o SSL ainda o utiliza de maneiras seguras (que existem, conforme descrito aqui: http://en.wikipedia.org/wiki/RC4 ). Atualização : isso é menos verdade agora do que no passado. A confiança na segurança do RC4 está reduzindo ainda mais, à medida que as técnicas para quebrá-lo avançam, e 2013 nos deu vários progressos na quebra do RC4 e especulações sobre o fato de a NSA ter conseguido . Citando a Wikipedia:

A partir de 2013, especula-se que algumas agências criptográficas estaduais possam possuir a capacidade de quebrar o RC4 mesmo quando usado no protocolo TLS. [3] A Microsoft recomenda desativar o RC4 sempre que possível. [4] [5]

Então, ainda posso recomendar o RC4? Não é realmente em geral. É claro que você precisa trocar a segurança e o desempenho e talvez não precise de muita segurança - qualquer criptografia, mesmo o RC4, ainda atrasará os esforços de vigilância de arrastões como os da NSA. Mas eu seria muito cuidadoso com dados realmente confidenciais e mudaria o algoritmo para outra coisa, se possível (comecei a comparar meu Raspberry para procurar alternativas rápidas).

Atualização 2 : no meu Raspberry (com overclock), o AES não é tão lento, se você tiver CPU suficiente disponível. A tabela abaixo mostra que o RC4 pode criptografar ~ 57MB / s, enquanto o AES-128-CBC pode criptografar ~ 21.4MB / s. Obviamente, isso não explica por que você obtém um desempenho tão ruim - mas talvez você esteja usando por padrão um código mais lento, ou talvez haja alguma outra ineficiência que possa ser melhorada.

$ openssl speed rc4 aes
[...]
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
rc4              45281.36k    54782.67k    57196.80k    57391.48k    57570.77k
aes-128 cbc      17904.15k    20469.38k    21133.95k    21449.62k    21403.72k

Configurações de overclock de /boot/config.txt:

arm_freq=950

# for more options see http://elinux.org/RPi_config.txt
core_freq=250
sdram_freq=450
over_voltage=6

— Blaisorblade
fonte

Qualquer tipo de criptografia (ssh / vpn) causará uso adicional da CPU, que provavelmente é seu gargalo.

— earthmeLon

Meu argumento foi que o RC4 usa menos CPU do que outras cifras, portanto pode ser bom nessa situação. Mas não tenho certeza se você concorda ou discorda da minha resposta.

— Blaisorblade

@earthmeLon: atualizei minha resposta para declarar meu argumento explicitamente, porque, de qualquer maneira, não estava claro. Não tenho certeza de que aborda seu comentário.

— Blaisorblade

Absolutamente. Fiquei muito agradecido por saber que o RC4 é uma boa solução com sobrecarga mínima, devido à implementação do SSH2. Obrigado pela informação: D. Pena que você não podia ver, eu te dei uma votação, não é?

— earthmeLon

De fato - só notei depois que seu comentário coincidiu com o momento da votação. Obrigado!

— Blaisorblade