On 22/08/2011 17:42, Tom Eastep wrote:
> On Mon, 2011-08-22 at 07:14 -0700, Tom Eastep wrote:
>
>>
>> What is your objection to doing a 'shorewall restart'. Packet/Byte
>> counter reset?
Actually, for my scenario there are two main problems, arguably these
aren't as important for other users, but they are to me...:
1) Time - the router is an Alix board (500mhz geode) and a fast restart
takes 2-5 seconds. One of the network connections we are building the
router for is an Iridium satellite link, this is priced at around
$1.50/min and billed in 20 second increments. PPP takes approx the
first 10 seconds to connect, and then if we are fairly efficient we can
get some data transferred and the link hung up before we incur the
second 20 second increment. Unfortunately 2-3 seconds becomes a large
fraction of the 10 seconds we have to hit that target. Adding extra 20
second increments is roughly 50c a go and if we do some rough numbers at
3 dialups per day, 200 days, then we are hitting say $300/year extra
data per box (hopefully hundreds/thousands of boxes...). It's worth
pinching the extra seconds here
2) Accurate byte counts. The other type of connection we will support is
a 3G style satellite connection where you pay by the byte. We will be
using a captive portal (simple iptables + ipsets) to allocate usage per
device (and implicitly per user). It would appear that we can "leak"
during the restart of iptables? As far as possible I want to target
having packet accurate usage counts (the more accurate you can get saves
arguments later)
2.5) I'm trying to get very rigid control over the routing tables, so
users have to agree to use each connection one by one. I'm worried that
inflight data is going to risk routing peculiarly during the restart and
given subsequent "track" and the like, it may cause some complex (and
unintended) routing to persist after the restart?
Just for background - the appliance is going to be given to non
technical end users who will only have a web interface to interact with.
I want to offer them flexibility to plug in additional hardware, but
I'm proposing up front to set some bounds on what we support. Roughly,
the box will be preconfigured to support:
- eth0-4
- wlan0-1
- ppp0-4 (dialup)
- ppp5-9 (3G/PPPoE)
To a very large extent I can preconfigure each of these options
statically right now, and if say wlan1 is added/removed, all we need do
is add the additional routing tables, the rest of the firewall can be
pre-configured (approximately all internet connections will be
considered the same). Same too for the PPP connections, as udev notices
new real hardware, our daemon applies appropriate logic to wire up a
free PPP slot and apart from the routing we are good to go.
The main thing I am missing here is that as my device manager (not
NetworkManager) notices cables being pulled, wlan connections going down
and 3g hardware going out of cellular range, then I need to adjust the
routing tables appropriately
> One reason that I dislike the notion of modifying the running
> configuration in place is that it substantially increases the testing
> complexity.
Understood. Please bear in mind that my proposal was largely not to
change the code /var/lib/shorewall/firewall (well more than very
slightly). The proposal was to re-organise it into additional functions
so that a user with more complex requirements (me) can go outside of the
normal use case.
I think my proposal doesn't change the actual script which is run for
normal users?
> Plus, implementing your suggesting is not as straightforward as it might
> seem.
>
> - An interface can be either hard down (e.g., ifdown ethx) or soft down
> (the interface is in the UP state but the link isn't functional). The
> steps needed to bring the interface back up from these two different
> 'down' states are quite different (think about traffic shaping, for
> example).
I'm not currently using traffic shaping, so I hadn't considered some of
the complexities there.
Note that my proposal is that shorewall is "normally" used the same as
it is today. The main change is simply exposing the routing up/down
code so that it can be used independently.
I'm hampered by my stupid mail client being stuck in plain text, must
fix that. However, basically my ./firewall script says something like:
if [ -n "$SW_PPP0_IS_USABLE" ]; then
#
# Add Provider pppp0 (11)
#
.... code here to bring up ppp0 ....
else
error_message "WARNING: Interface ppp0 is not usable -- Provider
pppp0 (11) not Added"
fi
I'm hoping that you will move that ".... code here ..." into a separate
function in the script (and allow me to access it)
> - Shorewall supports a 'compile' command that
> replaces /var/lib/shorewall/firewall. Changes in the configuration could
> cause up/down processing to fail or to do the wrong thing if the running
> configuration isn't compatible with the new one.
I agree that this is outside of the scope of shorewall as it stands
today. What I am proposing is strictly for use by a smarter link
monitor - the person implementing that link monitor will need to
understand these limitations.
I don't see it (at least not unless it matures significantly) as being a
"user" type feature - it's purely a hook to allow integration with
another system
Note that in my case at least, the configuration will never/rarely
change, link state changes are far more frequent
I risk mis-explaining things here... What you are supposed to read here
is that this should look like a reasonably small code change, which is
intended to allow third party stuff to "hook in.
Thanks
Ed W
------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
