Slug is a Dell 486/33 EISA machine. It's loaded with an SMC Ethercard, a DigiBoard PC/8E, and an Adaptec 1542.
For my non-permanent connections to a variety of places, I'm using the diald package. It works by setting up a slip interface for each connection, and then when traffic appears on it, brings up a PPP connection. What's really neat is that it can handle dynamic IP addresses for both ends of the link, so if you're going in to a site via a modem pool or something where you don't know the IP addresses that you'll be using, you can still do automatic demand dial.
Starting with version 2.3.3 of ppp, pppd supports a demand options to do the same thing, if the kernel supports the Berkeley Packet Filter. Linux now has it's own version of this, so it may be possible to do away with diald.
There's one for incoming calls, and one for outgoing calls.
Another wrinkle to the network setup on slug is the need to redirect response packets for any tcp connections that came in via one of the PPP links to return the same way rather than use the default route. Source based routing is a feature of the newest 2.1 kernels. In addition to running the latest development kernel, you also need to use a "Professional" routing table maintenance program.
The typical way to deal with incoming services is to use some form or proxy servers, or to run the service on the gateway. In our current setup, all incoming services are run off of matrix, so with a few exceptions, the FWTK plug-gw module can handle them.
On the other hand, if you don't need the filtering capabilities of the FWTK, you may want to consider port forwarding. This simply re-write the address of incoming packets and sends them to a single internal machine. Two advantages are that is uses less resources than firing up a port-fw process, and when the connection is made to your internal machine, it get the address of the source rather than your firewall.
When I had a single host doing everything, I had to hack bind to hide the internal network. Now, I do the standard internal/external BIND setup.
The maildrop, for now, remains on matrix. Mail destined for our domain and delivered to slug must be passed on to matrix. Mail delivered to matrix is handled as normal. The sendmail config for slug follows:
divert(-1) include(`../m4/cf.m4') VERSIONID(`$Id: slug.html,v 1.14 2002/11/01 21:47:34 ajlill Exp $') define(`LOCAL_MAILER_ARGS',`mail -d $u')dnl define(`UUCP_MAX_SIZE',`10000000')dnl define(`MAIL_HUB', esmtp:matrix.ajlc.waterloo.on.ca.)dnl define(`confTRUSTED_USERS', `uucp')dnl OSTYPE(linux)dnl # These defines must be here because svr4 overwrites them FEATURE(mailertable, hash /etc/mailertable)dnl FEATURE(nouucp)dnl MAILER(local)dnl MAILER(smtp)dnl
I'm using fwtk to gateway http into matrix. I was using the in-kernel port forwarding, but it didn't work with policy based routing.
Ditto for nntp. Incoming news is sucked in using the fetch-news script, so it's not affected.
Currently not available from outside.
The telnet firewall rules were copied from matrix and turned into plug-gw calls.
An XNTP Time Server is set up on this host.
Anon FTP is set up on slug, with the appropriate spools nfs mounted from matrix (read only).
Needed to re-compile uucp, since the rpm is not compiled to use SVR4-style configs.