mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-24 15:18:53 +01:00
Support alternative syntax for ipet lists
Signed-off-by: Tom Eastep <teastep@shorewall.net>
This commit is contained in:
Tom Eastep
parent
0c6882c3a8
commit
25ca73ca54
@ -2588,14 +2588,14 @@ sub match_source_net( $;$ ) {
|
||||
} elsif ( $net =~ /^(!?)\+[a-zA-Z][-\w]*(\[.*\])?/ ) {
|
||||
require_capability( 'IPSET_MATCH' , 'ipset names in Shorewall configuration files' , '' );
|
||||
join( '', '-m set ', $1 ? '! ' : '', get_set_flags( $net, 'src' ) );
|
||||
} elsif ( $net =~ /^\[(\+.+)\]$/ ) {
|
||||
} elsif ( $net =~ /^\+\[(.+)\]$/ ) {
|
||||
my $result = '';
|
||||
my @sets = mysplit $1;
|
||||
|
||||
require_capability 'KLUDGEFREE', 'Multiple ipset matches', '' if @sets > 1;
|
||||
|
||||
for $net ( @sets ) {
|
||||
fatal_error "Expected ipset name ($net)" unless $net =~ /^(!?)\+[a-zA-Z][-\w]*(\[.*\])?/;
|
||||
fatal_error "Expected ipset name ($net)" unless $net =~ /^(!?)(\+?)[a-zA-Z][-\w]*(\[.*\])?/;
|
||||
$result .= join( '', '-m set ', $1 ? '! ' : '', get_set_flags( $net, 'src' ) );
|
||||
}
|
||||
|
||||
@ -2624,14 +2624,14 @@ sub match_dest_net( $ ) {
|
||||
} elsif ( $net =~ /^(!?)\+[a-zA-Z][-\w]*(\[.*\])?$/ ) {
|
||||
require_capability( 'IPSET_MATCH' , 'ipset names in Shorewall configuration files' , '');
|
||||
join( '', '-m set ', $1 ? '! ' : '', get_set_flags( $net, 'dst' ) );
|
||||
} elsif ( $net =~ /^\[(\+.+)\]$/ ) {
|
||||
} elsif ( $net =~ /^\+\[(.+)\]$/ ) {
|
||||
my $result = '';
|
||||
my @sets = mysplit $1;
|
||||
|
||||
require_capability 'KLUDGEFREE', 'Multiple ipset matches', '' if @sets > 1;
|
||||
|
||||
for $net ( @sets ) {
|
||||
fatal_error "Expected ipset name ($net)" unless $net =~ /^(!?)\+[a-zA-Z][-\w]*(\[.*\])?/;
|
||||
fatal_error "Expected ipset name ($net)" unless $net =~ /^(!?)(\+?)[a-zA-Z][-\w]*(\[.*\])?/;
|
||||
$result .= join( '', '-m set ', $1 ? '! ' : '', get_set_flags( $net, 'dst' ) );
|
||||
}
|
||||
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
Changes in Shorewall 4.4.14
|
||||
|
||||
1) Support ipset lists.
|
||||
|
||||
Changes in Shorewall 4.4.13
|
||||
|
||||
1) Allow zone lists in rules SOURCE and DEST.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
----------------------------------------------------------------------------
|
||||
S H O R E W A L L 4 . 4 . 1 3
|
||||
R C 1
|
||||
S H O R E W A L L 4 . 4 . 1 4
|
||||
B E T A 1
|
||||
----------------------------------------------------------------------------
|
||||
|
||||
I. PROBLEMS CORRECTED IN THIS RELEASE
|
||||
@ -14,107 +14,7 @@ VI. PROBLEMS CORRECTED AND NEW FEATURES IN PRIOR RELEASES
|
||||
I. P R O B L E M S C O R R E C T E D I N T H I S R E L E A S E
|
||||
----------------------------------------------------------------------------
|
||||
|
||||
1) Under rare circumstances where COMMENT is used to attach comments
|
||||
to rules, OPTIMIZE 8 through 15 could result in invalid
|
||||
iptables-restore (ip6tables-restore) input.
|
||||
|
||||
2) Under rare circumstances involving exclusion, OPTIMIZE 8 through 15
|
||||
could result in invalid iptables-restore (ip6tables-restore) input.
|
||||
|
||||
3) The change in 4.4.12 to detect and use the new ipset match syntax
|
||||
broke the ability to detect the old ipset match capability. Now,
|
||||
both versions of the capability can be correctly detected.
|
||||
|
||||
4) Previously, if REQUIRE_INTERFACE=Yes then start/restart would fail
|
||||
if the last optional interface tested was not available.
|
||||
|
||||
5) Exclusion in the blacklist file was correctly validated but was then
|
||||
ignored when generating iptables (ip6tables) rules.
|
||||
|
||||
6) Previously, non-trivial exclusion (more than one excluded
|
||||
address/net) in CONTINUE, NONAT and ACCEPT+ rules generated
|
||||
valid but incorrect iptables input. This has been corrected but
|
||||
requires that your iptables/kernel support marking rules in any
|
||||
Netfilter table (CONTINUE in the tcrules file does not require this
|
||||
support).
|
||||
|
||||
This fix implements a new 'Mark in any table' capability; those
|
||||
who utilize a capabilities file should re-generate the file using
|
||||
this release.
|
||||
|
||||
7) Interface handling has been extensively modified in this release
|
||||
to correct a number of problems with the earlier
|
||||
implementation. Among those problems:
|
||||
|
||||
- Invalid shell variable names could be generated in the firewall
|
||||
script. The generated firewall script uses shell variables to
|
||||
track the availability of optional and required interfaces and
|
||||
to record detected gateways, detected addresses, etc.
|
||||
|
||||
- The same shell variable name could be generated by two different
|
||||
interface names.
|
||||
|
||||
- Entries in the interfaces file with a wildcard physical name
|
||||
(physical name ends with "+") and with the 'optional' option were
|
||||
handled strangely.
|
||||
|
||||
o If there were references to specific interfaces that matched
|
||||
the wildcard, those entries were handled as if they had been
|
||||
defined as optional in the interfaces file.
|
||||
|
||||
o If there were no references matching the wildcard, then the
|
||||
'optional' option was effectively ignored.
|
||||
|
||||
The new implementation:
|
||||
|
||||
- Insures valid shell variable names.
|
||||
|
||||
- Insures that shell variable names are unique.
|
||||
|
||||
- Handles interface names appearing in the INTERFACE column of the
|
||||
providers file as a special case for 'optional'. If the name
|
||||
matches a wildcard entry in the interfaces file then the
|
||||
usability of the specific interface is tracked individually.
|
||||
|
||||
- Handles the availabilty of other interfaces matching a wildcard
|
||||
as a group; if there is one useable interface in the group then
|
||||
the wildcard itself is considered usable.
|
||||
|
||||
The following example illustrates this use case:
|
||||
|
||||
/etc/shorewall/interfaces
|
||||
|
||||
net ppp+ - optional
|
||||
|
||||
/etc/shorewall/shorewall.conf
|
||||
|
||||
REQUIRE_INTERFACE=Yes
|
||||
|
||||
If there is any usable PPP interface then the firewall will be
|
||||
allowed to start. Previously, the firewall would never be allowed
|
||||
to start.
|
||||
|
||||
8) When a comma-separated list of 'src' and/or 'dst' was specified in
|
||||
an ipset invocation (e.g., "+fooset[src,src]), all but the first 'src'
|
||||
or 'dst' was previously ignored when generating the resulting
|
||||
iptables rule.
|
||||
|
||||
9) Beginning with Shorewall 4.4.9, the SAME target in tcrules has
|
||||
generated invalid iptables (ip6tables) input. That target now
|
||||
generates correct input.
|
||||
|
||||
10) Ipsets associated with 'dynamic' zones were being created during
|
||||
'restart' but not during 'start'.
|
||||
|
||||
11) To work around an issue in Netfilter/iptables, Shorewall now uses
|
||||
state match rather than conntrack match for UNTRACKED state
|
||||
matching.
|
||||
|
||||
12) If the routestopped files contains NOTRACK rules, 'shorewall* clear'
|
||||
did not clear the raw table.
|
||||
|
||||
13) An error message was incorrectly generated if a port range of the
|
||||
form :<port> (e.g., :22) appeared.
|
||||
None.
|
||||
|
||||
----------------------------------------------------------------------------
|
||||
I I. K N O W N P R O B L E M S R E M A I N I N G
|
||||
@ -127,136 +27,12 @@ VI. PROBLEMS CORRECTED AND NEW FEATURES IN PRIOR RELEASES
|
||||
I I I. N E W F E A T U R E S I N T H I S R E L E A S E
|
||||
----------------------------------------------------------------------------
|
||||
|
||||
1) Entries in the rules file (both Shorewall and Shorewall6) may now
|
||||
contain zone lists in the SOURCE and DEST column. A zone list is a
|
||||
comma-separated list of zone names where each name appears in the
|
||||
zones file. A zone list may be optionally followed by a plus sign
|
||||
("+") to indicate that the rule should apply to intra-zone traffic
|
||||
as well as to inter-zone traffic.
|
||||
1) Multiple source or destination ipset matches can be generated by
|
||||
enclosing the ipset list in [...].
|
||||
|
||||
Zone lists behave like 'all' and 'any' with respect to Optimization
|
||||
1. If the rule matches the applicable policy for a given (source
|
||||
zone, dest zone), then the rule will be suppessed for that pair of
|
||||
zones unless overridden by the '!' suffix on the target in the
|
||||
ACTION column (e.g., ACCEPT!, DROP!:info, etc.).
|
||||
Example (/etc/shorewall/rules):
|
||||
|
||||
Additionally, 'any', 'all' and zone lists may be qualified in the
|
||||
same way as a single zone.
|
||||
|
||||
Examples:
|
||||
|
||||
fw,dmz:90.90.191.120/29
|
||||
all:+blacklist
|
||||
|
||||
The 'all' and 'any' keywords now support exclusion in the form of a
|
||||
comma-separated list of excluded zones.
|
||||
|
||||
Examples:
|
||||
|
||||
all!fw (same as all-).
|
||||
any+!dmz,loc (All zones except 'dmz' and 'loc' and
|
||||
include intra-zone rules).
|
||||
|
||||
2) An IPSEC column has been added to the accounting file, allowing you
|
||||
to segregate IPSEC traffic from non-IPSEC traffic. See 'man
|
||||
shorewall-accounting' (man shorewall6-accounting) for details.
|
||||
|
||||
With this change, there are now three trees of accounting chains:
|
||||
|
||||
- The one rooted in the 'accounting' chain.
|
||||
- The one rooted in the 'accipsecin' chain. This tree handles
|
||||
traffic that has been decrypted on the firewall. Rules in this
|
||||
tree cannot specify an interface name in the DEST column.
|
||||
- The one rooted in the 'accipsecout' chain. This tree handles
|
||||
traffic that will be encrypted on the firewall. Rules in this
|
||||
tree cannot specify an interface name in the SOURCE column.
|
||||
|
||||
In reality, when there are bridges defined in the configuration,
|
||||
there is a fourth tree rooted in the 'accountout' chain. That chain
|
||||
handles traffic that originates on the firewall (both IPSEC and
|
||||
non-IPSEC).
|
||||
|
||||
This change also implements a couple of new warnings:
|
||||
|
||||
- WARNING: Adding rule to unreferenced accounting chain <name>
|
||||
|
||||
The first reference to user-defined accounting chain <name> is
|
||||
not a JUMP or COUNT from an already-defined chain.
|
||||
|
||||
- WARNING: Accounting chain <name> has o references
|
||||
|
||||
The named chain contains accounting rules but no JUMP or COUNT
|
||||
specifies that chain as the target.
|
||||
|
||||
3) Shorewall now supports the SECMARK and CONNSECMARK targets for
|
||||
manipulating the SELinux context of packets.
|
||||
|
||||
See the shorewall-secmarks and shorewall6-secmarks manpages for
|
||||
details.
|
||||
|
||||
As part of this change, the tcrules file now accepts $FW in the
|
||||
DEST column for marking packets in the INPUT chain.
|
||||
|
||||
4) Blacklisting has undergone considerable change in Shorewall 4.4.13.
|
||||
|
||||
a) Blacklisting is now based on zones rather than on interfaces and
|
||||
host groups.
|
||||
|
||||
b) Near compatibility with earlier releases is maintained.
|
||||
|
||||
c) The keywords 'src' and 'dst' are now preferred in the OPTIONS
|
||||
column in /etc/shoreawll/blacklist, replacing 'from' and 'to'
|
||||
respectively. The old keywords are still supported.
|
||||
|
||||
d) The 'blacklist' keyword may now appear in the OPTIONS,
|
||||
IN_OPTIONS and OUT_OPTIONS fields in /etc/shorewall/zones.
|
||||
|
||||
i) In the IN_OPTIONS column, it indicates that packets received
|
||||
on the interface are checked against the 'src' entries in
|
||||
/etc/shorewall/blacklist.
|
||||
|
||||
ii) In the OUT_OPTIONS column, it indicates that packets being
|
||||
sent to the interface are checked against the 'dst' entries.
|
||||
|
||||
iii) Placing 'blacklist' in the OPTIONS column is equivalent to
|
||||
placing in in both the IN_OPTIONS and OUT_OPTIONS columns.
|
||||
|
||||
e) The 'blacklist' option in the OPTIONS column of
|
||||
/etc/shorewall/interfaces or /etc/shorewall/hosts is now
|
||||
equivalent to placing it in the IN_OPTIONS column of the
|
||||
associates record in /etc/shorewall/zones. If no zone is given
|
||||
in the ZONE column of /etc/shorewall/interfaces, the 'blacklist'
|
||||
option is ignored with a warning (it was previously ignored
|
||||
silently).
|
||||
|
||||
f) The 'blacklist' option in the /etc/shorewall/interfaces and
|
||||
/etc/shorewall/hosts files is now deprecated but will continue
|
||||
to be supported for several releases. A warning will be added at
|
||||
least one release before support is removed.
|
||||
|
||||
5) There is now an OUT-BANDWIDTH column in
|
||||
/etc/shorewall/tcinterfaces.
|
||||
|
||||
The format of this column is:
|
||||
|
||||
<rate>[:[<burst>][:[<latency>][:[<peak>][:[<minburst>]]]]]
|
||||
|
||||
These terms are described in tc-tbf(8). Shorewall supplies default
|
||||
values as follows:
|
||||
|
||||
<burst> = 10kb
|
||||
<latency> = 200ms
|
||||
|
||||
The remaining options are defaulted by tc.
|
||||
|
||||
6) The IN-BANDWIDTH column in both /etc/shorewall/tcdevices and
|
||||
/etc/shorewall/tcinterfaces now accepts an optional burst parameter.
|
||||
|
||||
<rate>[:<burst>]
|
||||
|
||||
The default <burst> is 10kb. A larger <burst> can help make the
|
||||
<rate> more accurate; often for fast lines, the enforced rate is
|
||||
well below the specified <rate>.
|
||||
ACCEPT $FW net:+[dest-ip-map,dest-port-map]
|
||||
|
||||
----------------------------------------------------------------------------
|
||||
I V. R E L E A S E 4 . 4 H I G H L I G H T S
|
||||
@ -477,6 +253,247 @@ VI. PROBLEMS CORRECTED AND NEW FEATURES IN PRIOR RELEASES
|
||||
----------------------------------------------------------------------------
|
||||
V I. P R O B L E M S C O R R E C T E D A N D N E W F E A T U R E S
|
||||
I N P R I O R R E L E A S E S
|
||||
----------------------------------------------------------------------------
|
||||
P R O B L E M S C O R R E C T E D I N 4 . 4 . 1 3
|
||||
----------------------------------------------------------------------------
|
||||
|
||||
1) Under rare circumstances where COMMENT is used to attach comments
|
||||
to rules, OPTIMIZE 8 through 15 could result in invalid
|
||||
iptables-restore (ip6tables-restore) input.
|
||||
|
||||
2) Under rare circumstances involving exclusion, OPTIMIZE 8 through 15
|
||||
could result in invalid iptables-restore (ip6tables-restore) input.
|
||||
|
||||
3) The change in 4.4.12 to detect and use the new ipset match syntax
|
||||
broke the ability to detect the old ipset match capability. Now,
|
||||
both versions of the capability can be correctly detected.
|
||||
|
||||
4) Previously, if REQUIRE_INTERFACE=Yes then start/restart would fail
|
||||
if the last optional interface tested was not available.
|
||||
|
||||
5) Exclusion in the blacklist file was correctly validated but was then
|
||||
ignored when generating iptables (ip6tables) rules.
|
||||
|
||||
6) Previously, non-trivial exclusion (more than one excluded
|
||||
address/net) in CONTINUE, NONAT and ACCEPT+ rules generated
|
||||
valid but incorrect iptables input. This has been corrected but
|
||||
requires that your iptables/kernel support marking rules in any
|
||||
Netfilter table (CONTINUE in the tcrules file does not require this
|
||||
support).
|
||||
|
||||
This fix implements a new 'Mark in any table' capability; those
|
||||
who utilize a capabilities file should re-generate the file using
|
||||
this release.
|
||||
|
||||
7) Interface handling has been extensively modified in this release
|
||||
to correct a number of problems with the earlier
|
||||
implementation. Among those problems:
|
||||
|
||||
- Invalid shell variable names could be generated in the firewall
|
||||
script. The generated firewall script uses shell variables to
|
||||
track the availability of optional and required interfaces and
|
||||
to record detected gateways, detected addresses, etc.
|
||||
|
||||
- The same shell variable name could be generated by two different
|
||||
interface names.
|
||||
|
||||
- Entries in the interfaces file with a wildcard physical name
|
||||
(physical name ends with "+") and with the 'optional' option were
|
||||
handled strangely.
|
||||
|
||||
o If there were references to specific interfaces that matched
|
||||
the wildcard, those entries were handled as if they had been
|
||||
defined as optional in the interfaces file.
|
||||
|
||||
o If there were no references matching the wildcard, then the
|
||||
'optional' option was effectively ignored.
|
||||
|
||||
The new implementation:
|
||||
|
||||
- Insures valid shell variable names.
|
||||
|
||||
- Insures that shell variable names are unique.
|
||||
|
||||
- Handles interface names appearing in the INTERFACE column of the
|
||||
providers file as a special case for 'optional'. If the name
|
||||
matches a wildcard entry in the interfaces file then the
|
||||
usability of the specific interface is tracked individually.
|
||||
|
||||
- Handles the availabilty of other interfaces matching a wildcard
|
||||
as a group; if there is one useable interface in the group then
|
||||
the wildcard itself is considered usable.
|
||||
|
||||
The following example illustrates this use case:
|
||||
|
||||
/etc/shorewall/interfaces
|
||||
|
||||
net ppp+ - optional
|
||||
|
||||
/etc/shorewall/shorewall.conf
|
||||
|
||||
REQUIRE_INTERFACE=Yes
|
||||
|
||||
If there is any usable PPP interface then the firewall will be
|
||||
allowed to start. Previously, the firewall would never be allowed
|
||||
to start.
|
||||
|
||||
8) When a comma-separated list of 'src' and/or 'dst' was specified in
|
||||
an ipset invocation (e.g., "+fooset[src,src]), all but the first 'src'
|
||||
or 'dst' was previously ignored when generating the resulting
|
||||
iptables rule.
|
||||
|
||||
9) Beginning with Shorewall 4.4.9, the SAME target in tcrules has
|
||||
generated invalid iptables (ip6tables) input. That target now
|
||||
generates correct input.
|
||||
|
||||
10) Ipsets associated with 'dynamic' zones were being created during
|
||||
'restart' but not during 'start'.
|
||||
|
||||
11) To work around an issue in Netfilter/iptables, Shorewall now uses
|
||||
state match rather than conntrack match for UNTRACKED state
|
||||
matching.
|
||||
|
||||
12) If the routestopped files contains NOTRACK rules, 'shorewall* clear'
|
||||
did not clear the raw table.
|
||||
|
||||
13) An error message was incorrectly generated if a port range of the
|
||||
form :<port> (e.g., :22) appeared.
|
||||
|
||||
----------------------------------------------------------------------------
|
||||
N E W F E A T U R E S I N 4 . 4 . 1 3
|
||||
----------------------------------------------------------------------------
|
||||
|
||||
1) Entries in the rules file (both Shorewall and Shorewall6) may now
|
||||
contain zone lists in the SOURCE and DEST column. A zone list is a
|
||||
comma-separated list of zone names where each name appears in the
|
||||
zones file. A zone list may be optionally followed by a plus sign
|
||||
("+") to indicate that the rule should apply to intra-zone traffic
|
||||
as well as to inter-zone traffic.
|
||||
|
||||
Zone lists behave like 'all' and 'any' with respect to Optimization
|
||||
1. If the rule matches the applicable policy for a given (source
|
||||
zone, dest zone), then the rule will be suppessed for that pair of
|
||||
zones unless overridden by the '!' suffix on the target in the
|
||||
ACTION column (e.g., ACCEPT!, DROP!:info, etc.).
|
||||
|
||||
Additionally, 'any', 'all' and zone lists may be qualified in the
|
||||
same way as a single zone.
|
||||
|
||||
Examples:
|
||||
|
||||
fw,dmz:90.90.191.120/29
|
||||
all:+blacklist
|
||||
|
||||
The 'all' and 'any' keywords now support exclusion in the form of a
|
||||
comma-separated list of excluded zones.
|
||||
|
||||
Examples:
|
||||
|
||||
all!fw (same as all-).
|
||||
any+!dmz,loc (All zones except 'dmz' and 'loc' and
|
||||
include intra-zone rules).
|
||||
|
||||
2) An IPSEC column has been added to the accounting file, allowing you
|
||||
to segregate IPSEC traffic from non-IPSEC traffic. See 'man
|
||||
shorewall-accounting' (man shorewall6-accounting) for details.
|
||||
|
||||
With this change, there are now three trees of accounting chains:
|
||||
|
||||
- The one rooted in the 'accounting' chain.
|
||||
- The one rooted in the 'accipsecin' chain. This tree handles
|
||||
traffic that has been decrypted on the firewall. Rules in this
|
||||
tree cannot specify an interface name in the DEST column.
|
||||
- The one rooted in the 'accipsecout' chain. This tree handles
|
||||
traffic that will be encrypted on the firewall. Rules in this
|
||||
tree cannot specify an interface name in the SOURCE column.
|
||||
|
||||
In reality, when there are bridges defined in the configuration,
|
||||
there is a fourth tree rooted in the 'accountout' chain. That chain
|
||||
handles traffic that originates on the firewall (both IPSEC and
|
||||
non-IPSEC).
|
||||
|
||||
This change also implements a couple of new warnings:
|
||||
|
||||
- WARNING: Adding rule to unreferenced accounting chain <name>
|
||||
|
||||
The first reference to user-defined accounting chain <name> is
|
||||
not a JUMP or COUNT from an already-defined chain.
|
||||
|
||||
- WARNING: Accounting chain <name> has o references
|
||||
|
||||
The named chain contains accounting rules but no JUMP or COUNT
|
||||
specifies that chain as the target.
|
||||
|
||||
3) Shorewall now supports the SECMARK and CONNSECMARK targets for
|
||||
manipulating the SELinux context of packets.
|
||||
|
||||
See the shorewall-secmarks and shorewall6-secmarks manpages for
|
||||
details.
|
||||
|
||||
As part of this change, the tcrules file now accepts $FW in the
|
||||
DEST column for marking packets in the INPUT chain.
|
||||
|
||||
4) Blacklisting has undergone considerable change in Shorewall 4.4.13.
|
||||
|
||||
a) Blacklisting is now based on zones rather than on interfaces and
|
||||
host groups.
|
||||
|
||||
b) Near compatibility with earlier releases is maintained.
|
||||
|
||||
c) The keywords 'src' and 'dst' are now preferred in the OPTIONS
|
||||
column in /etc/shoreawll/blacklist, replacing 'from' and 'to'
|
||||
respectively. The old keywords are still supported.
|
||||
|
||||
d) The 'blacklist' keyword may now appear in the OPTIONS,
|
||||
IN_OPTIONS and OUT_OPTIONS fields in /etc/shorewall/zones.
|
||||
|
||||
i) In the IN_OPTIONS column, it indicates that packets received
|
||||
on the interface are checked against the 'src' entries in
|
||||
/etc/shorewall/blacklist.
|
||||
|
||||
ii) In the OUT_OPTIONS column, it indicates that packets being
|
||||
sent to the interface are checked against the 'dst' entries.
|
||||
|
||||
iii) Placing 'blacklist' in the OPTIONS column is equivalent to
|
||||
placing in in both the IN_OPTIONS and OUT_OPTIONS columns.
|
||||
|
||||
e) The 'blacklist' option in the OPTIONS column of
|
||||
/etc/shorewall/interfaces or /etc/shorewall/hosts is now
|
||||
equivalent to placing it in the IN_OPTIONS column of the
|
||||
associates record in /etc/shorewall/zones. If no zone is given
|
||||
in the ZONE column of /etc/shorewall/interfaces, the 'blacklist'
|
||||
option is ignored with a warning (it was previously ignored
|
||||
silently).
|
||||
|
||||
f) The 'blacklist' option in the /etc/shorewall/interfaces and
|
||||
/etc/shorewall/hosts files is now deprecated but will continue
|
||||
to be supported for several releases. A warning will be added at
|
||||
least one release before support is removed.
|
||||
|
||||
5) There is now an OUT-BANDWIDTH column in
|
||||
/etc/shorewall/tcinterfaces.
|
||||
|
||||
The format of this column is:
|
||||
|
||||
<rate>[:[<burst>][:[<latency>][:[<peak>][:[<minburst>]]]]]
|
||||
|
||||
These terms are described in tc-tbf(8). Shorewall supplies default
|
||||
values as follows:
|
||||
|
||||
<burst> = 10kb
|
||||
<latency> = 200ms
|
||||
|
||||
The remaining options are defaulted by tc.
|
||||
|
||||
6) The IN-BANDWIDTH column in both /etc/shorewall/tcdevices and
|
||||
/etc/shorewall/tcinterfaces now accepts an optional burst parameter.
|
||||
|
||||
<rate>[:<burst>]
|
||||
|
||||
The default <burst> is 10kb. A larger <burst> can help make the
|
||||
<rate> more accurate; often for fast lines, the enforced rate is
|
||||
well below the specified <rate>.
|
||||
|
||||
----------------------------------------------------------------------------
|
||||
P R O B L E M S C O R R E C T E D I N 4 . 4 . 1 2
|
||||
----------------------------------------------------------------------------
|
||||
|
||||
Loading…
Reference in New Issue
Block a user