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:
parent
54ee049cfa
commit
c92864d7e9
|
@ -24,14 +24,33 @@
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="adv-proxy-arp">
|
<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>
|
<para>
|
||||||
Proxy ARP is a method of advertising by a routing device
|
Proxy ARP is a technique for splitting an IP network into two
|
||||||
for a destination on one ethernet which is reachable via another
|
separate segments. Hosts on one segment can only reach hosts in the
|
||||||
ethernet. Frequently, a bridge is used instead. If a machine sits
|
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,
|
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
|
then routes to hosts in each segment and proxy ARP are required
|
||||||
network to communicate with another.
|
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>
|
||||||
<para>
|
<para>
|
||||||
The key part of the correct functioning of proxy ARP in a network is
|
The key part of the correct functioning of proxy ARP in a network is
|
||||||
|
|
|
@ -3,9 +3,8 @@
|
||||||
<chapter id="ch-advanced-routing">
|
<chapter id="ch-advanced-routing">
|
||||||
<title>Advanced IP Routing</title>
|
<title>Advanced IP Routing</title>
|
||||||
<section id="adv-routing">
|
<section id="adv-routing">
|
||||||
<title>Introduction to Advanced Routing</title>
|
<title>Introduction to Policy Routing</title>
|
||||||
<para>
|
<para>
|
||||||
FIXME
|
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="adv-overview">
|
<section id="adv-overview">
|
||||||
|
|
|
@ -146,8 +146,8 @@
|
||||||
<computeroutput>tcpdump: listening on eth0
|
<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: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: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: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: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>
|
</programlisting>
|
||||||
<calloutlist>
|
<calloutlist>
|
||||||
<callout
|
<callout
|
||||||
|
@ -659,28 +659,28 @@ Received 4 response(s)</computeroutput>
|
||||||
<prompt>[root@real-server]# </prompt><userinput>ip address show dev eth1</userinput>
|
<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
|
<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
|
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>
|
<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
|
<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] 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.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))
|
Sent 3 probes (1 broadcast(s))
|
||||||
Received 3 response(s)</computeroutput>
|
Received 3 response(s)</computeroutput>
|
||||||
<prompt>[root@real-client]# </prompt><userinput>arping -I eth0 -c 3 192.168.100.1</userinput>
|
<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
|
<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] 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.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))
|
Sent 3 probes (1 broadcast(s))
|
||||||
Received 3 response(s)</computeroutput>
|
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>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>
|
<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
|
<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] 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] 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))
|
Sent 3 probes (1 broadcast(s))
|
||||||
Received 3 response(s)</computeroutput>
|
Received 3 response(s)</computeroutput>
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
|
@ -540,6 +540,21 @@
|
||||||
<section id="links-misc">
|
<section id="links-misc">
|
||||||
<title>Miscellaneous Linux IP Resources</title>
|
<title>Miscellaneous Linux IP Resources</title>
|
||||||
<itemizedlist>
|
<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>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
For users who need to provide a standards compliant VPN solution
|
For users who need to provide a standards compliant VPN solution
|
||||||
|
|
|
@ -100,7 +100,7 @@
|
||||||
<title>Concepts</title>
|
<title>Concepts</title>
|
||||||
|
|
||||||
&basic; <!-- chapter on basic IP connectivity -->
|
&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 -->
|
ðer; <!-- chapter on ARP, VLANs and bonding -->
|
||||||
&bridging; <!-- chapter on bridging -->
|
&bridging; <!-- chapter on bridging -->
|
||||||
&routing; <!-- chapter on IP routing (static) -->
|
&routing; <!-- chapter on IP routing (static) -->
|
||||||
|
|
|
@ -190,6 +190,7 @@
|
||||||
table. For even modest machines, the connection tracking resource
|
table. For even modest machines, the connection tracking resource
|
||||||
consumption should not be problematic.
|
consumption should not be problematic.
|
||||||
</para>
|
</para>
|
||||||
|
<!-- FIXME; next paragraph needs to be rewritten -->
|
||||||
<para>
|
<para>
|
||||||
Netfilter DNAT allows the user to select packets based on
|
Netfilter DNAT allows the user to select packets based on
|
||||||
characteristics such as destination port. This blurs the distinction
|
characteristics such as destination port. This blurs the distinction
|
||||||
|
@ -233,8 +234,9 @@
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>real IP</term>
|
<term>real IP</term>
|
||||||
<term>hidden IP</term>
|
|
||||||
<term>server IP</term>
|
<term>server IP</term>
|
||||||
|
<term>hidden IP</term>
|
||||||
|
<term>private IP</term>
|
||||||
<term>internal IP</term>
|
<term>internal IP</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
|
@ -264,15 +266,40 @@
|
||||||
<section id="nat-break">
|
<section id="nat-break">
|
||||||
<title>Application Layer Protocols with Embedded Network Information</title>
|
<title>Application Layer Protocols with Embedded Network Information</title>
|
||||||
<para>
|
<para>
|
||||||
Some applications, FTP, H323, IRC?, use (check conntrack helpers) use
|
Network address translation is beautifully invisible when it works,
|
||||||
embedded network information inside the application layer protocol.
|
but has adverse effects on some protocols.
|
||||||
Introduce such problems, and how NAT confounds these 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>
|
||||||
<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>
|
||||||
<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>
|
||||||
<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>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
<section id="nat-stateless">
|
<section id="nat-stateless">
|
||||||
|
@ -281,7 +308,7 @@
|
||||||
Stateless NAT, occasionally maligned as dumb NAT
|
Stateless NAT, occasionally maligned as dumb NAT
|
||||||
<footnote>
|
<footnote>
|
||||||
<para>
|
<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>.
|
located in the file <filename>net/ipv4/ip_nat_dumb.c</filename>.
|
||||||
Even in the kernel, it has this reputation.
|
Even in the kernel, it has this reputation.
|
||||||
</para>
|
</para>
|
||||||
|
@ -331,219 +358,197 @@
|
||||||
a certain range. See <xref linkend="nat-stateless-rpdb"/>.
|
a certain range. See <xref linkend="nat-stateless-rpdb"/>.
|
||||||
</para>
|
</para>
|
||||||
<section id="nat-stateless-simple">
|
<section id="nat-stateless-simple">
|
||||||
<title>Simple Example</title>
|
<title>Stateless NAT Packet Capture and Introduction</title>
|
||||||
<para>
|
<para>
|
||||||
We want to provide SMTP service on an IP in our outside network
|
Assume that example company in
|
||||||
(205.254.211.0/24) but we know that six months from now we are
|
<link linkend="ax-example-network">example network</link> wants to
|
||||||
going to be moving to a new network (65.211.43.0/24) and we don't
|
provide SMTP service on a public IP (205.254.211.0/24) but plans to
|
||||||
want to have to readdress our SMTP server then. It's NAT to the
|
move to a different IP addressing space in the near future. Network
|
||||||
rescue.
|
address translation can assist example company prepare for the move.
|
||||||
</para>
|
The administrator will select an IP on the internal network
|
||||||
<para>
|
(192.168.100.0/24) and configure the router to accept and translate
|
||||||
We'll select an IP on the internal network (192.168.100.0/24) and
|
packets for the publicly reachable IP into the private IP.
|
||||||
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).
|
|
||||||
</para>
|
</para>
|
||||||
<example id="ex-nat-basic">
|
<example id="ex-nat-basic">
|
||||||
<title>
|
<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>
|
</title>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
<prompt>[root@masq-gw]# </prompt><userinput>tcpdump -q -n -n</userinput>
|
<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)
|
<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)
|
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)
|
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)</computeroutput>
|
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>
|
</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>
|
</example>
|
||||||
<para>
|
<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>
|
||||||
<para>
|
</section>
|
||||||
<computeroutput>19:30:17.824853 eth1 < 64.70.12.210.35131 > 205.254.211.17.25: tcp 0 (DF)</computeroutput>
|
<section id="nat-stateless-howto">
|
||||||
</para>
|
<title>Stateless NAT Practicum</title>
|
||||||
<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>
|
|
||||||
<para>
|
<para>
|
||||||
There are only a few commands which are required to enable NAT
|
There are only a few commands which are required to enable stateless
|
||||||
on your linux routing device.
|
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>
|
||||||
<para>
|
<example id="ex-nat-basic-commands">
|
||||||
Refer to <xref linkend="ex-nat-basic"/> to see the result of the
|
<title>Basic commands to create a stateless NAT</title>
|
||||||
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>
|
|
||||||
<programlisting>
|
<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 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>
|
<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>
|
<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>
|
<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>
|
<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
|
<computeroutput>0: from all lookup local
|
||||||
32765: from 192.168.100.17 lookup main map-to 205.254.211.17
|
32765: from 192.168.100.17 lookup main map-to 205.254.211.17
|
||||||
32766: from all lookup main
|
32766: from all lookup main
|
||||||
32767: from all lookup 253</computeroutput>
|
32767: from all lookup 253</computeroutput>
|
||||||
</programlisting>
|
</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>
|
<para>
|
||||||
Let's pause for a moment to examine what each of these commands
|
|
||||||
accomplishes.
|
|
||||||
</para>
|
</para>
|
||||||
<programlisting>
|
</section>
|
||||||
<prompt>[root@masq-gw]# </prompt><userinput>ip route add nat 205.254.211.17 via 192.168.100.17</userinput>
|
<section id="nat-stateless-rpdb">
|
||||||
</programlisting>
|
<title>Conditional Stateless NAT</title>
|
||||||
<para>
|
<para>
|
||||||
This command tells the kernel to perform network address translation
|
NAT introduces a complexity to the network in which it is
|
||||||
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
|
|
||||||
used because a service is reachable on a public and a private IP.
|
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
|
Usually, this is a reasonable tradeoff or else stateless NAT would
|
||||||
NAT as the appropriate tool. In the case that the linux routing
|
fail in the selection process.
|
||||||
device is connected to a public network and more than one private
|
In the case that the linux routing device is connected to a public
|
||||||
network, you have some extra work to do.
|
network and more than one private
|
||||||
|
network, there is more work to do.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Though you have made this service available to the public network on
|
Though the service is available to the public network on
|
||||||
a public IP, you may wish to have internal users connect to the service
|
a public (NAT) IP, internal users may need to connect to the private
|
||||||
on the internal IP.
|
or 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.
|
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
This is accomplished by use of the routing policy database (RPDB),
|
This is accomplished by use of the routing policy database (RPDB),
|
||||||
which allows conditional routing based on packet characteristics.
|
which allows conditional routing based on packet characteristics.
|
||||||
For a more complete explanation of the RPDB, see
|
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>
|
be manipulated with the <link linkend="tools-ip-rule"><command>
|
||||||
ip rule</command></link> command. In order to successfully
|
ip rule</command></link> command.
|
||||||
configure NAT, you need to have gained familiarity with the <command>
|
In order to successfully configure NAT, familiarity with the
|
||||||
ip rule</command>, so this is a logical extension.
|
<command> ip rule</command> command is required.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<example id="ex-nat-stateless-rpdb">
|
||||||
The assumptions <link linkend="nat-stateless-howto">above</link> about
|
<title>Conditional Stateless NAT (not performing NAT for a
|
||||||
our host &masq-gw; are still valid. Additionally, let's assume that
|
specified destination network)</title>
|
||||||
&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>
|
|
||||||
<programlisting>
|
<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 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>
|
<prompt>[root@masq-gw]# </prompt><userinput>ip route flush cache</userinput>
|
||||||
|
@ -554,7 +559,7 @@
|
||||||
32766: from all lookup main
|
32766: from all lookup main
|
||||||
32767: from all lookup 253</computeroutput>
|
32767: from all lookup 253</computeroutput>
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</example>
|
||||||
<para>
|
<para>
|
||||||
Note that we now have an entry of higher priority in the RPDB
|
Note that we now have an entry of higher priority in the RPDB
|
||||||
for any packets returning from 192.168.100.17 bound for
|
for any packets returning from 192.168.100.17 bound for
|
||||||
|
@ -585,7 +590,6 @@
|
||||||
<link linkend="ex-sc-static-nat">configuration file</link>
|
<link linkend="ex-sc-static-nat">configuration file</link>
|
||||||
can ease the burden of managing a number of NAT IPs on your system.
|
can ease the burden of managing a number of NAT IPs on your system.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
<section id="nat-stateless-pf-interaction">
|
<section id="nat-stateless-pf-interaction">
|
||||||
|
@ -599,11 +603,11 @@
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
All of the below requirements can be deduced from an understanding of
|
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>
|
<ulink url="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO-4.html#ss4.1"><command>ipchains</command>
|
||||||
packet path</ulink> as illustrated in the
|
packet path</ulink> as illustrated in the
|
||||||
<ulink url="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html"><command>ipchains</command>
|
<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
|
<command>ipchains</command>. Keep in mind when viewing the ASCII
|
||||||
diagram that stateless NAT will always occur in the routing stage. Also
|
diagram that stateless NAT will always occur in the routing stage. Also
|
||||||
consult the
|
consult the
|
||||||
|
@ -714,8 +718,8 @@
|
||||||
#
|
#
|
||||||
-->
|
-->
|
||||||
<example id="ex-nat-pf-ipchains">
|
<example id="ex-nat-pf-ipchains">
|
||||||
<title>NAT of public IP 205.254.211.17 to private IP
|
<title>Using an <command>ipchains</command> packet filter with
|
||||||
192.168.100.17</title>
|
stateless NAT</title>
|
||||||
<programlisting>
|
<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 -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 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>
|
<para>
|
||||||
The tool <command>traceroute</command> is available on most Unix-like
|
The tool <command>traceroute</command> is available on most Unix-like
|
||||||
platforms and even under Windows as <command>tracert</command>. Here,
|
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.
|
installed on linux systems.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
|
|
|
@ -8,6 +8,19 @@
|
||||||
|
|
||||||
<xsl:param name="html.stylesheet" select="'linux-ip.css'"/>
|
<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:template match="ulink" name="ulink">
|
||||||
<xsl:variable name="link">
|
<xsl:variable name="link">
|
||||||
<a class="nonlocal">
|
<a class="nonlocal">
|
||||||
|
|
Loading…
Reference in New Issue