168 lines
5.0 KiB
Plaintext
168 lines
5.0 KiB
Plaintext
# -*- 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.
|
|
#
|
|
# $Id: 9bf86978db676ef16f6062f4d359385e291cc930 $
|
|
#
|
|
######################################################################
|
|
|
|
# (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) Define a virtual server to be used when both of the
|
|
# home servers are down.
|
|
home_server acct_detail.example.com {
|
|
virtual_server = acct_detail.example.com
|
|
}
|
|
|
|
# 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.
|
|
|
|
# If all home servers are down, try a home server that
|
|
# is a local virtual server.
|
|
fallback = acct_detail.example.com
|
|
|
|
# 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 the virtual server to write the packets to the detail file
|
|
# This will be called when ALL home servers are down, because of the
|
|
# "fallback" configuration in the home server pool.
|
|
server acct_detail.example.com {
|
|
accounting {
|
|
detail.example.com
|
|
}
|
|
}
|
|
|
|
# (6) 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 {
|
|
detail.example.com
|
|
}
|
|
}
|
|
|
|
|
|
# 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-*:*"
|
|
load_factor = 10
|
|
}
|
|
|
|
# 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"
|
|
}
|
|
}
|
|
|
|
}
|