1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
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'
}
}
}
|
