Live data from Hacker News

Sshuttle - tunnel all your traffic through ssh

github.com

21–30 of 70 posts

Re: Sshuttle - tunnel all your traffic through ssh

#21

+1 for a reference to slirp, which let you turn a dial-in connection to a Unix terminal into a real internet connection back in the days when your University would give you a terminal connection but not a PPP connection.

I remember SLIRP -- and The Internet Adapter.

Re: Sshuttle - tunnel all your traffic through ssh

#22

Earlier quoted context omitted.

To use OpenVPN you have to install extra software on the server and edit configuration files and set up keys. Not sure how that is easier?

The setup cost is higher, true, but the performance is better. TCP-over-TCP does not work well.

"sshuttle assembles the TCP stream locally, multiplexes it statefully over an ssh session, and disassembles it back into packets at the other end. So it never ends up doing TCP-over-TCP. It's just data-over-TCP, which is safe."

I haven't bothered to look at how this is actually implemented, so I can't comment on how it actually works.

Re: Sshuttle - tunnel all your traffic through ssh

#23

Would this circumvent the checks Hulu does for example by forcing Flash to always connect directly. i.e using SOCKS Proxy will not work with Hulu but using full VPN will, so how will sshuttle rate ?

Full VPN, but it doesn't work on windows.

Also, if you start streaming Hulu through a shell account, there is a good chance that your shell account provider will notice and possibly get angry.

Re: Sshuttle - tunnel all your traffic through ssh

#25
post #24

[deleted]

It doesn't do TCP-over-TCP. From the README:

sshuttle assembles the TCP stream locally, multiplexes it statefully over an ssh session, and disassembles it back into packets at the other end. So it never ends up doing TCP-over-TCP. It's just data-over-TCP, which is safe.

Re: Sshuttle - tunnel all your traffic through ssh

#26
post #25
post #24

[deleted]

It doesn't do TCP-over-TCP. From the README: sshuttle assembles the TCP stream locally, multiplexes it statefully over an ssh session, and disassembles it back into packets at the other end. So it never ends up doing TCP-over-TCP. It's just data-over-TCP, which is safe.

I must read more carefully, I retract my comment.
Post reply on HN