937 lines
44 KiB
HTML
937 lines
44 KiB
HTML
<!--startcut ==========================================================-->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<Title>Setting up Your Network LG Issue 26</title>
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#A000A0"
|
|
ALINK="#FF0000">
|
|
<!--endcut ============================================================-->
|
|
|
|
<H4>
|
|
"Linux Gazette...<I>making Linux just a little more fun!</I>"
|
|
</H4>
|
|
|
|
<P> <HR> <P>
|
|
<!--===================================================================-->
|
|
|
|
I received two very similar articles this month: this one and one from Mark
|
|
Nielsen. I received this one first. Mark's is specific to Red Hat 5.0 and
|
|
can be found at <A HREF="http://linux.med.ohio-state.edu/nielsen/NetHome.html">
|
|
http://linux.med.ohio-state.edu/nielsen/NetHome.html</A>.
|
|
|
|
<P> <HR> <P>
|
|
<!--===================================================================-->
|
|
|
|
<center>
|
|
<h1>Setting up Your In-Home (or In-Office) Network</h1>
|
|
<H4>By <a href="mailto:tkunz@redeemer.rutgers.edu">Tom Kunz</a></H4>
|
|
</center>
|
|
<P> <HR> <P>
|
|
<H3>Contents:</H3>
|
|
<ul>
|
|
<li><a HREF="./kunz.html#intro">What Does This Article Cover?</A>
|
|
<li><a HREF="./kunz.html#begin">Before You Begin - Have a Working
|
|
Network!</A>
|
|
<li><a HREF="./kunz.html#config">Configuring Your Local Network</A>
|
|
<li><a HREF="./kunz.html#diald">Installing diald</A>
|
|
<li><a HREF="./kunz.html#pppd">Installing pppd</A>
|
|
<li><a HREF="./kunz.html#kernel">Kernel Configuration</A>
|
|
<li><a HREF="./kunz.html#fire">Configuring IP Forwarding Firewall</A>
|
|
<li><a HREF="./kunz.html#pppd2">Configuring pppd</A>
|
|
<li><a HREF="./kunz.html#diald2">Configuring diald</A>
|
|
<li><a HREF="./kunz.html#time">Setting Time-Outs and Other Options</A>
|
|
<li><a HREF="./kunz.html#app">Application Notes</A>
|
|
<li><a HREF="./kunz.html#final">Conclusion</A>
|
|
</ul>
|
|
|
|
<A name="intro"></A>
|
|
<h3>What Does This Article Cover?</h3><br>
|
|
<P>
|
|
Well, this article covers a couple of topics that you've probably seen
|
|
discussed before in <i>Linux Gazette</i> and/or <i>Linux Journal</i>.
|
|
Let's say you have 2 or more computers, maybe in an office, maybe at
|
|
home, and you want to have one of them be the "gateway" for the
|
|
other(s). If your ISP charges by the minute (or in 5/10/15 minute
|
|
increments), which many of them do for corporate accounts, then you
|
|
don't want to spend excessive amounts of time on the line to your ISP.
|
|
You also don't want to risk <b><i>forgetting</i></b> that you are
|
|
connected and running up a bill while doing nothing! So what you want
|
|
is a way to get your local network onto and off of the Internet with
|
|
ease, and with a minimum of extraneous cost. This includes
|
|
demand-dialing, IP forwarding, IP Masquerading, PPP configuration, and
|
|
some basics of networking. Sounds like a lot (and believe me, it
|
|
<b><i>can be</i></b>!), but it's not so bad when you find out that,
|
|
for
|
|
the most part, you don't necessarily <i>need</i> all the power and
|
|
flexibility that the packages involved in this setup have.<p>
|
|
|
|
Please note that while I will be detailing how to set up your Internet
|
|
gateway in Linux, that does not imply that your entire network needs
|
|
to be running Linux. You can have one Linux box acting as the
|
|
gateway, while the rest of the network is a mix of other platforms.
|
|
You can have any kind of hardware and software on the network,
|
|
provided that the systems have a TCP/IP stack. Any mix of DOS, Mac,
|
|
Win95, or unix workstation can be applied to a network configured in
|
|
this way.<p>
|
|
|
|
This kind of arrangement is extremely useful for a number of reasons.
|
|
If WWW browsers are going to be used heavily, this kind of network is
|
|
ideal. WWW browsers open transient TCP connections for operation,
|
|
which download chunks of information in spurts, usually not remaining
|
|
connected for more than a few seconds. While someone reads a web
|
|
page, the browser generates no (or very little) network traffic, thus
|
|
leaving the connection idle, and allowing someone else to share the
|
|
unused bandwidth to full potential. Another reason for installing
|
|
this kind of arrangement is so that users don't tie up valuable phone
|
|
lines for extended periods. Recently, I installed a similar
|
|
arrangement for a small company whose employees were frequently on the
|
|
Internet from their PC's, each using their own phone line at their
|
|
desk. Of the few and costly phone lines they had, usually half of
|
|
them were doing dial-up connections, while the other half could handle
|
|
voice calls. By the arrangement that I prescribe here, they limited
|
|
it to one phone line, and everybody was able to access the Internet
|
|
while using the phone line at their desk for voice.<p>
|
|
|
|
To describe what I've done here, I'm working from the reference frame
|
|
of having installed a fresh copy of Red Hat 4.2, with the option of
|
|
installing everything set. From what I've seen, 5.0 isn't incredibly
|
|
different (for this stuff, anyway), and I'll also be pointing out the
|
|
differences between setting this up on Red Hat and setting this up on
|
|
Slackware 3.3.<p>
|
|
|
|
|
|
<A name="begin"></A>
|
|
<h3>Before You Begin - Have a Working Network!</h3><br>
|
|
<P>
|
|
First and foremost, I would recommend some other documents for your
|
|
perusal before engaging in setting up a working LAN. These would be:
|
|
<ul>
|
|
<li><a href="http://www.linuxresources.com/LDP/LDP/nag/nag.html">The
|
|
Network Administrator's Guide</a>
|
|
<li><a
|
|
href="http://www.linuxresources.com/LDP/LDP/sag/index.html">Linux
|
|
System Administrator's Guide</a>
|
|
<li><a
|
|
href="http://www.linuxresources.com/LDP/HOWTO/NET-3-HOWTO.html">NET-3-HOWTO,
|
|
Linux Networking</a>
|
|
<li><a
|
|
href="http://www.linuxresources.com/LDP/HOWTO/Ethernet-HOWTO.html">Ethernet-HOWTO,
|
|
the details about ethernet hardware for Linux</a>
|
|
</ul>
|
|
In order to set up a home or office network with a dial-up gateway,
|
|
you first need to have a local area network (LAN) working correctly.
|
|
I would recommend you read over the above documents in some detail as
|
|
you attempt to get your network going. The exact type of network card
|
|
you use is not important to the discussion of the text, but if asked,
|
|
I would recommend ISA cards, either 16- or 8-bit, in order to cut your
|
|
teeth on networking. They provide the least hassles and have been
|
|
well supported by Linux for years. My personal favorites are the
|
|
SMC/WD 80*3 cards, but virtually all legacy ISA cards (non-PnP,
|
|
jumper-configurable cards) should work. See the documentation listed
|
|
above for exact details on making your network run.<p>
|
|
|
|
<A name="config"></A>
|
|
<h3>Configuring Your Local Network</h3><br>
|
|
<P>
|
|
I will be using the term "Linux gateway" or "gateway" to denote the
|
|
machine on your network which will be running Linux and actually have
|
|
the modem and will be performing the connections to the outside world
|
|
for your network.<p>
|
|
|
|
Networks for small offices or within a home are generally not in
|
|
registered domains. If you are setting up a connection for an office
|
|
which <i>is</i> in a registered domain with an IP address which is
|
|
part of the Internet (ie, not one of the reserved network numbers for
|
|
private use), then you will need to configure your network according
|
|
to that registered domain and IP address block which you have been
|
|
allocated by InterNIC. If you don't know what I'm talking about, then
|
|
you want to use one of the "reserved" network numbers that are set
|
|
aside for private usage. The network number which I will use will be
|
|
"192.168.1.0", which I have configured for my home usage. Because
|
|
it's reserved, I know that all my packets will not conflict with
|
|
anyone on the Internet, since all packets destined for reserved
|
|
addresses are dropped by your ISP's routers, and the main backbone
|
|
routers on the Internet.<p>
|
|
|
|
Note that the steps I describe here are often done in parallel with
|
|
the previous section on "Have a Working Network". Once you've
|
|
selected a reserved IP address block for your network, you need to
|
|
configure your hardware to be recognized and give the appropriate
|
|
parameters to the software. I recommend setting the gateway's address
|
|
to the ".1" node number of your network. It's not a law, but it's
|
|
commonly accepted and easy to remember. For example, if you are using
|
|
192.168.1.0 as your network, then 192.168.1.1 will be your Linux
|
|
gateway. Then have the other systems on the network numbered as
|
|
192.168.1.2 through 192.168.1.254. Some administrators like to have
|
|
their nameserver for the LAN set up as ".254", but if you only have a
|
|
few machines on your network, you're not likely to need or want a
|
|
nameserver.<p>
|
|
|
|
Selecting a domain name doesn't deserve a huge amount of thought.
|
|
It's just a matter of coming up with something that is easy to
|
|
remember, describes your network, and will not conflict with any
|
|
registered domain names. The extensions of ".com", ".org", and
|
|
".edu", as well as country abbreviations (".de", ".uk", ".au", etc.)
|
|
are off-limits. Just don't use anything that looks like a typical
|
|
address, and you'll be ok. For example, my local network at home is
|
|
the domain of "kunz.home". There's no domain out there belonging to
|
|
".home", so it's OK. Or if you want to set up an office network for
|
|
"ACME Inc.", then you might try "acme.office" as your domain name.<p>
|
|
|
|
The network parameters can be set up in Linux either while performing
|
|
the initial installation or after the installation has been done. If
|
|
you decide that you would like to have your gateway named "linux-gw",
|
|
and that you want your domain to be "smith.home", you will not have
|
|
any conflicts with names outside of your network. If you are using
|
|
192.168.1.0 as your network number, then the parameters for networking
|
|
should look like this:
|
|
<ul>
|
|
<li>Host Name: linux-gw
|
|
<li>Domain Name: smith.home
|
|
<li>IP Address: 192.168.1.1
|
|
<li>Netmask: 255.255.255.0
|
|
<li>Broadcast: 192.168.1.255
|
|
<li>Default Gateway:
|
|
<li>Primary Nameserver: (IP address of your ISP's primary nameserver)
|
|
<li>Secondary Nameserver: (IP address of your ISP's secondary
|
|
nameserver)
|
|
<li>Tertiary Nameserver: (IP address of your ISP's tertiary
|
|
nameserver)
|
|
</ul>
|
|
|
|
Note: Not all TCP/IP implementations will ask for or be configurable
|
|
for more than one or two nameservers. Just ignore the "secondary" and
|
|
"tertiary" fields if that's the case.<p>
|
|
|
|
Also, notice that it's important to leave the default gateway
|
|
<i><b>empty!</b></i> The routing tables will be modified by diald,
|
|
which will be discussed later.<p>
|
|
|
|
On "linux-gw", you should make/edit the /etc/hosts file. It should
|
|
contain the IP addresses and names of all the machines on the
|
|
network. Let's say you will have 4 machines on the network besides
|
|
the Linux gateway. You might, conceivably, have an /etc/hosts file
|
|
that looks something like this:
|
|
<pre>
|
|
127.0.0.1 localhost localhost.localdomain
|
|
192.168.1.1 linux-gw.smith.home linux-gw
|
|
192.168.1.2 winchester.smith.home winchester
|
|
192.168.1.3 ruger.smith.home ruger
|
|
192.168.1.4 browning.smith.home browning
|
|
192.168.1.5 mossberg.smith.home mossberg
|
|
</pre>
|
|
By doing this, the Linux gateway knows the names of all the machines
|
|
on the network. This should also be done on any unix workstations or
|
|
other Linux machines you have on the network. On Slackware
|
|
installations, you'll need to edit this by hand. On Red Hat, you can
|
|
use the "netcfg" program under X to modify the "Hosts" entry.<p>
|
|
|
|
On each of the other machines in the network, you will need to
|
|
configure their parameters as follows. Be sure not to duplicate IP
|
|
addresses between different machines! The following sample entry is
|
|
for a client on the "smith.home" network named "winchester".
|
|
<ul>
|
|
<li>Host Name: winchester
|
|
<li>Domain Name: smith.home
|
|
<li>IP Address: 192.168.1.2
|
|
<li>Netmask: 255.255.255.0
|
|
<li>Broadcast: 192.168.1.255
|
|
<li>Default Gateway: 192.168.1.1
|
|
<li>Primary Nameserver: (IP address of your ISP's primary nameserver)
|
|
<li>Secondary Nameserver: (IP address of your ISP's secondary
|
|
nameserver)
|
|
<li>Tertiary Nameserver: (IP address of your ISP's tertiary
|
|
nameserver)
|
|
</ul>
|
|
|
|
Now, notice basically only one major change: the default gateway.
|
|
When any of the machines on the network send out packets, we want them
|
|
to route them through 192.168.1.1, which is your Linux gateway. As
|
|
the gateway for the rest of the network, Linux will decide where
|
|
packets get sent. You should configure all the machines on the
|
|
network with the above paramters, changing only the host name and the
|
|
IP address for each. Any TCP/IP-capable platform should have the
|
|
provisions to be configured as above, save only possibly for the
|
|
secondary and tertiary nameserver portion. Note that it's also quite
|
|
possible that your ISP will only provide one or two nameservers, and
|
|
that the third is unlikely to be filled, most of the time.<p>
|
|
|
|
If you are configuring a Slackware Linux machine as your gateway
|
|
<i>after</i> installation, the appropriate way to change the network
|
|
parameters is to run the program "netconfig" as root. You will be
|
|
prompted for the network parameters one at a time, and should follow
|
|
the "linux-gw" listing above. Under Red Hat, you should run the
|
|
"netcfg" program from X while root. This provides a graphical tool
|
|
for doing the same thing. Running "control-panel" as root in Red Hat
|
|
provides an X front-end to many of the administrative tasks, including
|
|
networking.<p>
|
|
|
|
By the time you get this far, you should have a working network, where
|
|
you can telnet from any of the machines on your network into the Linux
|
|
gateway.<p>
|
|
|
|
<A name="diald"></A>
|
|
<h3>Installing diald</h3><br>
|
|
<P>
|
|
The package that we will be using for performing the automatic
|
|
dialling is "diald". This assumes that you have a modem which Linux
|
|
is already aware of. If not, you need to consult your installation
|
|
documentation and the incredibly useful <a
|
|
href="http://www.linuxresources.com/LDP/linux.html">Linux
|
|
Resources</a> page<p>
|
|
|
|
Once you can verify that your modem is working ok and is recognized by
|
|
Linux correctly, we can configure diald to do the work for us. As a
|
|
note, I would like to say that I've had the least problems with
|
|
external modems and with non-PnP modems. These days, it's hard (if
|
|
possible at all) to find a non-PnP internal modem. If you absolutely
|
|
<i>have</i> to use a PnP modem, then I recommend getting the <a
|
|
href="http://www.sunsite.unc.edu/pub/Linux/system/hardware/isapnptools-1.11.tgz">isapnptools
|
|
package</a>
|
|
for initializing PnP configuration.<p>
|
|
|
|
First, you need to obtain and install diald. If not already installed
|
|
on your system, it's possible to obtain the <a
|
|
href="http://www.sunsite.unc.edu/pub/Linux/system/network/serial/diald-0.16.tar.gz">
|
|
code</a> from Sunsite. If you have Red Hat, you can find the binary
|
|
distribution in RPM format on your Red Hat 4.2 CDROM. It is located
|
|
in /[mountpoint]/RHSCont/i386/diald-0.16-3.i386.rpm. The file
|
|
diald-config-0.1-1.i386.rpm is found in the same directory, and I
|
|
recommend you install it, since it contains some sample configurations
|
|
that may be useful to you. Under Red Hat 5.0, I was unable to find it
|
|
on the 2-CDROM distribution set from Red Hat, so the latest version of
|
|
diald should be <a
|
|
href="http://www.sunsite.unc.edu/pub/Linux/system/network/serial/diald-0.16.tar.gz">
|
|
downloaded from Sunsite</a>. The same goes for Slackware. Download
|
|
the pacakge and follow the build instructions included. [LG HTML
|
|
note: if you find those links are broken by the time you read this,
|
|
you should be able to browse <a
|
|
href="http://www.sunsite.unc.edu/pub/Linux/system/network/serial/">
|
|
http://www.sunsite.unc.edu/pub/Linux/system/network/serial/</a> to
|
|
find the current version of diald]<p>
|
|
|
|
<A name="pppd"></A>
|
|
<h3>Installing pppd</h3>
|
|
<P>
|
|
Once you have diald installed, we need to install pppd. This comes up
|
|
in both Slackware and Red Hat 4.2/5.0 as packages that are selected
|
|
for installation if you install everything. If it is not installed,
|
|
it can be found on your Red Hat 4.2 CD in
|
|
/[mountpoint]/RedHat/RPMS/ppp-2.2.0f-3.i386.rpm. If you have RedHat
|
|
5.0, you will find it on the first CD of the set, in
|
|
/[mountpoint]/RedHat/RPMS/ppp-2.2.0f-5.i386.rpm. Slackware contains
|
|
the ppp.tgz package at or around floppy N3 or
|
|
/[mountpoint]/slakware/n3. If you don't have it installed on your
|
|
Linux gateway already, you may need to <a
|
|
href="http://www.sunsite.unc.edu/pub/Linux/system/network/serial/ppp/ppp-2.2.0g.tar.gz">download</a>
|
|
the source for it from Sunsite. Basically, just follow the build
|
|
instructions and install it via the Makefile.
|
|
|
|
<A name="kernel"></A>
|
|
<h3>Kernel Configuration</h3>
|
|
<P>
|
|
Now you have diald and pppd installed, but you may not have any
|
|
support for IP Masquerading, which is an absolute MUST for this kind
|
|
of networking scheme. If you are using a stock Red Hat 5.0 kernel,
|
|
you will be fine, as just about everything is compiled as a module.
|
|
IP forwarding will be provided on-demand by kernel module loader, as
|
|
long as you have modified /etc/sysconfig/network (see "Configuring IP
|
|
Forwarding Firewall", below). If you're using a stock kernel that
|
|
came with Slackware, you probably don't have support for the IP
|
|
Masquerading ready. If you installed everything as I recommend in the
|
|
beginning, you'll have the kernel sources already on your Linux
|
|
gateway. But if not, you can download the source code for <a
|
|
href="http://www.sunsite.unc.edu/pub/Linux/kernel/v2.0/linux-2.0.33.tar.gz">kernel
|
|
2.0.33</a> from Sunsite. Be patient! It's a 6M file!<p>
|
|
|
|
Just untar it in your /usr/src directory, and the do the following:
|
|
<ol>
|
|
<li>cd /usr/src/linux
|
|
<li>If you are in X, type "make xconfig". Otherwise, just "make
|
|
config".
|
|
<li>You will need to set several options in the "Networking Options"
|
|
section of the configuration. You should say "Y" to:
|
|
<ul>
|
|
<li>Network firewalls
|
|
<li>TCP/IP networking
|
|
<li>IP: forwarding/gatewaying
|
|
<li>IP: firewalling
|
|
<li>IP: masquerading
|
|
<li>IP: ICMP masquerading
|
|
</ul>
|
|
<li>Note that you need not configure any of the logging/accounting
|
|
features. Most users won't need that. Only configure it if you know
|
|
why you are doing it. I won't mention anything substantial about
|
|
accounting or logging features in this article.
|
|
|
|
<li>When you've configured all your hardware the way it should be, you
|
|
will want to click on "Save & Exit" if you're running "make xconfig".
|
|
If you need help determining how your kernel should be set up, you
|
|
need to consult the resources at <a
|
|
href="http://www.linuxresources.com/">Linux Resources</a> to find out
|
|
how to best compile your kernel to support all your hardware
|
|
correctly.
|
|
|
|
<li>If you are <i>reasonably</i> certain your kernel configuration is
|
|
correct, you will type in "make dep ; make clean ; make zlilo". If
|
|
you
|
|
are compiling in loadable module support for certain items, you will
|
|
want to also do "make modules ; make modules_install" after "make
|
|
zlilo" finishes. If "make zlilo" finishes with saying something about
|
|
the kernel being too big (usually a result of trying to compile too
|
|
many drivers into the kernel directly, rather than as modules), then
|
|
you will want to try "make bzlilo", which allows for larger kernel.
|
|
<li>When you complete the previous step, you will want to reboot the
|
|
machine so that the new kernel can take over. Provided you configured
|
|
your kernel correctly, you'll be booting up a system capable of IP
|
|
forwarding and masquerading!
|
|
</ol>
|
|
|
|
<A name="fire"></A>
|
|
<h3>Configuring IP Forwarding Firewall</h3>
|
|
|
|
<P>
|
|
The next step along the path to having a Linux machine that can act as
|
|
a gateway to the Internet is to configure IP forwarding. IP
|
|
forwarding can be a very complicated and involved thing, however, to
|
|
act as a simple gateway and firewall to the Internet, all we need to
|
|
do is configure the forwarding rules so that packets of all types
|
|
found on the ethernet interface are copied onto ppp interface.<p>
|
|
|
|
Please be aware that you should be fully informed of the security
|
|
concerns of this. I recommend that you read some materials on
|
|
security, keep a copy of <a
|
|
href="http://www.sunsite.unc.edu/pub/Linux/system/network/admin/satan-1.1.1.linux.fixed2.tgz">SATAN</a>
|
|
handy, and consult some security experts if you worry about security.
|
|
If you have a dial-up service to a local ISP, there is a lower
|
|
probability that you will be hacked on than if you are using a
|
|
university as your ISP. College kids aren't necessarily malicious,
|
|
but they can be deemed a security risk, as they are usually more
|
|
"inquisitive" than the typical Windoze 95 user at home who happens to
|
|
be a customer of your local ISP. Don't take me as Gospel Truth, check
|
|
into it for yourself and find out the issues about security if it is
|
|
something you want to know about.<p>
|
|
|
|
The first thing to have is the ipfwadm package installed on your
|
|
system. If you have it already installed and your kernel has been
|
|
compiled in the previous step to support packet forwarding, then
|
|
you're set, and you can move onto the actual configuration of the
|
|
firewall. If you are using Red Hat 4.2, the package can be found at
|
|
/[mountpoint]/RedHat/RPMS/ipfwadm-2.3.0-2.i386.rpm. If you are using
|
|
Red Hat 5.0, you should find it on the first CD of the set, in
|
|
/[mountpoint]/RedHat/RPMS/ipfwadm-2.3.0-5.i386.rpm. If you're using
|
|
Red Hat, you will note that you'll also have to modify the file
|
|
/etc/sysconfig/network, making the line containing "FORWARD_IPV4" to
|
|
say "FOWARD_IPV4=true". For Slackware, you should find installed in
|
|
the base TCP/IP package (N6, "tcpip.tgz"), so if you have TCP/IP
|
|
networking installed, it should already be there. If you need to
|
|
download it, the source can be found at its <a
|
|
href="http://www.xos.nl/linux/ipfwadm/">home page</a>.<p>
|
|
|
|
Once you have the package installed, you need to know how to use it!
|
|
Depending on how secure you would like it to be, you can make a few
|
|
changes to what I have here. What you want to do is flush the table
|
|
of all previous firewall forwarding entries, set a default policy for
|
|
either accepting or rejecting packets, and then tell it how to forward
|
|
packets between different interfaces. For example, the following
|
|
script will flush all forwarding rules, set the default policy to
|
|
"accept" packets, and will forward packets between all of the
|
|
available interfaces:
|
|
|
|
<pre>
|
|
#!/bin/sh
|
|
ipfwadm -F -f
|
|
ipfwadm -F -p accept
|
|
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0
|
|
</pre>
|
|
|
|
We can view the IP forwarding rules by issuing the command "ipfwadm -F
|
|
-l -n", which will list the rules numerically. If we do that, we will
|
|
get output looking like this:
|
|
<pre>
|
|
IP firewall forward rules, default policy: accept
|
|
type prot source destination ports
|
|
acc/m all 192.168.1.0/24 0.0.0.0/0 n/a
|
|
</pre>
|
|
|
|
This tells us that any packets going from our network to anything
|
|
other than just our network will be forwarded between all of the
|
|
interfaces. Now, if we specify an additional "-e" option to the
|
|
previous command, we get extended output of the forwarding rules.
|
|
This is to our advantage, but you should have a 132 character wide
|
|
screen when you run it. Here is a sample output:
|
|
<pre>
|
|
IP firewall forward rules, default policy: accept
|
|
pkts bytes type prot opt tosa tosx ifname ifaddress source
|
|
destination ports
|
|
113 9452 acc/m all ---- 0xFF 0x00 any any
|
|
192.168.1.0/24 anywhere n/a
|
|
</pre>
|
|
|
|
Thus, we can see that even though IP forwarding can be incredibly
|
|
complicated and selective, we can write a simple script which will do
|
|
all the work for us and establish a forwarding firewall.<p>
|
|
|
|
If you read the manpage for ipfwadm, you will find that the -W option
|
|
may be used to specified. For simple situations and a simple network
|
|
in a generally trusted environment, the -W option isn't necessary,
|
|
because you are probably interested in having <i>all</i> interfaces
|
|
able to see <i>all</i> packets. However, if you are interested in
|
|
keeping certain interfaces from receiving packets, you may use the -W
|
|
option for security.<p>
|
|
|
|
<A name="pppd2"></A>
|
|
<h3>Configuring pppd</h3>
|
|
<P>
|
|
The first thing we want to do is configure pppd, because it's often
|
|
easier to test out than diald. To do this, we want to create a chat
|
|
script, which will dialog with the ISP, and establish the connection.
|
|
You will want to read the man page for "chat" first, but here is an
|
|
example of a chat script I use:
|
|
|
|
<pre>
|
|
REPORT CONNECT ABORT BUSY '' atdt5551212 CONNECT '' : tkunz : PaSsWoRd
|
|
action ppp
|
|
</pre>
|
|
|
|
>From the manpage:<br>
|
|
|
|
<pre>
|
|
This sequence will expect nothing; and then send the
|
|
string ATDT5551212 to dial the telephone. The expected
|
|
string is CONNECT. If the string CONNECT is received the
|
|
remainder of the script is executed. In addition the pro-
|
|
gram will write to the expect-file the string "CONNECT"
|
|
plus any characters which follow it such as the connection
|
|
rate.
|
|
</pre>
|
|
|
|
First, the script will report what the modem returns after "CONNECT"
|
|
into the report file, to be analyzed later, in order to diagnose what
|
|
could have gone wrong with the dial-up. The ABORT string means to
|
|
abort the script should it see the "BUSY" string returned by the
|
|
modem. After that, this script will diald "555-1212" as the phone
|
|
number, and wait for the CONNECT message to come back from the remote
|
|
end. It will then wait for a colon (":"), and reply with "tkunz". It
|
|
will wait for another color (":"), and reply with "PaSsWoRd". When
|
|
the string "action" is received from the remote end, it replies with
|
|
"ppp" and the chat script terminates. Chat will then pass control
|
|
back to the program that called it. But here's another script that
|
|
will work fine, provided we don't need the "REPORT" error checking,
|
|
and we don't ever expect to get a busy signal:
|
|
|
|
<pre>
|
|
atz OK atdt5551212 CONNECT name: tkunz word: PaSsWoRd action: ppp
|
|
</pre>
|
|
|
|
This one will do the same thing, only it will initialize the modem to
|
|
the default setting by issuing "atz" first, and instead of expecting
|
|
only a colon, it waits for "name:" and "word:" to be received before
|
|
issuing "tkunz" and "PaSsWoRd", respectively, to the remote end.<p>
|
|
|
|
These simple one-line scripts like the above examples can be used with
|
|
chat to automate the login procedure with your ISP.<p>
|
|
|
|
pppd uses chat to establish a connection, and then when chat
|
|
terminates, pppd continues to dialog with the remote end, determining
|
|
its local and remote IP addresses, and then pppd follows the other
|
|
command line options to secure a reliable connection.<p>
|
|
|
|
To give you an idea of what a set of scripts would look like that
|
|
starts a PPP connection, here is a sample of something I use to
|
|
manually bring up a PPP connection to my ISP.<p>
|
|
|
|
The contents of a file in my own directory, named "startppp":
|
|
|
|
<pre>
|
|
#!/bin/sh
|
|
/usr/sbin/pppd /dev/cua3 115200 connect 'chat -f /etc/ppp/chatscript'
|
|
defaultroute crtscts proxyarp passive
|
|
</pre>
|
|
|
|
This tells pppd to use my modem, located on /dev/cua3 (COM4 in DOS),
|
|
at a speed of 115200, which my 33.6kbps modem can handle. The
|
|
"connect" parameter says to use the next quoted string as the
|
|
command-line which will connect pppd to the remote host.
|
|
<ul>
|
|
<li>
|
|
Note to programmers: pppd connects its stdin and stdout to the stdin
|
|
and stdout of the command-line specified by the "connect" option.
|
|
This is good to know, if chat doesn't work with your modem. This is
|
|
often the case with PCMCIA modems or some non-standard modems, so you
|
|
might decide to write a shell script incorporating "expect" and/or
|
|
other text utilities, or a Perl script that does the same. A chat
|
|
replacement is only required to use stdin and stdout to dialog with
|
|
the remote end and then exit by returning 0. See the "chat" manpage
|
|
for more details on termination codes.
|
|
</ul>
|
|
<P>
|
|
The option "defaultroute" tells pppd to modify the routing tables so
|
|
that this connection is added as a default route to the rest of the
|
|
world. The "crtscts" option tells pppd to use hardware flow control
|
|
for the modem, a MUST for modems faster than about 9600 baud.
|
|
"proxyarp" says to add an ARP entry for the local and remote systems
|
|
to the ARP table. The "passive" option tells pppd to be patient about
|
|
receiving LCP packets from the ISP. If pppd does not immediately
|
|
receive an LCP packet from the remote end, it drops carrier. I have
|
|
personally found this to be the "magic ingredient" to getting pppd
|
|
working with several different ISP's.
|
|
|
|
The contents of the file /etc/ppp/chatscript, used by "chat" in
|
|
"startppp":
|
|
|
|
<pre>
|
|
REPORT CONNECT ABORT BUSY '' atdt5551212 CONNECT '' : tkunz : PaSsWoRd
|
|
action ppp
|
|
</pre>
|
|
|
|
Substitute in your login name, password, and the command which starts
|
|
ppp (if any) for the appropriate fields in the
|
|
/etc/ppp/chatscript, and see what happens. You may need to
|
|
contact your ISP if you have never used pppd in Linux before to
|
|
establish a PPP connection, to determine if there are specific options
|
|
necessary to make and sustain a PPP connection. You can try the above
|
|
script and then watch the /var/log/messages file to see what happens.
|
|
You might need to modify your /etc/syslog.conf file to get the
|
|
messages printed to the right location if you use Red Hat. I prefer a
|
|
slightly modified Slackware /etc/syslog.conf, which is shown here:
|
|
|
|
<pre>
|
|
# /etc/syslog.conf
|
|
# Very Important! All whitespace are TABs, not " " (space) characters!
|
|
#
|
|
*.=info;*.=notice /var/log/messages
|
|
*.=debug /var/log/debug
|
|
*.warn /var/log/syslog
|
|
</pre>
|
|
|
|
After making this your syslog.conf file, you can do a "touch" on
|
|
/var/log/messages, /var/log/debug, and /var/log/syslog, restart
|
|
syslogd and watch the messages appear. Occaisonally, I've noticed
|
|
strangeness with syslogd not wanting to give up the previous
|
|
configuration, so you might find a reboot rather than just a restart
|
|
of syslogd is in order.<p>
|
|
|
|
Once you have syslogd logging the right level of messages to the
|
|
locations mentioned above, you can watch the progress of pppd from one
|
|
window or virtual console while you execute "startppp" from another.
|
|
By watching /var/log/messages (and possibly by watching the modem
|
|
lights if you have an external modem), you can determine if chat
|
|
succeeded or failed, or if the right options were specified to pppd.
|
|
As root, the command "tail -f /var/log/messages" will enable you to
|
|
see messages as they are dumped into /var/log/messages.<p>
|
|
|
|
By experimentation, you should be able to get a PPP connection started
|
|
by using these scripts and commands. Again, I mention that you might
|
|
have to call your ISP to find out if any special LCP or IPCP options
|
|
need to be set.<p>
|
|
|
|
<A name="diald2"></A>
|
|
<h3>Configuring diald</h3>
|
|
|
|
<P>
|
|
By this time, you should be able to regularly initiate a PPP link to
|
|
your ISP by executing "startppp", and you should be able to use web
|
|
browsers and the like to get onto the Internet from the other machines
|
|
on the network once you have the IP forwarding rules installed. The
|
|
next peice of the puzzle is diald. diald is designed as a
|
|
demand-dialer, meaning that when it senses that you want to get from
|
|
the local network out onto the Internet, it dials your ISP and sets up
|
|
the connection for you.<p>
|
|
|
|
The first thing to realize is that we are going to have to change the
|
|
way we think about pppd and chat for the moment. Before, in our
|
|
previous script in the section about configuring pppd, we had pppd
|
|
start up, then issue the "connect" command. After that occurred, pppd
|
|
would run according to the options we put on the command line. In
|
|
diald, we have to recognize that diald will be handling many of the
|
|
details that pppd handled before. These details include the dialing
|
|
script and options that would normally be passed to pppd. diald will
|
|
be responsible for implementing these things now, not pppd.<p>
|
|
|
|
What diald does is it creates a "virtual" interface, sl0, which is a
|
|
slip interface to nowhere. We will have it assign the IP address of
|
|
192.168.0.1 to sl0, and an IP address of 192.168.0.2 to the remote end
|
|
(basically <i>nothing!</i>) of the fake slip interface. Then it
|
|
creates a route so that traffic not intended for the local network
|
|
will go into sl0. When diald finds packets being copied onto sl0, it
|
|
realizes that those packets should go into the Internat, and starts
|
|
the dialing process. In order to make our particular network
|
|
arrangement work, we have to set up the IP forwarding to be
|
|
promiscuous, in a sense, in that it forwards between all interfaces,
|
|
including sl0. Thus, packets which are generated by one of the other
|
|
machines on the network will go into the Linux gateway, the IP
|
|
forwarding mechanism will copy them onto the sl0 interface if they are
|
|
not destined for only the local network, and then diald will take
|
|
over, starting the dialing process and pppd to bring up the link.<p>
|
|
|
|
The manpage of diald-examples should have been installed on your
|
|
system when you installed it. If you read that, you will probably
|
|
find your own situation there in the manpage, however, most of you
|
|
will probably find that it corresponds with the section named "A Leaf
|
|
Node with Dynamic Local Address using PPP". The following comes
|
|
directly from the diald-examples(5) manpage for this situation: <p>
|
|
<pre>
|
|
mode ppp
|
|
connect /etc/diald/connect
|
|
device /dev/ttyS1
|
|
speed 115200
|
|
modem
|
|
lock
|
|
crtscts
|
|
local 192.168.0.1
|
|
remote 192.168.0.2
|
|
dynamic
|
|
defaultroute
|
|
include /usr/lib/diald/standard.filter
|
|
</pre>
|
|
To start off with, you should have the above as your initial
|
|
/etc/diald.conf file. We will add options to it later.
|
|
|
|
At this point, please understand that diald has to know exactly where
|
|
to find the external programs of route, ifconfig, and pppd. This
|
|
article assumes that you have installed pppd, ifconfig, and
|
|
route into their default locations, which are:<p>
|
|
<pre>
|
|
/usr/sbin/pppd
|
|
/sbin/ifconfig
|
|
/sbin/route
|
|
</pre>
|
|
|
|
If for some reason you do not have them installed in the above
|
|
locations, please make links or move them to the appropriate
|
|
locations.<p>
|
|
|
|
Now we come to the part where we modify that initial /etc/diald.conf
|
|
file. First of all, we have created a working chat script in an
|
|
earlier part of this article, "Configuring pppd". Using that
|
|
information, we modify the lines starting with "connect ...", "device
|
|
..." and "speed ..." to reflect your configuration. If you followed
|
|
my directions exactly in "Configuring pppd" and have a 33.6kbps modem
|
|
on COM4 like I do, then you would get a diald.conf that looks like
|
|
this: <p>
|
|
<pre>
|
|
mode ppp
|
|
connect "chat -f /etc/ppp/chatscript"
|
|
device /dev/cua3
|
|
speed 115200
|
|
modem
|
|
lock
|
|
crtscts
|
|
local 192.168.0.1
|
|
remote 192.168.0.2
|
|
dynamic
|
|
defaultroute
|
|
include /usr/lib/diald/standard.filter
|
|
</pre>
|
|
|
|
Note that if you have a 28.8k, 33.6k, or 56k modem, your "speed ..."
|
|
line will look the same. If you're using a 14.4k, you'll most likely
|
|
have to use "speed 57600". Also, make sure you use the correct number
|
|
of the COM port. COM ports in DOS are one higher than the appropriate
|
|
cua number, since DOS starts numbering from "1" and unix tends to
|
|
number things starting from "0".<p>
|
|
|
|
One thing to note about the diald.conf file is the set of options
|
|
which would normally have been specified to pppd. According to the
|
|
diald manpage, you must <i>not</i> specify those as direct options to
|
|
pppd. This is one of those details handled only by diald. In our
|
|
original "startppp" script, we specified "... defaultroute crtscts
|
|
proxyarp passive". In our new situation, using diald instead of pppd
|
|
to manipulate those options, we need to set those here in diald.conf.
|
|
All but the "passive" option can be specified. Thus, we get a
|
|
diald.conf that looks like this: <p>
|
|
<pre>
|
|
mode ppp
|
|
connect "chat -f /etc/ppp/chatscript"
|
|
device /dev/cua3
|
|
speed 115200
|
|
modem
|
|
lock
|
|
crtscts
|
|
local 192.168.0.1
|
|
remote 192.168.0.2
|
|
dynamic
|
|
defaultroute
|
|
proxyarp
|
|
include /usr/lib/diald/standard.filter
|
|
</pre>
|
|
|
|
If we need to add the "passive" command to pppd to make it work with
|
|
your ISP correctly, then we can insert a new line into the above of
|
|
the form:<p>
|
|
<pre>
|
|
pppd-options passive
|
|
</pre>
|
|
|
|
The above diald.conf <i>should</i> get you started with a working
|
|
connection to your ISP. If not, you may need to consult your ISP's
|
|
technical support line to find out what they recommend.<p>
|
|
|
|
At this point, you should be able to start diald and watch the
|
|
messages in /var/log/messages appear which it generates upon start-up.
|
|
After diald starts, you should also be able to send packets from other
|
|
nodes of your network to the Internet, and then watch as diald
|
|
automatically dials out and establishes a connection. If not, go back
|
|
over the previous steps to find out what went wrong.<p>
|
|
|
|
|
|
<A name="time"></A>
|
|
<h3>Setting Time-Outs and Other Options</h3>
|
|
|
|
A very useful feature of diald is its ability to detect inactivity,
|
|
and then bring down the ppp link appropriately after a user-specified
|
|
amount of time. If you have a single phone line in your home, which
|
|
you need to use only in short spurts for dialing out, you'll enjoy
|
|
this feature. Or if you're a corporate entity who is charged on
|
|
5/10/15 minute increments, you can be sure that the link will go down
|
|
after a certain time of inactivity, keeping costs low.<p>
|
|
|
|
There are also important variables which are not associated with the
|
|
link uptime itself, but with the time that different portions of diald
|
|
take to execute or time-out. For example, if dialing your ISP and
|
|
passing the username, password and related actions take more than 60
|
|
seconds, typically, you will want to add a line to the file that says
|
|
something like:<p>
|
|
<pre>
|
|
connect-timeout 120
|
|
</pre>
|
|
|
|
Or, if you wish to have diald attempt a redial 10 times before giving
|
|
up and only wait 15 seconds to clear the modem between dials, you will
|
|
want to add in the following two lines:<p>
|
|
<pre>
|
|
retry-count 10
|
|
redial-timeout 15
|
|
</pre>
|
|
|
|
You may also wish to play with some of the other options that diald
|
|
has to offer. For example, one option that can be useful is
|
|
"two-way". This tells diald that if carrier is dropped while in
|
|
operation, that it will not retry dialing. What good is that? Well,
|
|
if you have to forcibly terminate the PPP connection to your ISP
|
|
(killing off pppd manually to free the line, physically pulling the
|
|
phone line connection, etc.) diald will not try to outsmart you and
|
|
dial again. If you have a somewhat dedicated line, and you are not
|
|
concerned about how long you are connected to your ISP, you won't need
|
|
that option very much, as you'll probably stay connected for longer
|
|
periods of time.<p>
|
|
|
|
If you are concerned with accounting for the time that is spent
|
|
online, then you will want to play with the "accounting-log ..."
|
|
option. The parameter to "accounting-log" should be the full pathname
|
|
of a file which will log the times when the link comes up and goes
|
|
down, and how much data was sent down the wire. But I said I wouldn't
|
|
spend any time talking about accounting and logging ...<p>
|
|
|
|
The diald manpage is rich with options, and I would recommend that you
|
|
read it in parallel with reading this article. Diald is wonderfully
|
|
configurable, and can meet a <b>wide</b> variety of needs, depending
|
|
on how complex of an arrangement you wish.<p>
|
|
|
|
|
|
<A name="app"></A>
|
|
<h3>Application Notes</h3>
|
|
<P>
|
|
OK! Now you can go to any node of your network, start up {Netscape,
|
|
IE, Arena, Mosaic, any browser} and get to somewhere out on the rest
|
|
of the Internet. However, why does it seem like sometimes your Linux
|
|
gateway almost randomly fires up a connection? What's it doing?<p>
|
|
|
|
Well, now you need to delve into the particular applications on your
|
|
network and how they're configured. Two of the big things to check
|
|
are mail client and web browsers which contain mail clients. If your
|
|
mail client makes requests for new mail, it will generate a packet
|
|
which goes to your gateway, and initiates a call. This means that
|
|
while the Internet connection is down, someone with a mail client up
|
|
and running somewhere on your local network can unwittingly cause the
|
|
gateway to establish a connection. This can be annoying and/or
|
|
costly, both for the typical home user and the corporation. I know
|
|
that I've accidentally done this to my wife on a number of occaisons,
|
|
where my gateway attempted to dial out while she was on the phone with
|
|
someone! (But she's a wonderful, patient, forgiving wife.)<p>
|
|
|
|
To fix this, what you need to do is to inform your staff (or family)
|
|
that once they finish with their mail client, they should terminate it
|
|
immediately. And they should also be informed that they should turn
|
|
off the automatic mail-fetching for any mail client that they use,
|
|
especially if you are billed for connection time to your ISP or per
|
|
minute of call (European countries often bill for even local
|
|
calls).<p>
|
|
|
|
Another thing to watch out for is the /etc/resolv.conf on the unix
|
|
hosts on your network. You must not have any nameservers which are
|
|
outside of your local network listed in it, or else every application
|
|
that accepts a hostname will generate packets and cause your gateway
|
|
to dial out. For this reason, it's wise to keep every hostname your
|
|
local network needs in /etc/hosts on each unix machine. If your local
|
|
network is large enough to warrant the effort, you might also set up
|
|
your own local nameserver to handle the name requests. A local
|
|
nameserver with its own maps for the local domain, and a caching
|
|
nameserver for outside requests is probably the most efficient way of
|
|
handling that. If you are going to be using a local mail agent like
|
|
sendmail, then you will want to be sure to configure it in such a way
|
|
that it will not cause the gateway to dial-up the ISP at every
|
|
instance of outgoing mail. You'll want it spooled until a connection
|
|
is available, or at a routinely scheduled time when all queued mail
|
|
will be transmitted out.<p>
|
|
|
|
Obviously, this document is not going to go into any detail about how
|
|
to configure the various applications on your network around using a
|
|
demand-dialed gateway. It is useful, however, to be aware of some of
|
|
the issues you will face when you add different applications and
|
|
platforms to your network, and why things may not be going the way you
|
|
initially supposed they would. If you are faced with a larger network
|
|
which requires greater upkeep in order to keep it working right, and
|
|
high bandwidth to the Internet on a regular basis, it may be time to
|
|
consider investing in faster connections (ISDN, T1, T3, OC3, etc.) and
|
|
leased lines which better suit your needs. Note that diald can work
|
|
with ISDN, but in a larger-scale network with higher bandwidth
|
|
demands, a full-time connection may be the best solution.<p>
|
|
|
|
<A name="final"></A>
|
|
<h3>Conclusion</h3>
|
|
<P>
|
|
Well, it's seems apropriate to say that configuring a small network
|
|
with demand dialing via diald is a task which can be <i>quite</i>
|
|
involved, depending on the complexity of your network. But if you
|
|
have fairly "ordinary" needs, you can follow the above procedures to
|
|
get a working and reliable demand-dialed connection. Many, at this
|
|
point, will say "Well, what are 'ordinary needs' anyway?" or "How big
|
|
of a network will this support?". The answer is subjective, however I
|
|
can say with reasonable certainty that a network of 2 to 8 machines,
|
|
each running their own web browsers, mail clients, and the like, will
|
|
be quite adequate over even a 28.8kbps modem. The connection I get to
|
|
my local ISP rarely gets past 28.8kbps on my 33.6kbps modem, because
|
|
of the lines in my area, and often drops down to 21.6kbps or so, yet I
|
|
still get reasonably quick response from having 2 or 3 machines
|
|
accessing the Internet simultaneously. If you lust for speed, then
|
|
you will do well to get a 56kbps modem, and a line to your ISP that
|
|
can sustain 56kbps (yes, 53k download by FCC law). From my
|
|
experience, diald will have no trouble with a 56kbps, provided it is
|
|
either external and connected to a 16550 UART, or if you have built
|
|
some version of a PnP configuration manager which can reliably
|
|
configure an internal 56k modem.<p>
|
|
|
|
|
|
<!--===================================================================-->
|
|
<P> <hr> <P>
|
|
<center><H5>Copyright © 1998, Tom Kunz <BR>
|
|
Published in Issue 26 of <i>Linux Gazette</i>, March 1998</H5></center>
|
|
|
|
<!--===================================================================-->
|
|
<P> <hr> <P>
|
|
<A HREF="./index.html"><IMG ALIGN=BOTTOM SRC="../gx/indexnew.gif"
|
|
ALT="[ TABLE OF CONTENTS ]"></A>
|
|
<A HREF="../index.html"><IMG ALIGN=BOTTOM SRC="../gx/homenew.gif"
|
|
ALT="[ FRONT PAGE ]"></A>
|
|
<A HREF="./ayers.html"><IMG SRC="../gx/back2.gif"
|
|
ALT=" Back "></A>
|
|
<A HREF="./obrien.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
|
|
<P> <hr> <P>
|
|
<!--startcut ==========================================================-->
|
|
</BODY>
|
|
</HTML>
|
|
<!--endcut ============================================================-->
|