Virtual private networks (VPN) letremote users connect back to corporate networks over encrypted links. Many VPNsare built with proprietary technology and can be tricky and expensive to setup. For a small business or an individual who needs a simple way to securelyaccess remote networks, setting up a true VPN might be prohibitively expensivein terms of both money and time. Let's look at two simple approaches that bringyou transparency without the cost. All you need is Secure Shell (SSH) access toa server on the network you're trying to access.
SSH, a simple and common way toaccess remote networks without a VPN, can be used to get a command prompt on aremote machine. Through SSH extensions such as Secure File Transfer Protocol (SFTP)and Secure Copy (SCP), you can transfer files to and from a remote machine.
A technique known as portforwarding or SSH tunneling opens up even more possibilities. Forexample, you could set up a port forward for accessing an Internet MessageAccess Protocol (IMAP) server, Virtual Network Computing (VNC) server, or Webproxy that is behind a firewall. OpenSSH even allows you to create a DynamicForward,which essentially acts as a SOCKS proxy. The nice thing about this feature isthat you can tunnel a variety of services over a single secure port andconnection. The drawback, however, is that the proxying is not transparent tothe client. All client programs that need access to services behind the firewallneed to be configured to use the proxy. That means that you have to go into allof your Web browsers, email clients, VNC clients, and so on and configure themto use the proxy -- and not necessarily all programs support proxies. Forexample, recently I tried to use Evolution on my home Linux machine to accessmy IMAP server at work and found that I could not get it to work through aproxy. Furthermore, once you've set up all your programs to use a proxy, whatdo you do when the proxy is no longer available? You have to disable that proxyin all your client programs.
Ideally, you'd have a transparentway to securely access services on a protected remote network. You don't wantto have to configure every client program separately. The beauty of VPNs is thatthey do exactly that -- once you're connected, applications just work, with noextra configuration.
The Transparent SOCKS proxyinglibrary
The Transparent SOCKS (tsocks)proxying library is a simple piece of software that builds on the SOCKS proxyapproach with some clever tricks to make access more transparent and easy. Itallows non-SOCKS-aware applications to use SOCKS proxies by intercepting thecalls that applications make to networking code and routing the traffic througha SOCKS server as necessary. You don't need to understand exactly how this isaccomplished, but if you're interested and you understand a bit about Unixprogramming, the short explanation is that tsocks provides a shared librarywith alternative implementations of the BSD socket functions, and it uses the LD_PRELOAD environment variable to force applications to use the newsocket functions.
Before you try to use tsocks, youneed to fire up an SSH tunnel for tsocks to use:
$ ssh -D 1080remoteuser@host1.firewalleddomain.net
This creates a SOCKS 4 server on theremotehost.com, which you can access at port 1080 on the local machine. Youcould simplify this previous command by putting directives in your~/.ssh/config file; check out the man page for ssh_config for more details.
Installing and using tsocks on myUbuntu Linux machine was a snap. First, I installed the package using apt-get, then edited my /etc/tsocks.conf file:
path{
reaches = 207.126.239.0/255.255.255.0
server = 127.0.0.1
server_type = 4
server_port = 1080
}
This simple configuration tellstsocks to route all traffic destined for 207.126.239.x to a SOCKS 4 server on127.0.0.1:1080 (the localhost, port 1080). Of course, you will have to changethe "reaches" parameter to match the IP address and netmask of thenetwork you're trying to access.
If you have a more complex setup,chances are that tsocks can handle it. You can specify multiple paths in thetsocks.conf file, as well as a default SOCKS server, for addresses that don'tmatch any of the listed paths. You can also provide a "local"directive that specifies local networks that tsocks should never use a proxyfor. For example, a suitable "local" specification for my homenetwork (and many other home networks) would be local = 192.168.1.0/255.255.255.0
You can use tsocks in two ways. Thesimplest way is to simply preface your commands with "tsocks":
$tsocks ssh host1.firewalleddomain.net
$tsocks evolution
$tsocks firefox
However, this method is not exactlytransparent, and you can easily forget. The following alternative way of usingtsocks is more convenient:
$source /usr/bin/tsocks on
$ssh host1.firewalleddomain.net
$evolution
$firefox
$source /usr/bin/tsocks off
While tsocks is turned on, you canaccess the remote network transparently and run applications as you usually do.
Virtual Tunnel
Virtual Tunnel (VTun) is a more complex solution, but it creates more of a VPN-likeexperience. Whereas tsocks relies on environment variables that are local toeach process on the system, using VTun involves loading a kernel module andmodifying the system IP routing table. Using VTun, you can create a virtualnetwork interface through which IP traffic destined for the remote privatenetwork is routed. Individual applications need to know nothing of the virtualnetwork interface or the system IP routing tables.
To illustrate, I'll show you how Iset up VTun to securely access my home network. Only the SSH port (port 22) isopen to the outside. All traffic is tunneled through SSH encrypted.
First, I opened an SSH tunnel to myhome Linux server. Both the VTun client and server were configured to use port9000, so I set up port 9000 on the client machine to forward (through SSH) toport 9000 on my home Linux server:
client:$ ssh -L 9000:localhost:9000marc@server
Then I started a VTun server on myhome Linux server:
server:$ sudo vtund -n -s -f vtund-server.conf
The -n option tells vtund not todaemonize, which makes debugging easier since messages will be logged to theconsole. The -s option tells vtund to act as a server. The -foption specifies that vtund-server.conf is the configuration file to use. Ifyou get an error about the "tun" kernel module not being loaded, thenyou may need to load the module using modprobe or insmodon a Linux system or kldload on a FreeBSD system.
Then I started a VTun client on theclient machine:
client:$ sudo vtund -n -f vtund-client.confmy_tunnel localhost
Again, if the "tun" kernelmodule is not loaded, you may need to preface this by loading the kernelmodule, as mentioned in the previous paragraph.
The effect of all of this is that Icreated a sort of virtual private peer-to-peer network with an address of10.3.0 and these mappings:
| Address | Hostname |
| 10.3.0.1 | server |
| 10.3.0.2 | client |
Each machine still belongs to thephysical network(s) that they belonged to before. They now also belong to thisadditional private network. Ordinarily, a machine with one network adapter canonly belong to one network. However, in this case, VTun makes use of a virtual"tun" adapter that the "tun" kernel module creates. Thisallows each machine to simultaneously exist on a physical network (via thephysical network adapter) and a virtual network (via the "tun"virtual network adapter). A machine that exists on more than one network is ineffect a router, and thus directing traffic properly requires modifying the networkroute tables. Lines in the VTun configuration files automatically create theroutes when the VTun client connects to the VTun server. You can see theevidence of this by looking at the network route tables on both machines:
client:$netstat -r | grep tun
10.3.0.1 10.3.0.2 UH 0 78 tun0
server:$netstat -r | grep tun
10.3.0.2 * 255.255.255.255 UH 0 0 0 tun0
The minor differences in the formatof the netstat output between the two machines are due to the fact that myclient is running FreeBSD and my server is running Linux.
At this point, the two machines areconnected and act as if they are on the same network. Thus, on the client youcan connect to the server:
client:$ ssh 10.3.0.1
You can also connect from the serverto the client:
server:$ ssh 10.3.0.2
If you run into problems, goodcommands to use for troubleshooting are netstat -r, route,tracepath, and traceroute.
I've only discussed connecting twomachines, one on each network. If more machines are involved, then things get abit more complex, because all of the involved machines will need proper entriesin their route tables, and the VTun machines will need to act as gateways,forwarding network traffic between their interfaces and doing network addresstranslation.
Thanks...
Monday, November 22, 2010
Anu
