debhelpers on stretch do not care about the wrong uinit name, and the
name used is always the one from --name.
But buster cares, so fix it to the right one.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Stoiko Ivanov [Sat, 26 May 2018 20:50:30 +0000 (22:50 +0200)]
Don't change external ebtables rules
* Fixes #1764
* Introduces ebtables_enable option to cluster config
* All ebtables chains not created by PVE are left in place
* get_ruleset_status optionally takes an additional argument
(a regex indicating which chains should be left intact)
Since we don't have signatures in ebtables we need to also
see empty chains to not think we have to create them.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
ebtables doesn't have comment rules we could store the
digest in, so we need to match the ebtables-save output
instead.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
need ebtables-save && ebtables-restore, ebtables debian package don't include them.
ebtables-restore need to restore the full ruleset (atomicaly),
so we can't update only 1 chain
Signed-off-by: Alexandre Derumier <aderumier at odiso.com> Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
-A FORWARD -j PVEFW-FORWARD
-A PVEFW-FORWARD -p IPv4 -j ACCEPT #filter mac in iptables for ipv4, so we can speedup rules with conntrack established
-A PVEFW-FORWARD -p IPv6 -j ACCEPT
-A PVEFW-FORWARD -o fwln+ -j PVEFW-FWBR-OUT
-A PVEFW-FWBR-OUT -i tap110i0 -j tap110i0-OUT
-A tap110i0-OUT -s ! 36:97:15:91:19:3c -j DROP
-A tap110i0-OUT -p ARP -j ACCEPT
-A tap110i0-OUT -j DROP
-A tap110i0-OUT -j ACCEPT
-A PVEFW-FWBR-OUT -i veth130.1 -j veth130.1-OUT
-A veth130.1-OUT -s ! 36:95:a9:ae:f5:ec -j DROP
-A veth130.1-OUT -j ACCEPT
Signed-off-by: Alexandre Derumier <aderumier at odiso.com> Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
parse_protocol_file: support lines without end comments
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The multiport `--ports` parameter is an `OR` match on source
and destination ports, so we should not use it.
We also don't actually use the port count, so let the port
range parser simply return a boolean and use the counter
only for the internal check. This also fixes a regression
caused by the previous multiport check which caused a single
port range to be recognized as a multiport option while it
did not have to be one, causing entries such as the SMB
macro to be added with `--match multiport` mistakenly, which
refused to accept the source port option.
Additionally, we now allow the case with 1 multiport and 1
single port entry: In order for the iptables command to
accept this the single port entry must come first, otherwise
it'll be passed to the multiport matcher (because why
shouldn't it interpret a singular `--Xport` as an alias to
the plural version `--Xports`... *sigh*).
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com> Fixes: 6a241ca745f7 ("check multiport limit in port ranges")
Tom Weber [Wed, 18 Oct 2017 20:24:05 +0000 (22:24 +0200)]
implement ipt_rule_to_cmds, ruleset_add_ipt_cmd
ipt_rule_to_cmds converts a %rule to an array of iptables commands
ruleset_add_ipt_cmd adds such an iptables command to a chain
ruleset_generate_rule uses these now
ruleset_generate_rule_old is an interim workaround
Tom Weber [Wed, 18 Oct 2017 20:24:02 +0000 (22:24 +0200)]
make $pve_std_chains a copy of $pve_std_chains_conf
create a new $pve_std_chains with $pve_std_chains_conf as template on
every compilation of the rules. This avoids persitant changes to the
$pve_std_chains and makes it easier to read the std_chains configuration
from external config files (later to implement).
Tom Weber [Wed, 18 Oct 2017 20:23:59 +0000 (22:23 +0200)]
prepare code for more generic firewall logging
making ruleset generation aware of a match and action
part in iptable rules.
code will generate the same iptables as before! (except for
a few additional spaces between match and action).
g_thread_new is part of glib directly, libgthread only
contains the deprecated g_thread_init() & friends which we
do not use.
This silences a build warning.
Thomas Lamprecht [Tue, 13 Dec 2016 12:13:39 +0000 (13:13 +0100)]
fix ambiguous if statements
the funciton nflog_bind_pf(...) returns an integer smaller 0 on a
failure, we negated that which results in 1 if no failure and 0 if
there was a failure.
This is ambiguous and as no parenthesis are set the GCC 6 warning
"logical-not-parentheses" gets triggered.
Use a simple
nflog_bind_pf(...) < 0
check instead.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>