Existem desvantagens no encapsulamento SSH?

Recentemente, "comprei" um VPS que quero usar como Proxy para poder usar alguns sites e coisas que não consigo acessar da Alemanha.

Como ainda estava com preguiça de configurar o Squid e o OpenVPN (que atualmente acho necessário), uso o ssh-tunneling.

Agora, depois de algumas semanas, perguntei-me se o encapsulamento de ssh não estava bom, ou - e essa é minha pergunta - se há alguma advertência / contras / desvantagem que eu preciso ter em mente?

ssh proxy ssh-tunneling

— Nils Riedemann
fonte

Pelo que vale, o OpenVPN é extremamente fácil de configurar usando uma chave estática, se você estiver passando do Linux para o Linux. É um pouco mais complicado se uma de suas máquinas for Windows, mas factível. bit.ly/ujkD2

— transistor1

Respostas:

O problema de desempenho surge quando você está encapsulando o TCP sobre o TCP, porque você tem duas camadas fazendo correções adaptativas (início lento, prevenção de congestionamentos, re-transmissão rápida, consulte RFC2001 ).

Não tendo conhecimento um do outro, eles enfrentarão grandes dificuldades se houver perda na conexão externa.

Esta página descreve o fenômeno em detalhes.

editar:

Em vez de ficar com o problema de TCP sobre TCP, observe o sshuttle, que o impede.
Veja a seção " Teoria da operação " para obter mais detalhes sobre essa situação.

— Shadok
fonte

A camada interna não sabe que está falando com a interface de loopback?

— Random832

Sobre a sua pergunta, o problema é que o TCP não suporta desabilitar essas "otimizações", mesmo que de alguma forma esteja "ciente de sua posição" como um fluxo interno, não pode fazer nada. O problema aqui é que o comportamento adaptativo externo interromperá o interno, que tentará se adaptar diminuindo a retransmissão, por exemplo, embora o fluxo TCP externo já esteja se adaptando a isso.

— Shadok 19/03/12

Eu estava pensando no caso em que é uma conexão TCP encapsulada normal, não "TCP sobre IP sobre PPP sobre TCP" - nesse caso, não há realmente uma segunda pilha de protocolo TCP - o ssh está apenas encaminhando um fluxo de bytes. E eu não quis dizer "ciente de sua posição como um fluxo interno", quis dizer como nessa situação ele teria uma interface de loopback (a porta local ssh está ouvindo) como destino.

— Random832

O OP falou sobre "alguns sites", presumi que ele estivesse fazendo HTTP sobre SocksV5 através de SSH, o que significa que ele estava fazendo TCP sobre TCP (o próprio SSH é TCP e o HTTP dentro do túnel flui sobre outros fluxos TCP, que estão encapsulados em SSH).

— Shadok 19/03/12

@Shadok Tenho certeza de que suas conclusões não são verdadeiras. apenwarr estava se referindo ao tun/taptunelamento que resulta em tcp-over-tcp. O SOCKSv5 não apresenta os mesmos problemas, mas não funciona de forma transparente com todos os aplicativos (enquanto o tun / tap é apenas outra interface de rede para que possa ser manuseado de forma transparente).

— JPC

Uma coisa que consigo pensar na cabeça é o desempenho. Mas isso realmente depende do tipo de coisa que você está encapsulando.

— Marcus
fonte

Que tipo de performance? Largura de banda? Atualmente, eu o uso para acessar o hulu e alguns vídeos do youtube bloqueados.

— Nils Riedemann

Sobrecarga da CPU (criptografia) e possivelmente latência, provavelmente.

— XTL

Normalmente, descobri que a latência aumenta, mas a taxa de transferência é boa (90%) do normal com o tunelamento SSH. Certifique-se de definir ServerAliveIntervalpara evitar desconexões e envolva-o em um script para continuar reiniciando o túnel em caso de falha.

A principal desvantagem é que é um túnel de porta por TCP, a menos que você use SOCKS. O SOCKS é bom, mas a latência parece aumentar ainda mais com ele e, é claro, nem todo cliente suporta o SOCKS.

Pode ser necessário executar GatewayPortsno cliente ou servidor SSH para permitir que outras pessoas se conectem através do seu túnel. No servidor, isso requer acesso root ao sshd_config.

A principal advertência de desempenho (como outros observam) é que as conexões não confiáveis provavelmente não se saem bem com essa abordagem, pois os algoritmos do TCP não reagem bem sob o encapsulamento.

Dito isto, o SSH parece "fazer a coisa certa" na maioria das vezes.

— Stu Charlton
fonte

O problema com as conexões não confiáveis observadas provavelmente está relacionado ao aumento da latência e dos handshakes que precisam ser repetidos quando as conexões caem. O encaminhamento de porta SSH não faz o encapsulamento tcp-over-tcp.

— Jpc #