ssh -D localport -fN user@vps
Then for chrome/chromium:
If you need multiple instances running different proxy connections use different data directories like:
chromium --user-data-dir="other-dir" --proxy-server="socks5:localhost:localport"
Edit: sshuttle covers more than port forwarding but the article was geared at browsing the web through a vps hence my comment.
For that, you need to change your routing table so that anything destined for 0.0.0.0 goes through the tunnel.
This is basically what sshuttle does.
One downside is that SSH tunnels can only forward TCP, not UDP, traffic. sshuttle adds special handling for DNS (which is UDP) but any other UDP communication will not work.
Come on. As always, naivete is dangerous: until you can't rely on anything but promises, whatever they say can't be trusted.
They also go out of their way to accept anonymous payment sources, something most VPN providers don't bother with.
Enter API key creds, it makes the box for you, sets it up, and hands you a config you can use for your client of choice. (The script is open source for those of you that don't want to enter creds - we don't store them, and actually remove access whenever we can; for example, we delete our own SSH key from DO because they let us).
I will check out Viscosity, as I don't particularly like having to use the config files directly each time I want to make a small change. Do you know whether the performance (throughput, latency) differs between the two?
I have been using it to build an VPN network with cheap VPS from different providers and found it really reliable and easy to set up. Besides that, once used it to watch some south park at UK and also worked wonders, no need to even setup a proxy, just route your traffic through the interface.
Link for the interested: http://www.tinc-vpn.org/
What is great is it's able to re-route around any peering issues suffered by local ISPs. Say you have three nodes in the US, UK, JP and your JP ISP loses routing to your US ISP. If both can still route to the UK then tinc will automatically keep traffic flowing.
But now that I haven't setup tinc for awhile I have no idea how to do it again and the examples are horrible.
Every node needs to have a copy of every other node's configuration file and it is annoying to add a file to N servers when you are adding the N+1th server.
Now, I must agree on that, it might not be a friendly solution for dead easy routing to an exit node as a proxy with dns-tunneling built in. I just wanted to know why tinc does not get enough love, and you answered accordingly. But if you are building a serious network I do think tinc hits the sweet spot between being easy and allowing for any network you can think of without being tied to a particular server provider that might offer private IPs.
As for the configuration I use git, which makes it super easy to setup the N+1th server. None of the private keys are committed to the repo, of course. My infrastructure is not that big so I am still doing some things by hand, but it should be easy to automate some parts by using git hooks + puppet|ansible|chef.
About the protocol I do not understand why it would be a problem, other than not being ssh or the possibility of being filtered over the network. Doesn't most VPN solutions have their own protocol?
The problem with a non-vetted protocol is that it could have flaws.
I have a similar setup on my Android phone, by using Vx ConnectBot (http://connectbot.vx.sk/) plus ProxyDroid (https://github.com/madeye/proxydroid).
If anyone need some of the advanced features provided by OpenVPN, I can suggest this script: https://github.com/Nyr/openvpn-install
I've successfully used it to install OpenVPN several times, and it's mostly effortless.
As for the VPSs, I can suggest http://lowendspirit.com/, awesome owner and can't beat the 3€/year (yes, year) price. You don't get a public dedicate ipv4, but if you need only a VPN then it's not really needed.
Another neat trick is having a wildcard for a host to set global options, like compression.
Here's a little sample of what my ~/.ssh/config looks like:
Free != lazy
Also, lazy people dislike having to manually configure their web clients.
It's free for a low number of users, though. And it also has clients for Android.
I find that I get better speeds through OVPN than through an SSH tunnel. YMMV :)
" OpenVPN is designed to operate optimally over UDP, but TCP capability is provided for situations where UDP cannot be used. In comparison with UDP, TCP will usually be somewhat less efficient and less robust when used over unreliable or congested networks."
More detailed info:
Another noteworthy script for instantiating an openvpn server quickly is this:
Again, this has emphasis on scrambled connections (ie china)
I enabled masquerading on the server for ppp0 interface and then I'm doing this on the client:
route del default
route add -host vps.host gw my_local_gateway eth0
pppd pty "ssh vps.host -t -e none -o 'Batchmode yes' sudo /usr/sbin/pppd" 192.168.16.1:192.168.16.254 local nodetach silent
route add default ppp0
Yes. You'll get all kinds of performance weirdness running TCP-over-TCP
Thanks for the link, it's really useful to know this.
Your VPS, on the other hand, is your VPS. If the police comes to your server, the company has no reason to hide who you are. That's 0% deniability, they'll come straight to you as the owner of the server. You'll then have to prove somehow it wasn't you (and you were, so it's a tough one). At the very least you'll get lawyers involved.
They don't need logs on the box to track the activity of the box.
I have used both techniques discussed, mostly for being able to download stuff I purchased on iTunes while being over seas.
Not poor yet, but on my way to being there it'd seem.
Given me a LOT to think about. Thank you all. :)