mirror of https://github.com/tLDP/LDP
590 lines
23 KiB
Plaintext
590 lines
23 KiB
Plaintext
<chapter id="X-087-2-ipmasq"><title>IP Masquerade and <?lb>Network Address <?lb>Translation</title>
|
|
<indexterm id="chmq.ip.masq" class="startofrange"><primary>IP (Internet Protocol)</primary><secondary>masquerade</secondary></indexterm>
|
|
|
|
<para>
|
|
You don't have to have a good memory to remember a time when only large
|
|
organizations could afford to have a number of computers networked together
|
|
by a LAN. Today network technology has dropped so much in
|
|
price that two things have happened. First, LANs are now
|
|
commonplace, even in many household environments. Certainly many Linux
|
|
users will have two or more computers connected by some Ethernet.
|
|
Second, network resources, particularly IP addresses, are now
|
|
a scarce resource and while they used to be free, they are now being bought
|
|
and sold.
|
|
</para>
|
|
|
|
<para>
|
|
Most people with a LAN will probably also want an Internet
|
|
connection that every computer on the LAN can use. The IP routing rules
|
|
are quite strict in how they deal with this situation. Traditional solutions
|
|
to this problem would have involved requesting an IP network address, perhaps
|
|
a class C address for small sites, assigning each host on the LAN an
|
|
address from this network and using a router to connect the LAN to the
|
|
Internet.
|
|
</para>
|
|
|
|
<para>
|
|
In a commercialized Internet environment, this is quite an
|
|
expensive proposition. First, you'd be required to pay for the network
|
|
address that is assigned to you. Second, you'd probably have to pay your
|
|
Internet Service Provider for the privilege of having a suitable route
|
|
to your network put in place so that the rest of the Internet knows how to
|
|
reach you. This might still be practical for companies, but domestic
|
|
installations don't usually justify the cost.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>NAT (Network Address Translation)</primary></indexterm>
|
|
Fortunately, Linux provides an answer to this dilemma.
|
|
This answer involves a component of a group of advanced networking features
|
|
called <emphasis>Network Address Translation</emphasis> (NAT).
|
|
NAT describes the process of modifying the network
|
|
addresses contained with datagram headers while they are in transit. This
|
|
might sound odd at first, but we'll show that it is ideal for solving
|
|
the problem we've just described and many have encountered. IP masquerade
|
|
is the name given to one type of network address translation
|
|
that allows all of the hosts on a private network to use the Internet at the
|
|
price of a single IP address.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>masquerade</primary><secondary>how it works</secondary></indexterm>
|
|
<INDEXTERM><PRIMARY>datagrams</PRIMARY><SECONDARY>masquerading</SECONDARY></INDEXTERM>
|
|
IP masquerading allows you to use a private (reserved) IP network
|
|
address on your LAN and have your Linux-based router perform some
|
|
clever, real-time translation of IP addresses and ports. When it
|
|
receives a datagram from a computer on the LAN, it takes note of the
|
|
type of datagram it is, “TCP,” “UDP,”
|
|
“ICMP,” etc., and modifies the datagram so that it looks
|
|
like it was generated by the router machine itself (and remembers that
|
|
it has done so). It then transmits the datagram onto the Internet with
|
|
its single connected IP address. When the destination host receives
|
|
this datagram, it believes the datagram has come from the routing
|
|
host and sends any reply datagrams back to that address. When the
|
|
Linux masquerade router receives a datagram from its Internet
|
|
connection, it looks in its table of established masqueraded
|
|
connections to see if this datagram actually belongs to a computer on
|
|
the LAN, and if it does, it reverses the modification it did on the
|
|
forward path and transmits the datagram to the LAN computer.
|
|
</para>
|
|
|
|
<para>
|
|
A simple example is illustrated in <xref linkend="X-087-2-masquerade.net">.
|
|
</para>
|
|
|
|
<figure id="X-087-2-masquerade.net" float=0>
|
|
<title>A typical IP masquerade configuration</title>
|
|
<!-- <graphic fileref="lag2_1101.jpg"></graphic> -->
|
|
<!-- 2016-01-28; MAB, TLDP -->
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/lag2_1101.jpg" format="jpg">
|
|
</imageobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/lag2_1101.eps" format="eps">
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<para>
|
|
We have a small Ethernet network using one of the reserved network addresses.
|
|
The network has a Linux-based masquerade router providing access to the
|
|
Internet. One of the workstations on the network (192.168.1.3) wishes to
|
|
establish a connection to the remote host 209.1.106.178 on port 8888. The
|
|
workstation routes its datagram to the masquerade router, which identifies
|
|
this connection request as requiring masquerade services. It accepts the
|
|
datagram and allocates a port number to use (1035), substitutes its own
|
|
IP address and port number for those of the originating host, and transmits
|
|
the datagram to the destination host. The destination host believes it has
|
|
received a connection request from the Linux masquerade host and generates
|
|
a reply datagram. The masquerade host, upon receiving this datagram,
|
|
finds the association in its masquerade table and reverses the substution
|
|
it performed on the outgoing datagram. It then transmits the reply datagram
|
|
to the originating host.
|
|
</para>
|
|
|
|
<para>
|
|
The local host believes it is speaking directly to the remote host. The
|
|
remote host knows nothing about the local host at all and believes it has
|
|
received a connection from the Linux masquerade host. The Linux masquerade
|
|
host knows these two hosts are speaking to each other, and on what ports,
|
|
and performs the address and port translations necessary to allow
|
|
communication.
|
|
</para>
|
|
|
|
<para>
|
|
This might all seem a little confusing, and it can be, but it works and
|
|
is really quite simple to configure. So don't worry if you don't understand
|
|
all the details yet.
|
|
</para>
|
|
|
|
<sect1 id="X-087-2-masq.side.effects"><title>Side Effects and Fringe Benefits</title>
|
|
<para>
|
|
<INDEXTERM><PRIMARY>masquerade</PRIMARY><SECONDARY>side effects of</SECONDARY></INDEXTERM>
|
|
The IP masquerade facility comes with its own set of side effects, some of
|
|
which are useful and some of which might become bothersome.
|
|
</para>
|
|
|
|
<para>
|
|
<?troff .hw specially>
|
|
None of the hosts on the supported network behind the masquerade router
|
|
are ever directly seen; consequently, you need only one valid and
|
|
routable IP address to allow all hosts to make network connections out
|
|
onto the Internet. This has a downside; none of those hosts are
|
|
visible from the Internet and you can't directly connect to them from
|
|
the Internet; the only host visible on a masqueraded network is the
|
|
masquerade machine itself. This is important when you consider
|
|
services such as mail or FTP. It helps determine what services should
|
|
be provided by the masquerade host and what services it should proxy
|
|
or otherwise treat specially.
|
|
</para>
|
|
|
|
<para>
|
|
Second, because none of the masqueraded hosts are visible, they are relatively
|
|
protected from attacks from outside; this could simplify or even remove
|
|
the need for firewall configuration on the masquerade host. You shouldn't rely
|
|
too heavily on this, though. Your whole network will be only as safe as
|
|
your masquerade host, so you should use firewall to protect it if security is
|
|
a concern.
|
|
</para>
|
|
|
|
<para>
|
|
Third, IP masquerade will have some impact on the performance of your
|
|
networking. In typical configurations this will probably be barely measurable.
|
|
If you have large numbers of active masquerade sessions, though, you may find
|
|
that the processing required at the masquerade machine begins to impact
|
|
your network throughput. IP masquerade must do a good deal of work for
|
|
each datagram compared to the process of conventional routing. That
|
|
386SX16 machine you have been planning on using as a masquerade machine
|
|
supporting a dial-up link to the Internet might be fine, but don't expect
|
|
too much if you decide you want to use it as a router in your corporate
|
|
network at Ethernet speeds.
|
|
</para>
|
|
|
|
<para>
|
|
Last, some network services just won't work through masquerade, or at least
|
|
not without a lot of help. Typically, these are services that rely on incoming
|
|
sessions to work, such as some types of Direct Communications Channels (DCC),
|
|
features in IRC, or certain types of video and audio multicasting services.
|
|
Some of these services have specially developed kernel modules to provide
|
|
solutions for these, and we'll talk about those in a moment. For others, it
|
|
is possible that you will find no support, so be aware,it won't be suitable
|
|
in all situations.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-masq.kernel.config"><title>Configuring the Kernel <?lb>for IP Masquerade</title>
|
|
<para>
|
|
<INDEXTERM><PRIMARY>configuring</PRIMARY><SECONDARY>kernel</SECONDARY><TERTIARY SORTAS="IP masquerade">for IP masquerade</TERTIARY></INDEXTERM>
|
|
<indexterm><primary>masquerade</primary><secondary>kernel configuration</secondary></indexterm>
|
|
<indexterm><primary>kernels</primary><secondary>configuring for masquerade</secondary></indexterm>
|
|
|
|
<?troff .hw kernel>
|
|
<INDEXTERM><PRIMARY>2.2 kernels</PRIMARY><SECONDARY>IP masquerade</SECONDARY></INDEXTERM>
|
|
To use the IP masquerade facility, your kernel must be compiled with masquerade
|
|
support. You must select the following options when configuring a 2.2 series
|
|
kernel:
|
|
|
|
<screen>
|
|
Networking options --->
|
|
[*] Network firewalls
|
|
[*] TCP/IP networking
|
|
[*] IP: firewalling
|
|
[*] IP: masquerading
|
|
--- Protocol-specific masquerading support will be built as modules.
|
|
[*] IP: ipautofw masq support
|
|
[*] IP: ICMP masquerading
|
|
</screen>
|
|
|
|
Note that some of the masquerade support is available only as a kernel module.
|
|
This means that you must ensure that you
|
|
“<literal>make modules</literal>” in addition to the usual
|
|
“<literal>make zImage</literal>” when building
|
|
your kernel.
|
|
</para>
|
|
|
|
<para>
|
|
<INDEXTERM><PRIMARY>2.4 kernels</PRIMARY><SECONDARY>IP masquerade</SECONDARY></INDEXTERM>
|
|
The 2.4 series kernels no longer offer IP masquerade support as a kernel
|
|
compile time option. Instead, you should select the network packet
|
|
filtering option:
|
|
|
|
<screen width=80>
|
|
Networking options --->
|
|
[M] Network packet filtering (replaces ipchains)
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
In the 2.2 series kernels, a number of protocol-specific helper
|
|
modules are created during kernel compilation. Some protocols begin with
|
|
an outgoing request on one port, and then expect an incoming connection on
|
|
another. Normally these cannot be masqueraded, as there is no way of associating
|
|
the second connection with the first without peering inside the protocols
|
|
themselves. The helper modules do just that; they actually look inside the
|
|
datagrams and allow masquerading to work for supported protocols that
|
|
otherwise would be impossible to masquerade. The supported protocols are:
|
|
|
|
<informaltable>
|
|
<tgroup cols="2">
|
|
<thead>
|
|
<row>
|
|
<entry>Module</entry>
|
|
<entry>Protocol</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry>ip_masq_ftp</entry>
|
|
<entry>FTP</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ip_masq_irc</entry>
|
|
<entry>IRC</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ip_masq_raudio</entry>
|
|
<entry>RealAudio</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ip_masq_cuseeme</entry>
|
|
<entry>CU-See-Me</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ip_masq_vdolive</entry>
|
|
<entry>For VDO Live</entry>
|
|
</row>
|
|
<row>
|
|
<entry>ip_masq_quake</entry>
|
|
<entry>IdSoftware's Quake</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
You must load these modules manually using the <command>insmod</command>
|
|
command to implement them. Note that these modules cannot be loaded using
|
|
the <command>kerneld</command> daemon. Each of the modules takes an argument
|
|
specifying what ports it will listen on. For the
|
|
RealAudio™ module you might use:<footnote id="X-087-2-MQ01">
|
|
<para>
|
|
RealAudio is a trademark of the Progressive Networks Corporation.
|
|
</para>
|
|
</footnote>
|
|
<screen>
|
|
# <userinput>insmod ip_masq_raudio.o ports=7070,7071,7072</userinput> </screen>
|
|
|
|
The ports you need to specify depend on the protocol. An IP masquerade
|
|
mini-HOWTO written by Ambrose Au explains more about the IP masquerade modules
|
|
and how to configure them.<footnote id="X-087-2-FNMQ02">
|
|
<para>
|
|
You can contact Ambrose at
|
|
<systemitem role="email">ambrose@writeme.com</systemitem>.
|
|
</para>
|
|
</footnote>
|
|
</para>
|
|
|
|
<para>
|
|
The <emphasis>netfilter</emphasis> package includes modules that perform
|
|
similar functions. For example, to provide connection tracking of FTP
|
|
sessions, you'd load and use the <filename>ip_conntrack_ ftp</filename> and
|
|
<filename>ip_nat_ ftp.o</filename> modules.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-masq.configuration"><title>Configuring IP Masquerade</title>
|
|
<para>
|
|
<indexterm><primary>masquerade</primary><secondary>configuration</secondary></indexterm>
|
|
<indexterm><primary>configuring</primary><secondary>IP masquerade</secondary></indexterm>
|
|
<INDEXTERM id="ipfwadm.config.masq" class=startofrange><PRIMARY>ipfwadm command</PRIMARY><SECONDARY>configuring IP masquerade</SECONDARY></INDEXTERM>
|
|
<INDEXTERM id="ipchains.config.masq" class=startofrange><PRIMARY>ipchains command</PRIMARY><SECONDARY>configuring IP masquerade</SECONDARY></INDEXTERM>
|
|
<INDEXTERM id="iptables.config.masq" class=startofrange><PRIMARY>iptables command</PRIMARY><SECONDARY>configuring IP masquerade</SECONDARY></INDEXTERM>
|
|
If you've already read the firewall and accounting chapters, it
|
|
probably comes as no surprise that the <command>ipfwadm</command>,
|
|
<command>ipchains</command>, and <command>iptables</command> commands
|
|
are used to configure the IP masquerade rules as well.
|
|
</para>
|
|
|
|
<para>
|
|
Masquerade rules are a special class of filtering rule. You can
|
|
masquerade only datagrams that are received on one interface that will
|
|
be routed to another interface. To configure a masquerade rule you
|
|
construct a rule very similar to a firewall forwarding rule, but with
|
|
special options that tell the kernel to masquerade the datagram. The
|
|
<command>ipfwadm</command> command uses the <emphasis>-m</emphasis>
|
|
option, <command>ipchains</command> uses <literal>-j MASQ</literal>, and <command>iptables</command> uses
|
|
<literal>-j MASQUERADE</literal> to
|
|
indicate that datagrams matching the rule specification should be
|
|
masqueraded.
|
|
</para>
|
|
<?troff .wcon_off>
|
|
|
|
<para>
|
|
Let's look at an example.
|
|
A computing science student at Groucho Marx University has a number of
|
|
computers at home internetworked onto a small Ethernet-based local area
|
|
network. She has chosen to use one of the reserved private Internet network
|
|
addresses for her network. She shares her accomodation with other students,
|
|
all of whom have an interest in using the Internet. Because student living
|
|
conditions are very frugal, they cannot afford to use a permanent Internet
|
|
connection, so instead they use a simple dial-up PPP Internet connection.
|
|
They would all like to be able
|
|
<?troff .ne 10>
|
|
to share the connection to chat on IRC, surf
|
|
the Web, and retrieve files by FTP directly to each of their computers—IP
|
|
masquerade is the answer.
|
|
</para>
|
|
|
|
<para>
|
|
The student first configures a Linux machine to support the dial-up link and to
|
|
act as a router for the LAN. The IP address she is assigned when she dials up
|
|
isn't important. She configures the Linux router with IP masquerade and uses
|
|
one of the private network addresses for her LAN:
|
|
<literal>192.168.1.0</literal>. She ensures that each of the hosts on the
|
|
LAN has a default route pointing at the Linux router.
|
|
</para>
|
|
|
|
<para>
|
|
The following <command>ipfwadm</command> commands are all that are required to
|
|
make masquerading work in her configuration:
|
|
|
|
<screen>
|
|
# <userinput>ipfwadm -F -p deny</userinput>
|
|
# <userinput>ipfwadm -F -a accept -m -S 192.168.1.0/24 -D 0/0</userinput>
|
|
</screen>
|
|
|
|
or with <command>ipchains</command>:
|
|
|
|
<screen>
|
|
# <userinput>ipchains -P forward -j deny</userinput>
|
|
# <userinput>ipchains -A forward -s 192.168.1.0/24 -d 0/0 -j MASQ</userinput>
|
|
</screen>
|
|
|
|
or with <command>iptables</command>:
|
|
|
|
<screen>
|
|
# <userinput>iptables -t nat -P POSTROUTING DROP</userinput>
|
|
# <userinput>iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE</userinput>
|
|
</screen>
|
|
|
|
Now whenever any of the LAN hosts try to connect to a service on a
|
|
remote host, their datagrams will be automatically masqueraded by the
|
|
Linux masquerade router. The first rule in each example prevents the
|
|
Linux machine from routing any other datagrams and also adds some
|
|
security.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>masquerade</primary><secondary>listing rules</secondary></indexterm>
|
|
To list the masquerade rules you have created, use the <literal>-l</literal>
|
|
argument to the <command>ipfwadm</command>
|
|
command, as we described in earlier while discussing firewalls.
|
|
</para>
|
|
|
|
<para>
|
|
To list the rule we created earlier we use:
|
|
|
|
<screen>
|
|
# <userinput>ipfwadm -F -l -e</userinput>
|
|
</screen>
|
|
|
|
which should display something like:
|
|
|
|
<screen>
|
|
# <userinput>ipfwadm -F -l -e</userinput>
|
|
IP firewall forward rules, default policy: accept
|
|
pkts bytes type prot opt tosa tosx ifname ifaddress …
|
|
0 0 acc/m all ---- 0xFF 0x00 any any …
|
|
</screen>
|
|
|
|
The “<literal>/m</literal>” in the output indicates this is a
|
|
masquerade rule.
|
|
</para>
|
|
|
|
<para>
|
|
To list the masquerade rules with the <command>ipchains</command> command,
|
|
use the <command>-L</command> argument. If we list the rule
|
|
we created earlier with <command>ipchains</command>, the output will look like:
|
|
|
|
<screen>
|
|
<userinput># ipchains -L</userinput>
|
|
Chain input (policy ACCEPT):
|
|
Chain forward (policy ACCEPT):
|
|
target prot opt source destination ports
|
|
MASQ all ------ 192.168.1.0/24 anywhere n/a
|
|
|
|
Chain output (policy ACCEPT):
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
Any rules with a target of <literal>MASQ</literal> are masquerade rules.
|
|
</para>
|
|
|
|
<para>
|
|
Finally, to list the rules using <command>iptables</command> you need to use:
|
|
|
|
<screen width=98>
|
|
# <userinput>iptables -t nat -L</userinput>
|
|
Chain PREROUTING (policy ACCEPT)
|
|
target prot opt source destination
|
|
|
|
Chain POSTROUTING (policy DROP)
|
|
target prot opt source destination
|
|
MASQUERADE all -- anywhere anywhere MASQUERADE
|
|
|
|
Chain OUTPUT (policy ACCEPT)
|
|
target prot opt source destination
|
|
</screen>
|
|
|
|
Again, masquerade rules appear with a target of <literal>MASQUERADE</literal>.
|
|
</para>
|
|
|
|
<sect2 id="X-087-2-masq.setting.timing"><title>Setting Timing Parameters for IP Masquerade</title>
|
|
<para>
|
|
<indexterm><primary>masquerade</primary><secondary>setting timing parameters for</secondary></indexterm>
|
|
When each new connection is established, the IP masquerade software
|
|
creates an association in memory between each of the hosts involved in
|
|
the connection. You can view these associations at any time by
|
|
looking at the <filename>/proc/net/ip_masquerade</filename> file.
|
|
These associations will timeout after a period of inactivity, though.
|
|
</para>
|
|
|
|
<para>
|
|
<INDEXTERM startref="ipfwadm.config.masq" class=endofrange>
|
|
You can set the timeout values using the <command>ipfwadm</command> command.
|
|
The general syntax for this is:
|
|
|
|
<screen>
|
|
ipfwadm -M -s <<replaceable>tcp</replaceable>> <<replaceable>tcpfin</replaceable>> <<replaceable>udp</replaceable>>
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
<INDEXTERM startref="ipchains.config.masq" class=endofrange>
|
|
and for the <command>ipchains</command> command it is:
|
|
|
|
<screen>
|
|
ipchains -M -S <<replaceable>tcp</replaceable>> <<replaceable>tcpfin</replaceable>> <<replaceable>udp</replaceable>>
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
The <emphasis>iptables</emphasis> implementation uses much longer default
|
|
timers and does not allow you to set them.
|
|
</para>
|
|
|
|
<para>
|
|
<?troff .hw meanings>
|
|
Each of these values represents a timer used by the IP masquerade software and
|
|
are in units of seconds. The following table summarizes the timers and their
|
|
meanings:
|
|
</para>
|
|
|
|
<informaltable>
|
|
<tgroup cols=2><colspec colnum="2" colwidth="3.57i">
|
|
<thead>
|
|
<row>
|
|
<entry>Name</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry>tcp</entry>
|
|
<entry><para>
|
|
TCP session timeout. How long a TCP connection may remain idle before the
|
|
association for it is removed.
|
|
</para></entry>
|
|
</row>
|
|
<row>
|
|
<entry>tcpfin</entry>
|
|
<entry><para>
|
|
<?troff .hw disconnected>
|
|
TCP timeout after FIN. How long an association will remain
|
|
after a TCP connection has been disconnected.
|
|
</para></entry>
|
|
</row>
|
|
<row>
|
|
<entry>udp</entry>
|
|
<entry><para>
|
|
UDP session timeout. How long a UDP connection may remain idle before the
|
|
association for it is removed.
|
|
</para></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-masq.namelookups"><title>Handling Name Server Lookups</title>
|
|
<para>
|
|
<indexterm><primary>masquerade</primary><secondary>name server lookups</secondary></indexterm>
|
|
<indexterm><primary>name servers</primary><secondary>for IP masquerade</secondary></indexterm>
|
|
Handling domain name server lookups from the hosts on the LAN with IP
|
|
masquerading has always presented a problem. There are two ways of
|
|
accomodating DNS in a masquerade environment. You can tell each of the
|
|
hosts that they use the same DNS that the Linux router machine does,
|
|
and let IP masquerade do its magic on their DNS
|
|
requests. Alternatively, you can run a caching name server on the
|
|
Linux machine and have each of the hosts on the LAN use the Linux
|
|
machine as their DNS. Although a more aggressive action, this is
|
|
probably the better option because it reduces the volume of DNS
|
|
traffic travelling on the Internet link and will be marginally faster
|
|
for most requests, since they'll be served from the cache. The downside
|
|
to this configuration is that it is more complex. <xref
|
|
linkend="X-087-2-resolv.named-cachingonly">,” in Chapter 6, describes how to configure
|
|
a caching name server.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1><title>More About Network Address Translation</title>
|
|
<para>
|
|
<indexterm><primary>NAT (Network Address Translation)</primary></indexterm>
|
|
The <emphasis>netfilter</emphasis> software is capable of many different types
|
|
of Network Address Translation. IP Masquerade is one simple application of it.
|
|
</para>
|
|
|
|
<para>
|
|
It is possible, for example, to build NAT rules that translate only certain
|
|
addresses or ranges of addresses and leave all others untouched, or to
|
|
translate addresses into pools of addresses rather than just a single address,
|
|
as masquerade does. You can in fact use the <command>iptables</command> command
|
|
to generate NAT rules that map just about anything, with
|
|
combinations of matches using any of the standard attributes, such as source
|
|
address, destination address, protocol type, port number, etc.
|
|
</para>
|
|
|
|
<para>
|
|
<INDEXTERM startref="iptables.config.masq" class=endofrange>
|
|
Translating the Source Address of a datagram is referred to as “Source
|
|
NAT,” or <literal>SNAT</literal>, in the <emphasis>netfilter</emphasis>
|
|
documentation. Translating the Destination Address of a datagram is known as
|
|
“Destination NAT,” or <literal>DNAT</literal>. Translating the TCP
|
|
or UDP port is known by the term <literal>REDIRECT</literal>.
|
|
<literal>SNAT</literal>, <literal>DNAT</literal>, and
|
|
<literal>REDIRECT</literal> are targets that you may use with the
|
|
<command>iptables</command> command to build more complex and sophisticated
|
|
rules.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>IPTABLES-HOWTO</primary></indexterm>
|
|
<INDEXTERM><PRIMARY>HOWTOs</PRIMARY><SECONDARY>IPTABLES</SECONDARY></INDEXTERM>
|
|
The topic of Network Address Translation and its uses warrants at least a
|
|
whole chapter of its own.<footnote><para>
|
|
... and perhaps even a whole book!
|
|
</para>
|
|
</footnote> Unfortunately we don't have the space in this book to cover it in
|
|
any greater depth. You should read the IPTABLES-HOWTO for more information, if
|
|
you're interested in discovering more about how you might use Network Address
|
|
Translation.
|
|
</para>
|
|
</sect1>
|
|
|
|
<indexterm class="endofrange" startref="chmq.ip.masq">
|
|
</chapter>
|