Free http tunnel software for linux

HTTPTunnel is a simple client/server application for creating an HTTP tunnel between two machines, optionally via a Web proxy.
This is a small application for tunnelling an arbitrary TCP socket connection over HTTP. It can be used, for example, to tunnel traffic out from behind a restrictive firewall that only allows outgoing HTTP web connections.
The basic idea is that you run an instance of the HTTP Tunnel application locally in client mode, that then connects out to another instance that you run at the remote end of the tunnel in server mode.
You then connect to the local client end of the tunnel with the application whose traffic you wish to tunnel, and all communications are then wrapped in HTTP. The tunnel may also go via a HTTP proxy, either explicitly or transparently.
Enhancements:
- This release includes some major bugfixes and improvements in the tunneling error detection and retransmission code.
- It also introduces support for building and running under Cygwin.

tcptunnel is a simple TCP tunnel written in Perl.

Also is a versatile tcp tunnel. The tcptunnel uses:
- tunnelling through a firewall or proxy
- redirecting tcp connections to other ports or machines
- debugging tcp connections in-place
- packet sniffing

The tcptunnel listens on local port < port > and when a connection is made it connects the other end of the tunnel as follows:
a) With no proxy specified, it connects the other end
to < srvport > on < srv >.
b) With a proxy, it connects to < srvport > on < proxy >.
It then directs the proxy to telnet to < srv >, and then it connects the ends of the tunnel.

prtunnel is a program that can tunnel TCP/IP connections in a variety of ways, including through HTTP and SOCKS5 proxy servers. Some if its possible uses include:
- Tunneling TCP connections from client programs to a remote server through an HTTP or SOCKS5 proxy (useful if youre behind such a proxy and want to use a program that doesnt have native proxy support)
- Tunneling TCP connections from SOCKS-capable client programs through an HTTP or SOCKS5 proxy
- Tunneling TCP connections from an IPv4 client program to an IPv6 server and vice-versa
- Forwarding TCP connections
- Running as a simple SOCKS proxy server
prtunnel project was developed and used under Linux and BSD-based operating systems.
Enhancements:
- A bug that would cause malloc(0) to be called in some situations (which could cause problems on some systems) has been fixed.
- The server timeout, if specified, is now set before the proxy server successfully connects to the remote server, which will prevent the program from hanging if the proxy does not respond to the client.

Cubehub is a simple UDP over TCP tunnel application written in Java. It is designed to help people behind a firewall to connect through a TCP connection and play Quake and other UDP-based games.
SOCKS 4 and 5 are protocols that are supposed to allow users to send data through a firewall. However, they only work like this if the SOCKS server is on the firewall itself. Whilst TCP/IP traffic is frequently permitted through firewalls, UDP/IP (required by most online games) is often blocked. When a SOCKS 5 server relays UDP data (SOCKS 4 does not support UDP), the packets are simply relayed, there is no tunnelling involved.
This application provides a solution, tunnelling the data being relayed by a SOCKS server over one or (for better gaming performance) multiple TCP connections to help applications and games to work from behind a restrictive firewall.
Main features:
- Socks 4/5 server
- TCP and UDP tunnelling over single or multiple TCP connections
- Resilience against individual connection dropping

HTTunnel::Client is a client class for Apache::HTTunnel.

SYNOPSIS

my $hc = new HTTunnel::Client("http://localhost/httunnel") ;
$hc->connect(tcp, $some_host, $some_port) ;

$hc->print(some request) ;
my $some_response = $hc->read(1024) ;

$ch->close() ;

HTTunnel::Client is the client class to Apache::HTTunnel. It allows the creation of a network connection tunnelled through HTTP. All data sent and received during this connection will be transported inside normal HTTP requests.

HTTunnel::Client extends LWP::UserAgent, so all LWP::UserAgent methods are available through HTTunnel::Client.

CONSTRUCTORS

new ( URL, [ARGS] )

Creates an HTTunnel::Client object that will use URL to contact the Apache::HTTunnel server. ARGS are is passed directly to the LWP::UserAgent constructor.

METHODS

connect ( PROTO, HOST, PORT, [TIMEOUT] )

Asks the Apache::HTTunnel server to establish a connection of protocol PROTO to HOST:PORT. An exception is thrown if an error occurs.

Accepted values for PROTO are tcp and udp.

print ( DATA )

Asks the Apache::HTTunnel server to write DATA to the established remote connection. An exception is thrown if an error occurs.
DATA can be a scalar or a list, in which case the list items are concatenated together.

read ( LEN, [TIMEOUT], [LIFELINE], [LIFELINE_CUT_ACTION] )

Asks the Apache::HTTunnel server to read up to LEN bytes from the established remote connection. An exception is thrown if an error occurs.

When trying to read, HTTunnel::Client will establish an HTTP connection to the Apache::HTTunnel server asking that LEN bytes be read. If no data is available after TIMEOUT seconds (the default value is 15 seconds), the HTTP connection is closed by the server and the read method will establish a new one. This will go on until some data or EOF is returned.

Therefore read will return only when some (or no more) data is available to be read (like the regular read).

LIFELINE can be any valid filehandle from which one can read. If used, read will interrupt its connection loop and execute LIFELINE_CUT_ACTION when data (or EOF) is available to be read from LIFELINE. It will then return undef.
LIFELINE_CUT_ACTION wust be a CODE ref. The default value is

sub {die("lifeline cutn")}

These features can be used if you want fork and to start a process that does nothing but reads and returns the data via a pipe. You can then use a second pipe to make sure the reader process terminates when the master process terminates.

Here is an example:

my $lifeline = new IO::Pipe() ;
my $reader = new IO::Pipe() ;
my $pid = fork() ;
if ($pid){
$reader->reader() ;
$lifeline->writer() ;

# Read data from $reader...
}
else {
$reader->writer() ;
$reader->autoflush(1) ;
$lifeline->reader() ;

while (1){
my $data = $hc->read(1024, 15, $lifeline, sub {exit()}) ;
exit() unless defined($data) ;
print $reader $data ;
}
}
close ( )

Asks the Apache::HTTunnel server to close a previously established connection.
get_peer_info ( )

The get_peer_info method returns information about the remote connection. A string containing the IP address and port number, separated by a colon (:) is returned. This method can be useful with UDP connections to validate the sender of each packet.

request_callback ( REQUEST )

The request_callback method is a callback method that can be used to access the HTTP::Request object just before it is sent. The default implementation does nothing.

response_callback ( RESPONSE )

The response_callback method is a callback method that can be used to access the HTTP::Response object just after it is received. The default implementation does nothing.

The HTTP Time Protocl (HTP) system is a set of utilities to set and maintain the system clock from the HTTP/1.1 (RFC 2616) "Date:" header. HTP requires Libconfig.
The purpose of HTP is provide a simple to use system that can be used on any system that is connected to the internet and can access atleast one web page (either directly or through a proxy) to be able to maintain an accurate clock.
HTTP Time Protocol uses basic statistical analysis to arrive at the most accurate time possible given enough servers. The more servers HTP is configured to use the more accurate the clock can be.
Enhancements:
- Cleanup/simplification of the code.
- A more robust implementation of the "-p" (precision) switch.

HTTP::Handle is a HTTP Class designed for streaming.

SYNOPSIS

use HTTP::Handle;

my $http = HTTP::Handle->new( uri => "http://www.google.com/" );
$http->connect();

my $fd = $http->fd();

while () {
print "--> $_";
}

The HTTP::Handle module allows you to make HTTP requests and handle the data yourself. The general ideas is that you use this module to make a HTTP request and handle non-header data yourself. I needed such a feature for my mp3 player to listen to icecast streams.

HTTP::Handle->new()

Create a new HTTP::Handle object thingy.

Arguments possible:

url => "http://www.google.com/"

Sets the initial URL to connect to.

follow_redirects => [ 0 | 1 ]

Automatically follow HTTP redirects. This defaults to true (1). Set to 0 to disable this.

http_request => HASHREF

Any thing put in here will be sent as "key: value" in the http request string.

$http->connect()

Connect, send the http request, and process the response headers.

This function returns -1 on failure, undef otherwise. The reason for failure will be printed to STDERR.

$http->fd()

Get the file descriptor (socket) were using to connect.

$http->url( [ url_string ])

Get or set the URL. If a url string is passed, you will change the url that is requested. If no parameter is passed, a URI object will be returned containing the

$http->follow_redirects( [ 0 | 1 ] )

If a value is passed then you will set whether or not we will automatically follow HTTP 302 Redirects. If no value is passed, then we will return whatever the current option is.

Defaults to 1 (will follow redirects).

$http->http_request_string()

Returns a string containing the HTTP request and headers, this is used when

$http->connect() is called.

HTTPManifold is an application for tunnelling Web/HTTP traffic for multiple servers through a single IP address (a reverse proxy). HTTPManifold is intended for home users and small businesses so that they can host multiple domains and sub-domains through a single IP address on port 80.
HTTPManifold forwards traffic to other machines, logs requests, and rewrites content during the process. It can also log the raw content of requests for the purpose of debugging Web services, etc. It provides a Web interface for configuration and log viewing with some log analysis capabilities.
Main features:
- Ability to service HTTP request on any port.
- Allow SSL connections and therefore provide HTTPS to server that otherwise dont support it.
- Forward HTTP requests to any IP address on any port using HTTP or HTTPS.
- Rewrite HTTP headers and body during forward translation.
- Log raw HTTP request and response bytes for debugging purposes.
- Serve static HTML pages.
- Provide web interface to HTTPManifold configuration options.
Enhancements:
- This release adds the ability to forward requests to a sub-path on a destination server.
- It adds options to do simple string replacement when processing response content.
- The appearance of the Web interface has been updated.
- HSQLDB support has been added for enhanced request logging.
- X-forwarded-for header support has been added so that destination servers can see the source IP address.
- Some of the forwarding implementation has been touched up to improve performance and fix small defects.