Easily forwarding arbitrary TCP connections with rinetd

Posted by Steve on Tue 1 Jul 2008 at 12:30

In the past we've examined the use of firewall rules for forwarding incoming connections from one machine to another. But there is a simpler approach using the rinetd package. Read on to learn about this tool.

The rinetd package contains a simple tool which may be configured to listen for connections upon a machine, and silently redirect them to a new destination. In short it acts as a simple to configure TCP proxy.

You may install this package via :

root@silver:~# apt-get update
root@silver:~# apt-get install rinetd

(If you prefer you may use "aptitude update; aptitude install rinetd" - old habits die hard with me!)

Once installed you'll find a configuration file located at /etc/rinetd.conf. This file is used to tell the deamon which ports it should listen for connections upon, and what it should do when they arrive.

By default no ports are configured for forwarding, and so the file will consist entirely of comments. A default configuration file would look something like this, to give you an idea of the configuration:

#
# forwarding rules come here
#
# you may specify allow and deny rules after a specific forwarding rule
# to apply to only that forwarding rule
#
# bindadress    bindport  connectaddress  connectport


# logging information
logfile /var/log/rinetd.log

# uncomment the following line if you want web-server style logfile format
# logcommon

Note: There are more details about allowed options in the manpage which you may view by running "man rinetd".

To demonstrate how the forwarding is configured and used we'll make a simple example. Assume that you have a machine with the IP address 1.2.3.4 which has been running Apache, and that you'd like to move that to the IP address 4.3.2.1..

You've already updated DNS to point visitors to the new IP address, but you want to ensure that people connecting to the old IP still continue to receive service.

To handle this case you should update the /etc/rinetd.conf file to read:

# bindadress    bindport  connectaddress  connectport
1.2.3.4         80        4.3.2.1         80
1.2.3.4         443       4.3.2.1         443

Once you restart rinetd all incoming connections on port 80 and 443 will be seamlessly redirected from the old IP to the new one - although you will need to restart rinetd after making the change to your configuration file:

root@silver:~# /etc/init.d/rinetd restart
Stopping internet redirection server: rinetd.
Starting internet redirection server: rinetd.

rinetd is a very small, stable, and simple program, and you might find it simpler to understand than the matching generic iptables TCP proxy solution.

The only downside to using rinetd is that there is no support for UDP connections, and no support for redirecting FTP access - because of the complex nature of FTP.

 

 


Posted by Xeeper (87.195.xx.xx) on Tue 1 Jul 2008 at 14:04
Did you run some benchmarks to see if rinetd is faster/less resourceful than an iptables nat rule? TCP based connection makes up for more than 95% of the redirected traffic, so rinetd might be very interesting for gateways and routers. So comparison with LVS might also be interesting. We use LVS also for forwarded services. This makes things a lot easier if the service had to be loadbalanced.


P.s. I always thought that rinetd was just another inetd alternative.

[ Parent | Reply to this comment ]

Posted by Steve (80.68.xx.xx) on Tue 1 Jul 2008 at 14:18
[ View Steve's Scratchpad | View Weblogs ]

No, I've not benchmarked it - but I know I've used rinetd to forward hundreds of connections with no appreciable overhead. So it is probably "fast enough" for most users.

The fact that you can run it yourself, for high ports, without root access is also a nice bonus!

I'd agree that LVS is great, but probably overkill for most users.

Steve

[ Parent | Reply to this comment ]

Posted by HoverHell (92.241.xx.xx) on Wed 2 Jul 2008 at 08:39
For non-daemon (userspace) forwarding socat might be more useful than rinetd.
Also, i've seen quite a problems with rinetd and unstable connections (pppoe of some problematic ISP).
Yet, it worked well for quite some time.

[ Parent | Reply to this comment ]

Posted by djzort (203.10.xx.xx) on Fri 4 Jul 2008 at 00:36
its probably better to run

apt-get update && apt-get install

better to not run apt-get install if the update fails ;)

Dean
--
http://www.fragfest.com.au

[ Parent | Reply to this comment ]

Posted by fili (82.95.xx.xx) on Mon 7 Jul 2008 at 16:14
Thanks, this worked perfectly.

[ Parent | Reply to this comment ]

Posted by Anonymous (88.34.xx.xx) on Wed 9 Jul 2008 at 13:24
As a sidenote... there's also the package Stone:
http://packages.debian.org/etch/stone

- Command-line
- TCP and UDP
- Simple

Example... VNC forward from the gateway to an internal machine (192.168.1.2):
stone 192.168.1.2:5900 5900

[ Parent | Reply to this comment ]

Posted by Anonymous (67.186.xx.xx) on Wed 16 Jul 2008 at 07:28
Just be careful if you ifdown/ifup the interface that rinetd is listening on. It will go totally crazy, using 100% of CPU, and will write hundreds of MB of logs files per minute (all complaining of some problem with the interface).

Always stop the rinetd daemon before ifdown, and restart it after ifup.

[ Parent | Reply to this comment ]

Posted by atrixnet (64.39.xx.xx) on Thu 17 Jul 2008 at 21:44
[ View Weblogs ]
that sounds like a terrible bug, and should be fixed.

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

What do you use for configuration management?








( 251 votes ~ 1 comments )