1 |
This is almost certainly the wrong place to ask, but have any clever |
2 |
folks here got some ideas for doing per user (and eventually per |
3 |
user/per protocol) accounting for data crossing a router box (running |
4 |
gentoo)? |
5 |
|
6 |
The situation is something like: users connect to the router, are |
7 |
authenticated and then the router forwards data through one of several |
8 |
WAN connections (wireless, 3g and dialup). The goal is to track usage |
9 |
per user across each *WAN connection* in order to bill appropriately |
10 |
(because it costs more to use dialup than to use wireless, but sometimes |
11 |
dialup is all that is available - the hotspot is mobile...) |
12 |
|
13 |
For various reasons we can't assume that the bytes in/out from the LAN |
14 |
to the router are the same as the bytes sent over the WAN, eg in the |
15 |
simplest case lets add a squid proxy to the router and now the billable |
16 |
WAN data may be much lower than the LAN data. Additionally the router |
17 |
will host a simple CMS/file share that won't cause data to go over the WAN |
18 |
|
19 |
I guess the pieces are: |
20 |
|
21 |
1) User authentication on the wired/wireless (LAN) input side (802.1x + |
22 |
perhaps a captive portal which also auths via radius?) |
23 |
|
24 |
2) Gateway which allows authenticated users to route through the various |
25 |
WANs |
26 |
|
27 |
3) Packet accounting that collects info on the data used over each WAN |
28 |
|
29 |
|
30 |
I'm somewhat unsure what my options are though to pass through the |
31 |
per-user auth info collected in step 1 to other pieces of the puzzle? I |
32 |
could build a mapping of users to IP addresses and then IP becomes a |
33 |
synonym for "user". Are there other packet marking techniques I could |
34 |
use that will scale to hundreds of users? (eg vlans appear not to be a |
35 |
sensible option?) |
36 |
|
37 |
I think 3) will often require support from the applications running on |
38 |
the router itself, eg a web connection passing through squid is hard to |
39 |
account for across the WAN because it all looks like a mass of data from |
40 |
the squid process. Any thoughts on a scalable way to account for the |
41 |
data from each app and log it? (Radius / DB / some library which someone |
42 |
already wrote?) |
43 |
|
44 |
Ideally I would like to be able to show quite granular statistics for |
45 |
each user, eg connection at 8pm for 10 mins, 200KB of email, 5KB web, |
46 |
2KB DNS. Can radius be (mis) used to track accounting to this low level? |
47 |
|
48 |
The WAN connections in this scenario are quite expensive and we have a |
49 |
requirement to track quite granularly... |
50 |
|
51 |
|
52 |
Thanks for any pointers to techniques I could use to solve any of the |
53 |
pieces above? Note: I'm currently pulling apart wifidog and coova to |
54 |
get some ideas about how some of the captive portals implement the |
55 |
gateway part, but their bandwidth accounting is all measured at the user |
56 |
side and I need to measure mine at the WAN side... |
57 |
|
58 |
Thanks |
59 |
|
60 |
Ed W |