on server and local machine:
sudo gem install rtunnel
If you don't have root access you can run the above commands without
sudo and rubygems will install the gem into your
~/.gem directory. If you go this route, make sure you add the gems executable dir to your path.
on server (myserver.com):
on your local machine:
rtunnel_client -c myserver.com -f 4000 -t 3000
This would reverse tunnel myserver.com:4000 to localhost:3000 so that if you had a web server running at port 3000 on your local machine, anyone on the internet could access it by going to http://myserver.com:4000
Logging (verbosity) level
Both the server and the client support 4 levels of logging - 'debug', 'info', 'warn', 'error'. The -l parameter sets the logging level. The default level is 'error'. For example:
rtunnel_server -l debug
starts a server that will output debugging information.
RTunnel can be configured to use ssh keys to control access to the server. A ssh key (generated by ssh-genkey) is required on the client, and the server must have a list of authorized keys (using the format of known_hosts.) The keys are used to authenticate clients and guarantee data integrity. For performance reasons, encryption is not done.
rtunnel_server -a ~/.ssh/known_hosts
rtunnel_client -c myserver.com -f 4000 -t 3000 -k /etc/ssh/ssh_host_rsa_key
If you're concerned about security, you probably want to restrict the range of ports that clients can open up on the rtunnel server.
rtunnel_server -p 3000 -P 3999
restricts clients to using ports 3000-3999 for reverse tunnels.
This client/server allow you to reverse tunnel traffic. Reverse tunneling is useful if you want to run a server behind a NAT and you do not have the ability to use port forwarding. The specific reason I created this program was to reduce the pain of Facebook App development on a crappy internet connection that drops often. ssh -R was not cutting it.
How does reverse tunneling work?
- tunnel_client makes connection to tunnel_server (through NAT)
- tunnel_server listens on port X
- internet_user connects to port X on tunnel server
- tunnel_server uses existing connection to tunnel internet_user's request back to tunnel_client
- tunnel_client connects to local server on port Y
- tunnel_client tunnels internet_user's connection through to local server
- establish connection: tunnel_client --NAT--> tunnel_server
- reverse tunnel: internet_user -> tunnel_server --(NAT)--> tunnel_client -> server_running_behind_nat
How is this different than normal tunneling?
With tunneling, usually your connections are made in the same direction you create the tunnel connection. With reverse tunneling, you tunnel your connections the opposite direction of which you made the tunnel connection. So you initiate the tunnel with A -> B, but connections are tunneled from B -> A.
Why not just use ssh -R?
The same thing can be achieved with ssh -R, so why not just use it? A lot of ssh servers don't have the GatewayPorts sshd option set up to allow you to reverse tunnel. If you are not in control of the server and it is not setup correctly then you are SOL. RTunnel does not require you are in control of the server. ssh -R also has other annoyances. When your connection drops and you try to re-initiate the reverse tunnel sometimes you get an 'address already in use error' because the old tunnel process is still laying around. This may require you to kill the existing sshd process. RTunnel does not have this problem.