forked from extern/shorewall_code
Fix TOS processing; Update release notes
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@5731 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
parent
a983cc2a61
commit
d08dca7c6b
@ -37,7 +37,8 @@ use Shorewall::Proc;
|
||||
use strict;
|
||||
|
||||
our @ISA = qw(Exporter);
|
||||
our @EXPORT = qw( add_common_rules
|
||||
our @EXPORT = qw( process_tos
|
||||
add_common_rules
|
||||
setup_mac_lists
|
||||
process_criticalhosts
|
||||
process_routestopped
|
||||
@ -59,13 +60,13 @@ my @rule_chains;
|
||||
my $sectioned = 0;
|
||||
|
||||
sub process_tos() {
|
||||
my $chain = 'pretos';
|
||||
my $stdchain = 'PREROUTING';
|
||||
my $chain = $capabilities{MANGLE_FORWARD} ? 'fortos' : 'pretos';
|
||||
my $stdchain = $capabilities{MANGLE_FORWARD} ? 'FORWARD' : 'PREROUTING';
|
||||
|
||||
if ( -s "$ENV{TMP_DIR}/tos" ) {
|
||||
progress_message2 'Setting up TOS...';
|
||||
|
||||
my $pretosref = new_chain 'mangle' , 'pretos';
|
||||
my $pretosref = new_chain 'mangle' , $chain;
|
||||
my $outtosref = new_chain 'mangle' , 'outtos';
|
||||
|
||||
open TOS, "$ENV{TMP_DIR}/tos" or fatal_error "Unable to open stripped tos file: $!";
|
||||
@ -107,6 +108,9 @@ sub process_tos() {
|
||||
}
|
||||
|
||||
close TOS;
|
||||
|
||||
add_rule $mangle_table->{$stdchain}, "-j $chain";
|
||||
add_rule $mangle_table->{OUTPUT}, "-j outtos";
|
||||
}
|
||||
}
|
||||
|
||||
|
@ -750,6 +750,10 @@ sub compiler( $ ) {
|
||||
progress_message2 "$doing TC Rules...";
|
||||
setup_tc;
|
||||
#
|
||||
# TOS
|
||||
#
|
||||
process_tos;
|
||||
#
|
||||
# Setup Masquerading/SNAT
|
||||
#
|
||||
progress_message2 "$doing Masq file...";
|
||||
|
@ -40,33 +40,35 @@ d) Use of the perl compiler is optional! The old slow clunky
|
||||
The bad news:
|
||||
|
||||
There are a number of incompatibilities between the Perl-based compiler
|
||||
and the Bourne-shell one.
|
||||
and the Bourne-shell one. Some of these will probably go away by first
|
||||
official release but some will not.
|
||||
|
||||
a) The Perl-based compiler requires the following capabilities in your
|
||||
kernel and iptables.
|
||||
|
||||
- addrtype match
|
||||
- conntrack match
|
||||
- multiport match
|
||||
- addrtype match (may be relaxed later)
|
||||
- conntrack match (may be relaxed later)
|
||||
- multiport match (will not be relaxed)
|
||||
|
||||
These capabilities are in current distributions.
|
||||
|
||||
b) The Bourne-shell compiler goes to great pain (in some cases) to
|
||||
break very long port lists ( > 15 where port ranges in lists count
|
||||
as two ports) into individual rules. I'm removing the ugliness
|
||||
required to do that (at least initially). The new compiler just
|
||||
gives you an error. It will also give you an error if you insert a
|
||||
port range into a port list and you don't have extended multiport
|
||||
support. Now that Netfilter has features to deal reasonably with
|
||||
port lists, I see no reason to duplicate those features in
|
||||
Shorewall.
|
||||
as two ports) into individual rules. In the new compiler, I'm
|
||||
avoiding the ugliness required to do that. The new compiler just
|
||||
gives you an error if your list is too long. It will also give you
|
||||
an error if you insert a port range into a port list and you don't
|
||||
have extended multiport support. Now that Netfilter has features to
|
||||
deal reasonably with port lists, I see no reason to duplicate those
|
||||
features in Shorewall.
|
||||
|
||||
c) BRIDGING=Yes is not supported. The kernel code necessary to
|
||||
support this option was removed in Linux kernel 2.6.20.
|
||||
|
||||
d) 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.
|
||||
receive a warning. This will be relaxed if and when the addrtype
|
||||
match requirement is relaxed.
|
||||
|
||||
e) Because the compiler is now written in Perl, your compile-time
|
||||
extension scripts from earlier versions will no longer work.
|
||||
@ -83,7 +85,8 @@ g) Some run-time extension scripts are no longer supported because they
|
||||
refresh
|
||||
refreshed
|
||||
|
||||
h) The /etc/shorewall/tos file now has a format similar to the tcrules.
|
||||
h) The /etc/shorewall/tos file now has zone-independent SOURCE and DEST
|
||||
columns as do all other files except the rules and policy files.
|
||||
|
||||
The SOURCE column may be one of the following:
|
||||
|
||||
@ -95,6 +98,12 @@ h) The /etc/shorewall/tos file now has a format similar to the tcrules.
|
||||
[all:]<address>[,...]
|
||||
[all:]<interface>[:<address>[,...]]
|
||||
|
||||
This is a perminent change. The old zone-based rules have never
|
||||
worked right and this is a good time to replace them. I've tried to
|
||||
make the new syntax cover the most common cases without requiring
|
||||
change to existing files. In particular, it will handle the tos file
|
||||
released with Shorewall 1.4 and earlier.
|
||||
|
||||
i) 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. With scripts generated by the Perl-based
|
||||
@ -135,21 +144,22 @@ 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-perl 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 in that file. Since the params file is
|
||||
processed before shorewall.conf, using the -a option assures that the
|
||||
settings of your params variables are available to the new compiler
|
||||
should it be used.
|
||||
To use the new compiler, add this to shorewall.conf:
|
||||
|
||||
To actually use the new compiler, add this to shorewall.conf:
|
||||
|
||||
SHOREWALL_PERL=Yes
|
||||
SHOREWALL_COMPILER=perl
|
||||
|
||||
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.
|
||||
|
||||
Regardless of the setting of SHOREWALL_COMPILER, there is one change in
|
||||
Shorewall operation that is triggered simply by installing
|
||||
shorewall-perl. Your params file will be processed with the shell's
|
||||
'-a' option which causes any variables that you set or create in that
|
||||
file to be automatically exported. Since the params file is processed
|
||||
before shorewall.conf, using -a insures that the settings of your
|
||||
params variables are available to the new compiler should it's use be
|
||||
specified in shorewall.conf.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user