diff options
Diffstat (limited to 'raddb/sites-available/robust-proxy-accounting')
| -rw-r--r-- | raddb/sites-available/robust-proxy-accounting | 177 |
1 files changed, 177 insertions, 0 deletions
diff --git a/raddb/sites-available/robust-proxy-accounting b/raddb/sites-available/robust-proxy-accounting new file mode 100644 index 0000000..7371643 --- /dev/null +++ b/raddb/sites-available/robust-proxy-accounting @@ -0,0 +1,177 @@ +# -*- text -*- +###################################################################### +# +# This is a sample configuration for robust proxy accounting. +# accounting packets are proxied, OR logged locally if all +# home servers are down. When the home servers come back up, +# the accounting packets are forwarded. +# +# This method enables the server to proxy all packets to the +# home servers when they're up, AND to avoid writing to the +# detail file in most situations. +# +# In most situations, proxying of accounting messages is done +# in a "pass-through" fashion. If the home server does not +# respond, then the proxy server does not respond to the NAS. +# That means that the NAS must retransmit packets, sometimes +# forever. This example shows how the proxy server can still +# respond to the NAS, even if all home servers are down. +# +# This configuration could be done MUCH more simply if ALL +# packets were written to the detail file. But that would +# involve a lot more disk writes, which may not be a good idea. +# +# This file is NOT meant to be used as-is. It needs to be +# edited to match your local configuration. +# +# Please see the sites-available/default file, in the +# "Post-Proxy-Type Fail-Accounting" section. That should be +# configured to write packets to the "detail.example.com" +# file when proxying fails. The "listen" section below will +# then read packets from that file, and proxy them. +# +# See also mods-available/detail.example.com, which is the +# module that writes the "detail.example.com" file. +# +# +# $Id$ +# +###################################################################### + +# (1) Define two home servers. +home_server home1.example.com { + type = acct + ipaddr = 192.0.2.10 + port = 1813 + secret = testing123 + + # Mark this home server alive ONLY when it starts being responsive + status_check = request + username = "test_user_status_check" + + # Set the response timeout aggressively low. + # You MAY have to increase this, depending on tests with + # your local installation. + response_window = 6 +} + +home_server home2.example.com { + type = acct + ipaddr = 192.0.2.20 + port = 1813 + secret = testing123 + + # Mark this home server alive ONLY when it starts being responsive + status_check = request + username = "test_user_status_check" + + # Set the response timeout aggressively low. + # You MAY have to increase this, depending on tests with + # your local installation. + response_window = 6 +} + +# (2) Put all of the servers into a pool. +home_server_pool acct_pool.example.com { + type = load-balance # other types are OK, too. + + home_server = home1.example.com + home_server = home2.example.com + # add more home_server's here. + + # for pre/post-proxy policies + virtual_server = home.example.com +} + +# (3) Define a realm for these home servers. +# It should NOT be used as part of normal proxying decisions! +realm acct_realm.example.com { + acct_pool = acct_pool.example.com +} + +# (4) Define a detail file writer. +# See raddb/modules/detail.example.com + +# (5) Define a virtual server to handle pre/post-proxy re-writing +server home.example.com { + pre-proxy { + # Insert pre-proxy rules here + } + + post-proxy { + # Insert post-proxy rules here + + # This will be called when the CURRENT packet failed + # to be proxied. This may happen when one home server + # suddenly goes down, even though another home server + # may be alive. + # + # i.e. the current request has run out of time, so it + # cannot fail over to another (possibly) alive server. + # + # We want to respond to the NAS, so that it can stop + # re-sending the packet. We write the packet to the + # "detail" file, where it will be read, and sent to + # another home server. + # + Post-Proxy-Type Fail-Accounting { + detail.example.com + + # Now that the packet has been stored + # mark that we can respond to the NAS + acct_response + } + + # + # This section is run when there are problems + # proxying Access-Request packets + # + Post-Proxy-Type Fail-Authentication { + # add policies here + } + + } + + + # Read accounting packets from the detail file(s) for + # the home server. + # + # Note that you can have only ONE "listen" section reading + # detail files from a particular directory. That is why the + # destination host name is used as part of the directory name + # below. Having two "listen" sections reading detail files + # from the same directory WILL cause problems. The packets + # may be read by one, the other, or both "listen" sections. + listen { + type = detail + filename = "${radacctdir}/detail.example.com/detail-*:*" + + # + # See sites-available/buffered-sql for documentation + # on the configuration items for a detail listener. + # + load_factor = 90 + track = yes + } + + # All packets read from the detail file are proxied back to + # the home servers. + # + # The normal pre/post-proxy rules are applied to them, too. + # + # If the home servers are STILL down, then the server stops + # reading the detail file, and queues the packets for a later + # retransmission. The Post-Proxy-Type "Fail" handler is NOT + # called. + # + # When the home servers come back up, the packets are forwarded, + # and the detail file processed as normal. + accounting { + # You may want accounting policies here... + + update control { + &Proxy-To-Realm := 'acct_realm.example.com' + } + } + +} |