LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

long running updates and minor corrections. 

Began work on traceroute again....
This commit is contained in:
mabrown 2003-04-03 23:09:00 +00:00
parent cc39edebde
commit 2cd872fa9b
19 changed files with 850 additions and 346 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
LDP/guide/docbook/linux-ip/ACKNOWLEDGEMENTS
View File

@ -65,3 +65,9 @@
- Giovanni provided a PMTU example, which is available in the
document source of the routing chapter. I'll incorporate it when
I'm working on that content.
2003-02-28: Gilles Douillet "Gilles, Douillet" <gilles@uniskill.com>
- Gilles noted a typographical error in a NAT example, and has
offered to contribute to the project with some examples of SNAT
and pools of addresses.

12
LDP/guide/docbook/linux-ip/ROADMAP
View File

@ -27,13 +27,23 @@ Minor items and required experiments:
- test single and multiple dummy interfaces
- link layer broadcast; use ip link set broadcast to change the ethernet
broadcast address on several hosts and see what happens
- add references to MPLS; diffserv? Traffic Control?
- add section on VRRP
- add sysctl brief HOWTO and point to ipsysctl-tutorial
- add TCP/IP <--> OSI networking model pointers (layer 2, layer 3, etc.)
- add mailing list references
- add ethtool and mii-diag to mii-tool subsection
Major work:
- revamp the entire "cookbook" sections -- pitch? rewrite?
- add index
- add glossary
- add command synopses for all commands
- edit the tools appendices for accuracy, grammar, spelling
- add bridging 802.11; gatewaying 802.11
- add a bibliography for books like Stevens, etc.
- consider introduction to traffic control with pointer to LARTC
- consider chapter introducing traffic control with pointer to LARTC
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #
# #

2
LDP/guide/docbook/linux-ip/advanced-ip.xml
View File

@ -171,7 +171,7 @@
<link linkend="ether-arp-proxy-kernel">above</link>.
Consider familiarizing yourself with the methods of suppressing
and controling ARP through
<ulink url="http://www.linuxvirtualserver.org/~julian/">Julian
<ulink url="http://www.ssi.bg/~ja/">Julian
Anastasov's work</ulink>.
</para>
</section>

2
LDP/guide/docbook/linux-ip/advanced-routing.xml
View File

@ -359,7 +359,7 @@
patches (at least) which can help the linux routing device provide
Internet service to the internal network when one of the links is
down. See <ulink
url="http://www.linuxvirtualserver.org/~julian/#routes">here for
url="http://www.ssi.bg/~ja/#routes">here for
Julian's route work</ulink>.
</para>
<para>

3
LDP/guide/docbook/linux-ip/bridging.xml
View File

@ -49,8 +49,9 @@
</para>
</section>
<section id="bridging-tc">
<title>Using linux as a bridge</title>
<title>Traffic Control with a Bridge</title>
<para>
Yes, Virginia, it can be done.
</para>
<para>
</para>

91
LDP/guide/docbook/linux-ip/ether.xml
View File

@ -1,7 +1,7 @@
<!-- $Id$ -->
<chapter id="ch-ether">
<title>Ethernet: Address Resolution Protocol and Bridging</title>
<title>Ethernet</title>
<para>
The most common link layer network in use today is ethernet. Although
there are several common speeds of ethernet devices, they function
@ -188,6 +188,79 @@
hosts. Examining the ARP cache on each of these hosts would reveal
entries on each host for the other host's link layer address.
</para>
<para>
An even rarer usage of ARP is gratuitous ARP, where a machine
announces its ownership of an IP address on a media segment. The
<link linkend="tools-arping"><command>arping</command></link> utility
can generate these gratuitous ARP frames. Linux kernels will
disregard gratuitous ARP frames.
</para>
<example id="ex-ether-arp-gratuitous">
<title>Gratuitous ARP reply frames</title>
<programlisting>
<prompt>[root@tristan]# </prompt><userinput>arping -q -c 3 -A -I eth0 192.168.99.35</userinput>
<prompt>[root@masq-gw]# </prompt><userinput>tcpdump -c 3 -nni eth2 arp</userinput>
<computeroutput>tcpdump: listening on eth2
06:02:50.626330 arp reply 192.168.99.35 is-at 0:80:c8:f8:4a:51 (0:80:c8:f8:4a:51)
06:02:51.622727 arp reply 192.168.99.35 is-at 0:80:c8:f8:4a:51 (0:80:c8:f8:4a:51)
06:02:52.620954 arp reply 192.168.99.35 is-at 0:80:c8:f8:4a:51 (0:80:c8:f8:4a:51)</computeroutput>
<prompt>[root@masq-gw]# </prompt><userinput>ip neigh show</userinput>
</programlisting>
</example>
<para>
The frames generated in
<xref linkend="ex-ether-arp-gratuitous"/> are ARP replies to a
question never asked.
Unsolicited ARP request frames, on the other hand, are broadcast
ARP requests initiated by a host owning an IP address.
</para>
<example id="ex-ether-arp-unsolicited">
<title>Unsolicited ARP request frames</title>
<programlisting>
<prompt>[root@tristan]# </prompt><userinput>arping -q -c 3 -U -I eth0 192.168.99.35</userinput>
<prompt>[root@masq-gw]# </prompt><userinput>tcpdump -c 3 -nni eth2 arp</userinput>
<computeroutput>tcpdump: listening on eth2
06:28:23.172068 arp who-has 192.168.99.35 (ff:ff:ff:ff:ff:ff) tell 192.168.99.35
06:28:24.167290 arp who-has 192.168.99.35 (ff:ff:ff:ff:ff:ff) tell 192.168.99.35
06:28:25.167250 arp who-has 192.168.99.35 (ff:ff:ff:ff:ff:ff) tell 192.168.99.35</computeroutput>
<prompt>[root@masq-gw]# </prompt><userinput>ip neigh show</userinput>
</programlisting>
</example>
<para>
These two uses of <command>arping</command> can help diagnose ethernet
and ARP problems--particularly hosts replying for addresses which do
not belong to them.
</para>
<para>
To avoid IP address collisions on dynamic networks (where hosts are
turning on and off, connecting and disconnecting and otherwise
changing IP addresses) duplicate address detection becomes important.
Fortunately, <command>arping</command> provides this functionality as
well. A startup script could include the <command>arping</command>
utility in duplicate address detection mode to select between
IP addresses or methods of acquiring an IP address.
</para>
<example id="ex-ether-arp-dad">
<title>Duplicate Address Detection with ARP</title>
<programlisting>
<prompt>[root@tristan]# </prompt><userinput>arping -D -I eth0 192.168.99.147; echo $?</userinput>
<computeroutput>ARPING 192.168.99.47 from 0.0.0.0 eth0
Unicast reply from 192.168.99.47 [00:80:C8:E8:1E:FC] for 192.168.99.47 [00:80:C8:E8:1E:FC] 0.702ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
1</computeroutput>
<prompt>[root@tristan]# </prompt><userinput>tcpdump -eqtnni eth2 arp</userinput>
<computeroutput>tcpdump: listening on eth2
0:80:c8:f8:4a:51 ff:ff:ff:ff:ff:ff 60: arp who-has 192.168.99.147 (ff:ff:ff:ff:ff:ff) tell 0.0.0.0
0:80:c8:e8:1e:fc 0:80:c8:f8:4a:51 42: arp reply 192.168.99.147 is-at 0:80:c8:e8:1e:fc (0:80:c8:e8:1e:fc)</computeroutput>
<prompt>[root@masq-gw]# </prompt><userinput>ip neigh show</userinput>
</programlisting>
</example>
<para>
Address Resolution Protocol, which provides a method to connect
physical network addresses with logical network addresses
is a key element to the deployment of IP on ethernet networks.
</para>
</section>
<section id="ether-arp-cache">
<title>The ARP cache</title>
@ -377,7 +450,7 @@
</calloutlist>
</example>
<para>
The remaining neighbor table flags are visible when inital ARP
The remaining neighbor table flags are visible when initial ARP
requests are made. If no ARP cache entry exists for a requested
destination IP, the kernel will generate
<constant>mcast_solicit</constant> ARP requests until receiving an
@ -397,7 +470,7 @@
For machines not using a static mapping for link layer and IP
addresses, ARP provides on demand mappings. The remainder of this
section will cover the methods available under linux to control the
address resolution protocl.
address resolution protocol.
</para>
</section>
<section id="ether-arp-suppression">
@ -484,9 +557,9 @@ Received 4 response(s)</computeroutput>
process (possibly documented
<link linkend="ether-arp-filtering">here</link> at a later date)
include Julian Anastasov's
<ulink url="http://www.linuxvirtualserver.org/~julian/#iparp"><command>ip
<ulink url="http://www.ssi.bg/~ja/#iparp"><command>ip
arp</command></ulink> tool and his
<ulink url="http://www.linuxvirtualserver.org/~julian/#noarp">noarp
<ulink url="http://www.ssi.bg/~ja/#noarp">noarp
route flag</ulink>. While these tools were conceived in the course of
the
<ulink url="http://www.linuxvirtualserver.org/">Linux Virtual
@ -567,7 +640,7 @@ Received 3 response(s)</computeroutput>
<title>ARP flux prevention with <constant>hidden</constant></title>
<para>
The ARP flux problem can also be combatted with a
<ulink url="http://www.linuxvirtualserver.org/~julian/#hidden">kernel
<ulink url="http://www.ssi.bg/~ja/#hidden">kernel
patch</ulink> by Julian Anastasov, which was incorporated into the
2.2.14+ kernel series, but never into the 2.4+ kernel series. In sum,
this means that the functionality may not be available in all
@ -637,7 +710,7 @@ Received 2 response(s)</computeroutput>
</para>
<para>
For a brief description of the use of medium_id, see
<ulink url="http://www.linuxvirtualserver.org/~julian/#medium_id">Julian's
<ulink url="http://www.ssi.bg/~ja/#medium_id">Julian's
remarks</ulink>.
</para>
<anchor id="ether-arp-proxy-kernel"/>
@ -670,10 +743,10 @@ ALTER := [ src IP ] [ llsrc LLADDR ] [ lldst LLADDR ]</computeroutput>
</para>
<para>
The
<ulink url="http://www.linuxvirtualserver.org/~julian/#iparp"><command>ip
<ulink url="http://www.ssi.bg/~ja/#iparp"><command>ip
arp</command></ulink> tool.
Patches and code for the
<ulink url="http://www.linuxvirtualserver.org/~julian/#noarp">noarp
<ulink url="http://www.ssi.bg/~ja/#noarp">noarp
route flag</ulink>.
</para>
<para>

6
LDP/guide/docbook/linux-ip/index.html
View File

@ -47,6 +47,10 @@ complete enough to merit inclusion in the TLDP repository.
</table>
<p>
<ul>
<li>2003-03-15: added an
<a href="articles/htb-and-tcng.html">article on htb and tcng</a></li>
<li>2003-03-10: added some notes on using
<a href="traffic-control/">traffic control with tcng</a></li>
<li>2003-02-10: minor cleanup to index.html
<!-- If you are reading this, you have found an easter egg!
You can visit the current development copy at:
@ -60,7 +64,7 @@ complete enough to merit inclusion in the TLDP repository.
link breakages from the former home at http://plorf.net/linux-ip/
and I will try to fix them. The DocBook markup has been cleaned up,
and is now correct XML, parsed with xsltproc to produce the HTML
output.
output.</li>
</ul>
</p>
<p>

5
LDP/guide/docbook/linux-ip/intro.xml
View File

@ -232,6 +232,11 @@
giovanni, <emphasis>2003-02-06</emphasis>
</para>
</listitem>
<listitem>
<para>
Gilles Douillet, <emphasis>2003-02-28</emphasis>
</para>
</listitem>
</itemizedlist>
<para>
Please feel free to point out any irregularities, factual errors,

11
LDP/guide/docbook/linux-ip/links.xml
View File

@ -62,6 +62,15 @@
and Internet documentation.
</para>
<itemizedlist>
<listitem>
<para>
One of the key reference materials for any IP networking shop is
the seminal
<ulink url="http://www.kohala.com/start/">work by the late W.
Richard Stevens</ulink>. Three volumes catalog the architecture of
IP networking and higher layer protocols.
</para>
</listitem>
<listitem>
<para>
Here is a good introduction to
@ -238,7 +247,7 @@
&iproute2; and some documentation with
for the linux virtual server (LVS) in addition to a great deal of
code for LVS. See his <ulink
url="http://www.linuxvirtualserver.org/~julian/">main
url="http://www.ssi.bg/~ja/">main
site</ulink> for both patches and documentation.
</para>
</listitem>

45
LDP/guide/docbook/linux-ip/linux-ip.css
View File

@ -1,22 +1,27 @@
a:link { color: #009900 ; text-decoration: none ; }
a:visited { color: #009900 ; text-decoration: none ; }
a:hover { color: #009900 ; text-decoration: underline ; }
a:active { color: #009900 ; text-decoration: underline ; }
a:link { color: #009 ; text-decoration: none ; }
a:visited { color: #009 ; text-decoration: none ; }
a:hover { color: #009 ; text-decoration: underline ; }
a:active { color: #009 ; text-decoration: underline ; }
a.local:link { color: #009900 ; text-decoration: none ; }
a.local:visited { color: #009900 ; text-decoration: none ; }
a.local:hover { color: #009900 ; text-decoration: underline ; }
a.local:active { color: #009900 ; text-decoration: underline ; }
/*
a.local:link { color: #0f0 ; text-decoration: none ; }
a.local:visited { color: #0f0 ; text-decoration: none ; }
a.local:hover { color: #0f0 ; text-decoration: underline ; }
a.local:active { color: #0f0 ; text-decoration: underline ; }
*/
a.nonlocal:link { color: #0000ff ; text-decoration: none ; }
a.nonlocal:visited { color: #0000ff ; text-decoration: none ; }
a.nonlocal:hover { color: #0000ff ; text-decoration: underline ; }
a.nonlocal:active { color: #0000ff ; text-decoration: underline ; }
a.nonlocal:link { color: #00f ; text-decoration: none ; }
a.nonlocal:visited { color: #00f ; text-decoration: none ; }
a.nonlocal:hover { color: #00f ; text-decoration: underline ; }
a.nonlocal:active { color: #00f ; text-decoration: underline ; }
BODY {
color : black ;
/* font-size : 1.0em ; */
font-family : "New Century Schoolbook", Times, serif ;
color : black ;
/* background-color : #dae5f3 ; */ /* light blue */
/* background-color : #ddeeff ; */ /* pale blue */
background-color : #fff ;
/* font-size : 1.0em ; */
font-family : "New Century Schoolbook", Times, serif ;
}
/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
@ -29,6 +34,16 @@ div.variablelist {
margin : 1em 5% 1em 5% ;
}
/*
.calloutlist table {
background-color : #dff ;
}
.example table {
background-color : #9cc ;
}
*/
.variablelist .term {
font-weight : bold ;
}

21
LDP/guide/docbook/linux-ip/linux-ip.xml
View File

@ -8,11 +8,13 @@
<!-- publishing and other meta-information -->
<!ENTITY versionfile SYSTEM "VERSION" >
<!ENTITY version "&versionfile;" >
<!ENTITY pubdate "2003-02-19" >
<!ENTITY bookinfo SYSTEM "bookinfo.xml" >
<!ENTITY revision SYSTEM "revision.xml" >
<!ENTITY version "0.4.1" >
<!ENTITY pubdate "2003-02-19" >
<!ENTITY entities SYSTEM "entities.xml" >
<!-- some entitiies used in the code....should probably be shoved
into another file someplace else -->
@ -48,6 +50,7 @@
<!ENTITY intro SYSTEM "intro.xml" >
<!ENTITY basic SYSTEM "basic.xml" >
<!ENTITY devices SYSTEM "devices.xml" >
<!ENTITY ether SYSTEM "ether.xml" >
<!ENTITY bridging SYSTEM "bridging.xml" >
<!ENTITY routing SYSTEM "routing.xml" >
@ -71,27 +74,18 @@
<!ENTITY scripts SYSTEM "scripts.xml" >
<!-- Code snippets and examples -->
<!ENTITY sc-static-nat SYSTEM "scripts/static-nat" >
<!ENTITY sc-nat SYSTEM "scripts/nat" >
<!ENTITY sc-proxy-arp SYSTEM "scripts/proxy-arp" >
<!ENTITY sc-proxy-arp-conf SYSTEM "scripts/proxy-arp.conf" >
<!-- GNU Free Documentation License; -->
<!ENTITY gfdl SYSTEM "fdl.xml" >
]>
<!--
removed PAT chapter 2003-02-08; added content to NAT/DNAT chapter
<!ENTITY pat SYSTEM "pat.xml" >
-->
<!-- &pat; --> <!-- chapter on PAT/DNAT -->
<!--
DocBook Preamble and Entity Declaration done
-->
@ -105,6 +99,7 @@
<title>Concepts</title>
&basic; <!-- chapter on basic IP connectivity -->
&devices; <!-- chapter on the interfaces and devices -->
&ether; <!-- chapter on ARP, VLANs and bonding -->
&bridging; <!-- chapter on bridging -->
&routing; <!-- chapter on IP routing (static) -->

482
LDP/guide/docbook/linux-ip/nat.xml
View File

@ -19,8 +19,9 @@
via the <command>iptables</command> utility.
The experienced network administrator is probably puzzling about absent
references to source NAT (SNAT) and masquerading. These prominent and
more prevalent special cases of NAT are covered separately in
<xref linkend="ch-snat"/>.
prevalent uses of NAT are covered in
<xref linkend="ch-snat"/>, although many concepts involved in the special
purpose SNAT and masquerading will be introduced in this chapter.
</para>
<para>
Network address translation is known by a number of names in the
@ -39,7 +40,7 @@
<ulink url="http://www.suse.de/~mha/linux-ip-nat/diplom/nat.html">here</ulink>.
</para>
<section id="nat-overview">
<title>Rationale for NAT; Introduction to Inbound NAT</title>
<title>Rationale for and Introduction to NAT</title>
<para>
Network address translation (NAT) is a technique of transparently mapping
an IP address or range to another IP address or range. Any routing
@ -47,15 +48,25 @@
the packet. Network designers must however take one key element under
consideration when laying out a network with NAT in mind. The router(s)
performing NAT must have an opportunity to rewrite the packet upon entry
to the network and upon exit from the network.
to the network and upon exit from the network
<footnote>
<para>
If using
<link linkend="nat-stateless">stateless NAT</link>, the inbound and
outbound translations can occur on more than one device, provided
that all of the devices are performing the same translation.
</para>
</footnote>.
</para>
<para>
Because network address translation manipulates the addressing of a
packet, the NAT transformation becomes a passive but
critical part of the conversation
between hosts exchanging packets. NAT is by necessity transparent to
the application layer endpoints and operates in the general case on
any type of IP packet.
critical part of the conversation between hosts exchanging packets.
NAT is by necessity transparent to the application layer endpoints
and operates on any type of IP packet. There are some application and
even network layer protocols which will break as a result of this
rewriting. Consult
<xref linkend="nat-break"/> for a discussion of these cases.
</para>
<para>
Here are a few common reasons to consider NAT along with potential
@ -119,9 +130,9 @@
</itemizedlist>
<para>
These are the commonest reasons to consider and implement NAT. Other
niche applications of NAT, notably as part of a load balancing solution,
niche applications of NAT, notably as part of load balancing systems,
exist although this chapter will concentrate on the use of NAT
to hide networks or isolate networks from others. It will also cover
to hide, isolate or renumber networks. It will also cover
inbound connections,
leaving the discussion of many-to-one NAT, SNAT and masquerading for
<xref linkend="ch-snat"/>.
@ -129,11 +140,10 @@
<para>
One motivator for deploying NAT in a network is the benefit of
virtualizing the network. By isolating services provided in one network
from changes in other networks, the effects of those changes on the
service network may be minimal. The disadvantage of
from changes in other networks, the effects of such changes can be
minimized. The disadvantage of
virtualizing the network in this way is the increased reliance on the
NAT device. In addition to routing packets, the router also
transforms and manipulates packets ensuring its self-perpetuation.
NAT device.
</para>
<para>
Providing inbound services via NAT can be accomplished in several
@ -165,18 +175,20 @@
<command>ipmasqadm</command>, <command>ipnatadm</command> and
<command>ipportfw</command> across the Internet in older documentation,
these tools have been superseded in functionality and widespread
deployment by netfilter.
deployment by the netfilter engine and its userspace partner,
<command>iptables</command>.
</para>
<para>
The user interface to the netfilter engine provides a more flexible
language for selection of packets to be transformed. Additionally, any
NAT services provided by the netfilter engine come with the labor saving
and resource consuming connection tracking mechanism.
The netfilter engine provides a more flexible
language for selection of packets to be transformed than that provided
by the &iproute2; suite and kernel routing functionality.
Additionally, any
NAT services provided by the netfilter engine come with the labor-saving
and resource-consuming connection tracking mechanism.
<link linkend="nat-dnat">DNAT</link> translates the address on an
inbound packet and creates an entry in the connection tracking state
table. For even modest machines, the connection tracking resource
consumption should not be problematic and obviates the need for
synchronization of two commands as required by stateless NAT.
consumption should not be problematic.
</para>
<para>
Netfilter DNAT allows the user to select packets based on
@ -211,8 +223,9 @@
<listitem>
<para>
The IP address to which packets are addressed. This is the
address before the device performing NAT manipulates it.
This, is frequently also described as the public IP, although
address on the packet before the device performing NAT
manipulates it.
This is frequently also described as the public IP, although
any given application of NAT knows no distinction between public
and private address ranges.
</para>
@ -245,31 +258,56 @@
</varlistentry>
</variablelist>
<para>
The above terms will be used below and in general in discussion of NAT
although other terms are not uncommon.
The above terms will be used below and in general discussions of NAT.
</para>
</section>
<section id="nat-break">
<title>Application Layer Protocols with Embedded Network Information</title>
<para>
Some applications, FTP, H323, IRC?, use (check conntrack helpers) use
embedded network information inside the application layer protocol.
Introduce such problems, and how NAT confounds these protocols.
</para>
<para>
</para>
<para>
</para>
<para>
</para>
</section>
<section id="nat-stateless">
<title>Stateless NAT</title>
<title>Stateless NAT with &iproute2;</title>
<para>
Stateless NAT, occasionally maligned as dumb NAT, is the simplest form of
Stateless NAT, occasionally maligned as dumb NAT
<footnote>
<para>
In the kernel code tree, the stateless NAT, &iproute2; NAT can be
located in the file <filename>net/ipv4/ip_nat_dumb.c</filename>.
Even in the kernel, it has this reputation.
</para>
</footnote>,
is the simplest form of
NAT. It involves rewriting addresses passing through a
routing device: outbound packets will undergo source address rewriting
and inbound packets will undergo destination address rewriting. The
&iproute2; suite of tools provides the two commands
required to configure the kernel to perform network address translation
on packets passing through the machine. This section will cover only
routing device:
inbound packets will undergo destination address rewriting and
outbound packets will undergo source address rewriting.
The &iproute2; suite of tools provides the two commands
required to configure the kernel to perform stateless NAT.
This section will cover only
stateless NAT, which can only be accomplished under linux with the
&iproute2; tools, although it can be
<link linkend="ex-nat-dnat-full">simulated with netfilter</link>.
</para>
<anchor id="nat-stateless-arp"/>
<para>
Creating an &iproute2; NAT mapping has the side
effect of causing the kernel to answer ARP requests for the NAT IP.
For more detail on ARP filtering, suppression and conditional ARP, see
<xref linkend="ch-ether"/>. This can be considered alternatively a
benefit or a misfeature of the kernel support for NAT in the local
routing table. Conversely,
<xref linkend="ch-ether"/>. This can be considered, alternatively, a
benefit or a misfeature of the kernel support for NAT.
The <constant>nat</constant> entry in the local routing table causes
the kernel to reply for ARP requests to the NAT IP.
Conversely,
<link linkend="nat-dnat">netfilter DNAT</link> makes no ARP entry or
provision for neighbor advertisement.
</para>
@ -318,7 +356,7 @@
<computeroutput>19:30:17.824853 eth1 &lt; 64.70.12.210.35131 &gt; 205.254.211.17.25: tcp 0 (DF)
19:30:17.824976 eth0 &gt; 64.70.12.210.35131 &gt; 192.168.100.17.25: tcp 0 (DF)
19:30:17.825400 eth0 &lt; 192.168.100.17.25 &gt; 64.70.12.210.35131: tcp 0 (DF)
19:30:17.825568 eth1 &lt; 205.254.211.17.25 &gt; 64.70.12.210.35131: tcp 0 (DF)</computeroutput>
19:30:17.825568 eth1 &gt; 205.254.211.17.25 &gt; 64.70.12.210.35131: tcp 0 (DF)</computeroutput>
</programlisting>
</example>
<para>
@ -544,137 +582,141 @@
Naturally, you may not wish to create these rules manually every time
you want to use NAT on every device. A standard
<link linkend="ex-sc-nat">SysV initialization script</link> and
<link linkend="ex-sc-static-nat">configuration file</link> can ease the
burden of managing a number of NAT IPs on your system.
<link linkend="ex-sc-static-nat">configuration file</link>
can ease the burden of managing a number of NAT IPs on your system.
</para>
</section>
</section>
<section id="nat-stateless-pf-interaction">
<title>Using a packet filter with &iproute2; NAT</title>
<para>
Because NAT rewrites the packet as it passes through your linux box,
packet filtering can become complex. With attentiveness to the
addressing of the packet at each stage
in its journey through the packet filtering code, you can ease the
burden of writing a packet filter. Because
<command>netfilter</command> has a built-in NAT engine, I'll focus on
the requirements to get NAT'd packets through the
<command>ipchains</command> packet filter.
</para>
<para>
All of the below requirements can be deduced from a thorough
understanding of NAT and the <ulink
url="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO-4.html#ss4.1"><command>ipchains</command>
packet path</ulink> as illustrated in the <ulink
url="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html"><command>ipchains</command>
HOWTO</ulink>. Keep in mind when viewing the ASCII diagram that the NAT
will always occur in the routing stage in this diagram, so you'll need
to account for this when writing your packet filter rules.
</para>
<para>
Let's examine the IP addresses on a packet traversing each of the input,
forward and output chains in an <command>ipchains</command>
installation as it is operated upon by the &iproute2;
NAT code.
</para>
<table id="tb-nat-pf-ipchains">
<title>Filtering an &iproute2; NAT packet with
<command>ipchains</command></title>
<tgroup cols="3" align="center" colsep="1" rowsep="1">
<colspec colname="c1"/>
<colspec colname="c2"/>
<colspec colname="c3"/>
<spanspec spanname="fullspan" namest="c1" nameend="c3" align="center"/>
<thead>
<row>
<entry spanname="fullspan">Inbound to the NAT IP</entry>
</row>
<row>
<entry>Chain</entry>
<entry>Source IP</entry>
<entry>Destination IP</entry>
</row>
</thead>
<tbody>
<row>
<entry>input</entry>
<entry>64.70.12.210</entry>
<entry>205.254.211.17</entry>
</row>
<row>
<entry spanname="fullspan">Routing Stage</entry>
</row>
<row>
<entry>forward</entry>
<entry>64.70.12.210</entry>
<entry>192.168.100.17</entry>
</row>
<row>
<entry>output</entry>
<entry>64.70.12.210</entry>
<entry>192.168.100.17</entry>
</row>
</tbody>
</tgroup>
<tgroup cols="3" align="center" colsep="1" rowsep="1">
<colspec colname="c1"/>
<colspec colname="c2"/>
<colspec colname="c3"/>
<spanspec spanname="fullspan" namest="c1" nameend="c3" align="center"/>
<thead>
<row>
<entry spanname="fullspan">Outbound from the real IP</entry>
</row>
<row>
<entry>Chain</entry>
<entry>Source IP</entry>
<entry>Destination IP</entry>
</row>
</thead>
<tbody>
<row>
<entry>input</entry>
<entry>192.168.100.17</entry>
<entry>64.70.12.210</entry>
</row>
<row>
<entry spanname="fullspan">Routing Stage</entry>
</row>
<row>
<entry>forward</entry>
<entry>205.254.211.17</entry>
<entry>64.70.12.210</entry>
</row>
<row>
<entry>output</entry>
<entry>205.254.211.17</entry>
<entry>64.70.12.210</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
If you have a tight policy on your firewall, with a default deny in
every chain, you'll need to add quite a few chains to allow the NAT
packets to traverse your firewall. Let's take a look at a sensible
and defensible set
of chains to protect access to your NAT machine on a single specified
port. If we wish to apply packet filtering to the NAT we have set up in
<xref linkend="ex-nat-basic"/>, the following set of chains will restrict
access to only port 25
<footnote>
<para>
I assume here that the user has a restrictive default policy on the
firewalling device. I suggest a policy of DENY on each of the built
in <command>ipchains</command> chains.
</para>
</footnote>.
</para>
<example id="ex-nat-pf-ipchains">
<title>
NAT of public IP 205.254.211.17 to private IP 192.168.100.17
</title>
<programlisting>
</section>
<section id="nat-stateless-pf-interaction">
<title>Stateless NAT and Packet Filtering</title>
<para>
Because NAT rewrites the packet as it passes through the IP stack,
packet filtering can become complex. With attentiveness to the
addressing of the packet at each stage
in its journey through the packet filtering code, you can ease the
burden of writing a packet filter.
</para>
<para>
All of the below requirements can be deduced from an understanding of
NAT and the kernel packet traveling diagram. Consult the
<ulink url="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO-4.html#ss4.1"><command>ipchains</command>
packet path</ulink> as illustrated in the
<ulink url="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html"><command>ipchains</command>
HOWTO</ulink> to understand the packet path for kernels using
<command>ipchains</command>. Keep in mind when viewing the ASCII
diagram that stateless NAT will always occur in the routing stage. Also
consult the
<ulink url="http://docum.org/stef.coene/qos/kptd/">kernel packet
traveling diagram</ulink> for a good picture of a 2.4 kernel packet
path.
</para>
<para>
<xref linkend="tb-nat-pf-ipchains"/> identifies the IP addresses
on a packet traversing each of the input,
forward and output chains in an <command>ipchains</command>
installation.
</para>
<table id="tb-nat-pf-ipchains">
<title>Filtering an &iproute2; NAT packet with
<command>ipchains</command></title>
<tgroup cols="3" align="center" colsep="1" rowsep="1">
<colspec colname="c1"/>
<colspec colname="c2"/>
<colspec colname="c3"/>
<spanspec spanname="fullspan" namest="c1" nameend="c3" align="center"/>
<thead>
<row>
<entry spanname="fullspan">Inbound to the NAT IP</entry>
</row>
<row>
<entry>Chain</entry>
<entry>Source IP</entry>
<entry>Destination IP</entry>
</row>
</thead>
<tbody>
<row>
<entry>input</entry>
<entry>64.70.12.210</entry>
<entry>205.254.211.17</entry>
</row>
<row>
<entry spanname="fullspan">Routing Stage</entry>
</row>
<row>
<entry>forward</entry>
<entry>64.70.12.210</entry>
<entry>192.168.100.17</entry>
</row>
<row>
<entry>output</entry>
<entry>64.70.12.210</entry>
<entry>192.168.100.17</entry>
</row>
</tbody>
</tgroup>
<tgroup cols="3" align="center" colsep="1" rowsep="1">
<colspec colname="c1"/>
<colspec colname="c2"/>
<colspec colname="c3"/>
<spanspec spanname="fullspan" namest="c1" nameend="c3" align="center"/>
<thead>
<row>
<entry spanname="fullspan">Outbound from the real IP</entry>
</row>
<row>
<entry>Chain</entry>
<entry>Source IP</entry>
<entry>Destination IP</entry>
</row>
</thead>
<tbody>
<row>
<entry>input</entry>
<entry>192.168.100.17</entry>
<entry>64.70.12.210</entry>
</row>
<row>
<entry spanname="fullspan">Routing Stage</entry>
</row>
<row>
<entry>forward</entry>
<entry>205.254.211.17</entry>
<entry>64.70.12.210</entry>
</row>
<row>
<entry>output</entry>
<entry>205.254.211.17</entry>
<entry>64.70.12.210</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
A firewall implementing a tight policy (deny all, selectively allow)
will require a large number of individual rules to allow the NAT packets
to traverse the firewall packet filter.
Assuming the configuration detailed in
<xref linkend="ex-nat-basic"/>, the following set of chains is
required and will restrict access to only port 25
<footnote>
<para>
I assume here that the user has a restrictive default policy on the
firewalling device. I suggest a policy of DENY on each of the built
in <command>ipchains</command> chains.
</para>
</footnote>.
</para>
<!--
#
# XREF to minimum ICMP required from packetfilter.xml
#
-->
<example id="ex-nat-pf-ipchains">
<title>NAT of public IP 205.254.211.17 to private IP
192.168.100.17</title>
<programlisting>
<prompt>[root@masq-gw]# </prompt><userinput>ipchains -I input -i eth1 -p tcp -l -y -s 0/0 1024:65535 -d 205.254.211.17 25 -j ACCEPT</userinput>
<prompt>[root@masq-gw]# </prompt><userinput>ipchains -I input -i eth1 -p tcp ! -y -s 0/0 1024:65535 -d 205.254.211.17 25 -j ACCEPT</userinput>
<prompt>[root@masq-gw]# </prompt><userinput>ipchains -I forward -p tcp -s 0/0 1024:65535 -d 192.168.100.17 25 -j ACCEPT</userinput>
@ -691,56 +733,55 @@
<prompt>&gt; </prompt><userinput>ipchains -I forward -p icmp -s 205.254.211.17 $icmptype -d 0/0 -j ACCEPT</userinput>
<prompt>&gt; </prompt><userinput>ipchains -I output -i eth1 -p icmp -s 205.254.211.17 $icmptype -d 0/0 -j ACCEPT</userinput>
<prompt>&gt; </prompt><userinput>done</userinput>
</programlisting>
</example>
<para>
Please note that the formatting of the commands is simply for display
purposes, and to allow for easier reading of a complex set of commands.
The above set of rules is 31 individual chains. This is most certainly
a complex set of rules. For further details on how to use
<command>ipchains</command> please see the
<ulink url="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html"><command>ipchains</command>
HOWTO</ulink>. The salient detail you should notice from the above set
of rules is the difference between the IPs used in the input and forward
chains. Whenever a packet passes through the NAT rules, this happens in
the routing stage. Since all packets are routed between the input and
forward chains, any transformation of the packet (by the NAT code) will
by visible in the forward chain.
</para>
<para>
The first two lines cover all inbound TCP packets, the first line as a
special case of the second, indicating (<option>-l</option>) that we
want to log the packet. After successfully traversing the input chain,
the packet is routed, at which point the destination address of the
packet has changed. Now, we need to forward the packet from the public
source address to the private (or real) internal IP address. Finally,
we need to allow the packet out on the internal interface.
</para>
<para>
The next set of rules handles all of the TCP return packets. On the
input rule, we are careful to match only non-SYN packets from our
internal server bound for the world. Once again, the packet is
rewritten during the routing stage. Now in the forward chain, the
packet's source IP is the public IP of the service. Finally, we need to
let the packet out on our external interface.
</para>
<para>
The next series of lines are required ICMP rules to prevent network
traffic from breaking terribly. These types of ICMP, particularly
destination unreachable (ICMP 3) and source quench (ICMP 4) help to
ensure that TCP sessions run with optimized characteristics.
</para>
<para>
These rules are the minimum set of <command>ipchains</command> rules
needed to support a NAT'd TCP service. This concludes our discussion of
publishing a service to the world with &iproute2; based
NAT and protecting the service with <command>ipchains</command>. As you
can see, the complexity of supporting NAT with
&iproute2; can be substantial, which is why we'll
examine the benefits of inbound NAT (DNAT) with netfilter in the next
section.
</para>
</section>
</programlisting>
</example>
<para>
Please note that the formatting of the commands is simply for display
purposes, and to allow for easier reading of a complex set of commands.
The above set of rules is 31 individual chains. This is most certainly
a complex set of rules. For further details on how to use
<command>ipchains</command> please see the
<ulink url="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html"><command>ipchains</command>
HOWTO</ulink>. The salient detail you should notice from the above set
of rules is the difference between the IPs used in the input and forward
chains.
Since packets are rewritten by the stateless NAT code in the routing
stage, the transformation of the packet will by complete before the
forward chain is traversed.
</para>
<para>
The first two lines cover all inbound TCP packets, the first line as a
special case of the second, indicating (<option>-l</option>) that we
want to log the packet. After successfully traversing the input chain,
the packet is routed, at which point the destination address of the
packet has changed. Now, we need to forward the packet from the public
source address to the private (or real) internal IP address. Finally,
we need to allow the packet out on the internal interface.
</para>
<para>
The next set of rules handles all of the TCP return packets. On the
input rule, we are careful to match only non-SYN packets from our
internal server bound for the world. Once again, the packet is
rewritten during the routing stage. Now in the forward chain, the
packet's source IP is the public IP of the service. Finally, we need to
let the packet out on our external interface.
</para>
<para>
The next series of lines are required ICMP rules to prevent network
traffic from breaking terribly. These types of ICMP, particularly
destination unreachable (ICMP 3) and source quench (ICMP 4) help to
ensure that TCP sessions run with optimized characteristics.
</para>
<para>
These rules are the minimum set of <command>ipchains</command> rules
needed to support a NAT'd TCP service. This concludes our discussion of
publishing a service to the world with &iproute2; based
NAT and protecting the service with <command>ipchains</command>. As you
can see, the complexity of supporting NAT with
&iproute2; can be substantial, which is why we'll
examine the benefits of inbound NAT (DNAT) with netfilter in the next
section.
</para>
</section>
<section id="nat-dnat">
<title>Destination NAT with netfilter (DNAT)</title>
@ -756,8 +797,9 @@
<para>
In a devilishly subtle difference, netfilter DNAT does not cause the
kernel to answer ARP requests for the NAT IP, where
&iproute2; NAT automatically begins answering ARP
requests for the NAT IP. If the NAT IP is in a locally
&iproute2; NAT automatically begins
<link linkend="nat-stateless-arp">answering ARP requests</link>
for the NAT IP.
</para>
<example id="ex-nat-dnat-all">
<title>Using DNAT for all protocols (and ports) on one IP</title>
@ -771,9 +813,6 @@
10.10.14.2.
</para>
<para>
If only one port needs to be translated to an internal service the
following technique may lead to less resource consumption in the
connection tracking code.
</para>
<para>
</para>
@ -806,7 +845,8 @@
<example id="ex-nat-dnat-full">
<title>Simulating full NAT with SNAT and DNAT</title>
<programlisting>
<prompt>[root@real-server]# </prompt><userinput>iptables -t nat -A PREROUTING -p tcp -d 10.10.20.99 --dport 80 -j DNAT --to-destination 10.10.14.2</userinput>
<prompt>[root@real-server]# </prompt><userinput>iptables -t nat -A PREROUTING -d 205.254.211.17 -j DNAT --to-destination 192.168.100.17</userinput>
<prompt>[root@real-server]# </prompt><userinput>iptables -t nat -A POSTROUTING -s 192.168.100.17 -j SNAT --to-destination 205.254.211.17</userinput>
</programlisting>
</example>
<para>
@ -841,7 +881,7 @@
route between the two hosts connected by the port address translation.
</para>
<para>
PAT address translation has one important benefit over NAT (with the
PAT has one important benefit over NAT (with the
&iproute2; tools). Let's assume that you have only
five public IP addresses for which you have paid dearly. Additionally,
let's assume that you want to run services on standard ports. You had

266
LDP/guide/docbook/linux-ip/packetfilter.xml
View File

@ -4,32 +4,46 @@
<title>Packet Filtering</title>
<para>
It is not an uncommon story today to hear how people were first exposed to
linux. Many found linux an excellent and reliable masquerading firewall
in the mid-1990s and slowly became more and more accustomed to working
with linux as a result of the low cost.
linux. Many people found linux an excellent and reliable
masquerading firewall in the mid-1990s and slowly became more
and more accustomed to working with linux as a result of the low total
costo of ownership.
</para>
<para>
The capabilities of packet filtering code available today dwarfs those
of early linux (<command>ipfwadm</command>, anybody?) yet
The capabilities of packet filtering tools available under linux today
dwarfs that of early linux (<command>ipfwadm</command>, anybody?) yet
retains the reliability and expressive flexibility of the older tools.
</para>
<para>
For networks and machines directly connected to the Internet, packet
filtering is usually no longer an option, but a serious need. Here we'll
cover some of the Linux options and make some suggestions for further
reading.
filtering is no longer an option, but a need. This chapter will introduce
the packet filtering tools available under kernels 2.2 and 2.4. Since
there is much available documentation on packet filtering, host protection
and masquerading with a packet filter, this chapter will refer liberally
to external resources.
</para>
<para>
In this chapter, we'll begin with an <link linkend="pf-intro">introduction
to packet filtering</link> and then we'll discuss packet filtering from
the perspective of a <link linkend="pf-host">single machine</link> and
naturally also from the perspective of <link linkend="pf-network">a router
or firewall</link>.
This chapter begins with an
<link linkend="pf-intro">introduction to
and the history of packet filtering with linux</link>. After covering
some of the
<link linkend="pf-weakness">weaknesses of packet filtering</link>, it will
cover
<link linkend="pf-netfilter">the netfilter architecture</link>, and then
delve into
<link linkend="pf-netfilter-iptables">using
<command>iptables</command></link>. An introduction to the use of
<link linkend="pf-ipchains"><command>ipchains</command></link> will follow
along with introductions to
<link linkend="pf-host">host</link> and
<link linkend="pf-network">network protection</link>. The chapter will
close with an overview of
<link linkend="pf-further">further resources</link>.
</para>
<para>
</para>
<section id="pf-intro">
<title>Introduction to Packet Filtering</title>
<title>Rationale for and Introduction to Packet Filtering</title>
<para>
Packet filtering is one part of a good security stance for any network.
As the embodiment and expression of the acceptable flow of traffic from
@ -58,13 +72,94 @@
I will assume the reader has enough familiarity with the concepts of
packet filtering to put the material into context.
</para>
<para>
</para>
<para>
</para>
<para>
history of packet filtering with linux
</para>
<para>
Stress the importance of application layer security for packet filtered
services xref binding non-local
</para>
<para>
Stress the importance of SSL (or other network layer encryption).
</para>
<para>
packet filtering as part of a firewall, the conflation of the term
packet filter with the word firewall; refer to proxy services
</para>
<para>
Alternate names for packet filtering in other regions of the networking
world....ACLs
</para>
<para>
FIXME; this would be a good place for some links to external content on
packet filters, network security; firewalling; and so forth.
</para>
</section>
<section id="pf-weakness">
<title>Weaknesses of Packet Filtering</title>
<para>
Stateless packet filters. (cf. iptables connection tracking), cf. state
vs. stateless discussion.
</para>
<para>
Use of ICMP, when to block ICMP; tunneling through lax packet filters
with ICMP (trinoo, ICMPchat).
</para>
<para>
spoofed source addresses, xref binding non-local addresses
</para>
<para>
confounded application layer protocols like FTP, H323
</para>
<para>
DoS on connection tracking packet filters
</para>
<para>
DoS on rate limiters ?
</para>
<para>
</para>
<para>
</para>
<section id="pf-weakness-stateless">
<title>Complex Network Layer Stateless Packet Filters</title>
<para>
</para>
</section>
</section>
<section id="pf-icmp">
<title>General Packet Filter Requirements</title>
<para>
minimum ICMP required to meet the networking needs; xref PMTU discussion
</para>
<para>
source quench
</para>
<para>
parameter problem
</para>
<para>
inbound destination unreachable
</para>
<para>
outbound destination unreachable fragmentation needed
</para>
<para>
optional: echo request and echo reply
</para>
<para>
optional: outbound destination unreachable
</para>
<para>
optional: time exceeded
</para>
</section>
<section id="pf-netfilter">
<title>Netfilter and Packet Filtering</title>
<title>The Netfilter Architecture</title>
<para>
packet filtering engine in kernel 2.2 (skip history, adequately
documented elsewhere)
@ -82,13 +177,55 @@
</para>
<para>
</para>
<section id="pf-iptables">
<section id="pf-netfilter-iptables">
<title>Packet Filtering with <command>iptables</command></title>
<para>
selecting on interface
</para>
<para>
different chains, INPUT, OUTPUT, FORWARD
</para>
<para>
big picture; how chains are traversed
</para>
<para>
selecting on interface -i -o
</para>
<para>
targets; ACCEPT, DROP, REJECT....
</para>
</section>
<section id="pf-ipchains">
<title>Packet Filtering with <command>ipchains</command></title>
</section>
<section id="pf-ipchains">
<title>Packet Filtering with <command>ipchains</command></title>
<para>
the three builtin chains, input, output, forward
</para>
<para>
policy per chain, see targets
</para>
<para>
jumping from chain to chain, -j $TARGET; wher TARGET=chain
</para>
<para>
the big picture; how chains are traversed
</para>
<para>
targets (other than chains) ACCEPT, DENY, REJECT....
</para>
<para>
selecting on interface
</para>
<para>
</para>
<para>
</para>
<section id="pf-ipchains-mangling">
<title>Packet Mangling with <command>ipchains</command></title>
<para>
</para>
<para>
</para>
<para>
</para>
</section>
@ -112,26 +249,10 @@
</para>
<para>
</para>
<section id="pf-host-ipchains">
<title>Protecting a Host with <command>ipchains</command></title>
<para>
FIXME
</para>
</section>
<section id="pf-host-iptables">
<title>Protecting a Host with <command>iptables</command></title>
<para>
</para>
<para>
</para>
<para>
</para>
<para>
</para>
<example id="ex-pf-iptables-reject">
<title>Blocking a destination and using the <option>REJECT</option>
target, cf. <xref linkend="ex-tools-ip-route-add-prohibit"/></title>
<programlisting>
<example id="ex-pf-iptables-reject">
<title>Blocking a destination and using the <option>REJECT</option>
target, cf. <xref linkend="ex-tools-ip-route-add-prohibit"/></title>
<programlisting>
<prompt>[root@masq-gw]# </prompt><userinput>iptables -I FORWARD -p tcp -d 209.10.26.51 --dport 22 -j REJECT</userinput>
<prompt>[root@tristan]# </prompt><userinput>ssh 209.10.26.51</userinput>
<computeroutput>ssh: connect to address 209.10.26.51 port 22: Connection refused</computeroutput>
@ -139,34 +260,55 @@
<computeroutput>tcpdump: listening on eth2
22:16:59.111947 192.168.99.35.51991 &gt; 209.10.26.51.22: tcp 0 (DF)
22:16:59.112270 192.168.99.254 &gt; 192.168.99.35: icmp: 209.10.26.51 tcp port 22 unreachable (DF) [tos 0xc0]</computeroutput>
</programlisting>
</example>
<para>
</para>
</section>
</programlisting>
</example>
<para>
</para>
</section>
<section id="pf-network">
<title>Protecting a Network</title>
<para>
FIXME
</para>
<section id="pf-net-masq">
<title>Protecting a Masqueraded Network</title>
<para>
FIXME
</para>
</section>
<section id="pf-net-ipchains">
<title>Protecting a Network with <command>ipchains</command></title>
<para>
FIXME
</para>
</section>
<section id="pf-net-iptables">
<title>Protecting a Network with <command>iptables</command></title>
<para>
FIXME
</para>
</section>
<para>
</para>
<para>
</para>
<para>
</para>
</section>
<section id="pf-further">
<title>Further Resources</title>
<para>
The use of linux packet filtering features is mature and
well-documented in many places throughout the Internet. One of the most
thorough introductions to the use of <command>iptables</command> has
been collected by Oskar Andreasson at his
<ulink url="http://iptables-tutorial.frozentux.net/">Iptables
tutorial</ulink>. For further reference material on the use of
<command>iptables</command> consult this resource.
</para>
<para>
For those continuing to use <command>ipchains</command> the
<ulink url="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html">ipchains
HOWTO</ulink> courtesy of TLDP provides an introduction to the world of
<command>ipchains</command>.
</para>
<para>
For kernel 2.4, understanding the sequence of packet mangling, filtering
and network address translation is key. The
<ulink url="http://www.docum.org/stef.coene/qos/kptd/">kernel packet
traveling diagram</ulink> provides a visual representation of the path a
packet takes through the kernel. Here you will see the netfilter hooks,
traffic control, and routing stages. A similar picture of kernel 2.4's
packet path is available in a single page PDF entitled
<ulink url="http://open-source.arkoon.net/kernel/kernel_net.png">Linux
Kernel 2.4 Packet handling</ulink>.
</para>
<para>
See also
<xref linkend="links-ipchains"/> and
<xref linkend="links-netfilter"/> in the appendices for a more complete
set of references and links.
</para>
</section>
</chapter>

34
LDP/guide/docbook/linux-ip/routing.xml
View File

@ -451,7 +451,7 @@ default via 192.168.100.254 dev eth0</computeroutput>
</para>
</section>
<section id="routing-default">
<title>Routing through a Router, Commonly the Default Gateway</title>
<title>Sending Packets Through a Gateway</title>
<para>
By comparison to the total number of publicly accessible hosts on the
Internet there is an almost insignificant number of hosts inside any
@ -858,7 +858,7 @@ else
</para>
<para>
Also refer to this
<ulink url="http://defiant.coinet.com/iproute2/ip-cref/node155.html">excerpt</ulink>.
<ulink url="http://defiant.coinet.com/iproute2/ip-cref/node155.html">excerpt</ulink>
from the &iproute2; command reference.
</para>
</section>
@ -1339,10 +1339,13 @@ broadcast 192.168.254.255 proto kernel scope link src 192.168.254.254</comput
</section>
</section>
<section id="routing-rpdb">
<title>Routing Policy Database</title>
<title>Routing Policy Database (RPDB)</title>
<para>
The routing policy database controls the order in which the kernel
searches through the routing tables.
</para>
<para>
The routing policy database (RPDB) controls the order in which the
kernel searches through the routing tables. Each rule has a priority,
and rules are examined sequentially from rule 0 through rule 32767.
</para>
<para>
</para>
@ -1351,6 +1354,17 @@ broadcast 192.168.254.255 proto kernel scope link src 192.168.254.254</comput
</section>
<section id="routing-icmp">
<title>ICMP and Routing</title>
<!--
#
# content to add here:
#
# ignoring ICMP redirects (sysctl or pf); side effects, how to
# sending ICMP redirects
# suppressing generation of ICMP redirects (sysctl); how to
#
-->
<para>
ICMP is a very important part of the communication between hosts on
IP networks. Used by routers and endpoints (clients and servers)
@ -1372,6 +1386,16 @@ broadcast 192.168.254.255 proto kernel scope link src 192.168.254.254</comput
</para>
<section id="routing-icmp-mtu">
<title>MTU, MSS, and ICMP</title>
<!--
#
# content to add here:
#
# discuss path MTU, remove MSS; discuss necessary ICMP
# for communication with other hosts; xref pf-necessary-icmp
#
-->
<para>
One important use of ICMP, which is completely transparent
to most users (and indeed many admins), is the use of ICMP to discover

75
LDP/guide/docbook/linux-ip/tools-diagnostics.xml
View File

@ -546,12 +546,85 @@ round-trip min/avg/max/mdev = 53.976/61.630/69.285/7.658 ms</computeroutput>
<para>
<command>traceroute</command> is a utility for identifying the network
path a packet will take to a destination. Like ping, it can be called
a number of ways.
a number of ways. <command>traceroute</command> takes advantage of a
the TTL in an IP packet to determine hop by hop the reachability and
addressing of routers between the <command>traceroute</command> host
and the intended destination.
</para>
<para>
The tool <command>traceroute</command> is available on most Unix-like
platforms and even under Windows as <command>tracert</command>. Here,
we will only consider the common <command>traceroute</commmand>
installed on linux systems.
</para>
<para>
</para>
<para>
</para>
<para>
</para>
<section id="tools-traceroute-basic">
<title>Using <command>traceroute</command></title>
<para>
The default packet type created by <command>traceroute</command>
is a UDP packet. The first packet will be addressed to udp/33435
and each subsequent packet will be addressed to an incremented port
number. This allows <command>traceroute</command> to keep track of
which return ICMP packets correspond to which outbound packets.
</para>
<example id="ex-tools-traceroute-basic">
<title>Simple usage of <command>traceroute</command></title>
<programlisting>
<prompt>[root@isolde]# </prompt><userinput>traceroute -n 192.168.99.35</userinput>
<prompt>[root@isolde]# </prompt><userinput>tcpdump -nn -i eth0 not tcp</userinput>
tcpdump: listening on eth0
20:13:36.905537 192.168.100.17.32978 > 192.168.99.35.33435: udp 10 [ttl 1]
20:13:36.905668 192.168.100.254 > 192.168.100.17. icmp: time exceeded in-transit [tos 0xc0]
20:13:36.906005 192.168.100.17.32978 > 192.168.99.35.33436: udp 10 [ttl 1]
20:13:36.906112 192.168.100.254 > 192.168.100.17. icmp: time exceeded in-transit [tos 0xc0]
20:13:36.906357 192.168.100.17.32978 > 192.168.99.35.33437: udp 10 [ttl 1]
20:13:36.906457 192.168.100.254 > 192.168.100.17. icmp: time exceeded in-transit [tos 0xc0]
20:13:36.906759 192.168.100.17.32978 > 192.168.99.35.33438: udp 10
20:13:36.907061 192.168.99.35 > 192.168.100.17. icmp: 192.168.99.35 udp port 33438 unreachable [tos 0xc0]
20:13:36.907293 192.168.100.17.32978 > 192.168.99.35.33439: udp 10
20:13:36.907543 192.168.99.35 > 192.168.100.17. icmp: 192.168.99.35 udp port 33439 unreachable [tos 0xc0]
20:13:36.907753 192.168.100.17.32978 > 192.168.99.35.33440: udp 10
20:13:36.907990 192.168.99.35 > 192.168.100.17. icmp: 192.168.99.35 udp port 33440 unreachable [tos 0xc0]
13 packets received by filter
0 packets dropped by kernel
</programlisting>
</example>
<para>
Note in
<xref linkend="ex-tools-traceroute-basic"/> that
<command>tcpdump</command> conveniently reports the low TTL on the
first packets. Packets transmitted from a router with a TTL of 1
will expire at the next router they hit. This is the concept and
mechanism by which <command>traceroute</command> is able to detect
the path by which packets arrive at their destination.
</para>
<para>
Each of the first three packets transmitted in the above example
receive ICMP time exceeded replies from the upstream router
(&masq-gw;). The second set of packets have their TTL set to 2,
which is not reported by <command>tcpdump</command>. This allows
these packets to reach the intended destination, &tristan;.
</para>
<para>
There is a liability of using UDP traceroute on the Internet.
Many screening routers, firewalls, and even hosts will silently drop
UDP packets, effectively destroying the usability of
<command>traceroute</command>. On internal networks, or networks
known to have no firewalls, conventional
<command>traceroute</command> can continue to provide diagnostic
value. In the case that the network is known to have a firewall,
<link linkend="tools-traceroute-icmp"><command>traceroute</command>
can use ICMP</link>, and
<link linkend="tools-mtr"><command>mtr</command></link> is a good
example of a network diagnostic tool which uses ICMP only.
</para>
</section>
<section id="tools-traceroute-icmp">
<title>Telling <command>traceroute</command> to use ICMP echo request
instead of UDP</title>

36
LDP/guide/docbook/linux-ip/tools-ethernet.xml
View File

@ -768,9 +768,39 @@ default via 192.168.99.254 dev eth0</computeroutput>
delete</command></link>.
</para>
<para>
Any existing entry can be changed at any time. This allows you to
make a static entry if there's already an entry in the ARP cache for
the specified IP.
For those who insist on such a thing, there is support for creating
and deleting proxy ARP entries with <command>ip neighbor</command>,
although this has been deprecated. For a long discussion of this
topic, see
<ulink url="http://www.uwsg.iu.edu/hypermail/linux/kernel/0110.2/index.html#523">this
discussion on the kernel mailing list</ulink>. Other tools should be
used to create proxy ARP entries. Refer to
<xref linkend="tools-arp"/>,
<xref linkend="adv-proxy-arp"/> and
<xref linkend="ether-arp-proxy"/>.
</para>
<example id="ex-tools-ip-neighbor-add-proxy">
<title>Entering a proxy ARP entry with <command>ip
neighbor add proxy</command></title>
<programlisting>
<computeroutput># -- this is deprecated; use arp or kernel proxy_arp instead --#</computeroutput>
<prompt>[root@masq-gw]# </prompt><userinput>ip neighbor add proxy 192.168.100.1 dev eth0</userinput>
<computeroutput># -- this is deprecated; use arp or kernel proxy_arp instead --#</computeroutput>
</programlisting>
</example>
<para>
Strangely, the <command>ip neighbor show</command> command does not
display any entries added and deleted with <command>ip neighbor
add proxy</command>, so
<link linkend="tools-arp"><command>arp</command></link> is required
to view these entries. In short, don't use <command>ip neighbor add
proxy</command>.
</para>
<para>
Entries can also be modified at any time. This allows learned entries
to be replaced with
static entries if there's already an entry in the ARP cache for
a specified IP.
</para>
<example id="ex-tools-ip-neighbor-change">
<title>Altering an entry in the ARP cache with <command>ip neighbor

12
LDP/guide/docbook/linux-ip/tools-ip-management.xml
View File

@ -525,6 +525,18 @@ lo Link encap:Local Loopback
<section id="tools-ip-address-del">
<title>Using <command>ip address del</command> to remove IP addresses
from an interface</title>
<para>
There is a difference between IPs considered as primary addresses on
an interface and secondary addresses. If in the output, an address
is listed as a secondary address, removing the primary address will
also remove the secondary address.
</para>
<para>
A workaround is to set the netmask on the second address added to
the interface to /32. Unfortunately, this subterfuge will prevent
the kernel from entering the correct corresponding network and
broadcast routes.
</para>
<example id="ex-tools-ip-address-del">
<title>Removing IP addresses from interfaces with <command>ip address</command></title>
<programlisting>

24
LDP/guide/docbook/linux-ip/tools-misc.xml
View File

@ -80,7 +80,7 @@
</section>
<section id="tools-iproute2-remarks">
<title>Some general remarks about &iproute2;tools</title>
<title>Some general remarks about &iproute2; tools</title>
<para>
This is a meant to be a collected set of thoughts which don't fit
anyplace else about the &iproute2; tools. If you are
@ -147,7 +147,7 @@
available for manipulation and inspection. Where these are
covered in detail in this documentation, they will be relegated to
a non-canonical ghetto. Examples will (someday) include
<ulink url="http://www.linuxvirtualserver.org/~julian/#iparp"><command>ip
<ulink url="http://www.ssi.bg/~ja/#iparp"><command>ip
arp</command></ulink> and <command>tc</command> extensions.
</para>
</listitem>
@ -202,4 +202,24 @@
indispensable.
</para>
</section>
<section id="tools-sysctl-intro">
<title>Brief introduction to <command>sysctl</command></title>
<para>
Many behaviours of the linux kernel can be modified through the use of
run time variables. These variables can be changed manually or with
the use of a convenient command line utility. Most linux
distributions also include a standard configuration file which can
store these parameters for use at boot time.
</para>
<para>
For a deeper reference into the matter and use of
<command>sysctl</command> see
<ulink url="http://ipsysctl-tutorial.frozentux.net/">the IP Sysctl
tutorial</ulink>, maintained by Oskar Andreasson.
</para>
<para>
</para>
<para>
</para>
</section>
</appendix>

63
LDP/guide/docbook/linux-ip/tools-sockets.xml
View File

@ -25,8 +25,6 @@
<para>
Some services expect to run under another utility which will handle the
socket operations. We'll tour the following utilities:
<link linkend="tools-inetd"><command>inetd</command></link>, its
successor or logical child
<link linkend="tools-xinetd"><command>xinetd</command></link>,
<link linkend="tools-tcpserver"><command>tcpserver</command></link> and
the very specifically designed port redirection utility
@ -81,9 +79,25 @@
</example>
<para>
</para>
<para>
</para>
<para>
</para>
<example id="ex-tools-nc-server">
<title>Using <command>nc</command> as a server</title>
<programlisting>
<prompt>[root@tristan]# </prompt><userinput>nc -l -p 2048</userinput>
</programlisting>
</example>
<para>
</para>
<para>
</para>
<para>
</para>
<example id="ex-tools-nc-delay">
<title>Delaying a stream with <command>nc</command></title>
<programlisting>
<prompt>[root@tristan]# </prompt><userinput>nc -l -p 2048</userinput>
</programlisting>
</example>
@ -92,6 +106,7 @@
<example id="ex-tools-nc-udp">
<title>Using <command>nc</command> with UDP</title>
<programlisting>
<prompt>[root@tristan]# </prompt><userinput>nc -u 192.168.100.17 3000</userinput>
</programlisting>
</example>
<para>
@ -130,6 +145,27 @@
</example>
<para>
</para>
<example id="ex-tools-socat-serial">
<title>Connecting <command>socat</command> to a serial line</title>
<programlisting>
</programlisting>
</example>
<para>
</para>
<example id="ex-tools-socat-pty">
<title>Using a PTY with <command>socat</command></title>
<programlisting>
</programlisting>
</example>
<para>
</para>
<example id="ex-tools-socat-exec">
<title>Executing a command with <command>socat</command></title>
<programlisting>
</programlisting>
</example>
<para>
</para>
<example id="ex-tools-socat-socat">
<title>Connecting one <command>socat</command> to another one</title>
<programlisting>
@ -166,16 +202,25 @@
<para>
</para>
</section>
<section id="tools-inetd">
<title><command>inetd</command></title>
<para>
FIXME
</para>
</section>
<section id="tools-xinetd">
<title><command>xinetd</command></title>
<para>
FIXME
</para>
<example id="ex-tools-xinetd-redir">
<title>IP redirection with <command>xinetd</command></title>
<programlisting>
</programlisting>
</example>
<para>
</para>
<para>
</para>
<example id="ex-tools-xinetd-server">
<title>Publishing a service with <command>xinetd</command></title>
<programlisting>
</programlisting>
</example>
<para>
</para>
</section>
<section id="tools-tcpserver">