extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2025-06-14 13:47:07 +02:00
Code Issues Packages Projects Releases Wiki Activity

Update 3.0 Routing doc

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2732 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2005-09-25 15:24:59 +00:00
parent 69f5334d77
commit 0587f6a69e
1 changed files with 119 additions and 343 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

408
Shorewall-docs2/Shorewall_and_Routing.xml
View File

@ -15,7 +15,7 @@
</author> </author>
</authorgroup> </authorgroup>
<pubdate>2005-08-11</pubdate> <pubdate>2005-09-25</pubdate>
<copyright> <copyright>
<year>2005</year> <year>2005</year>
@ -305,138 +305,145 @@
Shorewall configuration files, enter "-" in a column if you don't want Shorewall configuration files, enter "-" in a column if you don't want
to enter any value.</para> to enter any value.</para>
<glossary> <variablelist>
<glossdiv> <varlistentry>
<title>/etc/shorewall/providers:</title> <term>NAME</term>
<glossentry> <listitem>
<glossterm>NAME</glossterm>
<glossdef>
<para>The provider name. Must begin with a letter and consist of <para>The provider name. Must begin with a letter and consist of
letters and digits. The provider name becomes the name of the letters and digits. The provider name becomes the name of the
generated routing table for this provider.</para> generated routing table for this provider.</para>
</glossdef> </listitem>
</glossentry> </varlistentry>
<glossentry> <varlistentry>
<glossterm>NUMBER</glossterm> <term>NUMBER</term>
<glossdef> <listitem>
<para>A number between 1 and 252. This becomes the routing table <para>A number between 1 and 252. This becomes the routing table
number for the generated table for this provider.</para> number for the generated table for this provider.</para>
</glossdef> </listitem>
</glossentry> </varlistentry>
<glossentry> <varlistentry>
<glossterm>MARK</glossterm> <term>MARK</term>
<glossdef> <listitem>
<para>A mark value used in your /etc/shorewall/tcrules file to <para>A mark value used in your /etc/shorewall/tcrules file to
direct packets to this provider. Shorewall will also mark direct packets to this provider. Shorewall will also mark
connections that have seen input from this provider with this connections that have seen input from this provider with this
value and will restore the packet mark in the PREROUTING value and will restore the packet mark in the PREROUTING
CHAIN.</para> CHAIN.</para>
</glossdef> </listitem>
</glossentry> </varlistentry>
<glossentry> <varlistentry>
<glossterm>DUPLICATE</glossterm> <term>DUPLICATE</term>
<glossdef> <listitem>
<para>Gives the name or number of a routing table to duplicate. <para>Gives the name or number of a routing table to duplicate.
May be 'main' or the name or number of a previously declared May be 'main' or the name or number of a previously declared
provider. For most applications, you want to specify 'main' provider. For most applications, you want to specify 'main'
here.</para> here.</para>
</glossdef> </listitem>
</glossentry> </varlistentry>
<glossentry> <varlistentry>
<glossterm>INTERFACE</glossterm> <term>INTERFACE</term>
<glossdef> <listitem>
<para>The name of the interface to the provider.</para> <para>The name of the interface to the provider.</para>
</glossdef> </listitem>
</glossentry> </varlistentry>
<glossentry> <varlistentry>
<glossterm>GATEWAY</glossterm> <term>GATEWAY</term>
<glossdef> <listitem>
<para>The IP address of the provider's Gateway router.</para> <para>The IP address of the provider's Gateway router.</para>
<para>You can enter <emphasis role="bold">detect</emphasis> here <para>You can enter <emphasis role="bold">detect</emphasis> here
and Shorewall will attempt to automatically determine the and Shorewall will attempt to automatically determine the gateway
gateway IP address.</para> IP address.</para>
<para><emphasis role="bold">Hint:</emphasis> <emphasis <para><emphasis role="bold">Hint:</emphasis> <emphasis
role="bold">"detect"</emphasis> is appropriate for use in cases role="bold">"detect"</emphasis> is appropriate for use in cases
where the interface named in the INTERFACE column is dynamically where the interface named in the INTERFACE column is dynamically
configured via DHCP etc.</para> configured via DHCP etc.</para>
</glossdef> </listitem>
</glossentry> </varlistentry>
<glossentry> <varlistentry>
<glossterm>OPTIONS</glossterm> <term>OPTIONS</term>
<glossdef> <listitem>
<para>A comma-separated list from the following:</para> <para>A comma-separated list from the following:</para>
<glosslist> <variablelist>
<glossentry> <varlistentry>
<glossterm>track</glossterm> <term>track</term>
<glossdef> <listitem>
<para>If specified, connections FROM this interface are to <para>If specified, connections FROM this interface are to
be tracked so that responses may be routed back out this be tracked so that responses may be routed back out this
same interface.</para> same interface.</para>
<para>You want specify 'track' if internet hosts will be <para>You want specify 'track' if internet hosts will be
connecting to local servers through this provider. Any connecting to local servers through this provider. Any time
time that you specify 'track', you will also want to that you specify 'track', you will also want to specify
specify 'balance' (see below).</para> 'balance' (see below).</para>
</glossdef> </listitem>
</glossentry> </varlistentry>
<glossentry> <varlistentry>
<glossterm>balance</glossterm> <term>balance</term>
<glossdef> <listitem>
<para>The providers that have 'balance' specified will get <para>The providers that have 'balance' specified will get
outbound traffic load-balanced among them. Balancing will outbound traffic load-balanced among them. Balancing will
not be perfect, as it is route based, and routes are not be perfect, as it is route based, and routes are cached.
cached. This means that routes to often-used sites will This means that routes to often-used sites will always be
always be over the same provider.</para> over the same provider.</para>
<para>By default, each provider is given the same weight <para>By default, each provider is given the same weight (1)
(1) . Beginning with 2.4.0-RC3, you can change the weight . Beginning with 2.4.0-RC3, you can change the weight of a
of a given provider by following given provider by following <emphasis>balance</emphasis>
<emphasis>balance</emphasis> with "=" and the desired with "=" and the desired weight (e.g., balance=2). The
weight (e.g., balance=2). The weights reflect the relative weights reflect the relative bandwidth of the providers
bandwidth of the providers connections and should be small connections and should be small numbers since the kernel
numbers since the kernel actually creates additional actually creates additional default routes for each weight
default routes for each weight increment.</para> increment.</para>
</glossdef> </listitem>
</glossentry> </varlistentry>
</glosslist>
</glossdef>
</glossentry>
<glossentry> <varlistentry>
<glossterm>COPY</glossterm> <term>loose</term>
<glossdef> <listitem>
<para>When you specify an existing table in the DUPLICATE <para>Do not include routing rules that force traffic whose
column, Shorewall copies all routes through the interface source IP is an address of the INTERFACE to be routed to
specified in the INTERFACE column plus the interfaces listed in this provider. Useful for defining providers that are to be
this column. At a minumum, you should list all interfaces on used only when the appropriate packet mark is
your firewall in this column except those internet interfaces applied.</para>
specified in the INTERFACE column of entries in this </listitem>
file.</para> </varlistentry>
</glossdef> </variablelist>
</glossentry> </listitem>
</glossdiv> </varlistentry>
</glossary>
<varlistentry>
<term>COPY</term>
<listitem>
<para>When you specify an existing table in the DUPLICATE column,
Shorewall copies all routes through the interface specified in the
INTERFACE column plus the interfaces listed in this column. At a
minumum, you should list all interfaces on your firewall in this
column except those internet interfaces specified in the INTERFACE
column of entries in this file.</para>
</listitem>
</varlistentry>
</variablelist>
</section> </section>
<section> <section>
@ -447,8 +454,9 @@
<orderedlist> <orderedlist>
<listitem> <listitem>
<para>An ip rule is generated for each IP address on the INTERFACE <para>Unless <emphasis role="bold">loose</emphasis> is specified, an
that routes traffic from that address through the associated routing ip rule is generated for each IP address on the INTERFACE that
routes traffic from that address through the associated routing
table.</para> table.</para>
</listitem> </listitem>
@ -562,236 +570,4 @@ eth1 eth2 130.252.99.27</programlisting>
2:P &lt;local network&gt; 0.0.0.0/0 tcp 25</programlisting> 2:P &lt;local network&gt; 0.0.0.0/0 tcp 25</programlisting>
</section> </section>
</section> </section>
<section id="RouteTarget">
<title>Experimental Routing with Shorewall 2.3.2 and Later</title>
<para>Beginning with Shorewall 2.3.2, Shorewall is integrated with the
ROUTE target extension available from Netfilter Patch-O-Matic-NG (<ulink
url="http://www.netfilter.org">http://www.netfilter.org</ulink>).</para>
<warning>
<para>As of this writing, I know of no distribution that is shipping a
kernel or iptables with the ROUTE target patch included. This means that
you must patch and build your own kernel and iptables in order to be
able to use the feature described in this section. <emphasis
role="bold">This code remains experimental</emphasis> since there is no
intent by the Netfilter team to ever submit the ROUTE target patch for
inclusion in the official kernels from kernel.org. This support may also
be removed from Shorewall in a future release.</para>
</warning>
<para>See <ulink url="FAQ.htm#faq42">Shorewall FAQ 42</ulink> for
information about determining if your kernel and iptables have this
support enabled. You must be running Shorewall 2.3.2 or later to make this
determination.</para>
<para>Routing with Shorewall is specified through entries in
<filename>/etc/shorewall/routes</filename>. Note that entries in the
<filename>/etc/shorewall/routes</filename> file override the routing
specified in your routing tables. These rules generate Netfilter rules in
the mangle tables FORWARD chain or OUTPUT chain depending whether the
packets are being routed through the firewall or originate on the firewall
itself (see the flow diagram at the top of this article).</para>
<para>Columns in this file are as follows:</para>
<glosslist>
<glossentry>
<glossterm>SOURCE</glossterm>
<glossdef>
<para>Source of the packet. May be any of the following:</para>
<itemizedlist>
<listitem>
<para>A host or network address</para>
</listitem>
<listitem>
<para>A network interface name.</para>
</listitem>
<listitem>
<para>The name of an ipset prefaced with "+"</para>
</listitem>
<listitem>
<para>$FW (for packets originating on the firewall)</para>
</listitem>
<listitem>
<para>A MAC address in Shorewall format</para>
</listitem>
<listitem>
<para>A range of IP addresses (assuming that your kernel and
iptables support range match)</para>
</listitem>
<listitem>
<para>A network interface name followed by ":" and an address or
address range.</para>
</listitem>
</itemizedlist>
</glossdef>
</glossentry>
<glossentry>
<glossterm>DEST</glossterm>
<glossdef>
<para>Destination of the packet. May be any of the following:</para>
<itemizedlist>
<listitem>
<para>A host or network address</para>
</listitem>
<listitem>
<para>A network interface name (determined from routing
table(s))</para>
</listitem>
<listitem>
<para>The name of an ipset prefaced with "+"</para>
</listitem>
<listitem>
<para>A network interface name followed by ":" and an address or
address range.</para>
</listitem>
</itemizedlist>
</glossdef>
</glossentry>
<glossentry>
<glossterm>PROTO</glossterm>
<glossdef>
<para>Protocol - Must be a protocol listed in /etc/protocols, a
number or "ipp2p", a number, or "all". "ipp2p" require ipp2p match
support in your kernel and iptables.</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>PORT(S)</glossterm>
<glossdef>
<para>Destination Ports. A comma-separated list of Port names (from
/etc/services), port numbers or port ranges; if the protocol is
"icmp", this column is interpreted as the destination
icmp-type(s).</para>
<para>If the protocol is ipp2p, this column is interpreted as an
ipp2p option without the leading "--" (example "bit" for
bit-torrent). If no PORT is given, "ipp2p" is assumed.</para>
<para>This column is ignored if PROTOCOL = all but must be entered
if any of the following field is supplied. In that case, it is
suggested that this field contain "-"</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>SOURCE PORT(S)</glossterm>
<glossdef>
<para>Optional) Source port(s). If omitted, any source port is
acceptable. Specified as a comma-separated list of port names, port
numbers or port ranges.</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>TEST</glossterm>
<glossdef>
<para>Defines a test on the existing packet or connection mark. The
rule will match only if the test returns true. Tests have the
format</para>
<blockquote>
<para>[!]&lt;value&gt;[/&lt;mask&gt;][:C]</para>
</blockquote>
<para>where:</para>
<glosslist>
<glossentry>
<glossterm>!</glossterm>
<glossdef>
<para>Inverts the test (not equal)</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>&lt;value&gt;</glossterm>
<glossdef>
<para>Value of the packet or connection mark.</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>&lt;mask&gt;</glossterm>
<glossdef>
<para>A mask to be applied to the mark before testing</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>:C</glossterm>
<glossdef>
<para>Designates a connection mark. If omitted, the packet
mark's value is tested</para>
</glossdef>
</glossentry>
</glosslist>
</glossdef>
</glossentry>
<glossentry>
<glossterm>INTERFACE</glossterm>
<glossdef>
<para>The interface that the packet is to be routed out of. If you
do not specify this field then you must place "-" in this column and
enter an IP address in the GATEWAY column.</para>
</glossdef>
</glossentry>
<glossentry>
<glossterm>GATEWAY</glossterm>
<glossdef>
<para>The gateway that the packet is to be forwarded through.</para>
</glossdef>
</glossentry>
</glosslist>
<para>The idea here is that traffic that matches the SOURCE, DEST, PROTO,
PORT(S), SOURCE PORT(S) and TEST columns is routed out of the INTERFACE
through the optional GATEWAY.</para>
<blockquote>
<para>Example:</para>
<para>Your local interface is eth1 and your DMZ interface is eth2. You
want to run Squid as a transparent proxy for HTTP on 192.168.3.22 in
your DMZ. You would use the following entry in
/etc/shorewall/routes:</para>
<programlisting>#SOURCE DEST PROTO PORT(S) SOURCE TEST INTERFACE GATEWAY
# PORT(S)
eth1 0.0.0.0/0 tcp 80 - - eth1 192.168.3.22</programlisting>
<para>This entry specifies that "traffic coming in through eth1 to TCP
port 80 is to be routed out of eth1 to gateway 192.168.3.22".</para>
</blockquote>
</section>
</article> </article>