لطفا منتظر باشید ...
Network
Protocol Support
The Networking Options kernel menu contains
options related to network protocols. You can include or exclude support
for entire protocol stacks, and for some (particularly TCP/IP), you can
fine-tune the support to optimize the kernel for particular roles, such as
router options or packet filtering.
Packet
and Socket Options
At a fairly low level, Linux networking operates by allowing
programs to send or receive chunks of data (known as packets )
via data structures known as sockets. In most
cases, a program opens a socket in a manner that's similar to the way a program
opens a file. The program can then send and receive data via that socket. The
network protocol stack (discussed shortly in "
processes the data in ways that allow it to reach its destination or to be
interpreted by the program after having been received from the sender.
In some cases, it's desirable or even necessary to process
network data in some other way, or to modify or extend the standard packet and
socket operations. Some of these options are important enough that they have
their own sections. A few miscellaneous options include the following:
Packet Socket This option
allows applications to bypass much of the normal protocol stack. Most programs
don't need this feature, but some network diagnostic tools and other low-level
utilities do need it. For instance, tcpdump ,
which displays low-level TCP/IP packet information, uses this kernel option.
Including this option unnecessarily will slightly increase the size of the
kernel and might allow an intruder to use low-level network diagnostics like tcpdump that you'd rather the intruder not
be able to use. Omitting this feature will prevent you
from running these utilities, though.
Packet Socket: Mmapped IO This
is a packet socket suboption that, if enabled, can improve the performance of
tools that use packet socket connections.
Unix Domain Sockets Several
common and important Linux programs use networking protocols to communicate
with each other when they run on a single computer. Examples include syslogd (which handles log files) and X (X
programs use network protocols to communicate with the X server, which displays
their windows). The Unix Domain Sockets option allows this within-computer
communication even on systems that lack conventional network hardware. When
computers have conventional hardware, the domain sockets approach is faster
than using the more general-purpose TCP sockets. You should include this option
on all normal Linux systems; only specialized embedded devices or the like
might lack this option.
These options all have default settings that are reasonable
for most installations. You might want to disable packet socket support on some
systems, though.
Network
Filter Options
Network filters are designed to allow the system to block or
modify packets that come into or leave a computer. One of these options (packet
filtering) is particularly important for constructing firewalls or performing
IP masquerading, as discussed in
can block certain types of undesirable access to a computer or a network that
it protects, and IP masquerading lets you share a single IP address among an
entire network. Specific kernel network filter options include the following:
Socket Filtering Normally, the
kernel passes all packets that it receives for a given socket on to the program
that created the socket. This option allows the program to point the kernel to
a small program (known as a filter ) that will
block some of the packets it receives. Few programs require this facility, but
the Dynamic Host Configuration Protocol (DHCP) is an important exceptionboth
recent DHCP servers and some DHCP clients require it. You should therefore
enable this option if your network uses DHCP.
Network Packet Filtering This
option is the 2.4.
x kernel's most important
type of filter, because it enables certain firewall and IP masquerading
techniques. Because these are so important, it's generally a good idea to
include this support. When you do so, the Network Packet Filtering Debugging option
becomes available, which you can enable if you experience problems. A later
submenu, IP: Netfilter Configuration, also becomes available. Subsequent items
in this list appear on this submenu.
Connection Tracking Enabling
this option allows the kernel to track network connections in greater detail
than is normal. For instance, a router usually passes packets more-or-less
blindly between two network interfaces, but when this option is enabled (both
in the kernel and by user-level tools), Linux can match up the source and
destination IP addresses and ports for future reference. This feature is
required for IP masquerading, so it should be enabled on a computer that is to
function in this way. It's not necessary for most other systems. If you enable
it, the FTP protocol support option becomes available. FTP requires extra
housekeeping, so enable this option if you want to use FTP on an IP masqueraded
connection.
IP Tables Support This option
includes kernel support routines for the iptables
utility, which is used to set up packet filter firewalls and IP masquerading,
as discussed in
you to select a number of suboptions that fine-tune the features available to
you. Many of these options have names of the form Criterion
Type Match Support, which enables the kernel to match on the specified Criterion Type. Of these, Connection State Match
Support is particularly important, because it allows the system to perform stateful packet inspection, a useful form of firewall
operation discussed in
and LOG Target Support options are also very important, as are each of their
suboptions. Enable all of these features if you want to use a computer as an IP
masquerading router or firewall. You can omit Full NAT for a standalone
workstation or server.
ipchains (2.2-Style) Support If you have an older firewall
script that's based on the ipchains
utility used by the 2.2.
x kernels, you can
activate support for this utility as long as you don't compile IP Tables Support
directly into the kernel. (The ipchains
and iptables tools are mutually
incompatible methods of doing largely the same things, but iptables is more advanced.) If you're
creating a firewall from scratch, you can safely omit ipchains support.
ipfwadm (2.0-Style) Support The 2.0.
x kernels used a firewall tool called ipfwadm . If you have an ipfwadm -based firewall script, you can use
it by compiling this feature, which is incompatible with both the iptables and ipchains support. Unless you have such a script and lack
the inclination to modify it to use iptables ,
you can safely omit this option.
Between the 2.0.
x and 2.4.
x kernels, Linux's network filtering options have
become more sophisticated. The 2.4.
x kernel
includes many optional features, and it's important that you activate all those
you'll need for the type of firewall you intend to implement. When in doubt
about a specific feature in the IP: Netfilter Configuration menu, I recommend
you activate it. This will increase the kernel's size slightly, but it will
also provide you with greater flexibility in designing firewall rules.
WARNING
align=left border=0> You may think that you don't need to implement firewall
rules on a Linux computer, particularly if it resides on a network behind a
dedicated firewall. Unfortunately, even many allegedly protected networks
have security flaws, so it's best to err on the side of caution. To that end,
implementing simple firewalls on individual Linux computers is often a good
idea.
TCP/IP Routing Options
A router (also referred to as
a gateway ) is a computer that transfers data
between two or more networks. For instance, a department at a large company or
university is likely to have a router to link its own subnetwork with the
larger network that belongs to the company or university as a whole. The
company or university will then have a router to link all of its computers to
the Internet. This topic is important enough that
devoted to the subject. For now, know that the Linux kernel includes several
options that can influence its router operation. These are clustered as
suboptions of IP: Advanced Router.
of these options in more detail.
IPv6
Support Options
The Internet is built on TCP/IP protocols, and particularly on
version 4 of the IP protocols ( IPv4 ). Unfortunately,
IPv4 is showing its age in many ways. For instance, it supports IP addresses
that are four bytes (32 bits) in length, meaning that there is a theoretical
maximum of 232, or 4,294,967,296, addresses. Because of
inefficiencies in the way addresses are assigned, the number of Internet
addresses is actually much lower than this. Consequently, the Internet is
running out of addresses. IPv4 also has security limitations that allow
miscreants to seriously disrupt Internet operation. These problems are not
severe in 2002, but they're likely to become critical well before decade's end.
For these reasons, an upgrade to IPv4, known as IPv6, is under development. Among other things, IPv6
uses a 128-bit IP address for a theoretical maximum of 2128, or 3.4 x
1038 addressesenough for 2.2 x 1018 addresses per square
millimeter of land surface on the Earth. IPv6 also includes better hooks for
certain types of security systems than does IPv4. In 2002, few networks allow
the use of IPv6, but if yours is one, or if you want to experiment with IPv6 on
a private internal network, you can activate experimental Linux IPv6 support
via the IPv6 Protocol (Experimental) option in the Networking Options menu.
Once you do this, another option or two may become available, including an
entire submenu entitled IPv6: Netfilter Configuration. This submenu includes a
subset of options similar to those described earlier, in "
towards IPv6 rather than IPv4.
NOTE
align=left border=0> In order to activate IPv6 support, you must select Yes for
the Prompt for Development and/or Incomplete Code/Drivers option in the
kernel's Code Maturity Level Options menu. This is true of other
"experimental" drivers as well. Eventually, IPv6 will become
mainstream and nonexperimental. Like other experimental features, you should
treat IPv6 support with some caution.
QoS Options
Suppose your Linux system is a router for a busy domain, or is
a major server that processes a lot of traffic. In situations like this, it's not
uncommon for Linux to find that it has more packets to process than it can send
over its network interfaces. Thus, Linux needs some system for scheduling the
transmission of outgoing packets. Ordinarily, Linux uses a first-in/first-out
(FIFO) strategy, in which each outgoing packet waits in line behind all the
others that have already been queued. In some situations, however, you might
not want to use this system. You might want to favor certain types of packets,
such as those delivered to certain networks or those that involve certain
protocols. For instance, you might want to favor packets that carry real-time
data, such as Internet telephony protocols. Adjusting packet priorities is the
job of the quality of service (QoS) options.
These options are all available from the QoS and/or Fair Queueing menu off of
the Networking Options menu.
In order to implement a QoS system, you must select the QoS
and/or Fair Queueing option in the menu of the same name. This action enables
many of the options on this menu. A few others rely upon your selection of one
or more other specific options. The most basic features are enabled by the
various packet scheduler and queue options, such as CBQ Packet Scheduler and
SFQ Queue. These options allow the kernel to schedule packets in more complex
ways than the default FIFO. The QoS Support and Packet Classifier API options,
as well as their individual suboptions, enable the use of Differentiated
Services and the Resource Reservation Protocol (RSVP). These both allow routers
to communicate QoS priorities to other routers. If all the routers between two
sites implement compatible QoS protocols, the end result can be greatly
improved performance for time-critical protocols, at the expense of less
time-critical protocols.
Most nonrouter systems don't need any QoS options. If you're
configuring a Linux computer as a router, thoughparticularly a heavily used
routeryou may want to activate these options. If you activate one, it may make
sense to activate them all, because without all options activated, the tools
you use to specify QoS criteria won't be as flexible. For instance, if you omit
the U32 Classifier option, you won't be able to prioritize traffic according to
the destination address.
In practice, using QoS features requires the use of advanced
routing tools, such as ip and tc .
can be extremely complex. The iproute2
+ tc Notes (
and Differentiated Services on Linux (target="_blank">http://diffserv.sourceforge.net )
Web sites contain additional documentation on these tools.
High-Level
Protocol Support
The Linux kernel includes explicit support for several
high-level network protocols. Placing this support in the kernel has two
principal advantages. First, this code can run more quickly than can an
ordinary user-level program. Second, placement in the kernel permits a tighter
integration of the features of that protocol with the rest of the system. For
instance, kernel-level support for network file-sharing protocols allows Linux
to mount remote file exports as if they were local filesystems. The 2.4.
x kernel includes support for three particularly
important high-level protocols: HTTP, NFS, and SMB/CIFS.
NOTE
align=left border=0> This list of protocols is not comprehensive. Several others (particularly
for network file-sharing protocols) are supported.
HTTP Acceleration
The Hypertext Transfer Protocol (HTTP) is at the core of the
World Wide Web. Beginning with the 2.4.
x
kernels, Linux includes what is effectively a simple HTTP server in the kernel.
This server is included with the Kernel HTTPd Acceleration option and
configured and activated by writing specific values to pseudofiles in the /proc/sys/net/khttpd directory, as
described in Chapter 20 , Running Web Servers.
The kernel's HTTP server was created because the work of
serving static Web pages (that is, those whose contents are fixed, as opposed
to dynamic pages whose contents may be customized for individual users) is
essentially just one of copying files from disk to a network address. This
operation can be performed much more efficiently in the kernel than in a
user-space program. For dynamic content and even some types of static content,
the kernel's server falls back on a user-space Web server such as Apache. No
special Apache configuration is required; Apache simply doesn't see requests
for static Web pages.
NFS
Options
Sun developed the Network Filesystem (NFS) as a way to share
files among several computers as if those files were local. Linux includes
support for NFS, as detailed in
remote NFS exports, you must include NFS support in the kernel. Most Linux NFS
servers also rely on support in the kernel. Both client and server NFS options
reside in the Network File Systems submenu off of the File Systems menu, not in
the Networking Options menu. Specifically, options you might want to activate
include the following:
NFS File System Support This
option enables basic NFS client support (that is, the ability to mount remote
NFS exports as if they were local disk partitions). Enable it if you want to
mount NFS directories exported by other computers.
Provide NFSv3 Client Support
NFS has undergone various revisions, the latest of which is version 3 (NFSv3). This
support must currently be explicitly enabled, because it's not as reliable as
is support for older versions of NFS, as activated by NFS File System Support.
The NFSv3 support relies on the basic NFS support.
Root File System on NFS If you
select IP: Kernel Level Autoconfiguration in the Networking Options menu, you
can select this option, which lets Linux mount its root filesystem from an NFS
export. You'll normally only use this option on workstations that lack hard
disks.
NFS Server Support To have
Linux function as an NFS server (that is, to make some or all of its
directories available to other computers), you need to run an NFS server. This
option provides acceleration features for NFS servers that are written to take
advantage of it. This option is not strictly required to run an NFS server, but
it's generally a good idea to include it, since most Linux NFS servers are
written to expect this support.
Provide NFSv3 Server Support
If you want to run a kernel-aware NFS server for clients that understand NFSv3,
activate this option. As with NFSv3 client support, this option relies upon the
matching generic NFS support.
NOTE
align=left border=0> NFS is used mainly by Unix and Linux systems. File sharing
between other platforms is usually handled by other tools, one of which is
discussed next.
SMB/CIFS Options
NFS isn't the only network file-sharing protocol available.
Macintoshes often use AppleTalk, for instance, and Novell's IPX/SPX is a
popular protocol stack with associated file-sharing tools. Perhaps the most
common file-sharing tool for Linux, aside from NFS, is Samba, which implements
the Server Message Block (SMB) protocol, which is also known as the Common
Internet Filesystem (CIFS).
covers Samba configuration and use.
Samba provides everything needed for Linux to function as an
SMB/CIFS server, so there's no kernel configuration required for this function.
If you want Linux to be able to mount SMB/CIFS shares, though, you must
activate the SMB File System Support option, which is roughly equivalent to NFS
File System Support for NFS. Two suboptions (Use a Default NLS and Default
Remote NLS Option) let Linux perform filename translations based on National
Language Support (NLS) character sets. These options may be important if you
use non-Roman alphabets like Cyrillic, or even extensions to the Roman alphabet
as used by English, like characters that contain umlauts.
NOTE
align=left border=0> It's possible to use Linux as an SMB/CIFS client using the smbclient program, even if you don't
activate Linux's SMB/CIFS kernel options. smbclient
doesn't actually mount an SMB/CIFS share, though; it gives you access to the
share using an FTP-like interface.
Alternative Network Stack
Options
Although TCP/IP is the most popular set of
network protocols for Linux, and the one upon which the Internet is built, it's
not the only choice of network protocol stack. The Networking Options menu
includes several others. Most of the options in this menu are actually
suboptions of TCP/IP Networking. If you scroll past these, you'll see the
alternatives to TCP/IP:
Asynchronous Transfer
Mode (ATM) This is an experimental set of
options to support ATM hardware and protocols. ATM is really at least as much
of a hardware definition as a network stack, but in the 2.4.
x kernels, it's enabled in the Networking Options
menu, along with other protocol stacks.
The IPX Protocol Novell's Internetwork Packet Exchange (IPX) is a protocol stack
that's used on many local networks, particularly those running the Netware
server OS. To use this stack, you'll need additional software, such as Mars_nwe
(documented at
target="_blank">http://www.redhat.com/support/docs/tips/Netware/netwarel ). The NCP File System Support option in the Network File Systems
submenu of the File Systems menu will let you mount Netware volumes, much as
the equivalent NFS and SMB/CIFS options let you mount NFS exports or Windows
file shares.
AppleTalk Protocol
Support Apple developed the AppleTalk protocol
stack to enable file and printer sharing on its Macintosh computers. Linux
supports AppleTalk through a combination of the kernel and the Netatalk package
( http://netatalk.sourceforge.net/ ).
DECnet Support Digital Equipment Corporation (DEC; since bought out by Compaq)
developed a network technology known as DECnet for its computers. Linux
includes support for DECnet, but you must have a package of programs to use
this protocol stack. Check target="_blank">http://linux-decnet.sourceforge.net
for more information.
Linux also includes support for a handful of
more obscure network protocols, such as Acorn's Econet. On most systems, TCP/IP
and possibly one or two other protocols will be quite sufficient. Because of
the success of the Internet, vendors who had previously used proprietary
protocol stacks have been converting their tools to use TCP/IP. For instance,
although Apple has long used AppleTalk, its file-sharing tools now work both
over plain AppleTalk and a TCP/IP-based variant.
NOTE
align=left border=0> The standard Linux kernel lacks support for
one common network stack, NetBEUI. This stack was the default for Windows
file sharing via SMB/CIFS in the past, but SMB/CIFS today works equally well
over TCP/IP.
Alternative Network Stacks, covers network stacks and their use in more detail.
