mirror of https://github.com/tLDP/LDP
2557 lines
110 KiB
XML
2557 lines
110 KiB
XML
<sect1 id="Overview">
|
||
|
||
<title>Overview</title>
|
||
|
||
<para>
|
||
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>
|
||
<screen>
|
||
The original volunteer to lead development of the kernel network code
|
||
was Ross Biro <biro@yggdrasil.com>. Ross produced a simple and
|
||
incomplete but mostly usable implementation set of routines that were
|
||
complemented by an ethernet driver for the WD-8003 network interface
|
||
card.This was enough to get many people testing and experimenting
|
||
with the software and some people even managed to connect machines in
|
||
this configuration to live internet connections. The pressure within
|
||
the Linux community driving development for networking support was
|
||
building and eventually the cost of a combination of some unfair
|
||
pressure applied to Ross and his own personal commitments outweighed
|
||
the benefit he was deriving and he stepped down as lead developer.
|
||
Ross's efforts in getting the project started and accepting the
|
||
responsibility for actually producing something useful in such
|
||
controversial circumstances were what catalyzed all future work and
|
||
were therefore an essential component of the success of the current
|
||
product.
|
||
|
||
Orest Zborowski <obz@Kodak.com> produced the original BSD socket
|
||
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.
|
||
|
||
Somewhere about this time Laurence Culhane <loz@holmes.demon.co.uk>
|
||
developed the first drivers for Linux to support the SLIP protocol.
|
||
These enabled many people who did not have access to Ethernet
|
||
networking to experiment with the new networking software. Again, some
|
||
people took this driver and pressed it into service to connect them to
|
||
the Internet. This gave many more people a taste of the possibilities
|
||
that could be realized if Linux had full networking support and grew
|
||
the number of users actively using and experimenting with the
|
||
networking software that existed.
|
||
|
||
One of the people that had also been actively working on the task of
|
||
building networking support was Fred van Kempen
|
||
<waltje@uwalt.nl.mugnet.org>.After a period of some uncertainty
|
||
following Ross's resignation from the lead developer position Fred
|
||
offered his time and effort and accepted the role essentially
|
||
unopposed. Fred had some ambitious plans for the direction that he
|
||
wanted to take the Linux networking software and he set about
|
||
progressing in those directions. Fred produced a series of networking
|
||
code called the `NET-2' kernel code (the `NET' code being Ross's)
|
||
which many people were able to use pretty much usefully. Fred formally
|
||
put a number of innovations on the development agenda, such as the
|
||
dynamic device interface, Amateur Radio AX.25 protocol support and a
|
||
more modularly designed networking implementation.Fred's NET-2 code
|
||
was used by a fairly large number of enthusiasts, the number
|
||
increasing all the time as word spread that the software was working.
|
||
The networking software at this time was still a large number of
|
||
patches to the standard release of kernel code and was not included in
|
||
the normal release.The NET-FAQ and subsequent NET-2-HOWTO's
|
||
described the then fairly complex procedure to get it all working.
|
||
Fred's focus was on developing innovations to the standard network
|
||
implementations and this was taking time. The community of users was
|
||
growing impatient for something that worked reliably and satisfied the
|
||
80% of users and, as with Ross, the pressure on Fred as lead developer
|
||
rose.
|
||
|
||
Alan Cox <iialan@www.uk.linux.org> proposed a solution to the problem
|
||
designed to resolve the situation. He proposed that he would take
|
||
Fred's NET-2 code and debug it, making it reliable and stable so that
|
||
it would satisfy the impatient user base while relieving that pressure
|
||
from Fred allowing him to continue his work. Alan set about doing
|
||
this, with some good success and his first version of Linux networking
|
||
code was called `Net-2D(ebugged)'. The code worked reliably in many
|
||
typical configurations and the user base was happy. Alan clearly had
|
||
ideas and skills of his own to contribute to the project and many
|
||
discussions relating to the direction the NET-2 code was heading
|
||
ensued. There developed two distinct schools within the Linux
|
||
networking community, one that had the philosophy of `make it work
|
||
first, then make it better' and the other of `make it better first'.
|
||
Linus ultimately arbitrated and offered his support to Alan's
|
||
development efforts and included Alan's code in the standard kernel
|
||
source distribution.This placed Fred in a difficult position. Any
|
||
continued development would lack the large user base actively using
|
||
and testing the code and this would mean progress would be slow and
|
||
difficult. Fred continued to work for a short time and eventually
|
||
stood down and Alan came to be the new leader of the Linux networking
|
||
kernel development effort.
|
||
|
||
Donald Becker <becker@cesdis.gsfc.nasa.gov> soon revealed his talents
|
||
in the low level aspects of networking and produced a huge range of
|
||
ethernet drivers, nearly all of those included in the current kernels
|
||
were developed by Donald. There have been other people that have made
|
||
significant contributions, but Donald's work is prolific and so
|
||
warrants special mention.
|
||
|
||
Alan continued refining the NET-2-Debugged code for some time while
|
||
working on progressing some of the matters that remained unaddressed
|
||
on the `TODO' list.By the time the Linux 1.3.* kernel source had
|
||
grown its teeth the kernel networking code had migrated to the NET-3
|
||
release on which current versions are based. Alan worked on many
|
||
different aspects of the networking code and with the assistance of a
|
||
range of other talented people from the Linux networking community
|
||
grew the code in all sorts of directions. Alan produced dynamic
|
||
network devices and the first standard AX.25 and IPX implementations.
|
||
Alan has continued tinkering with the code, slowly restructuring and
|
||
enhancing it to the state it is in today.
|
||
|
||
PPP support was added by Michael Callahan <callahan@maths.ox.ac.uk>
|
||
and Al Longyear <longyear@netcom.com> this too was critical to
|
||
increasing the number of people actively using linux for networking.
|
||
|
||
Jonathon Naylor <jsn@cs.nott.ac.uk> has contributed by significantly
|
||
enhancing Alan's AX.25 code, adding NetRom and Rose protocol support.
|
||
The AX.25/NetRom/Rose support itself is quite significant, because no
|
||
other operating system can boast standard native support for these
|
||
protocols beside Linux.
|
||
|
||
There have of course been hundreds of other people who have made
|
||
significant contribution to the development of the Linux networking
|
||
software. Some of these you will encounter later in the technology
|
||
specific sections, other people have contributed modules, drivers,
|
||
bug-fixes, suggestions, test reports and moral support. In all cases
|
||
each can claim to have played a part and offered what they could. The
|
||
Linux kernel networking code is an excellent example of the results
|
||
that can be obtained from the Linux style of anarchic development, if
|
||
it hasn't yet surprised you, it is bound to soon enough, the
|
||
development hasn't stopped.
|
||
|
||
Linux Networking HOWTO, http://tldp.org/HOWTO/NET3-4-HOWTO.html
|
||
</screen>
|
||
</para>
|
||
|
||
----------
|
||
|
||
<para>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
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:
|
||
|
||
|
||
<20> Host IP Address
|
||
|
||
<20> IP network address
|
||
|
||
<20> IP broadcast address
|
||
|
||
<20> IP netmask
|
||
|
||
<20> Router address
|
||
|
||
<20> Domain Name Server Address
|
||
|
||
|
||
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:
|
||
|
||
|
||
IP Routing is the process by which a host with multiple net<65>
|
||
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 |---|
|
||
| | | // | | |
|
||
| \-----/ \-----/ |
|
||
| |
|
||
- -
|
||
|
||
The diagram illustrates another possible reason to use IPIP encapsula<6C>
|
||
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
|
||
IP network addresses. Suppose that you want to allow any host on net<65>
|
||
work A to connect to any host on network B, just as if they were prop<6F>
|
||
erly connected to the Internet with a network route. IPIP encapsula<6C>
|
||
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).
|
||
|
||
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.
|
||
|
||
There are four categories of high level abstract connections:
|
||
- point-to-point
|
||
- point-to-multipoint
|
||
- multipoint-to-point
|
||
- multipoint-to-multipoint
|
||
|
||
In network terminology the word "point" is usually synonymous with "device".
|
||
|
||
4. Networking hardware supported
|
||
|
||
Linux supports a great variety of networking hardware, including some
|
||
obsolete equipment.
|
||
|
||
Some interesting documents:
|
||
|
||
<20> Hardware HOWTO <http://metalab.unc.edu/mdw/HOWTO/Hardware-
|
||
HOWTO.html>
|
||
|
||
<20> Ethernet HOWTO <http://metalab.unc.edu/mdw/HOWTO/Ethernet-
|
||
HOWTO.html>
|
||
|
||
6.9. Authentication
|
||
|
||
There are also various ways of authenticating users in mixed networks.
|
||
|
||
<20> For Linux/Windows NT:http://www.mindware.com.au/ftp/smb-NT-
|
||
verify.1.1.tar.gz
|
||
|
||
<20> The PAM (pluggable authentication module) which is a flexible
|
||
method of Unix authentication: PAM library
|
||
<http://www.kernel.org/pub/linux/libs/pam/index.html>.
|
||
|
||
<20> Finally, LDAP in Linux
|
||
<http://www.umich.edu/~dirsvcs/ldap/index.html>
|
||
|
||
7. Remote execution of applications
|
||
|
||
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.
|
||
|
||
7.2. Remote commands
|
||
|
||
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.
|
||
|
||
2.2. What makes Linux different?
|
||
|
||
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:
|
||
|
||
|
||
<20> Linux is a true 32-bit multitasking operating system, robust and
|
||
capable enough to be used in organizations ranging from
|
||
universities to large corporations.
|
||
|
||
<20> It runs on hardware ranging from low-end 386 boxes to massive
|
||
ultra-parallel machines in research centres.
|
||
|
||
<20> Out-of-the-box versions are available for Intel, Sparc, and Alpha
|
||
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.
|
||
|
||
<20> Finally, when it comes to networking, Linux is choice. Not only
|
||
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.
|
||
|
||
5. File Sharing and Printing
|
||
|
||
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.
|
||
|
||
8. Network Interconnection
|
||
|
||
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.
|
||
|
||
Common Network Protocols
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
Communications protocols can be divided into two basic types, connection-orientated
|
||
and connectionless:
|
||
|
||
- Connection-orientated protocols
|
||
|
||
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.
|
||
|
||
- Connectionless protocols
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
Common Network Protocols and Characteristics
|
||
|
||
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
|
||
|
||
Common WAN Architectures
|
||
|
||
- Circuit Switching
|
||
|
||
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.
|
||
|
||
- Message Switching
|
||
|
||
Message switching is a connectionless method of communication. Individual message units are sent across the network
|
||
with routing information without establishing a dedicated nework.
|
||
|
||
- Packet Switching
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
3.5. WAN Networking: X.25, Frame-relay, etc...
|
||
|
||
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.
|
||
|
||
|
||
<20> WAN resources for Linux:
|
||
http://www.secretagent.com/networking/wan.html
|
||
|
||
>Start Binh
|
||
|
||
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
|
||
network network, such a security policy is difficult to manage without
|
||
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.
|
||
|
||
</para>
|
||
</sect1>
|
||
|
||
<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>
|
||
|
||
</sect1 id="Internet">
|