forked from extern/shorewall_code
eff828015c
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@5687 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
145 lines
4.7 KiB
Plaintext
145 lines
4.7 KiB
Plaintext
Shorewall-pl 3.9.0
|
|
|
|
This companion product to Shorewall 3.4.2 and later includes a complete
|
|
rewrite of the compiler in Perl.
|
|
|
|
Shorewall-pl depends on Shorewall (3.4.2 or later). So if you want to use the
|
|
new compiler, you must install both Shorewall and Shorewall-pl.
|
|
|
|
Even if you install Shorewall-pl, you have a choice of which compiler you use.
|
|
The choice is specified in the shorewall.conf file so you can select the
|
|
compiler to use on a system-by-system basis when running Shorewall Lite on
|
|
remote systems.
|
|
|
|
I decided to make Shorewall-pl a separate product for several reasons:
|
|
|
|
a) Embedded applications are unlikely to adopt Shorewall-pl; even Mini-Perl
|
|
has a substantial disk and Ram footprint.
|
|
|
|
b) Because of the gross incompatibilities between the new compiler and the
|
|
old (see below), migration to the new compiler must be voluntary.
|
|
|
|
c) By allowing Shorewall-pl to co-exist with the current Shorewall stable
|
|
release (3.4), I'm hoping that the new compiler will get more testing and
|
|
validation than it would if I were to package it with a new development
|
|
version of Shorewall itself.
|
|
|
|
d) Along the same vein, I think that users will be more likely to experiment
|
|
with the new compiler if they can easily fall back to the old one if things
|
|
get sticky.
|
|
|
|
The good news:
|
|
|
|
a) The compiler is small.
|
|
b) The compiler is very fast.
|
|
c) The compiler generates a firewall script that uses iptables-restore;
|
|
so the script is very fast.
|
|
d) Use of the perl compiler is optional! The old slow clunky
|
|
Bourne-shell compiler is still available.
|
|
|
|
The bad news:
|
|
|
|
There are a number of incompatibilities between the Perl-based compiler
|
|
and the Bourne-shell one.
|
|
|
|
a) The Perl-based compiler requires the following capabilities in your
|
|
kernel and iptables.
|
|
|
|
- addrtype match
|
|
- conntrack match
|
|
- extended multiport match
|
|
|
|
These capabilities are in current distributions.
|
|
|
|
b) BRIDGING=Yes is not supported. The kernel code necessary to
|
|
support this option was removed in Linux kernel 2.6.20.
|
|
|
|
c) The BROADCAST column in the interfaces file is essentailly unused;
|
|
if you enter anything in this column but '-' or 'detect', you will
|
|
receive a warning.
|
|
|
|
d) Because the compiler is now written in Perl, your compile-time
|
|
extension scripts from earlier versions will no longer work.
|
|
|
|
e) The 'refresh' command is now synonamous with 'restart'.
|
|
|
|
f) Some run-time extension scripts are no longer supported because they
|
|
make no sense (iptables-restore instantiates the new configuration
|
|
atomically).
|
|
|
|
continue
|
|
initdone
|
|
continue
|
|
refresh
|
|
refreshed
|
|
|
|
g) The /etc/shorewall/tos file now has a format similar to the tcrules.
|
|
|
|
The SOURCE column may be one of the following:
|
|
|
|
[all:]<address>[,...]
|
|
[all:]<interface>[:<address>[,...]]
|
|
$FW[:<address>[,...]]
|
|
|
|
The DEST column may be one of the following:
|
|
[all:]<address>[,...]
|
|
[all:]<interface>[:<address>[,...]]
|
|
|
|
h) Currently, support for ipsets is untested. That will change with
|
|
future releases but one thing is certain -- Shorewall is now out of the
|
|
ipset load/reload business. If the Netfilter ruleset is never cleared,
|
|
then there is no opportunity for Shorewall to load/reload your
|
|
ipsets.
|
|
|
|
So:
|
|
|
|
i) Your ipsets must be loaded before Shorewall starts.
|
|
|
|
ii) Your ipsets may not be reloaded until Shorewall is stopped or
|
|
cleared.
|
|
|
|
iii) If you specify ipsets in your routestopped file then
|
|
Shorewall must be cleared in order to reload your ipsets.
|
|
|
|
As a consequence, scripts generated by the Perl-based compiler will
|
|
ignore /etc/shorewall/ipsets and will issue a warning if you set
|
|
SAVE_IPSETS=Yes in shorewall.conf.
|
|
|
|
Installation
|
|
------------
|
|
|
|
1) Unpack the tarball.
|
|
|
|
$ tar -jxf shorewall-pl-3.9.0-1.tar.bz2
|
|
$ pwd
|
|
/home/teastep/shorewall/
|
|
$ ls
|
|
shorewall-pl-3.9.0/
|
|
$
|
|
|
|
2) As root, create a symbolic link to the directory containing the unpacked
|
|
files.
|
|
|
|
$ ln -sf /home/teastep/shorewall/ /usr/share/shorewall-pl
|
|
|
|
Using the New compiler
|
|
----------------------
|
|
|
|
By default, the old Bourne-shell based compiler will be used.
|
|
|
|
There is one change in Shorewall operation that is triggered when
|
|
/usr/share/shorewall-pl exists and is either a directory or a symbolic
|
|
link that points to a directory: Your params file will be processed
|
|
with the shell's '-a' option set which will automatically export any
|
|
variables that you set or create.
|
|
|
|
To actually use the new compiler, add this to shorewall.conf:
|
|
|
|
SHOREWALL_PL=Yes
|
|
|
|
If you add this setting to /etc/shorewall/shorewall.conf then by
|
|
default, the new compiler will be used on the system. If you add it to
|
|
shorewall.conf in a separate directory (such as a Shorewall-lite export
|
|
directory) then the new compiler will only be used when you compile
|
|
from that directory.
|