2016-01-24 18:46:18 +00:00
|
|
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
2004-11-04 11:12:28 +00:00
|
|
|
|
<sect1 id="Overview">
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
<title>Overview</title>
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
<para>
|
2008-01-05 15:19:09 +00:00
|
|
|
|
As with the rest of the Linux operating system and its numerous components
|
|
|
|
|
|
development of networking stack within Linux has been both a slow and
|
|
|
|
|
|
complex journey that has resembled that journey that has been faced by
|
|
|
|
|
|
people in the development of networking stacks of other operating systems
|
|
|
|
|
|
such as Microsoft Windows and Free BSD.
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
|
As has been stated in the Linux Networking HOWTO
|
|
|
|
|
|
(http://tldp.org/HOWTO/NET3-4-HOWTO.html)
|
|
|
|
|
|
the actual implementation of the TCP/IP protocol stack was done
|
|
|
|
|
|
basically from scratch due to concerns with regards to copyright issues
|
|
|
|
|
|
as well as the possibilty that developers would be able to come up
|
|
|
|
|
|
with a protocol stack that was superior to existing protocol stacks.
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
<para>
|
2008-01-05 17:36:26 +00:00
|
|
|
|
Ross Biro originally implemented the first ethernet driver for the
|
|
|
|
|
|
WD-8003 network interface card which led to an increase in pressure
|
|
|
|
|
|
among the open source community for the development of more complete
|
|
|
|
|
|
networking support. However, due to increased personal commitments he
|
|
|
|
|
|
was unable to continue to do so and soon after left this project
|
|
|
|
|
|
having formed a crucial base for the development of better networking
|
|
|
|
|
|
support under Linux.
|
|
|
|
|
|
</para>
|
2008-01-05 15:19:09 +00:00
|
|
|
|
|
2008-01-05 17:36:26 +00:00
|
|
|
|
<para>
|
|
|
|
|
|
<screen>
|
2016-01-24 18:46:18 +00:00
|
|
|
|
Orest Zborowski <email>obz@Kodak.com</email> produced the original BSD socket
|
2008-01-05 15:19:09 +00:00
|
|
|
|
programming interface for the Linux kernel. This was a big step
|
|
|
|
|
|
forward as it allowed many of the existing network applications to be
|
|
|
|
|
|
ported to linux without serious modification.
|
2008-01-05 17:36:26 +00:00
|
|
|
|
</screen>
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
|
Soon after Laurence Culhane developed the first Linux drivers
|
|
|
|
|
|
to support the SLIP protocol which meant that an increasing
|
|
|
|
|
|
number of people were able to access the Internet from Linux.
|
|
|
|
|
|
It also led to a greater number of people who understood the
|
|
|
|
|
|
implications of what full networking support meant for Linux
|
|
|
|
|
|
which meant there was an increasing community of people who
|
|
|
|
|
|
went on to experiment with this software and further develop it.
|
|
|
|
|
|
</para>
|
2008-01-05 15:19:09 +00:00
|
|
|
|
|
2008-01-05 17:36:26 +00:00
|
|
|
|
<para>
|
|
|
|
|
|
Eventually Fred van Kempen took over the task of leading the
|
|
|
|
|
|
development of networking support under Linux. The primary
|
|
|
|
|
|
difference between himself and his former predecessors was that he
|
|
|
|
|
|
was far more ambitious in his desire to expand the Linux networking
|
|
|
|
|
|
code. He laid the plans for the development of a dynamic device
|
|
|
|
|
|
interface, Amateur Radio AX.25 protocol support and a more abstract
|
|
|
|
|
|
and modular networking implementation. Obviously, like his predecessor
|
|
|
|
|
|
there was increasing pressure on him to deliver a product that was
|
|
|
|
|
|
both reliable and satisfied the requirements of most users.
|
|
|
|
|
|
</para>
|
2008-01-05 15:19:09 +00:00
|
|
|
|
|
2008-01-05 17:36:26 +00:00
|
|
|
|
<para>
|
|
|
|
|
|
This issue was resolved by Alan Cox who eventually debugged the code
|
|
|
|
|
|
so that it was reliable enough to use in the general community.
|
2008-01-05 17:47:04 +00:00
|
|
|
|
He also became the new leader of the Linux networking effort.
|
2008-01-05 17:36:26 +00:00
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
<para>
|
2008-01-05 17:47:04 +00:00
|
|
|
|
Donald Becker then went on to make a name for himself through
|
|
|
|
|
|
his implementation of a huge range of ethernet drivers.
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
|
Alan continued to develop the networking code and through the aid of
|
|
|
|
|
|
other people added support for a multitude of other protocols such
|
|
|
|
|
|
as AX.25, IPX, PPP (Michael Callahan and Al Longyear), and AX.25/NetRom/Rose
|
|
|
|
|
|
protcol set (Jonathan Naylor).
|
|
|
|
|
|
</para>
|
2008-01-05 15:19:09 +00:00
|
|
|
|
|
2008-01-05 17:47:04 +00:00
|
|
|
|
<para>
|
|
|
|
|
|
While the current state of Linux networking is extremely stable (and
|
|
|
|
|
|
in some cases surpasses the capabilities and performance of commercial
|
|
|
|
|
|
implementations of Linux), there still seems to be significant issues with
|
|
|
|
|
|
regards to driver development. This is most especially the case with regards
|
|
|
|
|
|
to wireless driver development where while most internal cards are supported
|
|
|
|
|
|
there a small minority where support is non-existant and companies seem
|
|
|
|
|
|
to be unwilling to disclose enough information regarding the card to develop
|
|
|
|
|
|
something that is workeable.
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
|
<screen>
|
2008-01-05 15:19:09 +00:00
|
|
|
|
Linux Networking HOWTO, http://tldp.org/HOWTO/NET3-4-HOWTO.html
|
|
|
|
|
|
</screen>
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
----------
|
|
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
<![CDATA[
|
2004-11-04 02:03:06 +00:00
|
|
|
|
5.1.4. IP Addresses, an Explanation.
|
|
|
|
|
|
|
|
|
|
|
|
Internet Protocol Addresses are composed of four bytes. The convention
|
|
|
|
|
|
is to write addresses in what is called `dotted decimal notation'. In
|
|
|
|
|
|
this form each byte is converted to a decimal number (0-255) dropping
|
|
|
|
|
|
any leading zero's unless the number is zero and written with each
|
|
|
|
|
|
byte separated by a `.' character. By convention each interface of a
|
|
|
|
|
|
host or router has an IP address. It is legal for the same IP address
|
|
|
|
|
|
to be used on each interface of a single machine in some circumstances
|
|
|
|
|
|
but usually each interface will have its own address.
|
|
|
|
|
|
|
|
|
|
|
|
Internet Protocol Networks are contiguous sequences of IP addresses.
|
|
|
|
|
|
All addresses within a network have a number of digits within the
|
|
|
|
|
|
address in common. The portion of the address that is common amongst
|
|
|
|
|
|
all addresses within the network is called the `network portion' of
|
|
|
|
|
|
the address. The remaining digits are called the `host portion'. The
|
|
|
|
|
|
number of bits that are shared by all addresses within a network is
|
|
|
|
|
|
called the netmask and it is role of the netmask to determine which
|
|
|
|
|
|
addresses belong to the network it is applied to and which don't. For
|
|
|
|
|
|
example, consider the following:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
----------------- ---------------
|
|
|
|
|
|
Host Address 192.168.110.23
|
|
|
|
|
|
Network Mask 255.255.255.0
|
|
|
|
|
|
Network Portion 192.168.110.
|
|
|
|
|
|
Host portion .23
|
|
|
|
|
|
----------------- ---------------
|
|
|
|
|
|
Network Address 192.168.110.0
|
|
|
|
|
|
Broadcast Address 192.168.110.255
|
|
|
|
|
|
----------------- ---------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Any address that is 'bitwise anded' with its netmask will reveal the
|
|
|
|
|
|
address of the network it belongs to. The network address is therefore
|
|
|
|
|
|
always the lowest numbered address within the range of addresses on
|
|
|
|
|
|
the network and always has the host portion of the address coded all
|
|
|
|
|
|
zeroes.
|
|
|
|
|
|
|
|
|
|
|
|
The broadcast address is a special address that every host on the
|
|
|
|
|
|
network listens to in addition to its own unique address. This address
|
|
|
|
|
|
is the one that datagrams are sent to if every host on the network is
|
|
|
|
|
|
meant to receive it. Certain types of data like routing information
|
|
|
|
|
|
and warning messages are transmitted to the broadcast address so that
|
|
|
|
|
|
every host on the network can receive it simultaneously. There are two
|
|
|
|
|
|
commonly used standards for what the broadcast address should be. The
|
|
|
|
|
|
most widely accepted one is to use the highest possible address on the
|
|
|
|
|
|
network as the broadcast address. In the example above this would be
|
|
|
|
|
|
192.168.110.255. For some reason other sites have adopted the
|
|
|
|
|
|
convention of using the network address as the broadcast address. In
|
|
|
|
|
|
practice it doesn't matter very much which you use but you must make
|
|
|
|
|
|
sure that every host on the network is configured with the same
|
|
|
|
|
|
broadcast address.
|
|
|
|
|
|
|
|
|
|
|
|
For administrative reasons some time early in the development of the
|
|
|
|
|
|
IP protocol some arbitrary groups of addresses were formed into
|
|
|
|
|
|
networks and these networks were grouped into what are called classes.
|
|
|
|
|
|
These classes provide a number of standard size networks that could be
|
|
|
|
|
|
allocated. The ranges allocated are:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
----------------------------------------------------------
|
|
|
|
|
|
| Network | Netmask | Network Addresses |
|
|
|
|
|
|
| Class | | |
|
|
|
|
|
|
----------------------------------------------------------
|
|
|
|
|
|
| A | 255.0.0.0 | 0.0.0.0 - 127.255.255.255 |
|
|
|
|
|
|
| B | 255.255.0.0 | 128.0.0.0 - 191.255.255.255 |
|
|
|
|
|
|
| C | 255.255.255.0 | 192.0.0.0 - 223.255.255.255 |
|
|
|
|
|
|
|Multicast| 240.0.0.0 | 224.0.0.0 - 239.255.255.255 |
|
|
|
|
|
|
----------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
What addresses you should use depends on exactly what it is that you
|
|
|
|
|
|
are doing. You may have to use a combination of the following
|
|
|
|
|
|
activities to get all the addresses you need:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Installing a linux machine on an existing IP network
|
|
|
|
|
|
If you wish to install a linux machine onto an existing IP
|
|
|
|
|
|
network then you should contact whoever administers the network
|
|
|
|
|
|
and ask them for the following information:
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· Host IP Address
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· IP network address
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· IP broadcast address
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· IP netmask
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· Router address
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· Domain Name Server Address
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
You should then configure your linux network device with those
|
|
|
|
|
|
details. You can not make them up and expect your configuration
|
|
|
|
|
|
to work.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Building a brand new network that will never connect to the
|
|
|
|
|
|
Internet" If you are building a private network and you never
|
|
|
|
|
|
intend that network to be connected to the Internet then you can
|
|
|
|
|
|
choose whatever addresses you like. However, for safety and
|
|
|
|
|
|
consistency reasons there have been some IP network addresses
|
|
|
|
|
|
that have been reserved specifically for this purpose. These are
|
|
|
|
|
|
specified in RFC1597 and are as follows:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-----------------------------------------------------------
|
|
|
|
|
|
| RESERVED PRIVATE NETWORK ALLOCATIONS |
|
|
|
|
|
|
-----------------------------------------------------------
|
|
|
|
|
|
| Network | Netmask | Network Addresses |
|
|
|
|
|
|
| Class | | |
|
|
|
|
|
|
-----------------------------------------------------------
|
|
|
|
|
|
| A | 255.0.0.0 | 10.0.0.0 - 10.255.255.255 |
|
|
|
|
|
|
| B | 255.255.0.0 | 172.16.0.0 - 172.31.255.255 |
|
|
|
|
|
|
| C | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
|
|
|
|
|
|
-----------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
You should first decide how large you want your network to be and
|
|
|
|
|
|
then choose as many of the addresses as you require.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.2. Where should I put the configuration commands ?
|
|
|
|
|
|
|
|
|
|
|
|
There are a few different approaches to Linux system boot procedures.
|
|
|
|
|
|
After the kernel boots, it always executes a program called `init'.
|
|
|
|
|
|
The init program then reads its configuration file called /etc/inittab
|
|
|
|
|
|
and commences the boot process. There are a few different flavours of
|
|
|
|
|
|
init around, although everyone is now converging to the System V
|
|
|
|
|
|
(Five) flavor, developed by Miguel van Smoorenburg.
|
|
|
|
|
|
|
|
|
|
|
|
Despite the fact that the init program is always the same, the setup
|
|
|
|
|
|
of system boot is organized in a different way by each distribution.
|
|
|
|
|
|
|
|
|
|
|
|
Usually the /etc/inittab file contains an entry looking something
|
|
|
|
|
|
like:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
si::sysinit:/etc/init.d/boot
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This line specifies the name of the shell script file that actually
|
|
|
|
|
|
manages the boot sequence. This file is somewhat equivalent to the
|
|
|
|
|
|
AUTOEXEC.BAT file in MS-DOS.
|
|
|
|
|
|
|
|
|
|
|
|
There are usually other scripts that are called by the boot script and
|
|
|
|
|
|
often the network is configured within one of many of these.
|
|
|
|
|
|
|
|
|
|
|
|
The following table may be used as a guide for your system:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---------------------------------------------------------------------------
|
|
|
|
|
|
Distrib. | Interface Config/Routing | Server Initialization
|
|
|
|
|
|
---------------------------------------------------------------------------
|
|
|
|
|
|
Debian | /etc/init.d/network | /etc/rc2.d/*
|
|
|
|
|
|
---------------------------------------------------------------------------
|
|
|
|
|
|
Slackware| /etc/rc.d/rc.inet1 | /etc/rc.d/rc.inet2
|
|
|
|
|
|
---------------------------------------------------------------------------
|
|
|
|
|
|
RedHat | /etc/rc.d/init.d/network | /etc/rc.d/rc3.d/*
|
|
|
|
|
|
---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note that Debian and Red Hat use a whole directory to host scripts
|
|
|
|
|
|
that fire up system services (and usually information does not lie
|
|
|
|
|
|
within these files, for example Red Hat systems store all of system
|
|
|
|
|
|
configuration in files under /etc/sysconfig, whence it is retrieved by
|
|
|
|
|
|
boot scripts). If you want to grasp the details of the boot process,
|
|
|
|
|
|
my suggestion is to check /etc/inittab and the documentation that
|
|
|
|
|
|
accompanies init. Linux Journal is also going to publish an article
|
|
|
|
|
|
about system initialization, and this document will point to it as
|
|
|
|
|
|
soon as it is available on the web.
|
|
|
|
|
|
|
|
|
|
|
|
Most modern distributions include a program that will allow you to
|
|
|
|
|
|
configure many of the common sorts of network interfaces. If you have
|
|
|
|
|
|
one of these then you should see if it will do what you want before
|
|
|
|
|
|
attempting a manual configuration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-----------------------------------------
|
|
|
|
|
|
Distrib | Network configuration program
|
|
|
|
|
|
-----------------------------------------
|
|
|
|
|
|
RedHat | /usr/bin/netcfg
|
|
|
|
|
|
Slackware | /sbin/netconfig
|
|
|
|
|
|
-----------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.3. Creating your network interfaces.
|
|
|
|
|
|
|
|
|
|
|
|
In many Unix operating systems the network devices have appearances in
|
|
|
|
|
|
the /dev directory. This is not so in Linux. In Linux the network
|
|
|
|
|
|
devices are created dynamically in software and do not require device
|
|
|
|
|
|
files to be present.
|
|
|
|
|
|
|
|
|
|
|
|
In the majority of cases the network device is automatically created
|
|
|
|
|
|
by the device driver while it is initializing and has located your
|
|
|
|
|
|
hardware. For example, the ethernet device driver creates eth[0..n]
|
|
|
|
|
|
interfaces sequentially as it locates your ethernet hardware. The
|
|
|
|
|
|
first ethernet card found becomes eth0, the second eth1 etc.
|
|
|
|
|
|
|
|
|
|
|
|
In some cases though, notably slip and ppp, the network devices are
|
|
|
|
|
|
created through the action of some user program. The same sequential
|
|
|
|
|
|
device numbering applies, but the devices are not created
|
|
|
|
|
|
automatically at boot time. The reason for this is that unlike
|
|
|
|
|
|
ethernet devices, the number of active slip or ppp devices may vary
|
|
|
|
|
|
during the uptime of the machine. These cases will be covered in more
|
|
|
|
|
|
detail in later sections.
|
|
|
|
|
|
|
|
|
|
|
|
5.4. Configuring a network interface.
|
|
|
|
|
|
|
|
|
|
|
|
When you have all of the programs you need and your address and
|
|
|
|
|
|
network information you can configure your network interfaces. When we
|
|
|
|
|
|
talk about configuring a network interface we are talking about the
|
|
|
|
|
|
process of assigning appropriate addresses to a network device and to
|
|
|
|
|
|
setting appropriate values for other configurable parameters of a
|
|
|
|
|
|
network device. The program most commonly used to do this is the
|
|
|
|
|
|
ifconfig (interface configure) command.
|
|
|
|
|
|
|
|
|
|
|
|
Typically you would use a command similar to the following:
|
|
|
|
|
|
|
|
|
|
|
|
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
|
|
|
|
|
|
|
|
|
|
|
|
In this case I'm configuring an ethernet interface `eth0' with the IP
|
|
|
|
|
|
address `192.168.0.1' and a network mask of `255.255.255.0'. The `up'
|
|
|
|
|
|
that trails the command tells the interface that it should become
|
|
|
|
|
|
active, but can usually be omitted, as it is the default. To shutdown
|
|
|
|
|
|
an interface, you can just call ``ifconfig eth0 down''.
|
|
|
|
|
|
|
|
|
|
|
|
The kernel assumes certain defaults when configuring interfaces. For
|
|
|
|
|
|
example, you may specify the network address and broadcast address for
|
|
|
|
|
|
an interface, but if you don't, as in my example above, then the
|
|
|
|
|
|
kernel will make reasonable guesses as to what they should be based on
|
|
|
|
|
|
the netmask you supply and if you don't supply a netmask then on the
|
|
|
|
|
|
network class of the IP address configured. In my example the kernel
|
|
|
|
|
|
would assume that it is a class-C network being configured on the
|
|
|
|
|
|
interface and configure a network address of `192.168.0.0' and a
|
|
|
|
|
|
broadcast address of `192.168.0.255' for the interface.
|
|
|
|
|
|
|
|
|
|
|
|
There are many other options to the ifconfig command. The most
|
|
|
|
|
|
important of these are:
|
|
|
|
|
|
|
|
|
|
|
|
up this option activates an interface (and is the default).
|
|
|
|
|
|
|
|
|
|
|
|
down
|
|
|
|
|
|
this option deactivates an interface.
|
|
|
|
|
|
|
|
|
|
|
|
[-]arp
|
|
|
|
|
|
this option enables or disables use of the address resolution
|
|
|
|
|
|
protocol on this interface
|
|
|
|
|
|
|
|
|
|
|
|
[-]allmulti
|
|
|
|
|
|
this option enables or disables the reception of all hardware
|
|
|
|
|
|
multicast packets. Hardware multicast enables groups of hosts to
|
|
|
|
|
|
receive packets addressed to special destinations. This may be
|
|
|
|
|
|
of importance if you are using applications like desktop
|
|
|
|
|
|
videoconferencing but is normally not used.
|
|
|
|
|
|
|
|
|
|
|
|
mtu N
|
|
|
|
|
|
this parameter allows you to set the MTU of this device.
|
|
|
|
|
|
|
|
|
|
|
|
netmask <addr>
|
|
|
|
|
|
this parameter allows you to set the network mask of the network
|
|
|
|
|
|
this device belongs to.
|
|
|
|
|
|
|
|
|
|
|
|
irq <addr>
|
|
|
|
|
|
this parameter only works on certain types of hardware and
|
|
|
|
|
|
allows you to set the IRQ of the hardware of this device.
|
|
|
|
|
|
|
|
|
|
|
|
[-]broadcast [addr]
|
|
|
|
|
|
this parameter allows you to enable and set the accepting of
|
|
|
|
|
|
datagrams destined to the broadcast address, or to disable
|
|
|
|
|
|
reception of these datagrams.
|
|
|
|
|
|
|
|
|
|
|
|
[-]pointopoint [addr]
|
|
|
|
|
|
this parameter allows you to set the address of the machine at
|
|
|
|
|
|
the remote end of a point to point link such as for slip or ppp.
|
|
|
|
|
|
|
|
|
|
|
|
hw <type> <addr>
|
|
|
|
|
|
this parameter allows you to set the hardware address of certain
|
|
|
|
|
|
types of network devices. This is not often useful for ethernet,
|
|
|
|
|
|
but is useful for other network types such as AX.25.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
You may use the ifconfig command on any network interface. Some user
|
|
|
|
|
|
programs such as pppd and dip automatically configure the network
|
|
|
|
|
|
devices as they create them, so manual use of ifconfig is unnecessary.
|
|
|
|
|
|
|
|
|
|
|
|
5.5. Configuring your Name Resolver.
|
|
|
|
|
|
|
|
|
|
|
|
The `Name Resolver' is a part of the linux standard library. Its prime
|
|
|
|
|
|
function is to provide a service to convert human-friendly hostnames
|
|
|
|
|
|
like `ftp.funet.fi' into machine friendly IP addresses such as
|
|
|
|
|
|
128.214.248.6.
|
|
|
|
|
|
|
|
|
|
|
|
5.5.1. What's in a name ?
|
|
|
|
|
|
|
|
|
|
|
|
You will probably be familiar with the appearance of Internet host
|
|
|
|
|
|
names, but may not understand how they are constructed, or
|
|
|
|
|
|
deconstructed. Internet domain names are hierarchical in nature, that
|
|
|
|
|
|
is, they have a tree-like structure. A `domain' is a family, or group
|
|
|
|
|
|
of names. A `domain' may be broken down into `subdomain'. A `toplevel
|
|
|
|
|
|
domain' is a domain that is not a subdomain. The Top Level Domains are
|
|
|
|
|
|
specified in RFC-920. Some examples of the most common top level
|
|
|
|
|
|
domains are:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
COM
|
|
|
|
|
|
Commercial Organizations
|
|
|
|
|
|
|
|
|
|
|
|
EDU
|
|
|
|
|
|
Educational Organizations
|
|
|
|
|
|
|
|
|
|
|
|
GOV
|
|
|
|
|
|
Government Organizations
|
|
|
|
|
|
|
|
|
|
|
|
MIL
|
|
|
|
|
|
Military Organizations
|
|
|
|
|
|
|
|
|
|
|
|
ORG
|
|
|
|
|
|
Other organizations
|
|
|
|
|
|
|
|
|
|
|
|
NET
|
|
|
|
|
|
Internet-Related Organizations
|
|
|
|
|
|
|
|
|
|
|
|
Country Designator
|
|
|
|
|
|
these are two letters codes that represent a particular country.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For historical reasons most domains belonging to one of the non-
|
|
|
|
|
|
country based top level domains were used by organizations within the
|
|
|
|
|
|
United States, although the United States also has its own country
|
|
|
|
|
|
code `.us'. This is not true any more for .com and .org domains, which
|
|
|
|
|
|
are commonly used by non-us companies.
|
|
|
|
|
|
|
|
|
|
|
|
Each of these top level domains has subdomains. The top level domains
|
|
|
|
|
|
based on country name are often next broken down into subdomains based
|
|
|
|
|
|
on the com, edu, gov, mil and org domains. So for example you end up
|
|
|
|
|
|
with: com.au and gov.au for commercial and government organizations in
|
|
|
|
|
|
Australia; note that this is not a general rule, as actual policies
|
|
|
|
|
|
depend on the naming authority for each domain.
|
|
|
|
|
|
|
|
|
|
|
|
The next level of division usually represents the name of the
|
|
|
|
|
|
organization. Further subdomains vary in nature, often the next level
|
|
|
|
|
|
of subdomain is based on the departmental structure of the
|
|
|
|
|
|
organization but it may be based on any criterion considered
|
|
|
|
|
|
reasonable and meaningful by the network administrators for the
|
|
|
|
|
|
organization.
|
|
|
|
|
|
|
|
|
|
|
|
The very left-most portion of the name is always the unique name
|
|
|
|
|
|
assigned to the host machine and is called the `hostname', the portion
|
|
|
|
|
|
of the name to the right of the hostname is called the `domainname'
|
|
|
|
|
|
and the complete name is called the `Fully Qualified Domain Name'.
|
|
|
|
|
|
|
|
|
|
|
|
To use Terry's host as an example, the fully qualified domain name is
|
|
|
|
|
|
`perf.no.itg.telstra.com.au'. This means that the host name is `perf'
|
|
|
|
|
|
and the domain name is `no.itg.telstra.com.au'. The domain name is
|
|
|
|
|
|
based on a top level domain based on his country, Australia and as his
|
|
|
|
|
|
email address belongs to a commercial organization, `.com' is there as
|
|
|
|
|
|
the next level domain. The name of the company is (was) `telstra' and
|
|
|
|
|
|
their internal naming structure is based on organizational structure,
|
|
|
|
|
|
in this case the machine belongs to the Information Technology Group,
|
|
|
|
|
|
Network Operations section.
|
|
|
|
|
|
|
|
|
|
|
|
Usually, the names are fairly shorter; for example, my ISP is called
|
|
|
|
|
|
``systemy.it'' and my non-profit organization is called ``linux.it'',
|
|
|
|
|
|
without any com and org subdomain, so that my own host is just called
|
|
|
|
|
|
``morgana.systemy.it'' and rubini@linux.it is a valid email address.
|
|
|
|
|
|
Note that the owner of a domain has the rights to register hostnames
|
|
|
|
|
|
as well as subdomains; for example, the LUG I belong to uses the
|
|
|
|
|
|
domain pluto.linux.it, because the owners of linux.it agreed to open a
|
|
|
|
|
|
subdomain for the LUG.
|
|
|
|
|
|
|
|
|
|
|
|
5.5.2. What information you will need.
|
|
|
|
|
|
|
|
|
|
|
|
You will need to know what domain your hosts name will belong to. The
|
|
|
|
|
|
name resolver software provides this name translation service by
|
|
|
|
|
|
making requests to a `Domain Name Server', so you will need to know
|
|
|
|
|
|
the IP address of a local nameserver that you can use.
|
|
|
|
|
|
|
|
|
|
|
|
There are three files you need to edit, I'll cover each of these in
|
|
|
|
|
|
turn.
|
|
|
|
|
|
|
|
|
|
|
|
5.5.3. /etc/resolv.conf
|
|
|
|
|
|
|
|
|
|
|
|
The /etc/resolv.conf is the main configuration file for the name
|
|
|
|
|
|
resolver code. Its format is quite simple. It is a text file with one
|
|
|
|
|
|
keyword per line. There are three keywords typically used, they are:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
domain
|
|
|
|
|
|
this keyword specifies the local domain name.
|
|
|
|
|
|
|
|
|
|
|
|
search
|
|
|
|
|
|
this keyword specifies a list of alternate domain names to
|
|
|
|
|
|
search for a hostname
|
|
|
|
|
|
|
|
|
|
|
|
nameserver
|
|
|
|
|
|
this keyword, which may be used many times, specifies an IP
|
|
|
|
|
|
address of a domain name server to query when resolving names
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
An example /etc/resolv.conf might look something like:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
domain maths.wu.edu.au
|
|
|
|
|
|
search maths.wu.edu.au wu.edu.au
|
|
|
|
|
|
nameserver 192.168.10.1
|
|
|
|
|
|
nameserver 192.168.12.1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This example specifies that the default domain name to append to
|
|
|
|
|
|
unqualified names (ie hostnames supplied without a domain) is
|
|
|
|
|
|
maths.wu.edu.au and that if the host is not found in that domain to
|
|
|
|
|
|
also try the wu.edu.au domain directly. Two nameservers entry are
|
|
|
|
|
|
supplied, each of which may be called upon by the name resolver code
|
|
|
|
|
|
to resolve the name.
|
|
|
|
|
|
|
|
|
|
|
|
5.5.4. /etc/host.conf
|
|
|
|
|
|
|
|
|
|
|
|
The /etc/host.conf file is where you configure some items that govern
|
|
|
|
|
|
the behaviour of the name resolver code. The format of this file is
|
|
|
|
|
|
described in detail in the `resolv+' man page. In nearly all
|
|
|
|
|
|
circumstances the following example will work for you:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
order hosts,bind
|
|
|
|
|
|
multi on
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This configuration tells the name resolver to check the /etc/hosts
|
|
|
|
|
|
file before attempting to query a nameserver and to return all valid
|
|
|
|
|
|
addresses for a host found in the /etc/hosts file instead of just the
|
|
|
|
|
|
first.
|
|
|
|
|
|
|
|
|
|
|
|
5.5.5. /etc/hosts
|
|
|
|
|
|
|
|
|
|
|
|
The /etc/hosts file is where you put the name and IP address of local
|
|
|
|
|
|
hosts. If you place a host in this file then you do not need to query
|
|
|
|
|
|
the domain name server to get its IP Address. The disadvantage of
|
|
|
|
|
|
doing this is that you must keep this file up to date yourself if the
|
|
|
|
|
|
IP address for that host changes. In a well managed system the only
|
|
|
|
|
|
hostnames that usually appear in this file are an entry for the
|
|
|
|
|
|
loopback interface and the local hosts name.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# /etc/hosts
|
|
|
|
|
|
127.0.0.1 localhost loopback
|
|
|
|
|
|
192.168.0.1 this.host.name
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
You may specify more than one host name per line as demonstrated by
|
|
|
|
|
|
the first entry, which is a standard entry for the loopback interface.
|
|
|
|
|
|
|
|
|
|
|
|
5.5.6. Running a name server
|
|
|
|
|
|
|
|
|
|
|
|
If you want to run a local nameserver, you can do it easily. Please
|
|
|
|
|
|
refer to the DNS-HOWTO and to any documents included in your version
|
|
|
|
|
|
of BIND (Berkeley Internet Name Domain).
|
|
|
|
|
|
|
|
|
|
|
|
5.6. Configuring your loopback interface.
|
|
|
|
|
|
|
|
|
|
|
|
The `loopback' interface is a special type of interface that allows
|
|
|
|
|
|
you to make connections to yourself. There are various reasons why you
|
|
|
|
|
|
might want to do this, for example, you may wish to test some network
|
|
|
|
|
|
software without interfering with anybody else on your network. By
|
|
|
|
|
|
convention the IP address `127.0.0.1' has been assigned specifically
|
|
|
|
|
|
for loopback. So no matter what machine you go to, if you open a
|
|
|
|
|
|
telnet connection to 127.0.0.1 you will always reach the local host.
|
|
|
|
|
|
|
|
|
|
|
|
Configuring the loopback interface is simple and you should ensure you
|
|
|
|
|
|
do (but note that this task is usually performed by the standard
|
|
|
|
|
|
initialization scripts).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
root# ifconfig lo 127.0.0.1
|
|
|
|
|
|
root# route add -host 127.0.0.1 lo
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We'll talk more about the route command in the next section.
|
|
|
|
|
|
|
|
|
|
|
|
5.7. Routing.
|
|
|
|
|
|
|
|
|
|
|
|
Routing is a big topic. It is easily possible to write large volumes
|
|
|
|
|
|
of text about it. Most of you will have fairly simple routing
|
|
|
|
|
|
requirements, some of you will not. I will cover some basic
|
|
|
|
|
|
fundamentals of routing only. If you are interested in more detailed
|
|
|
|
|
|
information then I suggest you refer to the references provided at the
|
|
|
|
|
|
start of the document.
|
|
|
|
|
|
|
|
|
|
|
|
Let's start with a definition. What is IP routing ? Here is one that
|
|
|
|
|
|
I'm using:
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
IP Routing is the process by which a host with multiple net
|
2004-11-04 02:03:06 +00:00
|
|
|
|
work connections decides where to deliver IP datagrams it
|
|
|
|
|
|
has received.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It might be useful to illustrate this with an example. Imagine a
|
|
|
|
|
|
typical office router, it might have a PPP link off the Internet, a
|
|
|
|
|
|
number of ethernet segments feeding the workstations and another PPP
|
|
|
|
|
|
link off to another office. When the router receives a datagram on any
|
|
|
|
|
|
of its network connections, routing is the mechanism that it uses to
|
|
|
|
|
|
determine which interface it should send the datagram to next. Simple
|
|
|
|
|
|
hosts also need to route, all Internet hosts have two network devices,
|
|
|
|
|
|
one is the loopback interface described above and the other is the one
|
|
|
|
|
|
it uses to talk to the rest of the network, perhaps an ethernet,
|
|
|
|
|
|
perhaps a PPP or SLIP serial interface.
|
|
|
|
|
|
|
|
|
|
|
|
Ok, so how does routing work ? Each host keeps a special list of
|
|
|
|
|
|
routing rules, called a routing table. This table contains rows which
|
|
|
|
|
|
typically contain at least three fields, the first is a destination
|
|
|
|
|
|
address, the second is the name of the interface to which the datagram
|
|
|
|
|
|
is to be routed and the third is optionally the IP address of another
|
|
|
|
|
|
machine which will carry the datagram on its next step through the
|
|
|
|
|
|
network. In linux you can see this table by using the following
|
|
|
|
|
|
command:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
user% cat /proc/net/route
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
or by using either of the following commands:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
user% /sbin/route -n
|
|
|
|
|
|
user% netstat -r
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The routing process is fairly simple: an incoming datagram is
|
|
|
|
|
|
received, the destination address (who it is for) is examined and
|
|
|
|
|
|
compared with each entry in the table. The entry that best matches
|
|
|
|
|
|
that address is selected and the datagram is forwarded to the
|
|
|
|
|
|
specified interface. If the gateway field is filled then the datagram
|
|
|
|
|
|
is forwarded to that host via the specified interface, otherwise the
|
|
|
|
|
|
destination address is assumed to be on the network supported by the
|
|
|
|
|
|
interface.
|
|
|
|
|
|
|
|
|
|
|
|
To manipulate this table a special command is used. This command takes
|
|
|
|
|
|
command line arguments and converts them into kernel system calls that
|
|
|
|
|
|
request the kernel to add, delete or modify entries in the routing
|
|
|
|
|
|
table. The command is called `route'.
|
|
|
|
|
|
|
|
|
|
|
|
A simple example. Imagine you have an ethernet network. You've been
|
|
|
|
|
|
told it is a class-C network with an address of 192.168.1.0. You've
|
|
|
|
|
|
been supplied with an IP address of 192.168.1.10 for your use and have
|
|
|
|
|
|
been told that 192.168.1.1 is a router connected to the Internet.
|
|
|
|
|
|
|
|
|
|
|
|
The first step is to configure the interface as described earlier. You
|
|
|
|
|
|
would use a command like:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
You now need to add an entry into the routing table to tell the kernel
|
|
|
|
|
|
that datagrams for all hosts with addresses that match 192.168.1.*
|
|
|
|
|
|
should be sent to the ethernet device. You would use a command similar
|
|
|
|
|
|
to:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note the use of the `-net' argument to tell the route program that
|
|
|
|
|
|
this entry is a network route. Your other choice here is a `-host'
|
|
|
|
|
|
route which is a route that is specific to one IP address.
|
|
|
|
|
|
|
|
|
|
|
|
This route will enable you to establish IP connections with all of the
|
|
|
|
|
|
hosts on your ethernet segment. But what about all of the IP hosts
|
|
|
|
|
|
that aren't on your ethernet segment ?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It would be a very difficult job to have to add routes to every
|
|
|
|
|
|
possible destination network, so there is a special trick that is used
|
|
|
|
|
|
to simplify this task. The trick is called the `default' route. The
|
|
|
|
|
|
default route matches every possible destination, but poorly, so that
|
|
|
|
|
|
if any other entry exists that matches the required address it will be
|
|
|
|
|
|
used instead of the default route. The idea of the default route is
|
|
|
|
|
|
simply to enable you to say "and everything else should go here". In
|
|
|
|
|
|
the example I've contrived you would use an entry like:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
root# route add default gw 192.168.1.1 eth0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The `gw' argument tells the route command that the next argument is
|
|
|
|
|
|
the IP address, or name, of a gateway or router machine which all
|
|
|
|
|
|
datagrams matching this entry should be directed to for further
|
|
|
|
|
|
routing.
|
|
|
|
|
|
|
|
|
|
|
|
So, your complete configuration would look like:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
|
|
|
|
|
|
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
|
|
|
|
|
|
root# route add default gw 192.168.1.1 eth0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If you take a close look at your network `rc' files you will find that
|
|
|
|
|
|
at least one of them looks very similar to this. This is a very common
|
|
|
|
|
|
configuration.
|
|
|
|
|
|
|
|
|
|
|
|
Let's now look at a slightly more complicated routing configuration.
|
|
|
|
|
|
Let's imagine we are configuring the router we looked at earlier, the
|
|
|
|
|
|
one supporting the PPP link to the Internet and the lan segments
|
|
|
|
|
|
feeding the workstations in the office. Lets imagine the router has
|
|
|
|
|
|
three ethernet segments and one PPP link. Our routing configuration
|
|
|
|
|
|
would look something like:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
|
|
|
|
|
|
root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
|
|
|
|
|
|
root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
|
|
|
|
|
|
root# route add default ppp0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Each of the workstations would use the simpler form presented above,
|
|
|
|
|
|
only the router needs to specify each of the network routes separately
|
|
|
|
|
|
because for the workstations the default route mechanism will capture
|
|
|
|
|
|
all of them letting the router worry about splitting them up
|
|
|
|
|
|
appropriately. You may be wondering why the default route presented
|
|
|
|
|
|
doesn't specify a `gw'. The reason for this is simple, serial link
|
|
|
|
|
|
protocols such as PPP and slip only ever have two hosts on their
|
|
|
|
|
|
network, one at each end. To specify the host at the other end of the
|
|
|
|
|
|
link as the gateway is pointless and redundant as there is no other
|
|
|
|
|
|
choice, so you do not need to specify a gateway for these types of
|
|
|
|
|
|
network connections. Other network types such as ethernet, arcnet or
|
|
|
|
|
|
token ring do require the gateway to be specified as these networks
|
|
|
|
|
|
support large numbers of hosts on them.
|
|
|
|
|
|
|
|
|
|
|
|
5.7.1. So what does the routed program do ?
|
|
|
|
|
|
|
|
|
|
|
|
The routing configuration described above is best suited to simple
|
|
|
|
|
|
network arrangements where there are only ever single possible paths
|
|
|
|
|
|
to destinations. When you have a more complex network arrangement
|
|
|
|
|
|
things get a little more complicated. Fortunately for most of you this
|
|
|
|
|
|
won't be an issue.
|
|
|
|
|
|
|
|
|
|
|
|
The big problem with `manual routing' or `static routing' as
|
|
|
|
|
|
described, is that if a machine or link fails in your network then the
|
|
|
|
|
|
only way you can direct your datagrams another way, if another way
|
|
|
|
|
|
exists, is by manually intervening and executing the appropriate
|
|
|
|
|
|
commands. Naturally this is clumsy, slow, impractical and hazard
|
|
|
|
|
|
prone. Various techniques have been developed to automatically adjust
|
|
|
|
|
|
routing tables in the event of network failures where there are
|
|
|
|
|
|
alternate routes, all of these techniques are loosely grouped by the
|
|
|
|
|
|
term `dynamic routing protocols'.
|
|
|
|
|
|
|
|
|
|
|
|
You may have heard of some of the more common dynamic routing
|
|
|
|
|
|
protocols. The most common are probably RIP (Routing Information
|
|
|
|
|
|
Protocol) and OSPF (Open Shortest Path First Protocol). The Routing
|
|
|
|
|
|
Information Protocol is very common on small networks such as small-
|
|
|
|
|
|
medium sized corporate networks or building networks. OSPF is more
|
|
|
|
|
|
modern and more capable at handling large network configurations and
|
|
|
|
|
|
better suited to environments where there is a large number of
|
|
|
|
|
|
possible paths through the network. Common implementations of these
|
|
|
|
|
|
protocols are: `routed' - RIP and `gated' - RIP, OSPF and others. The
|
|
|
|
|
|
`routed' program is normally supplied with your Linux distribution or
|
|
|
|
|
|
is included in the `NetKit' package detailed above.
|
|
|
|
|
|
|
|
|
|
|
|
An example of where and how you might use a dynamic routing protocol
|
|
|
|
|
|
might look something like the following:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
192.168.1.0 / 192.168.2.0 /
|
|
|
|
|
|
255.255.255.0 255.255.255.0
|
|
|
|
|
|
- -
|
|
|
|
|
|
| |
|
|
|
|
|
|
| /-----\ /-----\ |
|
|
|
|
|
|
| | |ppp0 // ppp0| | |
|
|
|
|
|
|
eth0 |---| A |------//---------| B |---| eth0
|
|
|
|
|
|
| | | // | | |
|
|
|
|
|
|
| \-----/ \-----/ |
|
|
|
|
|
|
| \ ppp1 ppp1 / |
|
|
|
|
|
|
- \ / -
|
|
|
|
|
|
\ /
|
|
|
|
|
|
\ /
|
|
|
|
|
|
\ /
|
|
|
|
|
|
\ /
|
|
|
|
|
|
\ /
|
|
|
|
|
|
\ /
|
|
|
|
|
|
\ /
|
|
|
|
|
|
\ /
|
|
|
|
|
|
ppp0\ /ppp1
|
|
|
|
|
|
/-----\
|
|
|
|
|
|
| |
|
|
|
|
|
|
| C |
|
|
|
|
|
|
| |
|
|
|
|
|
|
\-----/
|
|
|
|
|
|
|eth0
|
|
|
|
|
|
|
|
|
|
|
|
|
|---------|
|
|
|
|
|
|
192.168.3.0 /
|
|
|
|
|
|
255.255.255.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We have three routers A, B and C. Each supports one ethernet segment
|
|
|
|
|
|
with a Class C IP network (netmask 255.255.255.0). Each router also
|
|
|
|
|
|
has a PPP link to each of the other routers. The network forms a
|
|
|
|
|
|
triangle.
|
|
|
|
|
|
|
|
|
|
|
|
It should be clear that the routing table at router A could look like:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
|
|
|
|
|
|
root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
|
|
|
|
|
|
root# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This would work just fine until the link between router A and B should
|
|
|
|
|
|
fail. If that link failed then with the routing entry shown above
|
|
|
|
|
|
hosts on the ethernet segment of A could not reach hosts on the
|
|
|
|
|
|
ethernet segment on B because their datagram would be directed to
|
|
|
|
|
|
router A's ppp0 link which is broken. They could still continue to
|
|
|
|
|
|
talk to hosts on the ethernet segment of C and hosts on the C's
|
|
|
|
|
|
ethernet segment could still talk to hosts on B's ethernet segment
|
|
|
|
|
|
because the link between B and C is still intact.
|
|
|
|
|
|
|
|
|
|
|
|
But wait, if A can talk to C and C can still talk to B, why shouldn't
|
|
|
|
|
|
A route its datagrams for B via C and let C send them to B ? This is
|
|
|
|
|
|
exactly the sort of problem that dynamic routing protocols like RIP
|
|
|
|
|
|
were designed to solve. If each of the routers A, B and C were running
|
|
|
|
|
|
a routing daemon then their routing tables would be automatically
|
|
|
|
|
|
adjusted to reflect the new state of the network should any one of the
|
|
|
|
|
|
links in the network fail. To configure such a network is simple, at
|
|
|
|
|
|
each router you need only do two things. In this case for Router A:
|
|
|
|
|
|
|
|
|
|
|
|
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
|
|
|
|
|
|
root# /usr/sbin/routed
|
|
|
|
|
|
|
|
|
|
|
|
The `routed' routing daemon automatically finds all active network
|
|
|
|
|
|
ports when it starts and sends and listens for messages on each of the
|
|
|
|
|
|
network devices to allow it to determine and update the routing table
|
|
|
|
|
|
on the host.
|
|
|
|
|
|
|
|
|
|
|
|
This has been a very brief explanation of dynamic routing and where
|
|
|
|
|
|
you would use it. If you want more information then you should refer
|
|
|
|
|
|
to the suggested references listed at the top of the document.
|
|
|
|
|
|
|
|
|
|
|
|
The important points relating to dynamic routing are:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1. You only need to run a dynamic routing protocol daemon when your
|
|
|
|
|
|
Linux machine has the possibility of selecting multiple possible
|
|
|
|
|
|
routes to a destination. An example of this would be if you plan
|
|
|
|
|
|
to use IP Masquerading.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2. The dynamic routing daemon will automatically modify your routing
|
|
|
|
|
|
table to adjust to changes in your network.
|
|
|
|
|
|
|
|
|
|
|
|
3. RIP is suited to small to medium sized networks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.8. Configuring your network servers and services.
|
|
|
|
|
|
|
|
|
|
|
|
Network servers and services are those programs that allow a remote
|
|
|
|
|
|
user to make user of your Linux machine. Server programs listen on
|
|
|
|
|
|
network ports. Network ports are a means of addressing a particular
|
|
|
|
|
|
service on any particular host and are how a server knows the
|
|
|
|
|
|
difference between an incoming telnet connection and an incoming ftp
|
|
|
|
|
|
connection. The remote user establishes a network connection to your
|
|
|
|
|
|
machine and the server program, the network daemon program, listening
|
|
|
|
|
|
on that port accepts the connection and executes. There are two ways
|
|
|
|
|
|
that network daemons may operate. Both are commonly employed in
|
|
|
|
|
|
practice. The two ways are:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
standalone
|
|
|
|
|
|
the network daemon program listens on the designated network
|
|
|
|
|
|
port and when an incoming connection is made it manages the
|
|
|
|
|
|
network connection itself to provide the service.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
slave to the inetd server
|
|
|
|
|
|
the inetd server is a special network daemon program that
|
|
|
|
|
|
specializes in managing incoming network connections. It has a
|
|
|
|
|
|
configuration file which tells it what program needs to be run
|
|
|
|
|
|
when an incoming connection is received. Any service port may be
|
|
|
|
|
|
configured for either of the tcp or udp protcols. The ports are
|
|
|
|
|
|
described in another file that we will talk about soon.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There are two important files that we need to configure. They are the
|
|
|
|
|
|
/etc/services file which assigns names to port numbers and the
|
|
|
|
|
|
/etc/inetd.conf file which is the configuration file for the inetd
|
|
|
|
|
|
network daemon.
|
|
|
|
|
|
|
|
|
|
|
|
5.8.1. /etc/services
|
|
|
|
|
|
|
|
|
|
|
|
The /etc/services file is a simple database that associates a human
|
|
|
|
|
|
friendly name to a machine friendly service port. Its format is quite
|
|
|
|
|
|
simple. The file is a text file with each line representing and entry
|
|
|
|
|
|
in the database. Each entry is comprised of three fields separated by
|
|
|
|
|
|
any number of whitespace (tab or space) characters. The fields are:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
name port/protocol aliases # comment
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
name
|
|
|
|
|
|
a single word name that represents the service being described.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
port/protocol
|
|
|
|
|
|
this field is split into two subfields.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
port
|
|
|
|
|
|
a number that specifies the port number the named service will
|
|
|
|
|
|
be available on. Most of the common services have assigned
|
|
|
|
|
|
service numbers. These are described in RFC-1340.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
protocol
|
|
|
|
|
|
this subfield may be set to either tcp or udp.
|
|
|
|
|
|
|
|
|
|
|
|
It is important to note that an entry of 18/tcp is very
|
|
|
|
|
|
different from an entry of 18/udp and that there is no technical
|
|
|
|
|
|
reason why the same service needs to exist on both. Normally
|
|
|
|
|
|
common sense prevails and it is only if a particular service is
|
|
|
|
|
|
available via both tcp and udp that you will see an entry for
|
|
|
|
|
|
both.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
aliases
|
|
|
|
|
|
other names that may be used to refer to this service entry.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Any text appearing in a line after a `#' character is ignored and
|
|
|
|
|
|
treated as a comment.
|
|
|
|
|
|
|
|
|
|
|
|
5.8.1.1. An example /etc/services file.
|
|
|
|
|
|
|
|
|
|
|
|
All modern linux distributions provide a good /etc/services file.
|
|
|
|
|
|
Just in case you happen to be building a machine from the ground up,
|
|
|
|
|
|
here is a copy of the /etc/services file supplied with an old Debian
|
|
|
|
|
|
distribution:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# /etc/services:
|
|
|
|
|
|
# $Id$
|
|
|
|
|
|
#
|
|
|
|
|
|
# Network services, Internet style
|
|
|
|
|
|
#
|
|
|
|
|
|
# Note that it is presently the policy of IANA to assign a single well-known
|
|
|
|
|
|
# port number for both TCP and UDP; hence, most entries here have two entries
|
|
|
|
|
|
# even if the protocol doesn't support UDP operations.
|
|
|
|
|
|
# Updated from RFC 1340, ``Assigned Numbers'' (July 1992). Not all ports
|
|
|
|
|
|
# are included, only the more common ones.
|
|
|
|
|
|
|
|
|
|
|
|
tcpmux 1/tcp # TCP port service multiplexer
|
|
|
|
|
|
echo 7/tcp
|
|
|
|
|
|
echo 7/udp
|
|
|
|
|
|
discard 9/tcp sink null
|
|
|
|
|
|
discard 9/udp sink null
|
|
|
|
|
|
systat 11/tcp users
|
|
|
|
|
|
daytime 13/tcp
|
|
|
|
|
|
daytime 13/udp
|
|
|
|
|
|
netstat 15/tcp
|
|
|
|
|
|
qotd 17/tcp quote
|
|
|
|
|
|
msp 18/tcp # message send protocol
|
|
|
|
|
|
msp 18/udp # message send protocol
|
|
|
|
|
|
chargen 19/tcp ttytst source
|
|
|
|
|
|
chargen 19/udp ttytst source
|
|
|
|
|
|
ftp-data 20/tcp
|
|
|
|
|
|
ftp 21/tcp
|
|
|
|
|
|
ssh 22/tcp # SSH Remote Login Protocol
|
|
|
|
|
|
ssh 22/udp # SSH Remote Login Protocol
|
|
|
|
|
|
telnet 23/tcp
|
|
|
|
|
|
# 24 - private
|
|
|
|
|
|
smtp 25/tcp mail
|
|
|
|
|
|
# 26 - unassigned
|
|
|
|
|
|
time 37/tcp timserver
|
|
|
|
|
|
time 37/udp timserver
|
|
|
|
|
|
rlp 39/udp resource # resource location
|
|
|
|
|
|
nameserver 42/tcp name # IEN 116
|
|
|
|
|
|
whois 43/tcp nicname
|
|
|
|
|
|
re-mail-ck 50/tcp # Remote Mail Checking Protocol
|
|
|
|
|
|
re-mail-ck 50/udp # Remote Mail Checking Protocol
|
|
|
|
|
|
domain 53/tcp nameserver # name-domain server
|
|
|
|
|
|
domain 53/udp nameserver
|
|
|
|
|
|
mtp 57/tcp # deprecated
|
|
|
|
|
|
bootps 67/tcp # BOOTP server
|
|
|
|
|
|
bootps 67/udp
|
|
|
|
|
|
bootpc 68/tcp # BOOTP client
|
|
|
|
|
|
bootpc 68/udp
|
|
|
|
|
|
tftp 69/udp
|
|
|
|
|
|
gopher 70/tcp # Internet Gopher
|
|
|
|
|
|
gopher 70/udp
|
|
|
|
|
|
rje 77/tcp netrjs
|
|
|
|
|
|
finger 79/tcp
|
|
|
|
|
|
www 80/tcp http # WorldWideWeb HTTP
|
|
|
|
|
|
www 80/udp # HyperText Transfer Protocol
|
|
|
|
|
|
link 87/tcp ttylink
|
|
|
|
|
|
kerberos 88/tcp kerberos5 krb5 # Kerberos v5
|
|
|
|
|
|
kerberos 88/udp kerberos5 krb5 # Kerberos v5
|
|
|
|
|
|
supdup 95/tcp
|
|
|
|
|
|
# 100 - reserved
|
|
|
|
|
|
hostnames 101/tcp hostname # usually from sri-nic
|
|
|
|
|
|
iso-tsap 102/tcp tsap # part of ISODE.
|
|
|
|
|
|
csnet-ns 105/tcp cso-ns # also used by CSO name server
|
|
|
|
|
|
csnet-ns 105/udp cso-ns
|
|
|
|
|
|
rtelnet 107/tcp # Remote Telnet
|
|
|
|
|
|
rtelnet 107/udp
|
|
|
|
|
|
pop-2 109/tcp postoffice # POP version 2
|
|
|
|
|
|
pop-2 109/udp
|
|
|
|
|
|
pop-3 110/tcp # POP version 3
|
|
|
|
|
|
pop-3 110/udp
|
|
|
|
|
|
sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCP
|
|
|
|
|
|
sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP
|
|
|
|
|
|
auth 113/tcp authentication tap ident
|
|
|
|
|
|
sftp 115/tcp
|
|
|
|
|
|
uucp-path 117/tcp
|
|
|
|
|
|
nntp 119/tcp readnews untp # USENET News Transfer Protocol
|
|
|
|
|
|
ntp 123/tcp
|
|
|
|
|
|
ntp 123/udp # Network Time Protocol
|
|
|
|
|
|
netbios-ns 137/tcp # NETBIOS Name Service
|
|
|
|
|
|
netbios-ns 137/udp
|
|
|
|
|
|
netbios-dgm 138/tcp # NETBIOS Datagram Service
|
|
|
|
|
|
netbios-dgm 138/udp
|
|
|
|
|
|
netbios-ssn 139/tcp # NETBIOS session service
|
|
|
|
|
|
netbios-ssn 139/udp
|
|
|
|
|
|
imap2 143/tcp # Interim Mail Access Proto v2
|
|
|
|
|
|
imap2 143/udp
|
|
|
|
|
|
snmp 161/udp # Simple Net Mgmt Proto
|
|
|
|
|
|
snmp-trap 162/udp snmptrap # Traps for SNMP
|
|
|
|
|
|
cmip-man 163/tcp # ISO mgmt over IP (CMOT)
|
|
|
|
|
|
cmip-man 163/udp
|
|
|
|
|
|
cmip-agent 164/tcp
|
|
|
|
|
|
cmip-agent 164/udp
|
|
|
|
|
|
xdmcp 177/tcp # X Display Mgr. Control Proto
|
|
|
|
|
|
xdmcp 177/udp
|
|
|
|
|
|
nextstep 178/tcp NeXTStep NextStep # NeXTStep window
|
|
|
|
|
|
nextstep 178/udp NeXTStep NextStep # server
|
|
|
|
|
|
bgp 179/tcp # Border Gateway Proto.
|
|
|
|
|
|
bgp 179/udp
|
|
|
|
|
|
prospero 191/tcp # Cliff Neuman's Prospero
|
|
|
|
|
|
prospero 191/udp
|
|
|
|
|
|
irc 194/tcp # Internet Relay Chat
|
|
|
|
|
|
irc 194/udp
|
|
|
|
|
|
smux 199/tcp # SNMP Unix Multiplexer
|
|
|
|
|
|
smux 199/udp
|
|
|
|
|
|
at-rtmp 201/tcp # AppleTalk routing
|
|
|
|
|
|
at-rtmp 201/udp
|
|
|
|
|
|
at-nbp 202/tcp # AppleTalk name binding
|
|
|
|
|
|
at-nbp 202/udp
|
|
|
|
|
|
at-echo 204/tcp # AppleTalk echo
|
|
|
|
|
|
at-echo 204/udp
|
|
|
|
|
|
at-zis 206/tcp # AppleTalk zone information
|
|
|
|
|
|
at-zis 206/udp
|
|
|
|
|
|
z3950 210/tcp wais # NISO Z39.50 database
|
|
|
|
|
|
z3950 210/udp wais
|
|
|
|
|
|
ipx 213/tcp # IPX
|
|
|
|
|
|
ipx 213/udp
|
|
|
|
|
|
imap3 220/tcp # Interactive Mail Access
|
|
|
|
|
|
imap3 220/udp # Protocol v3
|
|
|
|
|
|
ulistserv 372/tcp # UNIX Listserv
|
|
|
|
|
|
ulistserv 372/udp
|
|
|
|
|
|
#
|
|
|
|
|
|
# UNIX specific services
|
|
|
|
|
|
#
|
|
|
|
|
|
exec 512/tcp
|
|
|
|
|
|
biff 512/udp comsat
|
|
|
|
|
|
login 513/tcp
|
|
|
|
|
|
who 513/udp whod
|
|
|
|
|
|
shell 514/tcp cmd # no passwords used
|
|
|
|
|
|
syslog 514/udp
|
|
|
|
|
|
printer 515/tcp spooler # line printer spooler
|
|
|
|
|
|
talk 517/udp
|
|
|
|
|
|
ntalk 518/udp
|
|
|
|
|
|
route 520/udp router routed # RIP
|
|
|
|
|
|
timed 525/udp timeserver
|
|
|
|
|
|
tempo 526/tcp newdate
|
|
|
|
|
|
courier 530/tcp rpc
|
|
|
|
|
|
conference 531/tcp chat
|
|
|
|
|
|
netnews 532/tcp readnews
|
|
|
|
|
|
netwall 533/udp # -for emergency broadcasts
|
|
|
|
|
|
uucp 540/tcp uucpd # uucp daemon
|
|
|
|
|
|
remotefs 556/tcp rfs_server rfs # Brunhoff remote filesystem
|
|
|
|
|
|
klogin 543/tcp # Kerberized `rlogin' (v5)
|
|
|
|
|
|
kshell 544/tcp krcmd # Kerberized `rsh' (v5)
|
|
|
|
|
|
kerberos-adm 749/tcp # Kerberos `kadmin' (v5)
|
|
|
|
|
|
#
|
|
|
|
|
|
webster 765/tcp # Network dictionary
|
|
|
|
|
|
webster 765/udp
|
|
|
|
|
|
#
|
|
|
|
|
|
# From ``Assigned Numbers'':
|
|
|
|
|
|
#
|
|
|
|
|
|
#> The Registered Ports are not controlled by the IANA and on most systems
|
|
|
|
|
|
#> can be used by ordinary user processes or programs executed by ordinary
|
|
|
|
|
|
#> users.
|
|
|
|
|
|
#
|
|
|
|
|
|
#> Ports are used in the TCP [45,106] to name the ends of logical
|
|
|
|
|
|
#> connections which carry long term conversations. For the purpose of
|
|
|
|
|
|
#> providing services to unknown callers, a service contact port is
|
|
|
|
|
|
#> defined. This list specifies the port used by the server process as its
|
|
|
|
|
|
#> contact port. While the IANA can not control uses of these ports it
|
|
|
|
|
|
#> does register or list uses of these ports as a convenience to the
|
|
|
|
|
|
#> community.
|
|
|
|
|
|
#
|
|
|
|
|
|
ingreslock 1524/tcp
|
|
|
|
|
|
ingreslock 1524/udp
|
|
|
|
|
|
prospero-np 1525/tcp # Prospero non-privileged
|
|
|
|
|
|
prospero-np 1525/udp
|
|
|
|
|
|
rfe 5002/tcp # Radio Free Ethernet
|
|
|
|
|
|
rfe 5002/udp # Actually uses UDP only
|
|
|
|
|
|
bbs 7000/tcp # BBS service
|
|
|
|
|
|
#
|
|
|
|
|
|
#
|
|
|
|
|
|
# Kerberos (Project Athena/MIT) services
|
|
|
|
|
|
# Note that these are for Kerberos v4 and are unofficial. Sites running
|
|
|
|
|
|
# v4 should uncomment these and comment out the v5 entries above.
|
|
|
|
|
|
#
|
|
|
|
|
|
kerberos4 750/udp kdc # Kerberos (server) udp
|
|
|
|
|
|
kerberos4 750/tcp kdc # Kerberos (server) tcp
|
|
|
|
|
|
kerberos_master 751/udp # Kerberos authentication
|
|
|
|
|
|
kerberos_master 751/tcp # Kerberos authentication
|
|
|
|
|
|
passwd_server 752/udp # Kerberos passwd server
|
|
|
|
|
|
krb_prop 754/tcp # Kerberos slave propagation
|
|
|
|
|
|
krbupdate 760/tcp kreg # Kerberos registration
|
|
|
|
|
|
kpasswd 761/tcp kpwd # Kerberos "passwd"
|
|
|
|
|
|
kpop 1109/tcp # Pop with Kerberos
|
|
|
|
|
|
knetd 2053/tcp # Kerberos de-multiplexor
|
|
|
|
|
|
zephyr-srv 2102/udp # Zephyr server
|
|
|
|
|
|
zephyr-clt 2103/udp # Zephyr serv-hm connection
|
|
|
|
|
|
zephyr-hm 2104/udp # Zephyr hostmanager
|
|
|
|
|
|
eklogin 2105/tcp # Kerberos encrypted rlogin
|
|
|
|
|
|
#
|
|
|
|
|
|
# Unofficial but necessary (for NetBSD) services
|
|
|
|
|
|
#
|
|
|
|
|
|
supfilesrv 871/tcp # SUP server
|
|
|
|
|
|
supfiledbg 1127/tcp # SUP debugging
|
|
|
|
|
|
#
|
|
|
|
|
|
# Datagram Delivery Protocol services
|
|
|
|
|
|
#
|
|
|
|
|
|
rtmp 1/ddp # Routing Table Maintenance Protocol
|
|
|
|
|
|
nbp 2/ddp # Name Binding Protocol
|
|
|
|
|
|
echo 4/ddp # AppleTalk Echo Protocol
|
|
|
|
|
|
zip 6/ddp # Zone Information Protocol
|
|
|
|
|
|
#
|
|
|
|
|
|
# Debian GNU/Linux services
|
|
|
|
|
|
rmtcfg 1236/tcp # Gracilis Packeten remote config server
|
|
|
|
|
|
xtel 1313/tcp # french minitel
|
|
|
|
|
|
cfinger 2003/tcp # GNU Finger
|
|
|
|
|
|
postgres 4321/tcp # POSTGRES
|
|
|
|
|
|
mandelspawn 9359/udp mandelbrot # network mandelbrot
|
|
|
|
|
|
|
|
|
|
|
|
# Local services
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In the real world, the actual file is always growing as new services
|
|
|
|
|
|
are being created. If you fear your own copy is incomplete, I'd
|
|
|
|
|
|
suggest to copy a new /etc/services from a recent distribution.
|
|
|
|
|
|
|
|
|
|
|
|
5.8.2. /etc/inetd.conf
|
|
|
|
|
|
|
|
|
|
|
|
The /etc/inetd.conf file is the configuration file for the inetd
|
|
|
|
|
|
server daemon. Its function is to tell inetd what to do when it
|
|
|
|
|
|
receives a connection request for a particular service. For each
|
|
|
|
|
|
service that you wish to accept connections for you must tell inetd
|
|
|
|
|
|
what network server daemon to run and how to run it.
|
|
|
|
|
|
|
|
|
|
|
|
Its format is also fairly simple. It is a text file with each line
|
|
|
|
|
|
describing a service that you wish to provide. Any text in a line
|
|
|
|
|
|
following a `#' is ignored and considered a comment. Each line
|
|
|
|
|
|
contains seven fields separated by any number of whitespace (tab or
|
|
|
|
|
|
space) characters. The general format is as follows:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
service socket_type proto flags user server_path server_args
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
service
|
|
|
|
|
|
is the service relevant to this configuration as taken from the
|
|
|
|
|
|
/etc/services file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
socket_type
|
|
|
|
|
|
this field describes the type of socket that this entry will
|
|
|
|
|
|
consider relevant, allowable values are: stream, dgram, raw,
|
|
|
|
|
|
rdm, or seqpacket. This is a little technical in nature, but as
|
|
|
|
|
|
a rule of thumb nearly all tcp based services use stream and
|
|
|
|
|
|
nearly all udp based services use dgram. It is only very special
|
|
|
|
|
|
types of server daemons that would use any of the other values.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
proto
|
|
|
|
|
|
the protocol to considered valid for this entry. This should
|
|
|
|
|
|
match the appropriate entry in the /etc/services file and will
|
|
|
|
|
|
typically be either tcp or udp. Sun RPC (Remote Procedure Call)
|
|
|
|
|
|
based servers will use rpc/tcp or rpc/udp.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
flags
|
|
|
|
|
|
there are really only two possible settings for this field.
|
|
|
|
|
|
This field setting tells inetd whether the network server
|
|
|
|
|
|
program frees the socket after it has been started and therefore
|
|
|
|
|
|
whether inetd can start another one on the next connection
|
|
|
|
|
|
request, or whether inetd should wait and assume that any server
|
|
|
|
|
|
daemon already running will handle the new connection request.
|
|
|
|
|
|
Again this is a little tricky to work out, but as a rule of
|
|
|
|
|
|
thumb all tcp servers should have this entry set to nowait and
|
|
|
|
|
|
most udp servers should have this entry set to wait. Be warned
|
|
|
|
|
|
there are some notable exceptions to this, so let the example
|
|
|
|
|
|
guide you if you are not sure.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
user
|
|
|
|
|
|
this field describes which user account from /etc/passwd will be
|
|
|
|
|
|
set as the owner of the network daemon when it is started. This
|
|
|
|
|
|
is often useful if you want to safeguard against security risks.
|
|
|
|
|
|
You can set the user of an entry to the nobody user so that if
|
|
|
|
|
|
the network server security is breached the possible damage is
|
|
|
|
|
|
minimized. Typically this field is set to root though, because
|
|
|
|
|
|
many servers require root privileges in order to function
|
|
|
|
|
|
correctly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
server_path
|
|
|
|
|
|
this field is pathname to the actual server program to execute
|
|
|
|
|
|
for this entry.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
server_args
|
|
|
|
|
|
this field comprises the rest of the line and is optional. This
|
|
|
|
|
|
field is where you place any command line arguments that you
|
|
|
|
|
|
wish to pass to the server daemon program when it is launched.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.8.2.1. An example /etc/inetd.conf
|
|
|
|
|
|
|
|
|
|
|
|
As for the /etc/services file all modern distributions will include a
|
|
|
|
|
|
good /etc/inetd.conf file for you to work with. Here, for completeness
|
|
|
|
|
|
is the /etc/inetd.conf file from the Debian distribution.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# /etc/inetd.conf: see inetd(8) for further informations.
|
|
|
|
|
|
#
|
|
|
|
|
|
# Internet server configuration database
|
|
|
|
|
|
#
|
|
|
|
|
|
#
|
|
|
|
|
|
# Modified for Debian by Peter Tobias <tobias@et-inf.fho-emden.de>
|
|
|
|
|
|
#
|
|
|
|
|
|
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
|
|
|
|
|
|
#
|
|
|
|
|
|
# Internal services
|
|
|
|
|
|
#
|
|
|
|
|
|
#echo stream tcp nowait root internal
|
|
|
|
|
|
#echo dgram udp wait root internal
|
|
|
|
|
|
discard stream tcp nowait root internal
|
|
|
|
|
|
discard dgram udp wait root internal
|
|
|
|
|
|
daytime stream tcp nowait root internal
|
|
|
|
|
|
daytime dgram udp wait root internal
|
|
|
|
|
|
#chargen stream tcp nowait root internal
|
|
|
|
|
|
#chargen dgram udp wait root internal
|
|
|
|
|
|
time stream tcp nowait root internal
|
|
|
|
|
|
time dgram udp wait root internal
|
|
|
|
|
|
#
|
|
|
|
|
|
# These are standard services.
|
|
|
|
|
|
#
|
|
|
|
|
|
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
|
|
|
|
|
|
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd
|
|
|
|
|
|
#fsp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.fspd
|
|
|
|
|
|
#
|
|
|
|
|
|
# Shell, login, exec and talk are BSD protocols.
|
|
|
|
|
|
#
|
|
|
|
|
|
shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd
|
|
|
|
|
|
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
|
|
|
|
|
|
#exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd
|
|
|
|
|
|
talk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.talkd
|
|
|
|
|
|
ntalk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.ntalkd
|
|
|
|
|
|
#
|
|
|
|
|
|
# Mail, news and uucp services.
|
|
|
|
|
|
#
|
|
|
|
|
|
smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.smtpd
|
|
|
|
|
|
#nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/in.nntpd
|
|
|
|
|
|
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico
|
|
|
|
|
|
#comsat dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.comsat
|
|
|
|
|
|
#
|
|
|
|
|
|
# Pop et al
|
|
|
|
|
|
#
|
|
|
|
|
|
#pop-2 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop2d
|
|
|
|
|
|
#pop-3 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop3d
|
|
|
|
|
|
#
|
|
|
|
|
|
# `cfinger' is for the GNU finger server available for Debian. (NOTE: The
|
|
|
|
|
|
# current implementation of the `finger' daemon allows it to be run as `root'.)
|
|
|
|
|
|
#
|
|
|
|
|
|
#cfinger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.cfingerd
|
|
|
|
|
|
#finger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.fingerd
|
|
|
|
|
|
#netstat stream tcp nowait nobody /usr/sbin/tcpd /bin/netstat
|
|
|
|
|
|
#systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx
|
|
|
|
|
|
#
|
|
|
|
|
|
# Tftp service is provided primarily for booting. Most sites
|
|
|
|
|
|
# run this only on machines acting as "boot servers."
|
|
|
|
|
|
#
|
|
|
|
|
|
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd
|
|
|
|
|
|
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /boot
|
|
|
|
|
|
#bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120
|
|
|
|
|
|
#
|
|
|
|
|
|
# Kerberos authenticated services (these probably need to be corrected)
|
|
|
|
|
|
#
|
|
|
|
|
|
#klogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k
|
|
|
|
|
|
#eklogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k -x
|
|
|
|
|
|
#kshell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd -k
|
|
|
|
|
|
#
|
|
|
|
|
|
# Services run ONLY on the Kerberos server (these probably need to be corrected)
|
|
|
|
|
|
#
|
|
|
|
|
|
#krbupdate stream tcp nowait root /usr/sbin/tcpd /usr/sbin/registerd
|
|
|
|
|
|
#kpasswd stream tcp nowait root /usr/sbin/tcpd /usr/sbin/kpasswdd
|
|
|
|
|
|
#
|
|
|
|
|
|
# RPC based services
|
|
|
|
|
|
#
|
|
|
|
|
|
#mountd/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.mountd
|
|
|
|
|
|
#rstatd/1-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rstatd
|
|
|
|
|
|
#rusersd/2-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rusersd
|
|
|
|
|
|
#walld/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rwalld
|
|
|
|
|
|
#
|
|
|
|
|
|
# End of inetd.conf.
|
|
|
|
|
|
ident stream tcp nowait nobody /usr/sbin/identd identd -i
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.9. Other miscellaneous network related configuration files.
|
|
|
|
|
|
|
|
|
|
|
|
There are a number of miscellaneous files relating to network
|
|
|
|
|
|
configuration under linux that you might be interested in. You may
|
|
|
|
|
|
never have to modify these files, but it is worth describing them so
|
|
|
|
|
|
you know what they contain and what they are for.
|
|
|
|
|
|
|
|
|
|
|
|
5.9.1. /etc/protocols
|
|
|
|
|
|
|
|
|
|
|
|
The /etc/protocols file is a database that maps protocol id numbers
|
|
|
|
|
|
against protocol names. This is used by programmers to allow them to
|
|
|
|
|
|
specify protocols by name in their programs and also by some programs
|
|
|
|
|
|
such as tcpdump to allow them to display names instead of numbers in
|
|
|
|
|
|
their output. The general syntax of the file is:
|
|
|
|
|
|
|
|
|
|
|
|
protocolname number aliases
|
|
|
|
|
|
|
|
|
|
|
|
The /etc/protocols file supplied with the Debian distribution is as
|
|
|
|
|
|
follows:
|
|
|
|
|
|
|
|
|
|
|
|
# /etc/protocols:
|
|
|
|
|
|
# $Id$
|
|
|
|
|
|
#
|
|
|
|
|
|
# Internet (IP) protocols
|
|
|
|
|
|
#
|
|
|
|
|
|
# from: @(#)protocols 5.1 (Berkeley) 4/17/89
|
|
|
|
|
|
#
|
|
|
|
|
|
# Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).
|
|
|
|
|
|
|
|
|
|
|
|
ip 0 IP # internet protocol, pseudo protocol number
|
|
|
|
|
|
icmp 1 ICMP # internet control message protocol
|
|
|
|
|
|
igmp 2 IGMP # Internet Group Management
|
|
|
|
|
|
ggp 3 GGP # gateway-gateway protocol
|
|
|
|
|
|
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
|
|
|
|
|
|
st 5 ST # ST datagram mode
|
|
|
|
|
|
tcp 6 TCP # transmission control protocol
|
|
|
|
|
|
egp 8 EGP # exterior gateway protocol
|
|
|
|
|
|
pup 12 PUP # PARC universal packet protocol
|
|
|
|
|
|
udp 17 UDP # user datagram protocol
|
|
|
|
|
|
hmp 20 HMP # host monitoring protocol
|
|
|
|
|
|
xns-idp 22 XNS-IDP # Xerox NS IDP
|
|
|
|
|
|
rdp 27 RDP # "reliable datagram" protocol
|
|
|
|
|
|
iso-tp4 29 ISO-TP4 # ISO Transport Protocol class 4
|
|
|
|
|
|
xtp 36 XTP # Xpress Tranfer Protocol
|
|
|
|
|
|
ddp 37 DDP # Datagram Delivery Protocol
|
|
|
|
|
|
idpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transport
|
|
|
|
|
|
rspf 73 RSPF # Radio Shortest Path First.
|
|
|
|
|
|
vmtp 81 VMTP # Versatile Message Transport
|
|
|
|
|
|
ospf 89 OSPFIGP # Open Shortest Path First IGP
|
|
|
|
|
|
ipip 94 IPIP # Yet Another IP encapsulation
|
|
|
|
|
|
encap 98 ENCAP # Yet Another IP encapsulation
|
|
|
|
|
|
|
|
|
|
|
|
5.9.2. /etc/networks
|
|
|
|
|
|
|
|
|
|
|
|
The /etc/networks file has a similar function to that of the
|
|
|
|
|
|
/etc/hosts file. It provides a simple database of network names
|
|
|
|
|
|
against network addresses. Its format differs in that there may be
|
|
|
|
|
|
only two fields per line and that the fields are coded as:
|
|
|
|
|
|
|
|
|
|
|
|
networkname networkaddress
|
|
|
|
|
|
|
|
|
|
|
|
An example might look like:
|
|
|
|
|
|
|
|
|
|
|
|
loopnet 127.0.0.0
|
|
|
|
|
|
localnet 192.168.0.0
|
|
|
|
|
|
amprnet 44.0.0.0
|
|
|
|
|
|
|
|
|
|
|
|
When you use commands like the route command, if a destination is a
|
|
|
|
|
|
network and that network has an entry in the /etc/networks file then
|
|
|
|
|
|
the route command will display that network name instead of its
|
|
|
|
|
|
address.
|
|
|
|
|
|
|
|
|
|
|
|
5.10. Network Security and access control.
|
|
|
|
|
|
|
|
|
|
|
|
Let me start this section by warning you that securing your machine
|
|
|
|
|
|
and network against malicious attack is a complex art. I do not
|
|
|
|
|
|
consider myself an expert in this field at all and while the following
|
|
|
|
|
|
mechanisms I describe will help, if you are serious about security
|
|
|
|
|
|
then I recommend you do some research of your own into the subject.
|
|
|
|
|
|
There are many good references on the Internet relating to the
|
|
|
|
|
|
subject, including the Security-HOWTO
|
|
|
|
|
|
|
|
|
|
|
|
An important rule of thumb is: `Don't run servers you don't intend to
|
|
|
|
|
|
use'. Many distributions come configured with all sorts of services
|
|
|
|
|
|
configured and automatically started. To ensure even a minimum level
|
|
|
|
|
|
of safety you should go through your /etc/inetd.conf file and comment
|
|
|
|
|
|
out (place a `#' at the start of the line) any entries for services
|
|
|
|
|
|
you don't intend to use. Good candidates are services such as: shell,
|
|
|
|
|
|
login, exec, uucp, ftp and informational services such as finger,
|
|
|
|
|
|
netstat and systat.
|
|
|
|
|
|
|
|
|
|
|
|
There are all sorts of security and access control mechanisms, I'll
|
|
|
|
|
|
describe the most elementary of them.
|
|
|
|
|
|
|
|
|
|
|
|
5.10.1. /etc/ftpusers
|
|
|
|
|
|
|
|
|
|
|
|
The /etc/ftpusers file is a simple mechanism that allows you to deny
|
|
|
|
|
|
certain users from logging into your machine via ftp. The
|
|
|
|
|
|
/etc/ftpusers file is read by the ftp daemon program (ftpd) when an
|
|
|
|
|
|
incoming ftp connection is received. The file is a simple list of
|
|
|
|
|
|
those users who are disallowed from logging in. It might looks
|
|
|
|
|
|
something like:
|
|
|
|
|
|
|
|
|
|
|
|
# /etc/ftpusers - users not allowed to login via ftp
|
|
|
|
|
|
root
|
|
|
|
|
|
uucp
|
|
|
|
|
|
bin
|
|
|
|
|
|
mail
|
|
|
|
|
|
|
|
|
|
|
|
5.10.2. /etc/securetty
|
|
|
|
|
|
|
|
|
|
|
|
The /etc/securetty file allows you to specify which tty devices root
|
|
|
|
|
|
is allowed to login on. The /etc/securetty file is read by the login
|
|
|
|
|
|
program (usually /bin/login). Its format is a list of the tty devices
|
|
|
|
|
|
names allowed, on all others root login is disallowed:
|
|
|
|
|
|
|
|
|
|
|
|
# /etc/securetty - tty's on which root is allowed to login
|
|
|
|
|
|
tty1
|
|
|
|
|
|
tty2
|
|
|
|
|
|
tty3
|
|
|
|
|
|
tty4
|
|
|
|
|
|
|
|
|
|
|
|
5.10.3. The tcpd hosts access control mechanism.
|
|
|
|
|
|
|
|
|
|
|
|
The tcpd program you will have seen listed in the same /etc/inetd.conf
|
|
|
|
|
|
provides logging and access control mechanisms to services it is
|
|
|
|
|
|
configured to protect.
|
|
|
|
|
|
|
|
|
|
|
|
When it is invoked by the inetd program it reads two files containing
|
|
|
|
|
|
access rules and either allows or denies access to the server it is
|
|
|
|
|
|
protecting accordingly.
|
|
|
|
|
|
|
|
|
|
|
|
It will search the rules files until the first match is found. If no
|
|
|
|
|
|
match is found then it assumes that access should be allowed to
|
|
|
|
|
|
anyone. The files it searches in sequence are: /etc/hosts.allow,
|
|
|
|
|
|
/etc/hosts.deny. I'll describe each of these in turn. For a complete
|
|
|
|
|
|
description of this facility you should refer to the appropriate man
|
|
|
|
|
|
pages (hosts_access(5) is a good starting point).
|
|
|
|
|
|
|
|
|
|
|
|
5.10.3.1. /etc/hosts.allow
|
|
|
|
|
|
|
|
|
|
|
|
The /etc/hosts.allow file is a configuration file of the
|
|
|
|
|
|
/usr/sbin/tcpd program. The hosts.allow file contains rules describing
|
|
|
|
|
|
which hosts are allowed access to a service on your machine.
|
|
|
|
|
|
|
|
|
|
|
|
The file format is quite simple:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# /etc/hosts.allow
|
|
|
|
|
|
#
|
|
|
|
|
|
# <service list>: <host list> [: command]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
service list
|
|
|
|
|
|
is a comma delimited list of server names that this rule applies
|
|
|
|
|
|
to. Example server names are: ftpd, telnetd and fingerd.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
host list
|
|
|
|
|
|
is a comma delimited list of host names. You may also use IP
|
|
|
|
|
|
addresses here. You may additionally specify hostnames or
|
|
|
|
|
|
addresses using wildcard characters to match groups of hosts.
|
|
|
|
|
|
Examples include: gw.vk2ktj.ampr.org to match a specific host,
|
|
|
|
|
|
.uts.edu.au to match any hostname ending in that string, 44. to
|
|
|
|
|
|
match any IP address commencing with those digits. There are
|
|
|
|
|
|
some special tokens to simplify configuration, some of these
|
|
|
|
|
|
are: ALL matches every host, LOCAL matches any host whose name
|
|
|
|
|
|
does not contain a `.' ie is in the same domain as your machine
|
|
|
|
|
|
and PARANOID matches any host whose name does not match its
|
|
|
|
|
|
address (name spoofing). There is one last token that is also
|
|
|
|
|
|
useful. The EXCEPT token allows you to provide a list with
|
|
|
|
|
|
exceptions. This will be covered in an example later.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
command
|
|
|
|
|
|
is an optional parameter. This parameter is the full pathname of
|
|
|
|
|
|
a command that would be executed everytime this rule is matched.
|
|
|
|
|
|
It could for example run a command that would attempt to
|
|
|
|
|
|
identify who is logged onto the connecting host, or to generate
|
|
|
|
|
|
a mail message or some other warning to a system administrator
|
|
|
|
|
|
that someone is attempting to connect. There are a number of
|
|
|
|
|
|
expansions that may be included, some common examples are: %h
|
|
|
|
|
|
expands to the name of the connecting host or address if it
|
|
|
|
|
|
doesn't have a name, %d the daemon name being called.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
An example:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# /etc/hosts.allow
|
|
|
|
|
|
#
|
|
|
|
|
|
# Allow mail to anyone
|
|
|
|
|
|
in.smtpd: ALL
|
|
|
|
|
|
# All telnet and ftp to only hosts within my domain and my host at home.
|
|
|
|
|
|
telnetd, ftpd: LOCAL, myhost.athome.org.au
|
|
|
|
|
|
# Allow finger to anyone but keep a record of who they are.
|
|
|
|
|
|
fingerd: ALL: (finger @%h | mail -s "finger from %h" root)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.10.3.2. /etc/hosts.deny
|
|
|
|
|
|
|
|
|
|
|
|
The /etc/hosts.deny file is a configuration file of the /usr/sbin/tcpd
|
|
|
|
|
|
program. The hosts.deny file contains rules describing which hosts are
|
|
|
|
|
|
disallowed access to a service on your machine.
|
|
|
|
|
|
|
|
|
|
|
|
A simple sample would look something like this:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# /etc/hosts.deny
|
|
|
|
|
|
#
|
|
|
|
|
|
# Disallow all hosts with suspect hostnames
|
|
|
|
|
|
ALL: PARANOID
|
|
|
|
|
|
#
|
|
|
|
|
|
# Disallow all hosts.
|
|
|
|
|
|
ALL: ALL
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The PARANOID entry is really redundant because the other entry traps
|
|
|
|
|
|
everything in any case. Either of these entry would make a reasonable
|
|
|
|
|
|
default depending on your particular requirement.
|
|
|
|
|
|
|
|
|
|
|
|
Having an ALL: ALL default in the /etc/hosts.deny and then
|
|
|
|
|
|
specifically enabling on those services and hosts that you want in the
|
|
|
|
|
|
/etc/hosts.allow file is the safest configuration.
|
|
|
|
|
|
|
|
|
|
|
|
5.10.4. /etc/hosts.equiv
|
|
|
|
|
|
|
|
|
|
|
|
The hosts.equiv file is used to grant certain hosts and users access
|
|
|
|
|
|
rights to accounts on your machine without having to supply a
|
|
|
|
|
|
password. This is useful in a secure environment where you control all
|
|
|
|
|
|
machines, but is a security hazard otherwise. Your machine is only as
|
|
|
|
|
|
secure as the least secure of the trusted hosts. To maximize security,
|
|
|
|
|
|
don't use this mechanism and encourage your users not to use the
|
|
|
|
|
|
.rhosts file as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.10.5. Configure your ftp daemon properly.
|
|
|
|
|
|
|
|
|
|
|
|
Many sites will be interested in running an anonymous ftp server to
|
|
|
|
|
|
allow other people to upload and download files without requiring a
|
|
|
|
|
|
specific userid. If you decide to offer this facility make sure you
|
|
|
|
|
|
configure the ftp daemon properly for anonymous access. Most man pages
|
|
|
|
|
|
for ftpd(8) describe in some length how to go about this. You should
|
|
|
|
|
|
always ensure that you follow these instructions. An important tip is
|
|
|
|
|
|
to not use a copy of your /etc/passwd file in the anonymous account
|
|
|
|
|
|
/etc directory, make sure you strip out all account details except
|
|
|
|
|
|
those that you must have, otherwise you will be vulnerable to brute
|
|
|
|
|
|
force password cracking techniques.
|
|
|
|
|
|
|
|
|
|
|
|
5.10.6. Network Firewalling.
|
|
|
|
|
|
|
|
|
|
|
|
Not allowing datagrams to even reach your machine or servers is an
|
|
|
|
|
|
excellent means of security. This is covered in depth in the Firewall-
|
|
|
|
|
|
HOWTO, and (more concisely) in a later section of this document.
|
|
|
|
|
|
|
|
|
|
|
|
5.10.7. Other suggestions.
|
|
|
|
|
|
|
|
|
|
|
|
Here are some other, potentially religious suggestions for you to
|
|
|
|
|
|
consider.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sendmail
|
|
|
|
|
|
despite its popularity the sendmail daemon appears with
|
|
|
|
|
|
frightening regularity on security warning announcements. Its up
|
|
|
|
|
|
to you, but I choose not to run it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NFS and other Sun RPC services
|
|
|
|
|
|
be wary of these. There are all sorts of possible exploits for
|
|
|
|
|
|
these services. It is difficult finding an option to services
|
|
|
|
|
|
like NFS, but if you configure them, make sure you are careful
|
|
|
|
|
|
with who you allow mount rights to.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6. IP- and Ethernet-Related Information
|
|
|
|
|
|
|
|
|
|
|
|
This section covers information specific to Ethernet and IP. These
|
|
|
|
|
|
subsections have been grouped together because I think they are the
|
|
|
|
|
|
most interesting ones in the formerly-called ``Technology Specific''
|
|
|
|
|
|
Section. Anyone with a LAN should be able to benefit from these
|
|
|
|
|
|
goodies.
|
|
|
|
|
|
|
|
|
|
|
|
6.1. Ethernet
|
|
|
|
|
|
|
|
|
|
|
|
Ethernet device names are `eth0', `eth1', `eth2' etc. The first card
|
|
|
|
|
|
detected by the kernel is assigned `eth0' and the rest are assigned
|
|
|
|
|
|
sequentially in the order they are detected.
|
|
|
|
|
|
|
|
|
|
|
|
By default, the Linux kernel only probes for one Ethernet device, you
|
|
|
|
|
|
need to pass command line arguments to the kernel in order to force
|
|
|
|
|
|
detection of furter boards.
|
|
|
|
|
|
|
|
|
|
|
|
To learn how to make your ethernet card(s) working under Linux you
|
|
|
|
|
|
should refer to the Ethernet-HOWTO.
|
|
|
|
|
|
|
|
|
|
|
|
Once you have your kernel properly built to support your ethernet card
|
|
|
|
|
|
then configuration of the card is easy.
|
|
|
|
|
|
|
|
|
|
|
|
Typically you would use something like (which most distributions
|
|
|
|
|
|
already do for you, if you configured them to support your ethernet):
|
|
|
|
|
|
|
|
|
|
|
|
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
|
|
|
|
|
|
root# route add -net 192.168.0.0 netmask 255.255.255.0 eth0
|
|
|
|
|
|
|
|
|
|
|
|
Most of the ethernet drivers were developed by Donald Becker,
|
|
|
|
|
|
becker@CESDIS.gsfc.nasa.gov.
|
|
|
|
|
|
|
|
|
|
|
|
6.8. IPIP Encapsulation
|
|
|
|
|
|
|
|
|
|
|
|
Why would you want to encapsulate IP datagrams within IP datagrams? It
|
|
|
|
|
|
must seem an odd thing to do if you've never seen an application of it
|
|
|
|
|
|
before. Ok, here are a couple of common places where it is used:
|
|
|
|
|
|
Mobile-IP and IP-Multicast. What is perhaps the most widely spread use
|
|
|
|
|
|
of it though is also the least well known, Amateur Radio.
|
|
|
|
|
|
|
|
|
|
|
|
Kernel Compile Options:
|
|
|
|
|
|
|
|
|
|
|
|
Networking options --->
|
|
|
|
|
|
[*] TCP/IP networking
|
|
|
|
|
|
[*] IP: forwarding/gatewaying
|
|
|
|
|
|
....
|
|
|
|
|
|
<*> IP: tunneling
|
|
|
|
|
|
|
|
|
|
|
|
IP tunnel devices are called `tunl0', `tunl1' etc.
|
|
|
|
|
|
|
|
|
|
|
|
"But why ?". Ok, ok. Conventional IP routing rules mandate that an IP
|
|
|
|
|
|
network comprises a network address and a network mask. This produces
|
|
|
|
|
|
a series of contiguous addresses that may all be routed via a single
|
|
|
|
|
|
routing entry. This is very convenient, but it means that you may
|
|
|
|
|
|
only use any particular IP address while you are connected to the
|
|
|
|
|
|
particular piece of network to which it belongs. In most instances
|
|
|
|
|
|
this is ok, but if you are a mobile netizen then you may not be able
|
|
|
|
|
|
to stay connected to the one place all the time. IP/IP encapsulation
|
|
|
|
|
|
(IP tunneling) allows you to overcome this restriction by allowing
|
|
|
|
|
|
datagrams destined for your IP address to be wrapped up and redirected
|
|
|
|
|
|
to another IP address. If you know that you're going to be operating
|
|
|
|
|
|
from some other IP network for some time you can set up a machine on
|
|
|
|
|
|
your home network to accept datagrams to your IP address and redirect
|
|
|
|
|
|
them to the address that you will actually be using temporarily.
|
|
|
|
|
|
|
|
|
|
|
|
6.8.1. A tunneled network configuration.
|
|
|
|
|
|
|
|
|
|
|
|
192.168.1/24 192.168.2/24
|
|
|
|
|
|
|
|
|
|
|
|
- -
|
|
|
|
|
|
| ppp0 = ppp0 = |
|
|
|
|
|
|
| aaa.bbb.ccc.ddd fff.ggg.hhh.iii |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| /-----\ /-----\ |
|
|
|
|
|
|
| | | // | | |
|
|
|
|
|
|
|---| A |------//---------| B |---|
|
|
|
|
|
|
| | | // | | |
|
|
|
|
|
|
| \-----/ \-----/ |
|
|
|
|
|
|
| |
|
|
|
|
|
|
- -
|
|
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
The diagram illustrates another possible reason to use IPIP encapsula
|
2004-11-04 02:03:06 +00:00
|
|
|
|
tion, virtual private networking. This example presupposes that you
|
|
|
|
|
|
have two machines each with a simple dial up internet connection. Each
|
|
|
|
|
|
host is allocated just a single IP address. Behind each of these
|
|
|
|
|
|
machines are some private local area networks configured with reserved
|
2016-01-24 18:46:18 +00:00
|
|
|
|
IP network addresses. Suppose that you want to allow any host on net
|
|
|
|
|
|
work A to connect to any host on network B, just as if they were prop
|
|
|
|
|
|
erly connected to the Internet with a network route. IPIP encapsula
|
2004-11-04 02:03:06 +00:00
|
|
|
|
tion will allow you to do this. Note, encapsulation does not solve the
|
|
|
|
|
|
problem of how you get the hosts on networks A and B to talk to any
|
|
|
|
|
|
other on the Internet, you still need tricks like IP Masquerade for
|
|
|
|
|
|
that. Encapsulation is normally performed by machine functioning as
|
|
|
|
|
|
routers.
|
|
|
|
|
|
|
|
|
|
|
|
Linux router `A' would be configured with a script like the following:
|
|
|
|
|
|
|
|
|
|
|
|
#!/bin/sh
|
|
|
|
|
|
PATH=/sbin:/usr/sbin
|
|
|
|
|
|
mask=255.255.255.0
|
|
|
|
|
|
remotegw=fff.ggg.hhh.iii
|
|
|
|
|
|
#
|
|
|
|
|
|
# Ethernet configuration
|
|
|
|
|
|
ifconfig eth0 192.168.1.1 netmask $mask up
|
|
|
|
|
|
route add -net 192.168.1.0 netmask $mask eth0
|
|
|
|
|
|
#
|
|
|
|
|
|
# ppp0 configuration (start ppp link, set default route)
|
|
|
|
|
|
pppd
|
|
|
|
|
|
route add default ppp0
|
|
|
|
|
|
#
|
|
|
|
|
|
# Tunnel device configuration
|
|
|
|
|
|
ifconfig tunl0 192.168.1.1 up
|
|
|
|
|
|
route add -net 192.168.2.0 netmask $mask gw $remotegw tunl0
|
|
|
|
|
|
|
|
|
|
|
|
Linux router `B' would be configured with a similar script:
|
|
|
|
|
|
|
|
|
|
|
|
#!/bin/sh
|
|
|
|
|
|
PATH=/sbin:/usr/sbin
|
|
|
|
|
|
mask=255.255.255.0
|
|
|
|
|
|
remotegw=aaa.bbb.ccc.ddd
|
|
|
|
|
|
#
|
|
|
|
|
|
# Ethernet configuration
|
|
|
|
|
|
ifconfig eth0 192.168.2.1 netmask $mask up
|
|
|
|
|
|
route add -net 192.168.2.0 netmask $mask eth0
|
|
|
|
|
|
#
|
|
|
|
|
|
# ppp0 configuration (start ppp link, set default route)
|
|
|
|
|
|
pppd
|
|
|
|
|
|
route add default ppp0
|
|
|
|
|
|
#
|
|
|
|
|
|
# Tunnel device configuration
|
|
|
|
|
|
ifconfig tunl0 192.168.2.1 up
|
|
|
|
|
|
route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0
|
|
|
|
|
|
|
|
|
|
|
|
The command:
|
|
|
|
|
|
|
|
|
|
|
|
route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0
|
|
|
|
|
|
|
|
|
|
|
|
reads: `Send any datagrams destined for 192.168.1.0/24 inside an IPIP
|
|
|
|
|
|
encap datagram with a destination address of aaa.bbb.ccc.ddd'.
|
|
|
|
|
|
|
|
|
|
|
|
Note that the configurations are reciprocated at either end. The
|
|
|
|
|
|
tunnel device uses the `gw' in the route as the destination of the IP
|
|
|
|
|
|
datagram in which it will place the datagram it has received to route.
|
|
|
|
|
|
That machine must know how to decapsulate IPIP datagrams, that is, it
|
|
|
|
|
|
must also be configured with a tunnel device.
|
|
|
|
|
|
|
|
|
|
|
|
6.8.2. A tunneled host configuration.
|
|
|
|
|
|
|
|
|
|
|
|
It doesn't have to be a whole network you route. You could for example
|
|
|
|
|
|
route just a single IP address. In that instance you might configure
|
|
|
|
|
|
the tunl device on the `remote' machine with its home IP address and
|
|
|
|
|
|
at the A end just use a host route (and Proxy Arp) rather than a
|
|
|
|
|
|
network route via the tunnel device. Let's redraw and modify our
|
|
|
|
|
|
configuration appropriately. Now we have just host `B' which to want
|
|
|
|
|
|
to act and behave as if it is both fully connected to the Internet and
|
|
|
|
|
|
also part of the remote network supported by host `A':
|
|
|
|
|
|
|
|
|
|
|
|
192.168.1/24
|
|
|
|
|
|
|
|
|
|
|
|
-
|
|
|
|
|
|
| ppp0 = ppp0 =
|
|
|
|
|
|
| aaa.bbb.ccc.ddd fff.ggg.hhh.iii
|
|
|
|
|
|
|
|
|
|
|
|
|
| /-----\ /-----\
|
|
|
|
|
|
| | | // | |
|
|
|
|
|
|
|---| A |------//---------| B |
|
|
|
|
|
|
| | | // | |
|
|
|
|
|
|
| \-----/ \-----/
|
|
|
|
|
|
| also: 192.168.1.12
|
|
|
|
|
|
-
|
|
|
|
|
|
|
|
|
|
|
|
Linux router `A' would be configured with:
|
|
|
|
|
|
|
|
|
|
|
|
#!/bin/sh
|
|
|
|
|
|
PATH=/sbin:/usr/sbin
|
|
|
|
|
|
mask=255.255.255.0
|
|
|
|
|
|
remotegw=fff.ggg.hhh.iii
|
|
|
|
|
|
#
|
|
|
|
|
|
# Ethernet configuration
|
|
|
|
|
|
ifconfig eth0 192.168.1.1 netmask $mask up
|
|
|
|
|
|
route add -net 192.168.1.0 netmask $mask eth0
|
|
|
|
|
|
#
|
|
|
|
|
|
# ppp0 configuration (start ppp link, set default route)
|
|
|
|
|
|
pppd
|
|
|
|
|
|
route add default ppp0
|
|
|
|
|
|
#
|
|
|
|
|
|
# Tunnel device configuration
|
|
|
|
|
|
ifconfig tunl0 192.168.1.1 up
|
|
|
|
|
|
route add -host 192.168.1.12 gw $remotegw tunl0
|
|
|
|
|
|
#
|
|
|
|
|
|
# Proxy ARP for the remote host
|
|
|
|
|
|
arp -s 192.168.1.12 xx:xx:xx:xx:xx:xx pub
|
|
|
|
|
|
|
|
|
|
|
|
Linux host `B' would be configured with:
|
|
|
|
|
|
|
|
|
|
|
|
#!/bin/sh
|
|
|
|
|
|
PATH=/sbin:/usr/sbin
|
|
|
|
|
|
mask=255.255.255.0
|
|
|
|
|
|
remotegw=aaa.bbb.ccc.ddd
|
|
|
|
|
|
#
|
|
|
|
|
|
# ppp0 configuration (start ppp link, set default route)
|
|
|
|
|
|
pppd
|
|
|
|
|
|
route add default ppp0
|
|
|
|
|
|
#
|
|
|
|
|
|
# Tunnel device configuration
|
|
|
|
|
|
ifconfig tunl0 192.168.1.12 up
|
|
|
|
|
|
route add -net 192.168.1.0 netmask $mask gw $remotegwtunl0
|
|
|
|
|
|
|
|
|
|
|
|
This sort of configuration is more typical of a Mobile-IP application.
|
|
|
|
|
|
Where a single host wants to roam around the Internet and maintain a
|
|
|
|
|
|
single usable IP address the whole time. You should refer to the
|
|
|
|
|
|
Mobile-IP section for more information on how that is handled in
|
|
|
|
|
|
practice.
|
|
|
|
|
|
|
|
|
|
|
|
6.9. IP Masquerade
|
|
|
|
|
|
|
|
|
|
|
|
Many people have a simple dialup account to connect to the Internet.
|
|
|
|
|
|
Nearly everybody using this sort of configuration is allocated a
|
|
|
|
|
|
single IP address by the Internet Service Provider. This is normally
|
|
|
|
|
|
enough to allow only one host full access to the network. IP
|
|
|
|
|
|
Masquerade is a clever trick that enables you to have many machines
|
|
|
|
|
|
make use of that one IP address, by causing the other hosts to look
|
|
|
|
|
|
like, hence the term masquerade, the machine supporting the dialup
|
|
|
|
|
|
connection. There is a small caveat and that is that the masquerade
|
|
|
|
|
|
function nearly always works only in one direction, that is the
|
|
|
|
|
|
masqueraded hosts can make calls out, but they cannot accept or
|
|
|
|
|
|
receive network connections from remote hosts. This means that some
|
|
|
|
|
|
network services do not work such as talk and others such as ftp must
|
|
|
|
|
|
be configured to operate in passive (PASV) mode to operate.
|
|
|
|
|
|
Fortunately the most common network services such as telnet, World
|
|
|
|
|
|
Wide Web and irc do work just fine.
|
|
|
|
|
|
|
|
|
|
|
|
Kernel Compile Options:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Code maturity level options --->
|
|
|
|
|
|
[*] Prompt for development and/or incomplete code/drivers
|
|
|
|
|
|
Networking options --->
|
|
|
|
|
|
[*] Network firewalls
|
|
|
|
|
|
....
|
|
|
|
|
|
[*] TCP/IP networking
|
|
|
|
|
|
[*] IP: forwarding/gatewaying
|
|
|
|
|
|
....
|
|
|
|
|
|
[*] IP: masquerading (EXPERIMENTAL)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Normally you have your linux machine supporting a slip or PPP dialup
|
|
|
|
|
|
line just as it would if it were a standalone machine. Additionally it
|
|
|
|
|
|
would have another network device configured, perhaps an ethernet,
|
|
|
|
|
|
configured with one of the reserved network addresses. The hosts to be
|
|
|
|
|
|
masqueraded would be on this second network. Each of these hosts would
|
|
|
|
|
|
have the IP address of the ethernet port of the linux machine set as
|
|
|
|
|
|
their default gateway or router.
|
|
|
|
|
|
|
|
|
|
|
|
A typical configuration might look something like this:
|
|
|
|
|
|
|
|
|
|
|
|
- -
|
|
|
|
|
|
\ | 192.168.1.0
|
|
|
|
|
|
\ | /255.255.255.0
|
|
|
|
|
|
\ --------- |
|
|
|
|
|
|
| | Linux | .1.1 |
|
|
|
|
|
|
NET =================| masq |------|
|
|
|
|
|
|
| PPP/slip | router| | --------
|
|
|
|
|
|
/ --------- |--| host |
|
|
|
|
|
|
/ | | |
|
|
|
|
|
|
/ | --------
|
|
|
|
|
|
- -
|
|
|
|
|
|
|
|
|
|
|
|
Masquerading with IPFWADM
|
|
|
|
|
|
|
|
|
|
|
|
The most relevant commands for this configuration are:
|
|
|
|
|
|
|
|
|
|
|
|
# Network route for ethernet
|
|
|
|
|
|
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
|
|
|
|
|
|
#
|
|
|
|
|
|
# Default route to the rest of the internet.
|
|
|
|
|
|
route add default ppp0
|
|
|
|
|
|
#
|
|
|
|
|
|
# Cause all hosts on the 192.168.1/24 network to be masqueraded.
|
|
|
|
|
|
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0
|
|
|
|
|
|
|
|
|
|
|
|
Masquerading with IPCHAINS
|
|
|
|
|
|
|
|
|
|
|
|
This is similar to using IPFWADM but the command structure has
|
|
|
|
|
|
changed:
|
|
|
|
|
|
|
|
|
|
|
|
# Network route for ethernet
|
|
|
|
|
|
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
|
|
|
|
|
|
#
|
|
|
|
|
|
# Default route to the rest of the internet.
|
|
|
|
|
|
route add default ppp0
|
|
|
|
|
|
#
|
|
|
|
|
|
# Cause all hosts on the 192.168.1/24 network to be masqueraded.
|
|
|
|
|
|
ipchains -A forward -s 192.168.1.0/24 -j MASQ
|
|
|
|
|
|
|
|
|
|
|
|
You can get more information on the Linux IP Masquerade feature from
|
|
|
|
|
|
the IP Masquerade Resource Page. Also, a very detailed document about
|
|
|
|
|
|
masquesrading is the ``IP-Masquerade mini-HOWTO'' (which also intructs
|
|
|
|
|
|
to configure other OS's to run with a Linux masquerade server).
|
2004-11-12 09:21:35 +00:00
|
|
|
|
|
2004-11-04 02:03:06 +00:00
|
|
|
|
6.10. IP Transparent Proxy
|
|
|
|
|
|
|
|
|
|
|
|
IP transparent proxy is a feature that enables you to redirect servers
|
|
|
|
|
|
or services destined for another machine to those services on this
|
|
|
|
|
|
machine. Typically this would be useful where you have a linux
|
|
|
|
|
|
machine as a router and also provides a proxy server. You would
|
|
|
|
|
|
redirect all connections destined for that service remotely to the
|
|
|
|
|
|
local proxy server.
|
|
|
|
|
|
|
|
|
|
|
|
Kernel Compile Options:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Code maturity level options --->
|
|
|
|
|
|
[*] Prompt for development and/or incomplete code/drivers
|
|
|
|
|
|
Networking options --->
|
|
|
|
|
|
[*] Network firewalls
|
|
|
|
|
|
....
|
|
|
|
|
|
[*] TCP/IP networking
|
|
|
|
|
|
....
|
|
|
|
|
|
[*] IP: firewalling
|
|
|
|
|
|
....
|
|
|
|
|
|
[*] IP: transparent proxy support (EXPERIMENTAL)
|
|
|
|
|
|
|
|
|
|
|
|
Configuration of the transparent proxy feature is performed using the
|
|
|
|
|
|
ipfwadm command
|
|
|
|
|
|
|
|
|
|
|
|
An example that might be useful is as follows:
|
|
|
|
|
|
|
|
|
|
|
|
root# ipfwadm -I -a accept -D 0/0 telnet -r 2323
|
|
|
|
|
|
|
|
|
|
|
|
This example will cause any connection attempts to port telnet (23) on
|
|
|
|
|
|
any host to be redirected to port 2323 on this host. If you run a
|
|
|
|
|
|
service on that port, you could forward telnet connections, log them
|
|
|
|
|
|
or do whatever fits your need.
|
|
|
|
|
|
|
|
|
|
|
|
A more interesting example is redirecting all http traffic through a
|
|
|
|
|
|
local cache. However, the protocol used by proxy servers is different
|
|
|
|
|
|
from native http: where a client connects to www.server.com:80 and
|
|
|
|
|
|
asks for /path/page, when it connects to the local cache it contacts
|
|
|
|
|
|
proxy.local.domain:8080 and asks for www.server.com/path/page.
|
|
|
|
|
|
|
|
|
|
|
|
To filter an http request through the local proxy, you need to adapt
|
|
|
|
|
|
the protocol by inserting a small server, called transproxy (you can
|
|
|
|
|
|
find it on the world wide web). You can choose to run transproxy on
|
|
|
|
|
|
port 8081, and issue this command:
|
|
|
|
|
|
|
|
|
|
|
|
root# ipfwadm -I -a accept -D 0/0 80 -r 8081
|
|
|
|
|
|
|
|
|
|
|
|
The transproxy program, then, will receive all connections meant to
|
|
|
|
|
|
reach external servers and will pass them to the local proxy after
|
|
|
|
|
|
fixing protocol differences.
|
|
|
|
|
|
|
|
|
|
|
|
6.11. IPv6
|
|
|
|
|
|
|
|
|
|
|
|
Just when you thought you were beginning to understand IP networking
|
|
|
|
|
|
the rules get changed! IPv6 is the shorthand notation for version 6 of
|
|
|
|
|
|
the Internet Protocol. IPv6 was developed primarily to overcome the
|
|
|
|
|
|
concerns in the Internet community that there would soon be a shortage
|
|
|
|
|
|
of IP addresses to allocate. IPv6 addresses are 16 bytes long (128
|
|
|
|
|
|
bits). IPv6 incorporates a number of other changes, mostly
|
|
|
|
|
|
simplifications, that will make IPv6 networks more managable than IPv4
|
|
|
|
|
|
networks.
|
|
|
|
|
|
|
|
|
|
|
|
Linux already has a working, but not complete, IPv6 implementation in
|
|
|
|
|
|
the 2.2.* series kernels.
|
|
|
|
|
|
|
|
|
|
|
|
If you wish to experiment with this next generation Internet
|
|
|
|
|
|
technology, or have a requirement for it, then you should read the
|
|
|
|
|
|
IPv6-FAQ which is available from www.terra.net.
|
|
|
|
|
|
|
|
|
|
|
|
6.12. Mobile IP
|
|
|
|
|
|
|
|
|
|
|
|
The term "IP mobility" describes the ability of a host that is able to
|
|
|
|
|
|
move its network connection from one point on the Internet to another
|
|
|
|
|
|
without changing its IP address or losing connectivity. Usually when
|
|
|
|
|
|
an IP host changes its point of connectivity it must also change its
|
|
|
|
|
|
IP address. IP Mobility overcomes this problem by allocating a fixed
|
|
|
|
|
|
IP address to the mobile host and using IP encapsulation (tunneling)
|
|
|
|
|
|
with automatic routing to ensure that datagrams destined for it are
|
|
|
|
|
|
routed to the actual IP address it is currently using.
|
|
|
|
|
|
|
|
|
|
|
|
A project is underway to provide a complete set of IP mobility tools
|
|
|
|
|
|
for Linux. The Status of the project and tools may be obtained from
|
|
|
|
|
|
the: Linux Mobile IP Home Page.
|
|
|
|
|
|
|
|
|
|
|
|
6.13. Multicast
|
|
|
|
|
|
|
|
|
|
|
|
IP Multicast allows an arbitrary number of IP hosts on disparate IP
|
|
|
|
|
|
networks to have IP datagrams simultaneously routed to them. This
|
|
|
|
|
|
mechanism is exploited to provide Internet wide "broadcast" material
|
|
|
|
|
|
such as audio and video transmissions and other novel applications.
|
|
|
|
|
|
|
|
|
|
|
|
Kernel Compile Options:
|
|
|
|
|
|
|
|
|
|
|
|
Networking options --->
|
|
|
|
|
|
[*] TCP/IP networking
|
|
|
|
|
|
....
|
|
|
|
|
|
[*] IP: multicasting
|
|
|
|
|
|
|
|
|
|
|
|
A suite of tools and some minor network configuration is required.
|
|
|
|
|
|
Please check the Multicast-HOWTO for more information on Multicast
|
|
|
|
|
|
support in Linux.
|
|
|
|
|
|
|
|
|
|
|
|
6.14. NAT - Network Address Translation
|
|
|
|
|
|
|
|
|
|
|
|
The IP Network Address Translation facility is pretty much the
|
|
|
|
|
|
standardized big brother of the Linux IP Masquerade facility. It is
|
|
|
|
|
|
specified in some detail in RFC-1631 at your nearest RFC archive. NAT
|
|
|
|
|
|
provides features that IP-Masquerade does not that make it eminently
|
|
|
|
|
|
more suitable for use in corporate firewall router designs and larger
|
|
|
|
|
|
scale installations.
|
|
|
|
|
|
|
|
|
|
|
|
An alpha implementation of NAT for Linux 2.0.29 kernel has been
|
|
|
|
|
|
developed by Michael.Hasenstein, Michael.Hasenstein@informatik.tu-
|
|
|
|
|
|
chemnitz.de. Michaels documentation and implementation are available
|
|
|
|
|
|
from:
|
|
|
|
|
|
|
|
|
|
|
|
Linux IP Network Address Web Page
|
|
|
|
|
|
|
|
|
|
|
|
Newer Linux 2.2.x kernels also include some NAT functionality in the
|
|
|
|
|
|
routing algorithm.
|
|
|
|
|
|
|
|
|
|
|
|
6.15. Traffic Shaper - Changing allowed bandwidth
|
|
|
|
|
|
|
|
|
|
|
|
The traffic shaper is a driver that creates new interface devices,
|
|
|
|
|
|
those devices are traffic-limited in a user-defined way, they rely on
|
|
|
|
|
|
physical network devices for actual transmission and can be used as
|
|
|
|
|
|
outgoing routed for network traffic.
|
|
|
|
|
|
|
|
|
|
|
|
The shaper was introduced in Linux-2.1.15 and was backported to
|
|
|
|
|
|
Linux-2.0.36 (it appeared in 2.0.36-pre-patch-2 distributed by Alan
|
|
|
|
|
|
Cox, the author of the shaper device and maintainer of Linux-2.0).
|
|
|
|
|
|
|
|
|
|
|
|
The traffic shaper can only be compiled as a module and is configured
|
|
|
|
|
|
by the shapecfg program with commands like the following:
|
|
|
|
|
|
|
|
|
|
|
|
shapecfg attach shaper0 eth1
|
|
|
|
|
|
shapecfg speed shaper0 64000
|
|
|
|
|
|
|
|
|
|
|
|
The shaper device can only control the bandwidth of outgoing traffic,
|
|
|
|
|
|
as packets are transmitted via the shaper only according to the
|
|
|
|
|
|
routing tables; therefore, a ``route by source address'' functionality
|
|
|
|
|
|
could help in limiting the overall bandwidth of specific hosts using a
|
|
|
|
|
|
Linux router.
|
|
|
|
|
|
|
|
|
|
|
|
Linux-2.2 already has support for such routing, if you need it for
|
|
|
|
|
|
Linux-2.0 please check the patch by Mike McLagan, at ftp.invlogic.com.
|
|
|
|
|
|
Refer to Documentationnetworking/shaper.txt for further information
|
|
|
|
|
|
about the shaper.
|
|
|
|
|
|
|
|
|
|
|
|
If you want to try out a (tentative) shaping for incoming packets, try
|
|
|
|
|
|
out rshaper-1.01 (or newer), from ftp.systemy.it.
|
|
|
|
|
|
|
|
|
|
|
|
6.16. Routing in Linux-2.2
|
|
|
|
|
|
|
|
|
|
|
|
The latest versions of Linux, 2.2 offer a lot of flexibility in
|
|
|
|
|
|
routing policy. Unfortunately, you have to wait for the next version
|
|
|
|
|
|
of this howto, or go read the kernel sources.
|
|
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
There are four categories of high level abstract connections:
|
|
|
|
|
|
- point-to-point
|
|
|
|
|
|
- point-to-multipoint
|
|
|
|
|
|
- multipoint-to-point
|
|
|
|
|
|
- multipoint-to-multipoint
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
In network terminology the word "point" is usually synonymous with "device".
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
4. Networking hardware supported
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Linux supports a great variety of networking hardware, including some
|
|
|
|
|
|
obsolete equipment.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Some interesting documents:
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· Hardware HOWTO <http://metalab.unc.edu/mdw/HOWTO/Hardware-
|
2004-11-04 11:12:28 +00:00
|
|
|
|
HOWTO.html>
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· Ethernet HOWTO <http://metalab.unc.edu/mdw/HOWTO/Ethernet-
|
2004-11-04 11:12:28 +00:00
|
|
|
|
HOWTO.html>
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
6.9. Authentication
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
There are also various ways of authenticating users in mixed networks.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· For Linux/Windows NT:http://www.mindware.com.au/ftp/smb-NT-
|
2004-11-04 11:12:28 +00:00
|
|
|
|
verify.1.1.tar.gz
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· The PAM (pluggable authentication module) which is a flexible
|
2004-11-04 11:12:28 +00:00
|
|
|
|
method of Unix authentication: PAM library
|
|
|
|
|
|
<http://www.kernel.org/pub/linux/libs/pam/index.html>.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· Finally, LDAP in Linux
|
2004-11-04 11:12:28 +00:00
|
|
|
|
<http://www.umich.edu/~dirsvcs/ldap/index.html>
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
7. Remote execution of applications
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
One of the most amazing features of Unix (yet one of the most unknown
|
|
|
|
|
|
to new users) is its great support for remote and distributed
|
|
|
|
|
|
execution of applications.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
7.2. Remote commands
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
In Unix, and in particular in Linux, remote commands exist that allow
|
|
|
|
|
|
for interaction with other computers from the shell prompt. Examples
|
|
|
|
|
|
are: rlogin, which allows for login in a remote machine in a similar
|
|
|
|
|
|
way to telnet, rcp, which allows for the remote transfer of files
|
|
|
|
|
|
among machines, etc. Finally, the remote shell command rsh allows the
|
|
|
|
|
|
execution of a command on a remote machine without actually logging
|
|
|
|
|
|
onto that machine.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
2.2. What makes Linux different?
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Why work on Linux? Linux is generally cheaper (or at least no more
|
|
|
|
|
|
expensive) than other operating systems and is frequently less
|
|
|
|
|
|
problematic than many commercial systems. But what makes Linux
|
|
|
|
|
|
different is not its price (after all, why would anyone want an OS -
|
|
|
|
|
|
even a free one - if it is not good enough?) but its outstanding
|
|
|
|
|
|
capabilities:
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· Linux is a true 32-bit multitasking operating system, robust and
|
2004-11-04 11:12:28 +00:00
|
|
|
|
capable enough to be used in organizations ranging from
|
|
|
|
|
|
universities to large corporations.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· It runs on hardware ranging from low-end 386 boxes to massive
|
2004-11-04 11:12:28 +00:00
|
|
|
|
ultra-parallel machines in research centres.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· Out-of-the-box versions are available for Intel, Sparc, and Alpha
|
2004-11-04 11:12:28 +00:00
|
|
|
|
architectures, and experimental support exists for Power PC and
|
|
|
|
|
|
embedded systems, among others such as SGI, Ultra Sparc, AP1000+,
|
|
|
|
|
|
Strong ARM, and MIPS R3000/R4000.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· Finally, when it comes to networking, Linux is choice. Not only
|
2004-11-04 11:12:28 +00:00
|
|
|
|
because networking is tightly integrated with the OS itself and a
|
|
|
|
|
|
plethora of applications is freely available, but for the
|
|
|
|
|
|
robustness under heavy loads that can only be achieved after years
|
|
|
|
|
|
of debugging and testing in an Open Source project.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
5. File Sharing and Printing
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
The primary purpose of many PC based Local Area Networks is to provide
|
|
|
|
|
|
file and printer sharing services to the users. Linux as a corporate
|
|
|
|
|
|
file and print server turns out to be a great solution.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
8. Network Interconnection
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Linux networking is rich in features. A Linux box can be configured so
|
|
|
|
|
|
it can act as a router, bridge, etc... Some of the available options
|
|
|
|
|
|
are described below.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Common Network Protocols
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
As mentioned earlier, network protocols are sets of rules and standards for data commnucations
|
|
|
|
|
|
over networks. A network architecture (such as Ethernet) can support multiple protocols, and even
|
|
|
|
|
|
multiple protocols currently.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Protocols are typically organized into protocol suites, or sets of compatible protocols. These are
|
|
|
|
|
|
also referred to as protocol stacks. A stack includes protocols for several different layers of the
|
|
|
|
|
|
OSI model. Lower-level protocols provide services for use by upper-level protocols. The highest
|
|
|
|
|
|
level protocols communicate directly with applications.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Communications protocols can be divided into two basic types, connection-orientated
|
|
|
|
|
|
and connectionless:
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
- Connection-orientated protocols
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
establish a connection, or virtual circuit, before, communicating, and disconnect it when
|
|
|
|
|
|
finished. Connection-orientated protocols generally have a lower speed due to the
|
|
|
|
|
|
bandwidth used for session maintenance.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
- Connectionless protocols
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
do not establish a virtual circuit. Data is sent withoug establishing a connection, and may
|
|
|
|
|
|
be sent at any time. These protocols have low overhead, and are generally used where speed
|
|
|
|
|
|
is a high priority.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Another distinction between protocols is their reliablity. Some protocols send
|
|
|
|
|
|
acknowledgements for each transmitted packet. This makes for a more reliable connection,
|
|
|
|
|
|
but leaves less bandwidth for actual data transmission. These are called reliable protocols.
|
|
|
|
|
|
Protocols without acknowledgements are known as unreliable, although this does not
|
|
|
|
|
|
necessarily mean they are undependable.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Common Network Protocols and Characteristics
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Protocol Overhead Routable? Typical Application
|
|
|
|
|
|
TCP/IP Medium Yes Large networks; Internet and UNIX compatibility
|
|
|
|
|
|
NetBEUI Low No Small Windows-based networks
|
|
|
|
|
|
IPX/SPX Medium Yes NetWare compatiblity
|
|
|
|
|
|
Appletalk Medium Yes Apple Macintosh compatiblity
|
|
|
|
|
|
DLC Medium No IBM mainframe compatiblity; some network printers
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Common WAN Architectures
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
- Circuit Switching
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Circuit switching is a connection-orientated method of communication. A circuit is dedicated to the connection,
|
|
|
|
|
|
and a connection must be specifically established when needed and disconnected when not needed.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
- Message Switching
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Message switching is a connectionless method of communication. Individual message units are sent across the network
|
|
|
|
|
|
with routing information without establishing a dedicated nework.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
- Packet Switching
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Packet switching is a more efficient connectionless communication method. Packets (smaller than message units)
|
|
|
|
|
|
are sent individually and can follow different routes to their destination. Some packet switching systems use
|
|
|
|
|
|
virtual circuits for a logical connection, but don't use a dedicated physical connection.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Switched networks are generally less expensive and allow networking with multiple locations; non-switched
|
|
|
|
|
|
lnks are usually dedicated between two locations and provide more consistent available bandwidth.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
WAN connections typically require different (and more expensive) hardware than LAN connections. Typical
|
|
|
|
|
|
WAN equipment includes specialized types of routers, CSU/DSUs (Channel Service Unit/Digital Service Unit),
|
|
|
|
|
|
and multiplexers, which combine multiple signals (such as voice and data) for tranmissions on a single WAN
|
|
|
|
|
|
connection. A number of WAN technologies and public networks are available. FDDI, explained earlier in this
|
|
|
|
|
|
chapter, can also be used for wide-are networks. The common WAN technologies are described in detail in
|
|
|
|
|
|
the sections below.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
3.5. WAN Networking: X.25, Frame-relay, etc...
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
Several third parties provide T-1, T-3, X.25 and Frame Relay products
|
|
|
|
|
|
for Linux. Generally special hardware is required for these types of
|
|
|
|
|
|
connections. Vendors that provide the hardware also provide the
|
|
|
|
|
|
drivers with protocol support.
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
· WAN resources for Linux:
|
2004-11-04 11:12:28 +00:00
|
|
|
|
http://www.secretagent.com/networking/wan.html
|
2016-01-24 18:46:18 +00:00
|
|
|
|
]]>
|
2004-11-04 02:03:06 +00:00
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
>Start Binh
|
2005-02-09 13:09:12 +00:00
|
|
|
|
|
|
|
|
|
|
Attentuation is a physical phenomenon which causes a signal to gradually lose
|
|
|
|
|
|
power as it propogates through a medium. This is mainly due to due to two
|
|
|
|
|
|
factors, signal dispersion and signal absorption. Unfortunately, there is some
|
|
|
|
|
|
noise which generates a constant noise power, N, and so eventually, as the
|
|
|
|
|
|
signal travels a long enough distance, the signal poower will decrease to a
|
|
|
|
|
|
value less than the noise power.
|
|
|
|
|
|
|
|
|
|
|
|
This is similar to the effect observed when you are attempting to communicate
|
|
|
|
|
|
with another person with your natural voice. As the person moves further away
|
|
|
|
|
|
the voice is harder to hear as the signal power spreads out and is absorbed
|
|
|
|
|
|
by obstacles, etc....
|
|
|
|
|
|
|
|
|
|
|
|
Attenuation is generally a factor of distance and frequency.
|
|
|
|
|
|
|
|
|
|
|
|
This is very much in accordance with our current laws of physics.
|
|
|
|
|
|
The intensity if a signal is inversely proportional to the inverse square of the the signal distance.
|
|
|
|
|
|
You'll often notice that in military applications the usage of broad
|
|
|
|
|
|
frequency radar for spotting targets over great ranges and then the utilisation
|
|
|
|
|
|
of higher frequency signals as greater precision positioning is required.
|
|
|
|
|
|
|
|
|
|
|
|
Most transmission medium will have a rating which gives the attenuation as a
|
|
|
|
|
|
function of frequency and distance, eg. the attenuation per kilometer. Ideally
|
|
|
|
|
|
the attenuation is zero because this represents no loss in the signal power.
|
|
|
|
|
|
|
|
|
|
|
|
This leads us to the issue of digital transmission versus analogue
|
|
|
|
|
|
transmission. The primary advantage of digital transmission over analogue
|
|
|
|
|
|
transmission is the reduction in noise. The digital transmission system
|
|
|
|
|
|
reduces noise over successive transmissions because small variations in
|
|
|
|
|
|
the signal can be rounded off to the nearest level. Analogue transmission
|
|
|
|
|
|
systems need to filter out the noise, but the filter itself can sometimes
|
|
|
|
|
|
be a source of noise and generally, noise can accumulate to an unacceptable
|
|
|
|
|
|
level in an analogue tranmission system.
|
|
|
|
|
|
|
|
|
|
|
|
Consider two types of repeater to understand of digital transmission. In the
|
|
|
|
|
|
first instance (analogue) the situation is roughly synonymous with someone
|
|
|
|
|
|
who doesn't know Korean and who is trying to relay a message from one Korean
|
|
|
|
|
|
to another. It can be done if the person simply repeats the sounds that are
|
|
|
|
|
|
heard. In digital tranmission repitition would be more along the lines of
|
|
|
|
|
|
someone knowing Korean and actually "re-saying" what was heard (perhaps even
|
|
|
|
|
|
correcting for errors in what was heard).
|
|
|
|
|
|
|
|
|
|
|
|
Systems which transmit ananlogue signals (such as the calssical radio and
|
|
|
|
|
|
television broadcasting systems) can use one of three well known techniques,
|
|
|
|
|
|
Amplitude Modulation (AM), Frequency Modulation (FM), and Phase Modulation (PM).
|
|
|
|
|
|
AM works by varying the amplitude of a signal to code the bit stream. FM works
|
|
|
|
|
|
by varying frequency of a signal to code the bit stream. PM works by varying
|
|
|
|
|
|
the phase of a signal to code the bit stream.
|
|
|
|
|
|
|
|
|
|
|
|
To allow two transmission medium (usually of the same type) to be directly
|
|
|
|
|
|
connected the concept of a switch was developed. A general switch can be
|
|
|
|
|
|
built from many basic switches and is somtimes referred to as a switching
|
|
|
|
|
|
fabric. A lot of research and development contines in an attempt to build
|
|
|
|
|
|
better switching fabrics.
|
|
|
|
|
|
|
|
|
|
|
|
A circuit switched network operates at the physical layer to provide a single,
|
|
|
|
|
|
continuous transmission medium between any two hosts or end devices in the
|
|
|
|
|
|
network. Circuit switching is perhaps the most straightforward approach to building
|
|
|
|
|
|
communication network. Computer networks didn't actually evolve using circuit
|
|
|
|
|
|
switching though circuit switching is being considered for certain computer
|
|
|
|
|
|
applications such as video and voice. Because circuit switching constucts a
|
|
|
|
|
|
single long transmission medium with at most analogue repeaters the end devices
|
|
|
|
|
|
(in this case telephones) are able to modulate the signal on the medium however
|
|
|
|
|
|
they choose. This is also why two modems can communicate with one another over
|
|
|
|
|
|
a telephone network.
|
|
|
|
|
|
|
|
|
|
|
|
Multiplexing is used to share a single transmission medium among a number of
|
|
|
|
|
|
individual transmissions. The demultiplexer just undoes what the multiplexer
|
|
|
|
|
|
does. Therefore the multiplexer and demultiplexer must directly cooperate.
|
|
|
|
|
|
Multiplexers and demultiplexers are not so much network devices are not so much
|
|
|
|
|
|
network devices but functionality that is contained within a network device.
|
|
|
|
|
|
Switches (in the sense described here) may be similarly categorized in this way.
|
|
|
|
|
|
|
|
|
|
|
|
The transmission medium can be multiplexed in the time domain, called TDM (Time Domain
|
|
|
|
|
|
Multiplexing), using a simple switch and clocked control. Because of delays incurred
|
|
|
|
|
|
in the transmission line, the clocks may need to be out of phase with one another.
|
|
|
|
|
|
See that with the TDM, the shared medium must be able to transmit at a bit rate
|
|
|
|
|
|
that equals (or is better than) the sum of input bit rates. The swithes must also
|
|
|
|
|
|
be able to switch fast enough.
|
|
|
|
|
|
|
|
|
|
|
|
The previous example was assuming a synchronous transmission mode. In general, bit
|
|
|
|
|
|
streams can be divided into DU's called cells. Cells are fixed in length so that the
|
|
|
|
|
|
receiver knows when one cell finishes and the next cell begins.
|
|
|
|
|
|
|
|
|
|
|
|
Alternatively there is ATM (Asynchronous Transmission Mode, ATM is also the name
|
|
|
|
|
|
given to a popular network layer device that uses this multiplexing technique.),
|
|
|
|
|
|
where signals are irregularly multiplexed. How does the receiver know what order
|
|
|
|
|
|
the signals were multiplexed in?
|
|
|
|
|
|
|
|
|
|
|
|
Additional information is needed in the multiplexed signal. One way is to add a
|
|
|
|
|
|
header or label to the front of each cell. The header identifies the cell.
|
|
|
|
|
|
|
|
|
|
|
|
Using a header means using additional bits, which becomes overhead. Thus, to reduce
|
|
|
|
|
|
the overhead the cells should be reasonably larger than the header. Cells for
|
|
|
|
|
|
modern ATM transmission systems are about 50 butes in size.
|
|
|
|
|
|
|
|
|
|
|
|
Because modulators can transmit signals at different frequency bands, it is possible
|
|
|
|
|
|
to transmit several signals at one, with each signal transmitted within a different
|
|
|
|
|
|
frequency band. In this case the different signals have been frequency domain multiplexed.
|
|
|
|
|
|
This is known as FDM, (Frequency Domain Multiplexing).
|
|
|
|
|
|
|
|
|
|
|
|
Similar to FDM, WDM (Wavelength Division Multiplexing) uses each wavelength of light to
|
|
|
|
|
|
transmit a signal. WDM is for fiber optic systems. The number of wavelengths per
|
|
|
|
|
|
fiber, currently available, is about 300. Each wavelength can carry about 10Gbps.
|
|
|
|
|
|
This makes 3Tbps. AT&T predict that up to 1024 wavelengths may be available in the future.
|
|
|
|
|
|
|
|
|
|
|
|
The hub/optical hub is clearly an analogue device - input signals are reflected to all
|
|
|
|
|
|
outputs. It is also called passive, because it does not introduce any power to the signal
|
|
|
|
|
|
(otherwise it would be called active). Considering the hub as a device which repeats
|
|
|
|
|
|
input from an incoming signal on all outputs is quite simplistic however the basic
|
|
|
|
|
|
function should be understandable. When examining the Data-link layer it will become
|
|
|
|
|
|
clearer how computers communicate using a hub. For wireless communication, the
|
|
|
|
|
|
transmission of each device is implicity received by every other device. This is an
|
|
|
|
|
|
implicit hub.
|
|
|
|
|
|
|
|
|
|
|
|
Wireless communication usually takes place using the IEEE 802.11 standard which specifies
|
|
|
|
|
|
an unlicensed radio spectrum at 2.4GHz and provides wireless Ethernet access at 11Mbps.
|
|
|
|
|
|
There is also some spectrum allocated between 5GHz ad 6GHz that provides 54Mbps.
|
|
|
|
|
|
Sophisticated codes and frequency sharing technology is used to maximise the usage of
|
|
|
|
|
|
this communication medium. This topic is strictly concerned with Medium Access Control,
|
|
|
|
|
|
to be discussed later. Wireless also allows point-to-point communication in the sense
|
|
|
|
|
|
that each point-to-point link or channel is a dedicated frequency range that no other
|
|
|
|
|
|
pair of devices will use.
|
|
|
|
|
|
|
|
|
|
|
|
Analogue telephone networks use conventional circuit switching networks to
|
|
|
|
|
|
construct a connection between two telephones. You have seen that a modem
|
|
|
|
|
|
converts digital signals to analogue to be transmitted over an analogue
|
|
|
|
|
|
telephone network.
|
|
|
|
|
|
|
|
|
|
|
|
Digital telephone networks use a codec or coder-decoder to convert analogue
|
|
|
|
|
|
telephone (or modem) signals into digital form! This is so that new digital
|
|
|
|
|
|
techniques can be used within a conventionally an analogue network, ie.
|
|
|
|
|
|
transparently to the analogue devices. The codec is used to convert from
|
|
|
|
|
|
analogue to digital and digital to analogue.
|
|
|
|
|
|
|
|
|
|
|
|
Enough is known now to consider the complexity of a large digital network
|
|
|
|
|
|
that supporst communication of various kinds. As technologies improve some
|
|
|
|
|
|
networks become more dominant than others. In todays world we see a
|
|
|
|
|
|
significant shift towards computer networks, away from conventional
|
|
|
|
|
|
telecommunication networks.
|
|
|
|
|
|
|
|
|
|
|
|
This doesn't mean the end of telecommunications, but rather a collapse of
|
|
|
|
|
|
outdated technological layers towards the "core" networks that they connect
|
|
|
|
|
|
to. It will become more apparent to you as we progres through this subject
|
|
|
|
|
|
that networks can be built on top of other networks which are themseleves
|
|
|
|
|
|
built on top of ther networks.
|
|
|
|
|
|
|
|
|
|
|
|
The size and scale of a network can vary substantially from Local Area Networks
|
|
|
|
|
|
(LANs) which usually connect 10-15 computers in a
|
|
|
|
|
|
small area (usually a small building) to Metropolitan Area Networks (MANs)
|
|
|
|
|
|
which use long-distance links (such as telephone lines or dedicated media)
|
|
|
|
|
|
to connect two or more locations within a single city or metropolitan area
|
|
|
|
|
|
to Wide Area Networks (WANs) which use the same technology as MANs to
|
|
|
|
|
|
connect computers in distant locations but in different cities
|
|
|
|
|
|
or even different countries.
|
|
|
|
|
|
|
|
|
|
|
|
There are two basic types of networks: client-server networks, which use
|
|
|
|
|
|
dedicated servers; and peer-to-peer networks, which (normally) share files
|
|
|
|
|
|
between workstations.
|
|
|
|
|
|
|
|
|
|
|
|
Server-based networks (also called client-server networks) use a dedicated
|
|
|
|
|
|
server machine which provides files and printers to network workstations
|
|
|
|
|
|
called clients. Client machines are simply used by network users, and usually
|
|
|
|
|
|
do not share files or printers. The key benefit of the server-client model is
|
|
|
|
|
|
in centralization. There is only a single point of control for network acccess,
|
|
|
|
|
|
security, and management. The disadvantages of a server-based network are the
|
|
|
|
|
|
higher cost of dedicated servers and network operating systems, as well as the
|
|
|
|
|
|
increased level of administrative effort required.
|
|
|
|
|
|
|
|
|
|
|
|
Conversely, peer-to-peer networks consist solely of workstations called peers.
|
|
|
|
|
|
Each workstation can be used by a user, and can also make shared files or
|
|
|
|
|
|
printers available to users at other workstations. The advantages of peer
|
|
|
|
|
|
networks include their ease of installation and use, their relative
|
|
|
|
|
|
inexpensiveness in comparison with server-based networks (since a dedicated
|
|
|
|
|
|
server is not required) and the fact that an administrator mightn't be required
|
|
|
|
|
|
(if users are able to manage resource sharing). The primary disadvantage of
|
|
|
|
|
|
peer networks is the lack of a central control mechanism. Each user controls
|
|
|
|
|
|
access to their own workstation's shared files and printers. In a large scale
|
2016-10-24 12:10:39 +00:00
|
|
|
|
network, such a security policy is difficult to manage without
|
2005-02-09 13:09:12 +00:00
|
|
|
|
compromising security. Further, a workstation that is being accessed by peers
|
|
|
|
|
|
can also be slowed down, inconveniencing the user at that workstation. Hence,
|
|
|
|
|
|
its clear that this system is best suited to smaller networks.
|
|
|
|
|
|
|
2004-11-04 11:12:28 +00:00
|
|
|
|
</para>
|
|
|
|
|
|
</sect1>
|
2005-02-11 04:09:07 +00:00
|
|
|
|
|
|
|
|
|
|
<sect1 id="Internet">
|
|
|
|
|
|
|
|
|
|
|
|
<title>Internet</title>
|
|
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
|
Internet is not described as a network of any single kind. It can be construed
|
|
|
|
|
|
as a large set of heterogenous networks that support a certain set of protocols
|
|
|
|
|
|
(TCP/IP) and provide certain common services. A good way to learn about the
|
|
|
|
|
|
Internet is to use the Internet!
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
|
Linux is a great platform to act as an Intranet / Internet server. The
|
|
|
|
|
|
term Intranet refers to the application of Internet technologies
|
|
|
|
|
|
inside an organisation mainly for the purpose of distributing and
|
|
|
|
|
|
making available information inside the company. Internet and Intranet
|
|
|
|
|
|
services offered by Linux include mail, news, WWW servers and many
|
|
|
|
|
|
more that will be outlined further on in this document.
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
2016-01-24 18:46:18 +00:00
|
|
|
|
</sect1>
|
