Using SSH, SOCKS, tsocks, and proxy settings to create a simultaneous "dual use" work/home computer
The Problem:
Allow one linux workstation to be simultaneously used for both work and non-work purposes so that work and non-work traffic are segregated.The Requirements:
I would like to be able to use the following applications in the corporate environment- VNC
- Web (typically Google Chrome but potentially other browsers as well)
- Email - IMAP, SMTP, LDAP using Thunderbird
- IM - pidgin
As already mentioned here the corporate network has an SSH server that you authenticate and connect to and from there you can reach the other corporate network resources.
I would like non-work related traffic to bypass the corporate network - this is mostly web traffic but might also include things like Spotify, yum updates, and other assorted tasks.
Finally it would be nice (but not essential) to wrap all this up in a handy GUI operation or series of operations.
The Environment:
Fedora Core 16 (x86_64) and Gnome 3.The Solution:
Use SSH, SOCKS, tsocks and Gnome 3 proxy settings to sort out the traffic types.The Implementation:
I've already written about using SSH tunnels to selectively tunnel VNC traffic through a corporate firewall.
In short, one uses the -L switch of the ssh command and issues something like
ssh -L 5906:vncserver.example.com:5906 username@sshserver.example.com
vncviewer localhost:5906
So we simply extend our previous SSH command line to
ssh -L 5906:vncserver.example.com:5906 -D 1080 username@sshserver.example.com
Now we have to solve the problems of how to point the clients to localhost:1080 and, in the case of web traffic, how to segregate the traffic into work-related and non work-related.
I'll discuss these in reverse order.
Writing and using a Proxy Autoconfiguration File:
The filtering, or traffic segregation, is accomplished by means of Proxy Autoconfiguration file which is actually a piece of javascript code. It's easier to show the actual file than it is to describe what it does. Here is my (very simple) file:
function FindProxyForURL(url, host)
{
if (shExpMatch(host, "*.example.com"))
{
return "SOCKS5 localhost:1080; DIRECT";
}
return "DIRECT";
}
The only thing that seems the least bit tricky here is the use of the SOCKS5 token, as many of the examples that you find on the web use the word PROXY which carries with it a different semantic.
This file goes in your home directory - I called mine "~/.proxy.pac".
Now, inform the Gnome Shell about this file by going to System Settings | Network Settings | Network Proxy, then choosing "Automatic" as the option, and specifying the autoconfiguration file as a URL, for example "file:///home/someuser/.proxy.pac".
Setting up tsocks:
tsocks is part of the overall solution and we'll need it in the next section so
sudo yum install tsocks
server = 127.0.0.1
server_type = 5
server_port = 1080
Configuring the Clients:
With Firefox we do what we did for Gnome 3 - go to Preferences | Advanced | Settings and enter the URL for "Automatic proxy configuration URL i.e. "file:///home/someuser/.proxy.pac".
For Thunderbird following analogous steps as described for Firefox "works" except for one thing - the IMAP and SMTP ports are forwarded correctly but the LDAP queries (for address autocompletion) don't seem to be. For this reason I went with a tsocks based solution which forwards all ports to the tsocks server including LDAP. So either start Thunderbird from the command line as "tsocks thunderbird" or create a desktop file in .local/share/applications/mozilla-thunderbird.desktop and to the "Exec" line prepend "tsocks".
Pidgin - At least in my case Pidgin connects to a server outside the corporate firewall so
sudo yum install pidgin
Gnome proxy settings break the Gnome Shell weather extension:
As I pointed out here, the Gnome Shell weather extension cannot execute its queries to the query.yahooapis.com server when the Gnome Shell proxy settings are not set to "none". The weather extension is written in javascript as is the proxy autoconfiguration file. One might thing that this would be a "good thing" but apparently it's a bad thing as bad things happen when these two pieces of javascript collide. There is no known fix or workaround (other than manually going to your favorite weather site to check the weather) - but don't expect it to update your top panel in gnome shell until you turn off proxy settings.Putting all this together with the Gnome Shell:
Up until now we have a complete solution except the SSH tunnel is invoked from the command line. To make things more Gnome Shell friendly grab the Gnome Shell Connection Manager Extension from here or from here, create an entry for example.com, and you will now have a Gnome Shell panel utility that you can just click on and your SSH tunnel will be created for you. One trick in using this utility is that all the extra arguments go in the "host" field so in our working example the "host" is configured as "-L 5906:vncserver.example.com:5906 -D 1080 sshserver.example.com". Note that the username is inserted by the utility before the server name. This assumes the username is the same on the local and remote systems.
The more general solution is to configure a .ssh/config file and point the connection manager to this file. Once this is done all that is needed is to click on the connection manager, click on the particular connection desired, and then type in the password (if the password is of the one-time variety) in the spawned terminal window.
At the same time the Connection is toggled the Network Manager Proxy settings need to be toggled (by the user) and things work as set forth in the requirements section.
At the same time the Connection is toggled the Network Manager Proxy settings need to be toggled (by the user) and things work as set forth in the requirements section.
Comments