sshuttle hilft einem in bestimmten Situationen, mit wenig Aufwand in oder über andere Netze zu connecten. Für Ressourcenhungrige Dinge wie Streaming oder Filesharing beispielsweise ist es nicht sehr brauchbar. 4-7MB/s war bisher das höchste an Speed, was ich erreichen konnte; Bei deutlich schnellerer Anbindung drumrum.
Es ist aber eine wirklich schöne Lösung, z.B. "mal eben" in ein Kundennetz per SSH zu verbinden, ohne an Routern, Clients und Servern etwas konfigurieren zu müssen.
Es ist KEINE VPN Lösung für den regulären Betrieb.
Aber kommt es - je nach Anwendung - nicht dennoch auf TCP over TCP raus? Wenn ich durch den Tunnel sonstwohin connecte sind die Pakete doch schon mehrfach gesplittet, verpackt und mit Overhead versehen... Besser und schneller wird davon sicher nix
sshuttle ist kein TCP over TCP! sshuttle nutzt den Kernel um Daten auf Session-Ebene (iptables REDIRECT) weiterzuleiten, d.h. der Kernel öffnet lokal die TCP-Pakete, sendet nur die Nutzdaten über den Äther und der Server nutzt eine eigene TCP-Session um die Daten an das Ziel zu senden. Das ist kein TCP over TCP und entsprechend auch nicht für dessen Probleme anfällig.
Zu dem Thema der obligatorische Hinweis auf
http://sites.inka.de/bigred/devel/tcp-tcp.html
Das ist richtig und wichtig!
sshuttle hilft einem in bestimmten Situationen, mit wenig Aufwand in oder über andere Netze zu connecten. Für Ressourcenhungrige Dinge wie Streaming oder Filesharing beispielsweise ist es nicht sehr brauchbar. 4-7MB/s war bisher das höchste an Speed, was ich erreichen konnte; Bei deutlich schnellerer Anbindung drumrum.
Es ist aber eine wirklich schöne Lösung, z.B. "mal eben" in ein Kundennetz per SSH zu verbinden, ohne an Routern, Clients und Servern etwas konfigurieren zu müssen.
Es ist KEINE VPN Lösung für den regulären Betrieb.
Der hier völlig fehl am Platz ist. Das ist ein transparenter Proxy kein tcp over tcp.
Aber kommt es - je nach Anwendung - nicht dennoch auf TCP over TCP raus? Wenn ich durch den Tunnel sonstwohin connecte sind die Pakete doch schon mehrfach gesplittet, verpackt und mit Overhead versehen... Besser und schneller wird davon sicher nix
sshuttle ist kein TCP over TCP! sshuttle nutzt den Kernel um Daten auf Session-Ebene (iptables REDIRECT) weiterzuleiten, d.h. der Kernel öffnet lokal die TCP-Pakete, sendet nur die Nutzdaten über den Äther und der Server nutzt eine eigene TCP-Session um die Daten an das Ziel zu senden. Das ist kein TCP over TCP und entsprechend auch nicht für dessen Probleme anfällig.