Ik wou gewoon ff schrijven wat ik gedaan heb. Not sure if I'm doing it right but I was not getting any firewall rules for "alias" interfaces (eth0:0) when they had a dynamic IP, so I gave them a static IP instead. But iptables can't actually handle those names (they are not real interfaces) so I just performed a iptables-save | sed | iptables-restore on the result to turn it into regular eth0.
The version of iptrafvol.pl I had (probably still the same version) also couldn't handle any names with : or - in it, so I just adjusted a few of the regular expressions. Curious what I will do, my eth0:0 is actually ...well it is registering the input and output of the eth0 interface, which means all data for services on that primary IP. Meanwhile eth0:1 has/is a secondary IP that forwards data to an internal container (LXC) so I have put forwarding traffic on that accounting chain which means that traffic being forwarded (DNAT) appears as "input" on the accounting, and as "output" on the internal interface leading to the container. | 27 Sep| 5.4 282.6| 48.2 0.5| 0.5 48.2| |-------+---------------+---------------+---------------| | Total:| 5.4 282.6| 48.2 0.5| 0.5 48.2| | | eth0:0| eth0:1| lxc-nat-bridge| +-------------------------------------------------------+ Perhaps then not very useful. I wonder where tunnel traffic would be counted? You would assume input/output, since it is either a client or service running on eth0. Vuurmuur doesn't handle connmarks very well, so the 3 states I have seen used (values 0, 1, 2) I have transformed into masked values with 0/3, 1/3 and 2/3, such that I can use other bits (say, 32) as my own values for what I want to do. -t mangle -A INPUT -s 10.3.0.2 -m conntrack --ctstate NEW -j CONNMARK --or-mark 32 This transforms into some --set-xmark call: -A INPUT -s 10.3.0.2/32 -m conntrack --ctstate NEW -j CONNMARK --set-xmark 0x20/0x20 But it leaves any other values alone (since it is an or-operation). The values I've seen are now masked: -A OUTPUT -p udp -m udp -m conntrack --ctstate RELATED -m connmark --mark 0x0/0x3 -j CONNMARK --set-xmark 0x1/0x3 Instead of using the full range as before, leaving me the room to use other values. The mask effectively first zeroes those bits (in this case, bits 1 and 2) and then sets the value (such as 1 above). Then of course you can use them in whatever way you want: -t nat -A POSTROUTING -s 10.3.0.0/24 -o lxc-nat-bridge -m connmark ! --mark 32/32 -j SNAT --to-source 149.243.210.127 The mask ensures only the 6th bit is used (32). I was actually just experimenting with using internal containers (LXC), not really wanting to use it. Trouble is..... By using an internal container that you masquerade (which I think is the only sensible choice really) you delegate firewall configuration to the container for its own services. Normally a container would run a small subset of services but it does mean you have to install the same software (e.g. vuurmuur) and traffic accounting etc. which is always extra configuration and not really something you want to do. You *can* curtail traffic at the entry point (your host) but this seems suboptimal because to you it is forwarding traffic and because Vuurmuur does not currently have working packages it is an extra burden (and backing up your configuration is perhaps harder). Using a container to run a service seems suboptimal to begin with because of the duplication of configuration everywhere -- from the mail host (exim4) to the webserver (apache) -- everything needs a bit of duplicate configuration and in order to de-duplicate it... you have to go share filesystems which is another hard step to do. On Debian the /usr tree could be shared, but then you'd have to share /var/lib/dpkg as well. As well as perhaps /var/lib/apt, and make them read-only for the container. Same goes for /sbin and /lib* but not for /etc. If you're going to run duplicate services (which seems to be the whole intent) you will have a non-shared /var/log for those services, and possibly a non-shared /var/lib. It gets rather complex pretty soon. Bleed it together. The container hosts its own services so they are only INPUT to that container. To your host they may be FORWARDS. ------------------------------------------------------------------------------ _______________________________________________ Vuurmuur-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/vuurmuur-users
