I find it valuable to memorise the fact that the terms "remote" and "local" are referring to which end of the tunnel is doing the listening; with local forwarding, the local machine, i.e. the one you are SSH'ing from, is the one that's listening, while with remote it's the remote machine (server) that listens.
This is so true, I used to have trouble remembering how to do ssh tunneling w/o looking it up and then one day someone pointed out to just remember wether you are using a remote or local tunnel the listening side of the tunnel always comes first. After that it was easy sailing.
I really like openVPN better for this stuff. Have a RPI listening on just about every port that exists TCP and UDP (via IP tables rules). I travel a lot. Sometimes places like China. I always get out. Of course I keep the RPI outside my local DMZ for security reasons.
+1 for this approach if you need access from China. SOCKS won't help if you have poisoned DNS, so if using ssh you might want to run squid on your server, and use HTTP proxy instead.
Re: using multiple ports for OpenVPN, I do this too, and it works well in conjunction with remote-random configured on the client side. In my experience using the same IP/port for OpenVPN for long periods of time can get that combo blocked after a few days. TCP seems to have better throughout than UDP for me, although this didn't used to be the case.