mirror of https://github.com/tLDP/LDP
removed devices.xml (renamed interfaces.xml) will reappear someday
tweaks to advanced-*, few minor links, testing some XSL stuff, and importantly, revising nat.xml--much cleaner. (still needs work)
This commit is contained in:
mabrown
parent
54ee049cfa
commit
c92864d7e9
|
|
@ -24,14 +24,33 @@
|
|||
</para>
|
||||
</section>
|
||||
<section id="adv-proxy-arp">
|
||||
<title>Breaking a network in two with proxy arp</title>
|
||||
<title>Breaking a network in two with proxy ARP</title>
|
||||
<para>
|
||||
Proxy ARP is a method of advertising by a routing device
|
||||
for a destination on one ethernet which is reachable via another
|
||||
ethernet. Frequently, a bridge is used instead. If a machine sits
|
||||
Proxy ARP is a technique for splitting an IP network into two
|
||||
separate segments. Hosts on one segment can only reach hosts in the
|
||||
other segment through the router performing proxy ARP. If a router sits
|
||||
between two parts of an IP network and is not running bridging software,
|
||||
then routing and proxy ARP are required to allow each half of the IP
|
||||
network to communicate with another.
|
||||
then routes to hosts in each segment and proxy ARP are required
|
||||
on the router to allow each half of the
|
||||
network to communicate with the other half.
|
||||
</para>
|
||||
<para>
|
||||
Occasionally, this technique is incorrectly called proxy ARP bridging.
|
||||
An ethernet bridge operates on frames and a router operates on packets.
|
||||
The proxy ARP router should have routes to all hosts on both segments.
|
||||
Once the router can reach all locally connected destinations via the
|
||||
correct interfaces, you can begin to configure the proxy ARP
|
||||
functionality.
|
||||
</para>
|
||||
<para>
|
||||
Although proxy ARP complicates a network, a great advantage of proxy ARP
|
||||
technique is the greater control over IP connections between hosts.
|
||||
</para>
|
||||
<para>
|
||||
There are two primary proxy ARP techniques. With the 2.4 kernel, it is
|
||||
possible to use the sysctl
|
||||
<filename>net/ipv4/conf/all/proxy_arp</filename> to perform proxy ARP.
|
||||
Alternatively, manual population of the ARP table reaches the same end.
|
||||
</para>
|
||||
<para>
|
||||
The key part of the correct functioning of proxy ARP in a network is
|
||||
|
|
|
|||
|
|
@ -3,9 +3,8 @@
|
|||
<chapter id="ch-advanced-routing">
|
||||
<title>Advanced IP Routing</title>
|
||||
<section id="adv-routing">
|
||||
<title>Introduction to Advanced Routing</title>
|
||||
<title>Introduction to Policy Routing</title>
|
||||
<para>
|
||||
FIXME
|
||||
</para>
|
||||
</section>
|
||||
<section id="adv-overview">
|
||||
|
|
|
|||
|
|
@ -146,8 +146,8 @@
|
|||
<computeroutput>tcpdump: listening on eth0
|
||||
0:80:c8:f8:4a:51 ff:ff:ff:ff:ff:ff 42: arp who-has 192.168.99.254 tell 192.168.99.35 <co id="ex-eao-request" linkends="ex-eao-request-text"/>
|
||||
0:80:c8:f8:5c:73 0:80:c8:f8:4a:51 60: arp reply 192.168.99.254 is-at 0:80:c8:f8:5c:73 <co id="ex-eao-reply" linkends="ex-eao-reply-text"/>
|
||||
0:80:c8:f8:4a:51 0:80:c8:f8:5c:73 98: 192.168.99.35 > 192.168.99.254: icmp: echo request (DF) <co id="ex-eao-ip" linkends="ex-eao-ip-text"/>
|
||||
0:80:c8:f8:5c:73 0:80:c8:f8:4a:51 98: 192.168.99.254 > 192.168.99.35: icmp: echo reply <co id="ex-eao-ip2" linkends="ex-eao-ip-text"/></computeroutput>
|
||||
0:80:c8:f8:4a:51 0:80:c8:f8:5c:73 98: 192.168.99.35 > 192.168.99.254: icmp: echo request (DF) <co id="ex-eao-ip" linkends="ex-eao-ip-text"/>
|
||||
0:80:c8:f8:5c:73 0:80:c8:f8:4a:51 98: 192.168.99.254 > 192.168.99.35: icmp: echo reply <co id="ex-eao-ip2" linkends="ex-eao-ip-text"/></computeroutput>
|
||||
</programlisting>
|
||||
<calloutlist>
|
||||
<callout
|
||||
|
|
@ -659,28 +659,28 @@ Received 4 response(s)</computeroutput>
|
|||
<prompt>[root@real-server]# </prompt><userinput>ip address show dev eth1</userinput>
|
||||
<computeroutput>3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
|
||||
link/ether 00:80:c8:7e:71:d4 brd ff:ff:ff:ff:ff:ff
|
||||
inet 192.168.100.1/24 brd 192.168.100.255 scope global eth1</computeroutput> <co id="ex-eafa-server-setup" linkends="ex-eafa-server-setup-text"/>
|
||||
inet 192.168.100.1/24 brd 192.168.100.255 scope global eth1</computeroutput> <co id="ex-eafa-server-setup" linkends="ex-eafa-server-setup-text"/>
|
||||
<prompt>[root@real-client]# </prompt><userinput>arping -I eth0 -c 3 10.10.20.67</userinput>
|
||||
<computeroutput>ARPING 10.10.20.67 from 10.10.20.33 eth0
|
||||
Unicast reply from 10.10.20.67 [00:80:C8:E8:1E:FC] 0.882ms
|
||||
Unicast reply from 10.10.20.67 [00:80:C8:E8:1E:FC] 1.221ms
|
||||
Unicast reply from 10.10.20.67 [00:80:C8:E8:1E:FC] 1.487ms </computeroutput><!-- gotta wrap the callout in tags so it's in the parent object --><co id="ex-eafa-expected" linkends="ex-eafa-expected-text"/><computeroutput>
|
||||
Unicast reply from 10.10.20.67 [00:80:C8:E8:1E:FC] 1.487ms </computeroutput><!-- gotta wrap the callout in tags so it's in the parent object --><co id="ex-eafa-expected" linkends="ex-eafa-expected-text"/><computeroutput>
|
||||
Sent 3 probes (1 broadcast(s))
|
||||
Received 3 response(s)</computeroutput>
|
||||
<prompt>[root@real-client]# </prompt><userinput>arping -I eth0 -c 3 192.168.100.1</userinput>
|
||||
<computeroutput>ARPING 192.168.100.1 from 10.10.20.33 eth0
|
||||
Unicast reply from 192.168.100.1 [00:80:C8:E8:1E:FC] 0.877ms
|
||||
Unicast reply from 192.168.100.1 [00:80:C8:E8:1E:FC] 1.517ms
|
||||
Unicast reply from 192.168.100.1 [00:80:C8:E8:1E:FC] 1.661ms </computeroutput><!-- gotta wrap the callout in tags so it's in the parent object --><co id="ex-eafa-problemzone" linkends="ex-eafa-problemzone-text"/><computeroutput>
|
||||
Unicast reply from 192.168.100.1 [00:80:C8:E8:1E:FC] 1.661ms </computeroutput><!-- gotta wrap the callout in tags so it's in the parent object --><co id="ex-eafa-problemzone" linkends="ex-eafa-problemzone-text"/><computeroutput>
|
||||
Sent 3 probes (1 broadcast(s))
|
||||
Received 3 response(s)</computeroutput>
|
||||
<prompt>[root@real-client]# </prompt><userinput>ip neighbor del 192.168.100.1 dev eth0</userinput> <co id="ex-eafa-clearcache" linkends="ex-eafa-clearcache-text"/>
|
||||
<prompt>[root@real-client]# </prompt><userinput>ip neighbor del 192.168.100.1 dev eth0</userinput> <co id="ex-eafa-clearcache" linkends="ex-eafa-clearcache-text"/>
|
||||
<prompt>[root@real-client]# </prompt><userinput>ip address add 192.168.100.2/24 brd + dev eth0</userinput> <co id="ex-eafa-newip" linkends="ex-eafa-newip-text"/>
|
||||
<prompt>[root@real-client]# </prompt><userinput>arping -I eth0 -c 3 192.168.100.1</userinput>
|
||||
<computeroutput>ARPING 192.168.100.1 from 192.168.100.2 eth0
|
||||
Unicast reply from 192.168.100.1 [00:80:C8:7E:71:D4] 0.804ms
|
||||
Unicast reply from 192.168.100.1 [00:80:C8:7E:71:D4] 1.381ms
|
||||
Unicast reply from 192.168.100.1 [00:80:C8:7E:71:D4] 2.487ms </computeroutput><!-- gotta wrap the callout in tags so it's in the parent object --><co id="ex-eafa-workaround" linkends="ex-eafa-workaround-text"/><computeroutput>
|
||||
Unicast reply from 192.168.100.1 [00:80:C8:7E:71:D4] 2.487ms </computeroutput><!-- gotta wrap the callout in tags so it's in the parent object --><co id="ex-eafa-workaround" linkends="ex-eafa-workaround-text"/><computeroutput>
|
||||
Sent 3 probes (1 broadcast(s))
|
||||
Received 3 response(s)</computeroutput>
|
||||
</programlisting>
|
||||
|
|
|
|||
|
|
@ -540,6 +540,21 @@
|
|||
<section id="links-misc">
|
||||
<title>Miscellaneous Linux IP Resources</title>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The <command>sysctl</command> utility is a convenient tool for
|
||||
manipulating kernel parameters. Combined with the
|
||||
<filename>/etc/sysctl.conf</filename> this utility allows an
|
||||
administrator to alter or tune kernel parameters in a convenient
|
||||
fashion across a reboot. See this
|
||||
<ulink url="http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-proc-sysctl.html">brief
|
||||
RedHat page on the use of <command>sysctl</command></ulink>. See
|
||||
also
|
||||
<ulink url="http://ipsysctl-tutorial.frozentux.net/">Oskar
|
||||
Andreasson's IP Sysctl Tutorial</ulink> for a detailed examination
|
||||
of the parameters and their affect on system operation.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
For users who need to provide a standards compliant VPN solution
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@
|
|||
<title>Concepts</title>
|
||||
|
||||
&basic; <!-- chapter on basic IP connectivity -->
|
||||
&devices; <!-- chapter on the interfaces and devices -->
|
||||
<!-- &interfaces; --> <!-- chapter on the interfaces and devices -->
|
||||
ðer; <!-- chapter on ARP, VLANs and bonding -->
|
||||
&bridging; <!-- chapter on bridging -->
|
||||
&routing; <!-- chapter on IP routing (static) -->
|
||||
|
|
|
|||
|
|
@ -190,6 +190,7 @@
|
|||
table. For even modest machines, the connection tracking resource
|
||||
consumption should not be problematic.
|
||||
</para>
|
||||
<!-- FIXME; next paragraph needs to be rewritten -->
|
||||
<para>
|
||||
Netfilter DNAT allows the user to select packets based on
|
||||
characteristics such as destination port. This blurs the distinction
|
||||
|
|
@ -233,8 +234,9 @@
|
|||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>real IP</term>
|
||||
<term>hidden IP</term>
|
||||
<term>server IP</term>
|
||||
<term>hidden IP</term>
|
||||
<term>private IP</term>
|
||||
<term>internal IP</term>
|
||||
<listitem>
|
||||
<para>
|
||||
|
|
@ -264,15 +266,40 @@
|
|||
<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.
|
||||
Network address translation is beautifully invisible when it works,
|
||||
but has adverse effects on some protocols.
|
||||
Some network applications, e.g., FTP, SNMP, H323, LDAP, IRC, make use of
|
||||
embedded IP information in the application layer protocol or data
|
||||
stream. Since the 2.0.x kernel
|
||||
series (which is not covered here), linux has supported modules which
|
||||
inspect and manipulate packet contents on particular types of packets
|
||||
when used with NAT or masquerading.
|
||||
</para>
|
||||
<para>
|
||||
FTP is the classic example. Within the FTP control channel
|
||||
(usually established to destination port tcp/21) the client and the
|
||||
server exchange IP address and port information. If the network address
|
||||
translation device doesn't manipulate this data, the FTP server will not
|
||||
be able to contact the client to provide the data.
|
||||
</para>
|
||||
<para>
|
||||
Passive mode FTP provides the possibility for a network layer which
|
||||
requires only outbound TCP connections. This results in a more NAT
|
||||
friendly and firewall friendly protocol, because the connections are
|
||||
initiated from the client.
|
||||
</para>
|
||||
<para>
|
||||
Not only are there network applications which break when NAT is involved
|
||||
but also network layer protocols. IPSec is a standards-based
|
||||
network-layer security protocol commonly used in VPNs and IPv6 networks.
|
||||
There are many different ways to use IPSec, but, when used in AH
|
||||
(Authentication Header) mode, NAT will break IPSec functionality.
|
||||
</para>
|
||||
<para>
|
||||
This underscores the importance of determining if NAT is the best
|
||||
solution for the problem. There are kernel modules to help handle many
|
||||
(though not all) of the application layer protocol when using NAT, but
|
||||
some protocols, such as IPSec in AH mode simply cannot be used with NAT.
|
||||
</para>
|
||||
</section>
|
||||
<section id="nat-stateless">
|
||||
|
|
@ -281,7 +308,7 @@
|
|||
Stateless NAT, occasionally maligned as dumb NAT
|
||||
<footnote>
|
||||
<para>
|
||||
In the kernel code tree, the stateless NAT, &iproute2; NAT can be
|
||||
In the kernel code tree, 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>
|
||||
|
|
@ -331,219 +358,197 @@
|
|||
a certain range. See <xref linkend="nat-stateless-rpdb"/>.
|
||||
</para>
|
||||
<section id="nat-stateless-simple">
|
||||
<title>Simple Example</title>
|
||||
<title>Stateless NAT Packet Capture and Introduction</title>
|
||||
<para>
|
||||
We want to provide SMTP service on an IP in our outside network
|
||||
(205.254.211.0/24) but we know that six months from now we are
|
||||
going to be moving to a new network (65.211.43.0/24) and we don't
|
||||
want to have to readdress our SMTP server then. It's NAT to the
|
||||
rescue.
|
||||
</para>
|
||||
<para>
|
||||
We'll select an IP on the internal network (192.168.100.0/24) and
|
||||
tell our router to accept packets for 205.254.211.17 and translate
|
||||
this traffic to 192.168.100.17. Let's take a look at the packet
|
||||
as we accept the packet on our router's outside interface (eth1) and
|
||||
again as we transmit the packet out the router's inside interface
|
||||
(eth0).
|
||||
Assume that example company in
|
||||
<link linkend="ax-example-network">example network</link> wants to
|
||||
provide SMTP service on a public IP (205.254.211.0/24) but plans to
|
||||
move to a different IP addressing space in the near future. Network
|
||||
address translation can assist example company prepare for the move.
|
||||
The administrator will select an IP on the internal network
|
||||
(192.168.100.0/24) and configure the router to accept and translate
|
||||
packets for the publicly reachable IP into the private IP.
|
||||
</para>
|
||||
<example id="ex-nat-basic">
|
||||
<title>
|
||||
NAT of public IP 205.254.211.17 to private IP 192.168.100.17
|
||||
Stateless NAT Packet Capture
|
||||
<footnote>
|
||||
<para>
|
||||
If you are having some difficulty understanding the
|
||||
output of <command>tcpdump</command>, please see the
|
||||
section on <link linkend="tools-tcpdump">tcpdump</link>.
|
||||
</para>
|
||||
</footnote>
|
||||
</title>
|
||||
<programlisting>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>tcpdump -q -n -n</userinput>
|
||||
<computeroutput>19:30:17.824853 eth1 < 64.70.12.210.35131 > 205.254.211.17.25: tcp 0 (DF)
|
||||
19:30:17.824976 eth0 > 64.70.12.210.35131 > 192.168.100.17.25: tcp 0 (DF)
|
||||
19:30:17.825400 eth0 < 192.168.100.17.25 > 64.70.12.210.35131: tcp 0 (DF)
|
||||
19:30:17.825568 eth1 > 205.254.211.17.25 > 64.70.12.210.35131: tcp 0 (DF)</computeroutput>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>tcpdump -qnn</userinput>
|
||||
<computeroutput>19:30:17.824853 eth1 < 64.70.12.210.35131 > 205.254.211.17.25: tcp 0 (DF) <co id="ex-nb-public-in" linkends="ex-nb-public-in-text"/>
|
||||
19:30:17.824976 eth0 > 64.70.12.210.35131 > 192.168.100.17.25: tcp 0 (DF) <co id="ex-nb-private-out" linkends="ex-nb-private-out-text"/>
|
||||
19:30:17.825400 eth0 < 192.168.100.17.25 > 64.70.12.210.35131: tcp 0 (DF) <co id="ex-nb-private-in" linkends="ex-nb-private-in-text"/>
|
||||
19:30:17.825568 eth1 > 205.254.211.17.25 > 64.70.12.210.35131: tcp 0 (DF) <co id="ex-nb-public-out" linkends="ex-nb-public-out-text"/></computeroutput>
|
||||
</programlisting>
|
||||
<calloutlist>
|
||||
<callout
|
||||
arearefs="ex-nb-public-in"
|
||||
id="ex-nb-public-in-text">
|
||||
<simpara>
|
||||
The first packet comes in on eth1, &masq-gw;'s
|
||||
outside interface. The packet is addressed to the NAT IP,
|
||||
205.254.211.17 on tcp/25. This is the IP/port pair on which
|
||||
which our service runs. This is a snapshot
|
||||
of the packet before it has been handled by the NAT code.
|
||||
</simpara>
|
||||
</callout>
|
||||
<callout
|
||||
arearefs="ex-nb-private-out"
|
||||
id="ex-nb-private-out-text">
|
||||
<simpara>
|
||||
The next line is the "same" packet leaving eth0, &masq-gw;'s
|
||||
inside interface, bound for the internal network.
|
||||
The NAT code has substituted the real IP of the server,
|
||||
192.168.100.17. This rewriting is handled by the
|
||||
<constant>nat</constant> entry in the
|
||||
<constant>local</constant> routing table (<userinput>ip
|
||||
route</userinput>). See also
|
||||
<xref linkend="ex-nat-basic-commands"/>.
|
||||
</simpara>
|
||||
</callout>
|
||||
<callout
|
||||
arearefs="ex-nb-private-in"
|
||||
id="ex-nb-private-in-text">
|
||||
<simpara>
|
||||
The SMTP server then sends a return packet which arrives on
|
||||
eth0. This is the packet before the NAT code on &masq-gw;
|
||||
has rewritten the outbound packet. This rewriting is handled
|
||||
by the RPDB entry (<userinput>ip rule</userinput>). See also
|
||||
<xref linkend="ex-nat-basic-commands"/>.
|
||||
</simpara>
|
||||
</callout>
|
||||
<callout
|
||||
arearefs="ex-nb-public-out"
|
||||
id="ex-nb-public-out-text">
|
||||
<simpara>
|
||||
Finally, the return packet is transmitted on eth1 after having
|
||||
been rewritten. The source IP address on the packet is now
|
||||
the public IP on which the service is published.
|
||||
</simpara>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</example>
|
||||
<para>
|
||||
Let's examine each of the above packet details above to determine
|
||||
what we are seeing
|
||||
<footnote>
|
||||
<para>
|
||||
If you are having some difficulty understanding the
|
||||
output of <command>tcpdump</command>, please see the
|
||||
section on <link linkend="tools-tcpdump">tcpdump</link>.
|
||||
</para>
|
||||
</footnote>.
|
||||
The first packet comes in on eth1 (masq-gw's
|
||||
outside interface). The packet is addressed to 205.254.211.17:25
|
||||
which is the public IP on which our service runs. This is a snapshot
|
||||
of the packet before it has been handled by the NAT code.
|
||||
</para>
|
||||
<para>
|
||||
<computeroutput>19:30:17.824853 eth1 < 64.70.12.210.35131 > 205.254.211.17.25: tcp 0 (DF)</computeroutput>
|
||||
</para>
|
||||
<para>
|
||||
The next packet we see is the "same" packet leaving eth0 (masq-gw's
|
||||
inside interface) bound for the internal network. As you can see,
|
||||
the NAT code has substituted the IP 192.168.100.17 for the
|
||||
original destination IP.
|
||||
</para>
|
||||
<para>
|
||||
<computeroutput>19:30:17.824976 eth0 > 64.70.12.210.35131 > 192.168.100.17.25: tcp 0 (DF)</computeroutput>
|
||||
</para>
|
||||
<para>
|
||||
The SMTP server then sends a packet back to us which comes in on
|
||||
eth0. This is before &masq-gw; has rewritten the outbound packet.
|
||||
</para>
|
||||
<para>
|
||||
<computeroutput>19:30:17.825400 eth0 < 192.168.100.17.25 > 64.70.12.210.35131: tcp 0 (DF)</computeroutput>
|
||||
</para>
|
||||
<para>
|
||||
Finally, we see the return packet outbound on eth1 from the
|
||||
public IP on which we have elected to publish the service.
|
||||
</para>
|
||||
<para>
|
||||
<computeroutput>19:30:17.825568 eth1 > 205.254.211.17.25 > 64.70.12.210.35131: tcp 0 (DF)</computeroutput>
|
||||
</para>
|
||||
<para>
|
||||
Now that we have examined the general practice of NAT and looked at a
|
||||
simple example of network address translation, we have the background
|
||||
to begin looking at the tools available to perform NAT.
|
||||
</para>
|
||||
<section id="nat-stateless-howto">
|
||||
<title>iproute2 NAT Practicum</title>
|
||||
</section>
|
||||
<section id="nat-stateless-howto">
|
||||
<title>Stateless NAT Practicum</title>
|
||||
<para>
|
||||
There are only a few commands which are required to enable NAT
|
||||
on your linux routing device.
|
||||
There are only a few commands which are required to enable stateless
|
||||
NAT on a linux routing device. The commands below will configure
|
||||
the host &masq-gw; (see
|
||||
<xref linkend="example-network-netmap"/> and
|
||||
<xref linkend="example-network-addressing"/>) as shown above in
|
||||
<xref linkend="ex-nat-basic"/>.
|
||||
</para>
|
||||
<para>
|
||||
Refer to <xref linkend="ex-nat-basic"/> to see the result of the
|
||||
following NAT configuration. Our assumptions here are as follows:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
The machine &masq-gw; is connected to 205.254.211.0/24 on eth1.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The machine &masq-gw; is connected to 192.168.100.0/24 on eth0.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The machine &isolde; is listening on 192.168.100.17/24 on the
|
||||
same media as eth0 of &masq-gw;.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The machine &isolde; uses &masq-gw; as its default gateway.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The machine &isolde; has a server running on port 25 (SMTP).
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>
|
||||
<example id="ex-nat-basic-commands">
|
||||
<title>Basic commands to create a stateless NAT</title>
|
||||
<programlisting>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip route add nat 205.254.211.17 via 192.168.100.17</userinput>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip rule add nat 205.254.211.17 from 192.168.100.17</userinput>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip route flush cache</userinput>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip route show table all | grep ^nat</userinput>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip route add nat 205.254.211.17 via 192.168.100.17</userinput> <co id="ex-nbc-routenat" linkends="ex-nbc-routenat-text"/>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip rule add nat 205.254.211.17 from 192.168.100.17</userinput> <co id="ex-nbc-rulenat" linkends="ex-nbc-rulenat-text"/>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip route flush cache</userinput> <co id="ex-nbc-flushcache" linkends="ex-nbc-flushcache-text"/>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip route show table all | grep ^nat</userinput> <co id="ex-nbc-routeshow" linkends="ex-nbc-routeruleshow-text"/>
|
||||
<computeroutput>nat 205.254.211.17 via 192.168.100.17 table local scope host</computeroutput>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip rule show</userinput>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip rule show</userinput> <co id="ex-nbc-ruleshow" linkends="ex-nbc-routeruleshow-text"/>
|
||||
<computeroutput>0: from all lookup local
|
||||
32765: from 192.168.100.17 lookup main map-to 205.254.211.17
|
||||
32766: from all lookup main
|
||||
32767: from all lookup 253</computeroutput>
|
||||
</programlisting>
|
||||
</para>
|
||||
<calloutlist>
|
||||
<callout
|
||||
arearefs="ex-nbc-routenat"
|
||||
id="ex-nbc-routenat-text">
|
||||
<simpara>
|
||||
This command tells the kernel to perform network
|
||||
address translation on any packet bound for
|
||||
205.254.211.17. The parameter via tells the NAT code
|
||||
to rewrite the packet bound for 205.254.211.17 with the
|
||||
new destination address 192.168.100.17. Note, that this
|
||||
only handles inbound packets; that is, packets whose
|
||||
destination address contains 205.254.211.17.
|
||||
</simpara>
|
||||
</callout>
|
||||
<callout
|
||||
arearefs="ex-nbc-rulenat"
|
||||
id="ex-nbc-rulenat-text">
|
||||
<simpara>
|
||||
This command enters the corresponding rule for the
|
||||
outbound traffic into the RPDB (kernel 2.2 and up).
|
||||
This rule will cause the kernel rewrite any packet from
|
||||
192.168.100.17 with the specified source address
|
||||
(205.254.211.17). Any packet originating from
|
||||
192.168.100.17 which passes through this router
|
||||
will trigger this rule. In short, this command rewrites the
|
||||
source address of outbound packets so that they appear to
|
||||
originate from the NAT IP.
|
||||
</simpara>
|
||||
</callout>
|
||||
<callout
|
||||
arearefs="ex-nbc-flushcache"
|
||||
id="ex-nbc-flushcache-text">
|
||||
<simpara>
|
||||
The kernel maintains a routing cache to handle routing
|
||||
decisions more quickly
|
||||
(<xref linkend="routing-cache"/>). After making changes
|
||||
to the routing tables on a system, it is good practice to
|
||||
empty the routing cache with <userinput>ip route flush
|
||||
cache</userinput>. Once the cache is empty, the
|
||||
kernel is guaranteed to consult the routing tables again
|
||||
instead of the routing cache.
|
||||
</simpara>
|
||||
</callout>
|
||||
<callout
|
||||
arearefs="ex-nbc-routeshow ex-nbc-ruleshow"
|
||||
id="ex-nbc-routeruleshow-text">
|
||||
<simpara>
|
||||
These two commands allow the user to inspect the
|
||||
routing policy database and the <constant>local</constant>
|
||||
routing table to determine if the NAT routes and rules were
|
||||
added correctly.
|
||||
</simpara>
|
||||
</callout>
|
||||
</calloutlist>
|
||||
</example>
|
||||
<para>
|
||||
Let's pause for a moment to examine what each of these commands
|
||||
accomplishes.
|
||||
</para>
|
||||
<programlisting>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip route add nat 205.254.211.17 via 192.168.100.17</userinput>
|
||||
</programlisting>
|
||||
</section>
|
||||
<section id="nat-stateless-rpdb">
|
||||
<title>Conditional Stateless NAT</title>
|
||||
<para>
|
||||
This command tells the kernel to perform network address translation
|
||||
on any packet bound for 205.254.211.17. The parameter via tells the
|
||||
NAT code to rewrite the packet bound for 205.254.211.17 with the new
|
||||
destination address 192.168.100.17. Note, that this only handles
|
||||
inbound packets; that is, packets whose destination address contains
|
||||
205.254.211.17.
|
||||
</para>
|
||||
<programlisting>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip rule add nat 205.254.211.17 from 192.168.100.17</userinput>
|
||||
</programlisting>
|
||||
<para>
|
||||
This command instructs the routing policy database (kernel 2.2 and up)
|
||||
to rewrite any packet from 192.168.100.17 with the source address
|
||||
205.254.211.17. this rule will be triggered by any packet passing
|
||||
through this machine which originates from 192.168.100.17. This
|
||||
addresses the packets returning to the public network in our case.
|
||||
</para>
|
||||
<programlisting>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip route flush cache</userinput>
|
||||
</programlisting>
|
||||
<para>
|
||||
The kernel maintains a routing cache to handle routing decisions more
|
||||
quickly. After making changes to the routes on a system, you'll
|
||||
need to tell the cache to empty. Once the cache is empty, the kernel
|
||||
will again determine the best route by consulting the routing tables
|
||||
(instead of the cache).
|
||||
</para>
|
||||
<programlisting>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip route show table all | grep nat</userinput>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip rule show</userinput>
|
||||
</programlisting>
|
||||
<para>
|
||||
These two commands allow us to inspect the routing policy database and
|
||||
the (main) routing table to determine if the routes and rules we added
|
||||
appear as we expect. If your output is similar to the output above,
|
||||
you should be able to test to see if the linux routing device is
|
||||
performing NAT for you.
|
||||
</para>
|
||||
</section>
|
||||
<section id="nat-stateless-rpdb">
|
||||
<title>&iproute2; NAT with Multiple Private
|
||||
Networks</title>
|
||||
<para>
|
||||
Naturally, NAT introduces a complexity to the network in which it is
|
||||
NAT introduces a complexity to the network in which it is
|
||||
used because a service is reachable on a public and a private IP.
|
||||
Usually, this is a reasonable tradeoff or else you wouldn't select
|
||||
NAT as the appropriate tool. In the case that the linux routing
|
||||
device is connected to a public network and more than one private
|
||||
network, you have some extra work to do.
|
||||
Usually, this is a reasonable tradeoff or else stateless NAT would
|
||||
fail in the selection process.
|
||||
In the case that the linux routing device is connected to a public
|
||||
network and more than one private
|
||||
network, there is more work to do.
|
||||
</para>
|
||||
<para>
|
||||
Though you have made this service available to the public network on
|
||||
a public IP, you may wish to have internal users connect to the service
|
||||
on the internal IP.
|
||||
In <xref linkend="ex-nat-basic"/>, you would not want users on the internal
|
||||
network to reach the SMTP server on the public IP of the service, but
|
||||
rather the private IP.
|
||||
Though the service is available to the public network on
|
||||
a public (NAT) IP, internal users may need to connect to the private
|
||||
or internal IP.
|
||||
</para>
|
||||
<para>
|
||||
This is accomplished by use of the routing policy database (RPDB),
|
||||
which allows conditional routing based on packet characteristics.
|
||||
For a more complete explanation of the RPDB, see
|
||||
<xref linkend="adv-rpdb"/>. The routing policy database can
|
||||
<xref linkend="routing-rpdb"/>. The routing policy database can
|
||||
be manipulated with the <link linkend="tools-ip-rule"><command>
|
||||
ip rule</command></link> command. In order to successfully
|
||||
configure NAT, you need to have gained familiarity with the <command>
|
||||
ip rule</command>, so this is a logical extension.
|
||||
ip rule</command></link> command.
|
||||
In order to successfully configure NAT, familiarity with the
|
||||
<command> ip rule</command> command is required.
|
||||
</para>
|
||||
<para>
|
||||
The assumptions <link linkend="nat-stateless-howto">above</link> about
|
||||
our host &masq-gw; are still valid. Additionally, let's assume that
|
||||
&masq-gw; is connected to
|
||||
the internal network 192.168.99.0/24 on eth2. In order to allow hosts
|
||||
in this network to address 192.168.100.17 directly we'll have to
|
||||
create an entry in the RPDB with a higher priority than the current
|
||||
rule which handles all packets bound from 192.168.100.17 (and rewrites
|
||||
them with a source address of 205.254.211.17).
|
||||
</para>
|
||||
<para>
|
||||
<example id="ex-nat-stateless-rpdb">
|
||||
<title>Conditional Stateless NAT (not performing NAT for a
|
||||
specified destination network)</title>
|
||||
<programlisting>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip rule add to 192.168.99.0/24 from 192.168.100.17</userinput>
|
||||
<prompt>[root@masq-gw]# </prompt><userinput>ip route flush cache</userinput>
|
||||
|
|
@ -554,7 +559,7 @@
|
|||
32766: from all lookup main
|
||||
32767: from all lookup 253</computeroutput>
|
||||
</programlisting>
|
||||
</para>
|
||||
</example>
|
||||
<para>
|
||||
Note that we now have an entry of higher priority in the RPDB
|
||||
for any packets returning from 192.168.100.17 bound for
|
||||
|
|
@ -585,7 +590,6 @@
|
|||
<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>
|
||||
<section id="nat-stateless-pf-interaction">
|
||||
|
|
@ -599,11 +603,11 @@
|
|||
</para>
|
||||
<para>
|
||||
All of the below requirements can be deduced from an understanding of
|
||||
NAT and the kernel packet traveling diagram. Consult the
|
||||
NAT and the path a packet takes through the kernel. Consult also 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
|
||||
HOWTO</ulink> to understand the packet path when 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
|
||||
|
|
@ -714,8 +718,8 @@
|
|||
#
|
||||
-->
|
||||
<example id="ex-nat-pf-ipchains">
|
||||
<title>NAT of public IP 205.254.211.17 to private IP
|
||||
192.168.100.17</title>
|
||||
<title>Using an <command>ipchains</command> packet filter with
|
||||
stateless NAT</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>
|
||||
|
|
|
|||
|
|
@ -554,7 +554,7 @@ round-trip min/avg/max/mdev = 53.976/61.630/69.285/7.658 ms</computeroutput>
|
|||
<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>
|
||||
we will only consider the common <command>traceroute</command>
|
||||
installed on linux systems.
|
||||
</para>
|
||||
<para>
|
||||
|
|
|
|||
|
|
@ -8,6 +8,19 @@
|
|||
|
||||
<xsl:param name="html.stylesheet" select="'linux-ip.css'"/>
|
||||
|
||||
|
||||
<!--
|
||||
Tried chunk.tocs.and.lots, and got a main page with revision history
|
||||
and abstract. Not quite what I had hoped.
|
||||
|
||||
<xsl:param name="chunk.tocs.and.lots" select="1"/>
|
||||
|
||||
Appears to be used by the LDP stylesheets, on which this is based
|
||||
|
||||
<xsl:param name="chunk.first.sections" select="1"/>
|
||||
|
||||
-->
|
||||
|
||||
<xsl:template match="ulink" name="ulink">
|
||||
<xsl:variable name="link">
|
||||
<a class="nonlocal">
|
||||
|
|
|
|||
Loading…
Reference in New Issue