From: Antony Stone <Antony@Soft-Solutions.co.uk>
To: netfilter@lists.netfilter.org
Subject: Re: A practical problem regarding IP Accounting ...?
Date: Tue, 9 Mar 2004 09:04:01 +0000 [thread overview]
Message-ID: <200403090904.01979.Antony@Soft-Solutions.co.uk> (raw)
In-Reply-To: <7C9884991ADAE0479C14F10C858BCDF5122F0B@alderaan.smgtec.com>
On Tuesday 09 March 2004 1:02 am, Daniel Chemko wrote:
> # Outbound to PC
> iptables -t mangle -A PREROUTING -i eth1 --source <ip_address>
> # Inbound to PC
> iptables -t mangle -A POSTROUTING -o eth1 --destination <ip_address>
>
> Then use your own accounting tool to rip the byte count from "iptables -t
> mangle -nvxL". Remember though, the byte count can reset or overflow to 0,
> so make sure your accounting package can handle this.
I think this is an excellent answer, but there are some subtleties about it
which Daniel did not empphasise, and I think they're worth explaining so
people understand a little more about netfilter:
1. The rules have no targets! ie: there is no "-j ACCEPT" etc at the end.
This is perfectly correct and acceptable (in any chain, not just mangle), and
means the netfilter will count the packets which match, but not do anything
special with them. Such a rule is useful only for counting packets & bytes,
but it means you can count them without immediately deciding what happens to
them - you can sgtill follow the accounting rules with your normal filtering
/ natting / mangling rules.
2. The rules are in the mangle tables because this is the closest that
netfilter can get to the interfaces themselves, and it makes sure that the
rules really do count all the packets going in and out of the machine,
without some quietly slipping past behind the scenes as they could do if you
counted packets in the nat table (the rules would not see reply packets being
automatically de-natted), or the filter table (where it would be difficult to
combine sensible accounting with the stanadard stateful ESTABLISHED, RELATED
rule).
I hope this helps a few people understand a bit more about why this is a very
good solution to packet accounting, as well as perhaps a bit more about the
way packets go through mangle, nat and filter.
Regards,
Antony.
--
Wanted: telepath. You know where to apply.
Please reply to the list;
please don't CC me.
next prev parent reply other threads:[~2004-03-09 9:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-09 1:02 A practical problem regarding IP Accounting ...? Daniel Chemko
2004-03-09 9:04 ` Antony Stone [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-03-09 0:09 toto eucup
2004-03-09 2:53 ` Ted Kaczmarek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200403090904.01979.Antony@Soft-Solutions.co.uk \
--to=antony@soft-solutions.co.uk \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox