SSH Tunnel lento

Question

Acabei de me mudar para o outro lado do mundo e estou tendo um problema de conexão estranho. Eu tenho uma conexão dsl de 4 Mbps, posso com êxito ssh no meu servidor e configurar um túnel. Eu uso PuTTY (no meu desktop - PC) e Terminal (no meu mac). A velocidade do meu desktop está recebendo, em média, 0,5 Mbps. Se eu testar a velocidade direto para o servidor mais próximo (ou seja, sem o proxy / túnel) para o meu servidor, no entanto, recebo os 4 Mbps como anunciado.

As únicas diferenças são: a área de trabalho está em uma conexão CAT5 e o Mac é sem fio através do roteador DSL. Eu verifiquei o cabo, ligando-o ao Mac e ele tem 4 Mbps para o túnel. As outras conexões Ethernet para o roteador também obtêm a velocidade de 4 Mbps.

Abaixo está o putty.log. Não tenho certeza se é o roteador ou a configuração da conexão de putty e estou em uma perda depois de passar 4 horas no Google.

Qualquer ajuda seria apreciada. O próprio servidor está executando o Ubuntu 10.04.

2011-08-01 14:14:13 Looking up host "x.x.x.x"
2011-08-01 14:14:13 Connecting to x.x.x.x port 22
2011-08-01 14:14:13 Server version: SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
2011-08-01 14:14:13 We claim version: SSH-2.0-PuTTY_Release_0.60
2011-08-01 14:14:13 Using SSH protocol version 2
2011-08-01 14:14:14 Doing Diffie-Hellman group exchange
2011-08-01 14:14:14 Doing Diffie-Hellman key exchange with hash SHA-256
2011-08-01 14:14:14 Host key fingerprint is:
2011-08-01 14:14:14 ssh-rsa 2048 aa:bb:cc:dd:0f:a3:1e:06:bc:c8:7d:dd:cc:bb:aa:11
2011-08-01 14:14:14 Initialised AES-256 SDCTR client->server encryption
2011-08-01 14:14:14 Initialised HMAC-SHA1 client->server MAC algorithm
2011-08-01 14:14:14 Initialised AES-256 SDCTR server->client encryption
2011-08-01 14:14:14 Initialised HMAC-SHA1 server->client MAC algorithm
2011-08-01 14:14:15 Reading private key file "C:\key.ppk"
2011-08-01 14:14:17 Offered public key
2011-08-01 14:14:18 Offer of public key accepted
2011-08-01 14:14:20 Access granted
2011-08-01 14:14:21 Opened channel for session
2011-08-01 14:14:21 Local port 1080 SOCKS dynamic forwarding
2011-08-01 14:14:21 Allocated pty (ospeed 38400bps, ispeed 38400bps)
2011-08-01 14:14:21 Started a shell/command

    

Answer 1

Como regra geral, para conexões ssh / velocidade de túneis ... O Putty é um aplicativo de encadeamento único, portanto, mesmo em sistemas com vários núcleos, você está limitado por uma velocidade de núcleo único de cpu. Para altas velocidades, escolha cifra rápida - Blowfish. Configure-o em putty ou, se estiver usando a linha de comando ssh, especifique ssh -c blowfish ... para usá-lo. Usando isso, você ainda estará limitado a cerca de no máximo. 10 MB / s em uma rede local Gbit.

EDIT: Agora é 2018 e todas as CPUs e sistemas operacionais atuais devem suportar aceleração HW AES (instrução AES-NI). Portanto, a recomendação com o Blowfish aplica-se apenas ao HW mais antigo (ou HW lento como roteadores) agora. HW acelerado AES dá mais de 1 GB / s de taxa de criptografia, por isso é suficiente para ssh e / ou openssl.

    

Answer 2

Eu me deparei com problemas semelhantes com o WinSCP (com base na implementação SSH do PuTTY) em um link de alta latência através do Atlântico. A maneira como PuTTY e WinSCP lidariam com seus buffers de rede não permitiria que o dimensionamento de janelas TCP fizesse seu trabalho, o que é realmente necessário para links de alta latência. Ele sempre enviaria dois pacotes, um grande e outro pequeno. O primeiro teria uma carga útil de 1460 bytes e o segundo teria 76 bytes.

Este tópico tem uma ótima explicação do porquê 1460 + 76 bytes são significativos.

De qualquer forma, eu resolvi este problema sozinho descartando o PuTTY / WinSCP em favor do Bitvise Tunnilier , que não exibe esse tipo de problema de dimensionamento de buffer / janela.