extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-11-08 00:34:04 +01:00
Code Issues Packages Projects Releases Wiki Activity

Rename route_rules to rtrules

Browse Source 
Signed-off-by: Tom Eastep <teastep@shorewall.net>
This commit is contained in:
Tom Eastep 2012-01-09 06:38:55 -08:00
parent 048d380c28
commit 4c2df6fea7
4 changed files with 142 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Shorewall/configfiles/route_rules → Shorewall/configfiles/rtrules
View File

@ -1,7 +1,7 @@
#
# Shorewall version 4 - route_rules File
# Shorewall version 4 - route rules File
#
# For information about entries in this file, type "man shorewall-route_rules"
# For information about entries in this file, type "man shorewall-rtrules"
#
# For additional information, see http://www.shorewall.net/MultiISP.html
####################################################################################

13
Shorewall/install.sh
View File

@ -731,12 +731,15 @@ fi
#
# Install the Route Rules file
#
run_install $OWNERSHIP -m 0644 route_rules ${DESTDIR}/usr/share/$PRODUCT/configfiles/
run_install $OWNERSHIP -m 0644 route_rules.annotated ${DESTDIR}/usr/share/$PRODUCT/configfiles/
run_install $OWNERSHIP -m 0644 rtrules ${DESTDIR}/usr/share/$PRODUCT/configfiles/
run_install $OWNERSHIP -m 0644 rrules.annotated ${DESTDIR}/usr/share/$PRODUCT/configfiles/
if [ -z "$SPARSE" -a ! -f ${DESTDIR}/etc/$PRODUCT/route_rules ]; then
run_install $OWNERSHIP -m 0600 route_rules${suffix} ${DESTDIR}/etc/$PRODUCT/route_rules
echo "Routing rules file installed as ${DESTDIR}/etc/$PRODUCT/route_rules"
if [ -f ${DESTDIR}/etc/$PRODUCT/route_rules -a ! ${DESTDIR}/etc/$PRODUCT/rtrules ]; then
mv -f ${DESTDIR}/etc/$PRODUCT/route_rules ${DESTDIR}/etc/$PRODUCT/rtrules
echo "${DESTDIR}/etc/$PRODUCT/route_rules has been renamed ${DESTDIR}/etc/$PRODUCT/rtrules"
elif [ -z "$SPARSE" -a ! -f ${DESTDIR}/etc/$PRODUCT/rtrules ]; then
run_install $OWNERSHIP -m 0600 rtrules${suffix} ${DESTDIR}/etc/$PRODUCT/rtrules
echo "Routing rules file installed as ${DESTDIR}/etc/$PRODUCT/rtrules"
fi
#

4
Shorewall6/configfiles/route_rules → Shorewall6/configfiles/rtrules
View File

@ -1,7 +1,7 @@
#
# Shorewall6 version 4 - route_rules File
# Shorewall6 version 4 - route rules File
#
# For information about entries in this file, type "man shorewall6-route_rules"
# For information about entries in this file, type "man shorewall6-rtrules"
#
# For additional information, see http://www.shorewall.net/MultiISP.html
####################################################################################

158
docs/MultiISP.xml
View File

@ -28,6 +28,12 @@
<year>2009</year>
<year>2010</year>
<year>2011</year>
<year>2012</year>
<holder>Thomas M. Eastep</holder>
</copyright>
@ -43,7 +49,7 @@
</articleinfo>
<warning>
<para>This document describes the Multi-ISP facility in Shorewall 4.3.5
<para>This document describes the Multi-ISP facility in Shorewall 4.5.0
and later. If you are running an earlier release, please see the
documentation for that release.</para>
</warning>
@ -403,8 +409,8 @@
specify <emphasis role="bold">balance</emphasis> even if
you don't need it. You can still use entries in
<filename>/etc/shorewall/tcrules</filename> and
<filename>/etc/shorewall/route_rules</filename> to force
all traffic to one provider or another.<note>
<filename>/etc/shorewall/rtrules</filename> to force all
traffic to one provider or another.<note>
<para>If you don't heed this advice then please read
and follow the advice in <ulink
url="FAQ.htm#faq57">FAQ 57</ulink> and <ulink
@ -450,9 +456,9 @@
not specified. So, if you have multiple IP addresses on a
provider interface, you may be able to replace the rules
that Shorewall generates with one or two rules in
<filename>/etc/shorewall/route_rules</filename>. In that
case, you can specify <emphasis role="bold">loose</emphasis>
to suppress Shorewall's rule generation. See the <link
<filename>/etc/shorewall/rtrules</filename>. In that case,
you can specify <emphasis role="bold">loose</emphasis> to
suppress Shorewall's rule generation. See the <link
linkend="Complete">example</link> below.</para>
</listitem>
</varlistentry>
@ -624,7 +630,7 @@
omit interfaces like <emphasis role="bold">tun</emphasis> interfaces
that are created dynamically. Traffic to networks handled by those
interfaces should be routed through the main table using entries in
<filename>/etc/shorewall/route_rules</filename> (see Example 2 <link
<filename>/etc/shorewall/rtrules</filename> (see Example 2 <link
linkend="Examples">below</link>) or by using <link
linkend="USE_DEFAULT_RT">USE_DEFAULT_RT=Yes</link>.</para>
@ -685,7 +691,7 @@
with the provider's MARK value in
<filename>/etc/shorewall/tcrules</filename> and you must do that marking
in the PREROUTING chain; or, you must provide the appropriate rules in
<filename>/etc/shorewall/route_rules</filename>.</para>
<filename>/etc/shorewall/rtrules</filename>.</para>
</section>
<section>
@ -720,7 +726,7 @@ eth1 0.0.0.0/0 130.252.99.27</programlisting>
effect on which ISP a particular connection will be sent through. That
is rather the purpose of entries in
<filename>/etc/shorewall/tcrules</filename> and
<filename>/etc/shorewall/route_rules</filename>.</para>
<filename>/etc/shorewall/rtrules</filename>.</para>
</warning>
</section>
@ -957,9 +963,9 @@ eth3 0.0.0.0/0 16.105.78.4</programlisting></para>
<para>Note that some traffic originating on the firewall doesn't have a
SOURCE IP address before routing. At least one Shorewall user reports
that an entry in <filename>/etc/shorewall/route_rules</filename> with
'lo' in the SOURCE column seems to be the most reliable way to direct
such traffic to a particular ISP.</para>
that an entry in <filename>/etc/shorewall/rtrules</filename> with 'lo'
in the SOURCE column seems to be the most reliable way to direct such
traffic to a particular ISP.</para>
<para>Example:</para>
@ -968,12 +974,13 @@ lo - shorewall 1000</programlisting>
</section>
<section id="route_rules">
<title>/etc/shorewall/route_rules</title>
<title>/etc/shorewall/rtrules (formerly
/etc/shorewall/route_rules)</title>
<para>The <filename>route_rules</filename> file allows assigning certain
<para>The <filename>rtrules</filename> file allows assigning certain
traffic to a particular provider just as entries in the
<filename>tcrules</filename> file. The difference between the two files
is that entries in <filename>route_rules</filename> are independent of
is that entries in <filename>rtrules</filename> are independent of
Netfilter.</para>
<section id="Routing_rules">
@ -999,7 +1006,7 @@ gateway:~ #</programlisting>
</section>
<section id="route_rules_columns">
<title>Columns in the route_rules file</title>
<title>Columns in the rtrules file</title>
<para>Columns in the file are:</para>
@ -1294,8 +1301,8 @@ lillycat: #</programlisting>
USE_DEFAULT_RT=Yes, you can easily cause all traffic to use one provider
except when you explicitly direct it to use the other provider via
<ulink
url="manpages/shorewall-route_rules.html">shorewall-route_rules</ulink>
(5) or <ulink
url="manpages/shorewall-route_rules.html">shorewall-rtrules</ulink> (5)
or <ulink
url="manpages/shorewall-tcrules.html">shorewall-tcrules</ulink>
(5).</para>
@ -1304,7 +1311,7 @@ lillycat: #</programlisting>
<para>/etc/shorewall/providers:<programlisting>#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
linksys 1 1 - wlan0 172.20.1.1 track,balance=1,optional
shorewall 2 2 - eth0 192.168.1.254 track,balance=2,optional</programlisting>/etc/shorewall/route_rules:<programlisting>#SOURCE DEST PROVIDER PRIORITY
shorewall 2 2 - eth0 192.168.1.254 track,balance=2,optional</programlisting>/etc/shorewall/rtrules:<programlisting>#SOURCE DEST PROVIDER PRIORITY
- - shorewall 11999</programlisting></para>
<para>Tuomo Soini describes the following issue when using
@ -1325,7 +1332,7 @@ shorewall 2 2 - eth0 192.168.1.254 track,balance=2,optional<
interface because the main routing table included a route to the
/19.</para>
<para>The solution was to add an additional entry to route_rules:</para>
<para>The solution was to add an additional entry to rtrules:</para>
<programlisting>#SOURCE DEST PROVIDER PRIORITY
70.90.191.0/27 91.156.0.0/19 ISP1 900</programlisting>
@ -1339,6 +1346,101 @@ shorewall 2 2 - eth0 192.168.1.254 track,balance=2,optional<
10001: from all fwmark 0x200 lookup ISP2</programlisting>
</section>
<section>
<title>An alternative form of balancing</title>
<para>Beginning with Shorewall 4.5.0, an alternative to the
<option>balance</option>=<replaceable>weight</replaceable> option in
<ulink
url="manpages/shorewall-providers.html">shorewall-providers</ulink> (5)
is available in the form of a PROBABILITY column in <ulink
url="???">shorewall-tcrules</ulink> (5).</para>
<para>Here's an example:</para>
<para><filename>/etc/shorewall/shorewall.conf</filename>:</para>
<programlisting>MARK_IN_FORWARD_CHAIN=No
...
USE_DEFAULT_RT=Yes
...
TC_BITS=0
PROVIDER_BITS=2
PROVIDER_OFFSET=16
MASK_BITS=8
ZONE_BITS=4
</programlisting>
<note>
<para> PROVIDER_OFFSET=16 and ZONE_BITS=4 means that the provider mask
will be 0xf0000.</para>
</note>
<para><filename>/etc/shorewall/providers</filename>:</para>
<programlisting>#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
ComcastB 1 - - eth1 70.90.191.126 loose,balance
ComcastC 2 - - eth0 detect loose,balance
</programlisting>
<note>
<para> The <option>loose</option> option is specified so that the
compiler will not generate and rules based on interface IP addresses.
That way we have complete control over the priority of such rules
through entries in the rtrules file.</para>
</note>
<para><filename>/etc/shorewall/rtrules</filename>:</para>
<programlisting>#SOURCE DEST PROVIDER PRIORITY
70.90.191.120/29 - ComcastB 1000
&amp;eth0 - ComcastC 1000</programlisting>
<note>
<para>This example assumes that eth0 has a dynamic address, so
<emphasis role="bold">&amp;eth0</emphasis> is used in the SOURCE
column. That will cause the first IP address of eth0 to be substituted
when the firewall is started/restarted.</para>
</note>
<note>
<para> Priority = 1000 means that these rules will come before rules
that select a provider based on marks.</para>
</note>
<para><filename>/etc/shorewall/tcrules</filename>:</para>
<programlisting> #MARK SOURCE DEST PROTO DEST
# PORT(S)
CONTINUE - 70.90.191.120/29
CONTINUE - 10.0.10.0/24
CONTINUE - - tcp 80
# 70.90.191.120/29 is the local public subnet. 10.0.10.0/24 is a
# local network on eth1. We don't want to mark TCP 80, because
# we run a transparent proxy on the firewall.
0X10000/0xf0000 eth2 - ; probability=0.66666667
0x20000/0xf0000 eth2 - ; test=0/0x30000
# The above two split traffic entering the firewall through eth2
# (local LAN) between the two providers with 2/3 of the traffic
# going to eth1 and 1/3 going to eth0.
CONTINUE fw:70.90.191.120/29
CONTINUE fw 172.20.1.0/22
CONTINUE fw 70.90.191.120/29
CONTINUE fw 10.0.10.0/24
# Similar to rules above
0X10000/0xf0000 fw - ; probability=0.66666667
0x20000/0xf0000 fw - ; test=0/0x30000
# Again, split traffic from the firewall 2:1 in favor of eth1.
</programlisting>
</section>
<section id="LinkMonitor">
<title>Gateway Monitoring and Failover</title>
@ -1930,13 +2032,13 @@ exit 0
</listitem>
<listitem>
<para>You must add route_rules entries for networks that are
accessed through a particular provider.</para>
<para>You must add rtrules entries for networks that are accessed
through a particular provider.</para>
</listitem>
<listitem>
<para>If you have additional IP addresses through either provider,
you must add <filename>route_rules</filename> to direct traffic FROM
you must add <filename>rtrules</filename> to direct traffic FROM
each of those addresses through the appropriate provider.</para>
</listitem>
@ -2039,7 +2141,7 @@ wireless 3 3 - wlan0 172.20.1.1 track,o
</listitem>
</orderedlist>
<para>Here is the route_rules file:<programlisting>#SOURCE DEST PROVIDER PRIORITY
<para>Here is the rtrules file:<programlisting>#SOURCE DEST PROVIDER PRIORITY
- 206.124.146.176/31 avvanta 1000
- 206.124.146.178/31 avvanta 1000
- 206.124.146.180/32 avvanta 1000</programlisting></para>
@ -2154,7 +2256,7 @@ wlan0 192.168.0.0/24</programlisting><note>
<para>Connections initiated by the server and connections requested by
clients on the firewall that have bound their local socket to one of
the DSL IP addresses. Two entries in
<filename>/etc/shorewall/route_rules</filename> take care of that
<filename>/etc/shorewall/rtrules</filename> take care of that
traffic.</para>
</listitem>
</itemizedlist>
@ -2194,7 +2296,7 @@ Comcast 2 0x200 main eth3 detect track,balance
provider. The 'tun*' included in the COPY column is there because I run a
routed OpenVPN server on the firewall.</para>
<para><filename>/etc/shorewall/route_rules</filename>:</para>
<para><filename>/etc/shorewall/rtrules</filename>:</para>
<programlisting>#SOURCE DEST PROVIDER PRIORITY
- 172.20.0.0/24 main 1000 # Addresses assigned by routed OpenVPN server
@ -2203,8 +2305,8 @@ Comcast 2 0x200 main eth3 detect track,balance
- 216.168.3.44 Avvanta 26000 # Avvanta NNTP Server -- verifies source IP address
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
<para>The <filename>/etc/shorewall/route_rules </filename>entries provide
all of the provider selection necessary so my
<para>The <filename>/etc/shorewall/rtrules </filename>entries provide all
of the provider selection necessary so my
<filename>/etc/shorewall/tcrules</filename> file is used exclusively for
traffic shaping of the Avvanta line. Note that I still need to provide
values in the MARK colum of <filename>/etc/shorewall/providers</filename>