This article will explain briefly how you still can use SSH, Telnet, PPP, . . . or other protocols
when you find yourself trapped behind a very restrictive firewall.
httptunnel creates a bidirectional virtual data path tunnelled in HTTP requests.
The requests can be sent via an HTTP proxy if so desired.
If WWW access is allowed through an HTTP proxy, it's possible to use httptunnel and, say,
telnet or SSH to connect to a computer outside the firewall.
This program is mostly intended for technically oriented users. You should know what to do.
You can download httptunnel
here . Installation is pretty straightforward :
- sh configure
- make
- make install
I succesfully build the software on Slackware 9.1 (kernel 2.4.24), FreeBSD 4.9 and FreeBSD 5.2.
Afterwards, you should have 2 resulting binaries, being htc, the client part, and hts, the server part.
You have to install the software on both hosts. That is, you need hts on the remote host, and htc on the client.
··
On the REMOTE host
This is the machine you want to connect to. Say, it runs an SSH daemon listening at port 2222. At host REMOTE,
start hts like this :
[homer@stargate ~]$ hts -F localhost:2222 8888
|
This will forward an incoming connection at port 8888 to port 2222 (=your SSH daemon).
Use netstat to check if hts is listening at port 8888. You are of course free to choose your port number.
··
On the LOCAL host
This is the machine you want to connect from to the REMOTE host. At host LOCAL, start htc like this :
[bart@springfield ~]$ htc -F 3000 -P PROXY:8000 REMOTE:8888
|
or, if using a buffering HTTP proxy:
[bart@springfield ~]$ htc -F 3000 -P PROXY:8000 -B 48K REMOTE:8888
|
This will tunnel a connection made to port 3000 on LOCAL, through the proxy, to port 8888 on the REMOTE host.
Again, use netstat to check if htc is listening at port 3000. You are of course free to choose your port number.
Now you can do this at host LOCAL:
[bart@springfield ~]$ ssh -p 3000 localhost
|
and you will hopefully get a login prompt from host REMOTE.
There is a noticeable slowdown in the network traffic (as compared to a direct ssh connection) , but I found the overall speed to be largely sufficient.
This is of course highly dependant on your network link and traffic.
Up till now, I encountered only 1 small problem : if you disconnect e.g your ssh session, you can't reconnect immediately without
restarting htc but using another port (kill and start again) first. This seems to be because htc disconnects, but the ssh session on the REMOTE host
stays alive for a while. It seems to "die" a few minutes later and then you can connect again without restarting htc.
