extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-12-22 14:20:40 +01:00
Code Issues Packages Projects Releases Wiki Activity

More cleanup of the Multi-ISP null routing section.

Browse Source 
Signed-off-by: Tom Eastep <teastep@shorewall.net>
This commit is contained in:
Tom Eastep 2013-03-24 09:24:57 -07:00
parent 0c30e7c013
commit 1dfbc11cfa
1 changed files with 80 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

107
docs/MultiISP.xml
View File

@ -1212,7 +1212,7 @@ Comcast 192.168.4.0/24 | ip -4 route add 1
<para>Null routing is a type of routing which discards a given packet <para>Null routing is a type of routing which discards a given packet
instead of directing it through a specific predefined route. Generally instead of directing it through a specific predefined route. Generally
speaking there are 3 different types of Null routing as indicated speaking, there are 3 different types of Null routing as indicated
below:</para> below:</para>
<orderedlist> <orderedlist>
@ -1221,7 +1221,7 @@ Comcast 192.168.4.0/24 | ip -4 route add 1
<para>When used, a request for a routing decision returns a <para>When used, a request for a routing decision returns a
destination with an unreachable route type, an ICMP unreachable is destination with an unreachable route type, an ICMP unreachable is
generated (icmp code 3) and returned to the source address.</para> generated (icmp type 3) and returned to the source address.</para>
<para>Example:</para> <para>Example:</para>
@ -1257,7 +1257,7 @@ ip route add prohibit 192.168.14.0/26
ip route add prohibit 82.32.0.0/12</programlisting> ip route add prohibit 82.32.0.0/12</programlisting>
<para>"Prohibit" type routes are also indicated by a dash in the <para>"Prohibit" type routes are also indicated by a dash in the
"Iface" column as indicated above.</para> "Iface" column as shown above.</para>
</listitem> </listitem>
<listitem> <listitem>
@ -1265,8 +1265,8 @@ ip route add prohibit 82.32.0.0/12</programlisting>
<para>The difference between this type of routing and the previous <para>The difference between this type of routing and the previous
two listed above is that a packet matching a route with the route two listed above is that a packet matching a route with the route
type blackhole is discarded. No ICMP is sent and no packet is type blackhole is simply discarded (DROPed). No ICMP is sent and no
forwarded.</para> packet is forwarded.</para>
<para>Example:</para> <para>Example:</para>
@ -1274,7 +1274,7 @@ ip route add prohibit 82.32.0.0/12</programlisting>
ip route add blackhole 192.168.14.0/26 ip route add blackhole 192.168.14.0/26
ip route add blackhole 82.32.0.0/12</programlisting> ip route add blackhole 82.32.0.0/12</programlisting>
<para>Blackhole routes are usually indicated with a start ("*") in <para>Blackhole routes are usually indicated with a star ("*") in
the "Iface" column:</para> the "Iface" column:</para>
<programlisting>~# route -n <programlisting>~# route -n
@ -1303,10 +1303,11 @@ Destination Gateway Genmask Flags Metric Ref Use Iface
networks).</para> networks).</para>
<para>When combined with route filtering (ROUTE_FILTER=Yes or <para>When combined with route filtering (ROUTE_FILTER=Yes or
routefilter in shorewall-interfaces(5)), this option ensures that routefilter in <ulink
packets with an RFC1918 source address are only accepted from url="manpages/shorewall-interfaces.html">shorewall-interfaces</ulink>(5)),
interfaces having known routes to networks using such this option ensures that packets with an RFC1918 source address
addresses.</para> are only accepted from interfaces having known routes to networks
using such addresses.</para>
<para>When this option is used, the blackhole routes for all <para>When this option is used, the blackhole routes for all
RFC1918 subnets are defined for the "main" routing table only. RFC1918 subnets are defined for the "main" routing table only.
@ -1341,15 +1342,11 @@ ip replace blackhole 192.168.0.0/16
<para>This option allows for a better control over what is defined <para>This option allows for a better control over what is defined
as a null route in Shorewall and also allows for custom-defined as a null route in Shorewall and also allows for custom-defined
subnets (in addition to RFC1918 type networks) to be defined. subnets (in addition to RFC1918 type networks) to be added.
Blackhole routes defined in this way need to include the word Blackhole routes defined in this way need to include the word
"blackhole" in the GATEWAY column and the DEVICE column must also "blackhole" in the GATEWAY column and the DEVICE column must also
be ommitted (see example below).</para> be ommitted (see example below).</para>
<para>It is worth noting that blackhole routes created in such a
way cannot be "undone" automatically and have to be deleted
manually using the "ip route del" command.</para>
<para>Example of use <para>Example of use
(<filename>/etc/shorewall/routes</filename>):</para> (<filename>/etc/shorewall/routes</filename>):</para>
@ -1360,11 +1357,28 @@ dmz 192.168.14.0/26 blackhole
</programlisting> </programlisting>
<para>The above generates the following 3 statements for execution <para>The above generates the following 3 statements for execution
upon Shorewall startup: </para> upon Shorewall startup.</para>
<para>Shorewall 4.5.14:</para>
<programlisting>ip route add blackhole 10.0.0.0/8 table main
ip route add blackhole 82.32.0.0/12 table dmz
ip route add blackhole 192.168.14.0/26 table dmz</programlisting>
<para>Shorewall 4.5.15 and later:</para>
<programlisting>ip route replace blackhole 10.0.0.0/8 table main <programlisting>ip route replace blackhole 10.0.0.0/8 table main
ip route replace blackhole 82.32.0.0/12 table dmz ip route replace blackhole 82.32.0.0/12 table dmz
ip route replace blackhole 192.168.14.0/26 table dmz</programlisting> ip route replace blackhole 192.168.14.0/26 table dmz</programlisting>
<important>
<para>When blackhole routes are added to a
<replaceable>provider</replaceable> (including 'main'),
Shorewall creates a shell script file in
${VARDIR}/undo_<replaceable>provider</replaceable>_routing to
undo the routing, if needed (see below as to some instances when
this may be necessary).</para>
</important>
</listitem> </listitem>
</orderedlist> </orderedlist>
@ -1412,6 +1426,15 @@ dmz 192.168.14.0/26 unreachable
<programlisting>ip route replace unreachable 10.0.0.0/8 table main <programlisting>ip route replace unreachable 10.0.0.0/8 table main
ip route replace unreachable 82.32.0.0/12 table dmz ip route replace unreachable 82.32.0.0/12 table dmz
ip route replace unreachable 192.168.14.0/26 table dmz</programlisting> ip route replace unreachable 192.168.14.0/26 table dmz</programlisting>
<important>
<para>When prohibit or unreachable routes are added to a
<replaceable>provider</replaceable> (including 'main'),
Shorewall creates a shell script file in
${VARDIR}/undo_<replaceable>provider</replaceable>_routing to
undo the routing, if needed (see below as to some instances when
this may be necessary).</para>
</important>
</listitem> </listitem>
</orderedlist> </orderedlist>
</section> </section>
@ -1427,10 +1450,12 @@ ip route replace unreachable 192.168.14.0/26 table dmz</programlisting>
null route.</para> null route.</para>
<para>Lets take the following example: We need to null-route all <para>Lets take the following example: We need to null-route all
addresses from the 10.0.0.0/8 range, *except* 10.1.0.0/24. In such addresses from the 10.0.0.0/8 range, <emphasis
a case we need to define two routes in our "routes" file (assuming role="bold">except</emphasis> 10.1.0.0/24. In such a case we need
the default "main" routing table is used and also assuming that to define two routes in our "routes" file (assuming the default
10.1.0.0/24 is routed via the default gateway on eth0).</para> "main" routing table is used and also assuming that 10.1.0.0/24 is
routed via the default gateway on eth0 and we need to use
'blackhole' type null routing).</para>
<para><filename>/etc/shorewall/routes</filename>:</para> <para><filename>/etc/shorewall/routes</filename>:</para>
@ -1456,15 +1481,26 @@ ip route replace 10.1.0.0/24 table main
<para>Null routes, by their definition, are not attached to any <para>Null routes, by their definition, are not attached to any
network device. What this means in reality is that when the status network device. What this means in reality is that when the status
of a particular device changes (either going up or down), that has of a particular device changes (either going up or down), that has
absolutely NO effect on the null routes defined (as already absolutely <emphasis role="bold">no</emphasis> effect on the null
indicated, these are "static" and can only be removed by executing routes defined (as already indicated, these are "static" and can
"ip route del").</para> only be removed by executing "ip route del" or by executing the
relevant ${VARDIR}/undo_*_routing shell script).</para>
<important>
<para>The ${VARDIR}/undo_*_routing scripts generated by
Shorewall 4.5.14 and earlier cannot be executed directly from
the shell without first sourcing
${SHAREDIR}/shorewall/functions. Example:</para>
<programlisting>. /usr/share/shorewall/functions
. /var/lib/shorewall/undo_x_routing</programlisting>
</important>
<para>This sometimes may lead to undesirable side effect: when a <para>This sometimes may lead to undesirable side effect: when a
network interface goes down (even temporarily), then ALL routes network interface goes down (even temporarily), then <emphasis
defined or attached to that interface are simply deleted from the role="bold">all</emphasis> routes defined or attached to that
routing table by the kernel, while the blackhole routes are interface are simply deleted from the routing table by the kernel,
untouched.</para> while the blackhole routes are untouched.</para>
<para>Lets take our example above: when eth0 goes down, then the <para>Lets take our example above: when eth0 goes down, then the
route we defined in "routes" for our private subnet (10.1.0.0/24) route we defined in "routes" for our private subnet (10.1.0.0/24)
@ -1492,8 +1528,8 @@ ip route replace 10.1.0.0/24 table main
Debian and derivatives, it is Debian and derivatives, it is
<filename>/etc/network/interfaces</filename>.</para> <filename>/etc/network/interfaces</filename>.</para>
<para>That way, when the network device goes back up, the <para>That way, when the network device goes back up again,
Linux OS will add these routes "automatically". Using our the Linux OS will add these routes "automatically". Using our
example above - to add a route to 10.1.0.0/24 using the example above - to add a route to 10.1.0.0/24 using the
default gateway on eth0 and also using the main routing table, default gateway on eth0 and also using the main routing table,
the following needs to be added to the following needs to be added to
@ -1506,15 +1542,16 @@ ip route replace 10.1.0.0/24 table main
<para>On Debian and derivatives (in the eth0 stanza of <para>On Debian and derivatives (in the eth0 stanza of
<filename>/etc/network/interfaces</filename>):</para> <filename>/etc/network/interfaces</filename>):</para>
<programlisting> post-up ip route add 10.1.0.0/24 dev eth0 table main</programlisting> <programlisting>iface eth0 ...
...
post-up ip route add 10.1.0.0/24 dev eth0 table main</programlisting>
</listitem> </listitem>
<listitem> <listitem>
<para>A more elegant solution to this particular problem is, <para>A more elegant solution is, in addition to the
in addition to the "standard" shorewall package "standard" shorewall package (shorewall-lite, shorewall, etc),
(shorewall-lite, shorewall, etc), to add <ulink to add <ulink url="Shorewall-init.html">shorewall-init</ulink>
url="Shorewall-init.html">shorewall-init</ulink> to take care to take care of this automatically.</para>
of this automatically.</para>
<para>With this approach, when the network interface is <para>With this approach, when the network interface is
brought back up, the OS passes control to /sbin/ifup-local, brought back up, the OS passes control to /sbin/ifup-local,