From 7fcba909dfbff44c3ecfd68c397c002774615dc7 Mon Sep 17 00:00:00 2001 From: teastep Date: Fri, 30 Jan 2009 22:20:22 +0000 Subject: [PATCH] Doc updates git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@9355 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- docs/MultiISP.xml | 170 +++++++++++++++++++++++++++++++----- docs/traffic_shaping.xml | 47 +++++----- manpages/shorewall.conf.xml | 21 +++++ 3 files changed, 196 insertions(+), 42 deletions(-) diff --git a/docs/MultiISP.xml b/docs/MultiISP.xml index a286161e0..fcc5285f4 100644 --- a/docs/MultiISP.xml +++ b/docs/MultiISP.xml @@ -103,8 +103,9 @@ For most routing applications, Quagga is a better - solution. + url="http://www.quagga.net/">Quagga is a better solution + although it requires that your ISPs offer routing protocol + support. @@ -618,13 +619,136 @@ /etc/shorewall/route_rules. -
- What an entry in the Providers File Does NOT Do +
+ Gateway Monitoring and Failover - Given that Shorewall is simply a tool to configure Netfilter and - does not run continuously in your system, entries in the providers file - do not provide any automatic failover in the event - of failure of one of your Internet connections. + Beginning with Shorewall 4.2.6, Shorewall includes a sample + monitoring script swping. The + swping file is available in the main directory + contained in the Shorewall-common tarball and is included in the + Shorewall-common documentation directory on the Shorewall-common + RPM. + + For those not on 4.2.6 yet, the script may be downloaded from + http://www.shorewall.net/pub/shorewall/contrib/MultiISP-failover/. + + + These samples are offered as is — they work + for me but I don't make any claim that they will work for anyone else. + But if you have a need for automated link monitoring, they offer you a + place to start. + + + The script monitors two interfaces but it is a trivial exercise to + extend it to more than two. At the top are a number of variables to + set: + + # The commands to run when the status of a line changes. Both commands will be executed. +# +COMMAND1= +COMMAND2="ip -4 route ls" +... +# +# Interfaces to monitor -- you may use shell variables from your params file +# +IF1=eth0 +IF2=eth1 +# +# Sites to Ping. Must not depend on the associated interface having a default route through it. +# +TARGET1= +TARGET2= +# +# How often to ping +# +PING_INTERVAL=5 +# +# Value for ping's -W option +# +PING_TIMEOUT=2 +# +# This many successive pings must succeed for the interface to be marked up when it is down +# +UP_COUNT=5 +# +# This many successive pings must fail for the interface to be marked down when it is up +# +DOWN_COUNT=2 + + If you leave COMMAND1 empty, the script sets its value + automatically depending on whether Shorewall-lite is installed. + + When the status of an interface changes: + + + + For each interface, a file is placed in /etc/shorewall to + record the status of the interface: either 0 (UP) or 1 (DOWN). The + name of the file is interface.status where + interface is the interface (e.g., + eth0.status). + + + + A shorewall -f restart command is executed + (shorewall-lite restart, if Shorewall-lite is + installed). + + + + The contents of the main routing table are displayed. + + + + The .status files are intended to be used with the following + /etc/shorewall/isusable script.local status=0 + +case $1 in + eth0|eth1) + [ -f /etc/shorewall/${1}.status ] && status=$(cat /etc/shorewall/${1}.status) + ;; +esac + +return $status + + Be sure that you modify the interface names to match your + configuration. + + Also included is a sample init script + (swping.init) to start the monitoring daemon. Copy + it to /etc/init.d/swping and use your + distribution's SysV init tools to cause it to be run at boot. It works + on OpenSuSE 11.0 -- YMMV. Modify the PROG and + STATEDIR variables as needed. + + This simple script has a number of limitations: + + + + It only works on IPv4 (but is easy to modify for IPv6) + + + + It's method of determining whether an interface is up or down + is crude. You will normally specify the default gateway for each + provider as the sites to ping and being able to ping the default + gateway is not a surefire indication that the provider is usable. + The method of determining whether a site is up or down is also + crude. + + + + Because of the crudeness of the algorithm, hysteresis may + occur. + + + + It is tricky to configure a system such that a system works + correctly when one of its providers is down unless you largely don't + care which interface is used. + +
@@ -1007,7 +1131,7 @@ gateway:~ #Note that because we used a priority of 1000, the a USE_DEFAULT_RT option in shorewall.conf (5). - One of the drawbacks of the Mulit-ISP support as described in the + One of the drawbacks of the Multi-ISP support as described in the preceding sections is that changes to the main table made by applications are not added to the individual provider tables. This makes route rules such as described in one of the @@ -1136,7 +1260,7 @@ shorewall 2 2 - eth0 192.168.1.254 track,balance=2,optional< Example: - This is our home network circa fall 2008. We have two internet + This is our home network circa fall 2008. We have two Internet providers: @@ -1339,11 +1463,12 @@ wlan0 192.168.0.0/24 As a consequence, I have disabled all route filtering on the - firewall and do not use the balance - option in /etc/shorewall/providers. The default route - in the main table is established by DHCP. By specifying the fallback option on Avvanta, I ensure that there is - still a default route if Comcast is down. + firewall and only use the balance option + in /etc/shorewall/providers on the Comcast provider + whose default route in the main table is established by DHCP. By + specifying the fallback option on + Avvanta, I ensure that there is still a default route if Comcast is down. + swping is used to monitor the links. /etc/sysctl.conf: @@ -1351,13 +1476,19 @@ wlan0 192.168.0.0/24 /etc/shorewall/shorewall.conf: - ROUTE_FILTER=No + ROUTE_FILTER=No +RESTORE_DEFAULT_ROUTE=No + + The RESTORE_DEFAULT_ROUTE option was added in Shorewall-perl 4.2.6 + and causes the default route in the main table to be deleted when the + Comcast link is unavailable. That way, the default route in the default + table will be used until Comcast is available again. /etc/shorewall/providers: #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY Avvanta 1 0x100 main eth0 206.124.146.254 track,loose,fallback eth2,eth4,tun* -Comcast 2 0x200 main eth3 detect track eth2,eth4,tun* +Comcast 2 0x200 main eth3 detect track,balance eth2,eth4,tun* #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE The loose option on Avvanta results @@ -1372,7 +1503,7 @@ Comcast 2 0x200 main eth3 detect track /etc/shorewall/route_rules: #SOURCE DEST PROVIDER PRIORITY -- 162.20.0.0.24 main 1000 # Addresses assigned by routed OpenVPN server +- 172.20.0.0/24 main 1000 # Addresses assigned by routed OpenVPN server 206.124.146.176/30 - Avvanta 26000 206.124.146.180 - Avvanta 26000 - 216.168.3.44 Avvanta 26000 # Avvanta NNTP Server -- verifies source IP address @@ -1471,8 +1602,7 @@ COMMENT Masquerade Local Network eth3 0.0.0.0/0 eth0 !206.124.146.0/24 206.124.146.179 -#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE - +#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE All traffic leaving eth3 must use the dynamic IP address assigned to that interface as the SOURCE address. All traffic leaving eth0 that does diff --git a/docs/traffic_shaping.xml b/docs/traffic_shaping.xml index d352e95fd..47f33ab22 100644 --- a/docs/traffic_shaping.xml +++ b/docs/traffic_shaping.xml @@ -594,33 +594,36 @@ ppp0 6000kbit 500kbit file. Because tcrules are not stateful, it is necessary to understand - basic IP socket operation. Here is an excerpt from a post on the - Shorewall Users list:
+ basic IP socket operation. Here is an edited excerpt from a post on + the Shorewall Users list:
For the purposes of this discussion, the world is separated into clients and servers. Servers provide services to clients. - When a server starts, it creates a socket and *binds* the - socket to an *address*. For AF_INET (IPv4) and AF_INET6 (IPv6) - sockets, that address is an ordered triple consisting of an IPv4 - or IPv6 address, a protocol, and possibly a port number. Port - numbers are only used when the protocol is TCP, UDP, SCTP or SCCP. + When a server starts, it creates a socket and + binds the socket to an + address. For AF_INET (IPv4) and AF_INET6 + (IPv6) sockets, that address is an ordered triple consisting of an + IPv4 or IPv6 address, a protocol, and possibly a port number. Port + numbers are only used when the protocol is TCP, UDP, SCTP or DCCP. The protocol and port number used by a server are typically - well-known so that clients will be able to connect to it. So SSH - servers bind to TCP port 22, SMTP servers bind to TCP port 25, - etc. We will call this port the SERVER PORT. + well-known so that clients will be able to connect to it or send + datagrams to it. So SSH servers bind to TCP port 22, SMTP servers + bind to TCP port 25, etc. We will call this port the SERVER + PORT. When a client want to use the service provided by a server, - it also creates a socket. Like the server's socket, the client's - socket must also be bound to an address. But in the case of the - client, the socket is usually given an automatic address binding. - For AF_INET and AF_INET6 sockets. the IP address is the IP address - of the client system (loose generalization) and the port number is - selected from a *local port range*. On Linux systems, the local - port ranges can be seen by 'cat - /proc/sys/net/ipv4/ip_local_port_range'. So it is not possible in - advance to determine what port the client will be using. Whatever - it is, we'll call it the CLIENT PORT. + it also creates a socket and, like the server's socket, the + client's socket must be bound to an address. But in the case of + the client, the socket is usually given an automatic address + binding. For AF_INET and AF_INET6 sockets. the IP address is the + IP address of the client system (loose generalization) and the + port number is selected from a local port + range. On Linux systems, the local port range can be + seen by cat + /proc/sys/net/ipv4/ip_local_port_range. So it is not + possible in advance to determine what port the client will be + using. Whatever it is, we'll call it the CLIENT PORT. Now:
Packets sent from the client to the server will @@ -639,8 +642,8 @@ ppp0 6000kbit 500kbit
Since the SERVER PORT is generally the only port known ahead - of time, we therefore categorize traffic from the server to the - client using the SOURCE PORT. + of time, we must categorize traffic from the server to the client + using the SOURCE PORT.
diff --git a/manpages/shorewall.conf.xml b/manpages/shorewall.conf.xml index 04324cc67..56c25160f 100644 --- a/manpages/shorewall.conf.xml +++ b/manpages/shorewall.conf.xml @@ -1247,6 +1247,27 @@ net all DROP infothen the chain name is 'net2all' + + RESTORE_DEFAULT_ROUTE=[Yes|No] + + + Added in Shorewall 4.2.6, this option determines whether to + restore the default route saved when here are 'balance' providers + defined but all of them are down. + + The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the + pre-4.2.6 behavior. + + RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a + default route in the main table (USE_DEFAULT_RT=No) or in the + default table (USE_DEFAULT_RT=Yes) when there are no balance + providers available. In that case, RESTORE_DEFAULT_ROUTE=No will + cause any default route in the relevant table to be deleted. + + + RESTOREFILE=filename