Hi all,
I want to do some per-host accounting on shorewall 4.2.8 to find out
where all the Internet bandwidth usage is going. This gets kinda
interesting though because I have some virtual/tunnel interfaces on the
shorewall machine. Specifically I have an 6to4 tunnel as well as
openvpn.
Assumptions: internet interface is eth0.1
local machines are on br-lan
So first the basics. It seems that accounting rules of the sort will
account for standard internet usage:
acc_pc:COUNT - eth0.1 br-lan:10.75.22.1
acc_pc:COUNT - br-lan:10.75.22.1 eth0.1
DONE acc_pc
acc_j_lt:COUNT - eth0.1 br-lan:10.75.22.208
acc_j_lt:COUNT - br-lan:10.75.22.208 eth0.1
DONE acc_j_lt
acc_linux:COUNT - eth0.1 br-lan:10.75.22.3
acc_linux:COUNT - br-lan:10.75.22.3 eth0.1
DONE acc_linux
DONE - - eth0.1
DONE - eth0.1 -
This gives me individual chains for each machine as well as an overall
usage of eth0.1 so that I can see if there is something happening that I
am not accounting for.
But now, how are interfaces like tun0 (openvpn) and my "Link
encap:IPv6-in-IPv4" being handled? They are certainly not going to be
covered by the above rules. Do I need to add a:
acc_pc:COUNT - tun0 br-lan:10.75.22.1
acc_pc:COUNT - br-lan:10.75.22.1 tun0
for the openvpn traffic (which ultimately uses eth0.1) as well as:
acc_pc:COUNT - sixxs br-lan:10.75.22.1
acc_pc:COUNT - br-lan:10.75.22.1 sixxs
for the "encap:IPv6-in-IPv4" interface? But shorewall
doesn''t know
about the "sixxs" interface.
Is there a better way to do all of this?
How can I figure out if I have any "leaks"? i.e. traffic that is not
being accounted for. Probably some kind of logging rule might be
appropriate but given that I want all eth0.1 to fall through to the
final two "DONE" rules so that I get a total for the interface,
it''s not
clear to me where I could log traffic that does not get accounted for by
one of the previous rules/chains.
Thanx,
b.
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register
now!
http://p.sf.net/sfu/devconf
OK. I''ve refined (or tried to) my rules a bit. For a single host, I
have this:
#ACTION CHAIN SOURCE DESTINATION PROTO DEST SOURCE USER/
# PORT(S) PORT(S) GROUP
acc_pc:COUNT - eth0.1 br-lan:10.75.22.1
acc_pc:COUNT - br-lan:10.75.22.1 eth0.1
acc_pc:COUNT - tun0 br-lan:10.75.22.1
acc_pc:COUNT - br-lan:10.75.22.1 tun0
COUNT acc_pc - - tcp 143
COUNT acc_pc - - tcp 22
DONE acc_pc
so that the overall, per interface traffic per host is accounted for in
the accounting chain and a drill down of selected protocols is done in a
separate chain per host. (Yes, I know I need reciprocal rules for the
port 22,143 rules.)
The above rules result in a strange artifact though. Witness:
Chain acc_pc (4 references)
pkts bytes target prot opt in out source destination
3859 2993K all -- eth0.1 br-lan 0.0.0.0/0 10.75.22.1
3242 234K all -- br-lan eth0.1 10.75.22.1 0.0.0.0/0
199 28609 all -- tun0 br-lan 0.0.0.0/0 10.75.22.1
213 27023 all -- br-lan tun0 10.75.22.1 0.0.0.0/0
1837 127K tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:143
0 0 tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:22
7513 3283K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Chain accounting (3 references)
pkts bytes target prot opt in out source destination
3859 2993K acc_pc all -- eth0.1 br-lan 0.0.0.0/0 10.75.22.1
3242 234K acc_pc all -- br-lan eth0.1 10.75.22.1 0.0.0.0/0
199 28609 acc_pc all -- tun0 br-lan 0.0.0.0/0 10.75.22.1
213 27023 acc_pc all -- br-lan tun0 10.75.22.1 0.0.0.0/0
...
12124 2253K RETURN all -- * eth0.1 0.0.0.0/0 0.0.0.0/0
14236 13M RETURN all -- eth0.1 * 0.0.0.0/0 0.0.0.0/0
Why are the interface rules being added to both the accounting chain and
the acc_pc chain? The former is obvious, buy the latter?
Again, this is shorewall 4.2.8.
b.
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register
now!
http://p.sf.net/sfu/devconf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian J. Murrell wrote:> > Why are the interface rules being added to both the accounting chain and > the acc_pc chain? The former is obvious, buy the latter?Shorewall processes the accounting file in a single pass -- so it can''t know that all of the branches to acc_pc will include the same interface. - -Tom - -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrDnrwACgkQO/MAbZfjDLL7nwCeLEYIo6GdO4IAHcy7yNJBxB+E jSYAnRZ5QdLxIZTRjaE1UdzZlepIAONE =lg4T -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf