First, it’s Jabber, then the open standard XMPP, then libjingle (the thing behind GTalk and several other VoIP applications). An essential part of VoIP, VPN, P2P technologies is ICE (Interactive Connectivity Establishment), techniques that help computers behind routers connect to each other…
ow it’s Christmas time, but this has nothing to do with Xmas except the name: LIBJINGLE. For a long time, I’ve been trying to expose one of my home servers to the Internet. Normally, you’d just need to setup dynamic DNS to update the router IP address and NAT (Network Address Translation) to forward one port onto the server. Unfortunately, my ADSL router is a special (hardware / firmware) version OEM-ed by Comtrend to FPT (the local ISP), and no matter how I configure, NAT is simply forbidden. I’ve tried various techniques to punch holes (TCP, UDP) through NAT, such as this pwnat, a trick to fool the router using ICMP echo packet. However, due to different router implementation & configuration, no technique is known to work in 100% of the cases, as pointed out in this paper.
The NAT traversal problem repeats itself in various applications: VoIP, P2P network, VPN (Virtual Private Network), networking for games… Current technologies take a dual approach in solving this: a certain kind of ICE (Interactive Connectivity Establishment) when two peers can directly connect to each other, or a central server in between in case the routers forbid it all. Such as with libjingle, Google Talk servers are used in case a direct connection can not be made. Remember the Skype’s global disconnect problem lately? It’s the same sort of problem with ‘central servers’. With these knowledge in hands, it’s turned out that setting up a VPN to access my home servers from anywhere is quite easy as follow.
Build libjingle and fwd (a simple wrapper around libjingle). Building libjingle on Debian is a nightmare (yes, it’s a real nightmare, libjingle 0.4 has a nasty code base). It took me a whole day, and after changing several dozens of places in libjingle’s code, I got it compiled and run correctly (please refer to this post for some initial building instructions). Once the transportation channel has been established with libjingle, a SSH tunnel is setup to forward a port on your roaming laptop to the SSHD port (22) on the home server:
# port 2222 to port 22 of another machine (‘buffalo’)
./fwd -u email@example.com -p password 2222:buffalo:22
# on your laptop from anywhere on the Internet, almost
# the same command, but the -L option for client mode
./fwd -u firstname.lastname@example.org -p password -L 2222:buffalo:22
# then connecting to the ‘buffalo’ box is just setting up
# a SSH session, thus a SSH tunnel inside another SSH tunnel
ssh root@localhost -p 2222
The technique works flawlessly, I can now access my home VPN from anywhere. Basically you’re inside a VPN now, so various setups at home would transparently work (strictly speaking, this is still not real VPN as TCP, UDP broadcasting may not work, but most regular connections would). Next, I proceed to exposing some of my home services onto the outside world. Again SSH proves to be such a very very powerful tool as you can build SSH tunnel inside another tunnel, which can be nested for several layers (ssh is actually means ssshhh! – sign used to signal lowering one’s voice I think):
SFTP (Secured File Transfer Protocol) is built on top of SSH, and SFTP is native to any Linux (for Windows, we could use WinSCP, and for Mac is Cyberduck). Just connect to one end of the tunnel like with SSH (localhost:2222) and on the other end of the (nested) tunnels, we get access to the whole file system.
SSH is built-in into SVN (I often use SVN by command line rather than WebDAV). Something like: svn co svn+ssh2222://user@localhost/svn/project would do the job, where ssh2222 is defined in your subversion’s configuration file (under the [tunnels] section) as: ssh -p 2222, this instructs the secured shell to connect to the host, then call the ad-hoc svnserve instead of a real web server.
This is very useful since if helps surfing the Internet securely while you’re in public. After setting up Squid web proxy on the same server, the command: ssh -N -L 8080:localhost:8888 root@localhost -p 2222 tells SSH to forward the local port 8080 to the proxy port 8888, then pointing Firefox at localhost:8080 would secure our traffic more than enough (2 levels of nested tunnels and 2 levels of port-forwarding).
I use this to casually enjoy my music collections while not at home. Install FireFly (formerly mt-daapd) music streaming server and forward the default port 3689, then I can listen my favorites songs anywhere using Rhythmbox (Linux). And since the protocol (daap) is originated from Apple, listening is also natively available on any Mac machines using iTunes.