Y a-t-il des inconvénients dans le tunneling SSH?

J'ai récemment "acheté" un VPS que je veux utiliser comme proxy pour pouvoir utiliser certains sites et des choses que je ne peux pas atteindre en Allemagne.

Étant donné que j'étais encore trop paresseux pour configurer Squid et OpenVPN (ce que je pense actuellement nécessaire), j'utilise le tunnelage ssh.

Maintenant, après quelques semaines, je me suis demandé si le tunnel ssh ne convenait pas, ou - et c'est ma question - s'il y a des mises en garde / contras / inconvénients que je dois avoir à l'esprit?

ssh proxy ssh-tunneling Nils Riedemann
la source

Pour ce que ça vaut, OpenVPN est extrêmement facile à configurer à l'aide d'une clé statique si vous passez de Linux à Linux. C'est un peu plus compliqué si l'une de vos machines est Windows, mais c'est faisable. bit.ly/ujkD2

transistor1

Réponses:

Le problème de performances survient lorsque vous tunnelisez TCP sur TCP car vous avez deux couches effectuant des corrections adaptatives (démarrage lent, évitement de l'encombrement, retransmission rapide, voir RFC2001 ).

Pas bien conscients les uns des autres, ils éprouveront de grandes difficultés si vous avez une perte sur la connexion externe.

Cette page décrit le phénomène en détail.

Éditer:

Plutôt que de s'en tenir au problème TCP sur TCP, jetez un œil à sshuttle qui l'empêche.
Jetez un œil à la section intitulée " Théorie du fonctionnement " pour encore plus de détails sur cette situation.

Shadok
la source

La couche intérieure ne sait-elle pas qu'elle parle à l'interface de bouclage?

Random832

À propos de votre question, le problème est que TCP ne prend pas en charge la désactivation de ces «optimisations», même s'il était en quelque sorte «conscient de sa position» en tant que flux interne, il ne peut rien faire. Le problème ici est que le comportement adaptatif externe perturbera le comportement interne, qui tentera de s'adapter en ralentissant la retransmission par exemple, bien que le flux TCP externe s'adapte déjà à cela.

Shadok

Je pensais au cas où il s'agit d'une connexion TCP tunnelée normale, pas de "TCP sur IP sur PPP sur TCP" - dans ce cas, il n'y a en fait pas de deuxième pile de protocoles TCP - ssh ne fait que transmettre un flux d'octets. Et je ne voulais pas dire "conscient de sa position en tant que flux interne", je voulais dire comment, dans cette situation, il aurait une interface de bouclage (le port local ssh écoute) comme destination.

Random832

OP a parlé de "certains sites", j'ai supposé qu'il faisait HTTP sur SocksV5 via SSH, ce qui signifie qu'il fait TCP sur TCP (SSH lui-même est TCP et le HTTP à l'intérieur du tunnel circule sur un autre flux TCP, qui est encapsulé dans SSH).

Shadok

@Shadok Je suis sûr que vos conclusions ne sont pas vraies. apenwarr faisait référence au tun/taptunneling qui se traduit par tcp-over-tcp. SOCKSv5 ne souffre pas des mêmes problèmes mais ne fonctionne pas de manière transparente avec toutes les applications (alors que tun / tap est juste une autre interface réseau afin qu'il puisse être géré de manière transparente).

jpc

Une chose à laquelle je peux penser est la performance. Mais cela dépend vraiment du genre de choses que vous tunnelez.

Marcus
la source

Quel genre de performance? Bande passante? Je l'utilise actuellement pour accéder à hulu et à certaines vidéos youtube qui sont bloquées.

Nils Riedemann

Surcharge du processeur (chiffrement) et éventuellement latence, très probablement.

XTL

Normalement, j'ai constaté que la latence augmente, mais le débit est correct (90%) de la normale avec la tunnellisation SSH. Assurez-vous de définir ServerAliveIntervalpour éviter les déconnexions et enveloppez-le dans un script pour continuer à redémarrer le tunnel en cas d'échec.

Le principal inconvénient est qu'il s'agit d'un tunnel de port par TCP, sauf si vous utilisez SOCKS. SOCKS est bien, mais la latence semble augmenter encore plus avec elle, et bien sûr, tous les clients ne prennent pas en charge SOCKS.

Vous devrez peut-être exécuter GatewayPortssur le client ou le serveur SSH pour permettre aux autres de se connecter via votre tunnel. Sur le serveur, cela nécessite un accès root à sshd_config.

La principale mise en garde concernant les performances (comme d'autres le notent) est que les connexions non fiables ne conviennent probablement pas bien avec cette approche, car les algorithmes de TCP ne réagissent pas bien sous l'encapsulation.

Cela dit, SSH semble "faire la bonne chose" la plupart du temps.

Stu Charlton
la source

Le problème avec les connexions non fiables que vous observez est probablement lié à la latence accrue et aux prises de contact qui doivent être répétées lorsque les connexions tombent. La redirection de port SSH ne fait pas d'encapsulation tcp-over-tcp.

jpc