Odd SOCKS

As a follow-on from my last post I’ll discuss the networking on my Fedora 11 machine. I’m not a massive networking geek; I know quite a bit, but mostly through trial-and-error as a step to getting something else working. For this reason I’ve never introduced something unnecessary into the mix for its own sake, and thus all I knew about SOCKS was that there’s version 4 and 5 in the wild, and it’s used by The Onion Router. Since I’ve always used TOR for HTTP, and used a privacy-filtering-type proxy like Privoxy to handle the HTTP<->SOCKS tunneling, I’ve never bothered learning more about it.

Now, my office machine is set up to route through a SOCKS proxy on a different machine on the ethernetwork. Web browsing is simply a matter of Firefox’s Edit->Settings->Advanced->Network->Settings. However, Thunderbird (which has exactly the same connection changing interface as Firefox) can’t connect through IMAP this way. This is due to IMAP not going over HTTP. The same applies to SVN, ping, etc. There is a solution though, which is to use connect-tunnel to run a local server for redirecting calls to any port through a HTTP proxy. Running a connect-tunnel command like “./connect-tunnel -P 192.168.1.1:1080 -T 10234:mysite.com:3690” will allow us to run a command like “svn co svn://localhost:10234” which will think it’s checking out a subversion repository from the current machine on port 10234, when in fact it is being routed through a HTTP proxy on port 1080 of 192.168.1.1 to the remote machine at mysite.com on port 3690.

This is great, but the proxy isn’t HTTP, it’s SOCKS, so we need some way of tunneling this HTTP connection through SOCKS (so, in this example, we’d have a SOCKS proxy redirecting HTTP traffic which is encapsulating an SVN connection). This was fine for Firefox, which has built-in facilities to redirect over a SOCKS proxy, but not all applications do (especially if they don’t even know they’re being tunneled through HTTP in the first place!). This is where we use a “socksify” program, which intercepts HTTP requests and redirects them without the application which made them knowing about it. There are a few of these, for example Dante contains such functionality and is in Debian, but unfortunately it isn’t in Fedora and I was after something I wouldn’t have to compile (due to dependency hell). Fedora does contain tsocks which is pretty simple to set up and use, and worked for some applications. It could be used either via “tsocks my_application_name” (eg. “tsocks evolution” to run the Evolution mail reader through SOCKS), or via adding its library to the LD_PRELOAD environment variable, which affects all subsequently executed applications (eg. put it in your .bash_profile). However I found it didn’t work for some programs. I then tried proxychains, which I’m pretty happy with. It is called in a similar way to tsocks, eg. “proxychains evolution”, and works in some cases where tsocks doesn’t.

Aside from this I also recommend setting environment variables, such as “http_proxy” (which, once again, can be done via .bash_profile) and your desktop’s settings (I found Gnome’s to be useless here, since I didn’t come across any application which actually paid attention to it, but KDE applications consistently adhere to this setting, even if not all of them wind up working properly). For Subversion the /etc/subversion/servers file is a good place to put HTTP proxy settings, and try using http:// for the repository address, as this may be configured to work as well as svn://.

Basically, try everything you can find, try them in combination and try layering/tunneling them. Even if you don’t seem to need one method now, the next application you try may need it ;)</->