| 4 |
- |
1 |
1. Virtual Servers.
|
|
|
2 |
|
|
|
3 |
FreeRADIUS 2.0 supports virtual servers. This is probably the
|
|
|
4 |
single largest change that is NOT backwards compatible with 1.x.
|
|
|
5 |
|
|
|
6 |
The virtual servers do NOT have to be set up with the
|
|
|
7 |
"sites-available" and "sites-enabled" directories. You can still have
|
|
|
8 |
one "radiusd.conf" file, and put the server configuration there:
|
|
|
9 |
|
|
|
10 |
...
|
|
|
11 |
server {
|
|
|
12 |
authorize {
|
|
|
13 |
...
|
|
|
14 |
}
|
|
|
15 |
authenticate {
|
|
|
16 |
...
|
|
|
17 |
}
|
|
|
18 |
...
|
|
|
19 |
}
|
|
|
20 |
...
|
|
|
21 |
|
|
|
22 |
The power of virtual servers lies in their ability to separate
|
|
|
23 |
policies. A policy can be placed into a virtual server, where it is
|
|
|
24 |
guaranteed to affect only the requests that are passed through that
|
|
|
25 |
virtual server. In 1.x, the policies were global, and it sometimes
|
|
|
26 |
took much effort to write a policy so that it only applied in certain
|
|
|
27 |
limited situations.
|
|
|
28 |
|
|
|
29 |
|
|
|
30 |
2. What do we mean by "virtual server"?
|
|
|
31 |
|
|
|
32 |
|
|
|
33 |
A virtual server is a (nearly complete) RADIUS server, just like a
|
|
|
34 |
configuration for FreeRADIUS 1.x. However, FreeRADIUS can now run
|
|
|
35 |
multiple virtual servers at the same time. The virtual servers can
|
|
|
36 |
even proxy requests to each other!
|
|
|
37 |
|
|
|
38 |
The simplest way to create a virtual server is to take the all of
|
|
|
39 |
the request processing sections from radius.conf, ("authorize" ,
|
|
|
40 |
"authenticate", etc.) and wrap them in a "server {}" block, as above.
|
|
|
41 |
|
|
|
42 |
You can create another virtual server by:
|
|
|
43 |
|
|
|
44 |
1) defining a new "server foo {...}" section in radiusd.conf
|
|
|
45 |
2) Putting the normal "authorize", etc. sections inside of it
|
|
|
46 |
3) Adding a "listen" section *inside* of the "server" section.
|
|
|
47 |
|
|
|
48 |
e.g.
|
|
|
49 |
|
|
|
50 |
...
|
|
|
51 |
server foo {
|
|
|
52 |
listen {
|
|
|
53 |
ipaddr = 127.0.0.1
|
|
|
54 |
port = 2000
|
|
|
55 |
type = auth
|
|
|
56 |
}
|
|
|
57 |
|
|
|
58 |
authorize {
|
|
|
59 |
update control {
|
|
|
60 |
Cleartext-Password := "bob"
|
|
|
61 |
}
|
|
|
62 |
pap
|
|
|
63 |
}
|
|
|
64 |
|
|
|
65 |
authenticate {
|
|
|
66 |
pap
|
|
|
67 |
}
|
|
|
68 |
}
|
|
|
69 |
...
|
|
|
70 |
|
|
|
71 |
With that text added to "radiusd.conf", run the server in debugging
|
|
|
72 |
mode (radiusd -X), and in another terminal window, type:
|
|
|
73 |
|
|
|
74 |
$ radtest bob bob localhost:2000 0 testing123
|
|
|
75 |
|
|
|
76 |
You should see the server return an Access-Accept.
|
|
|
77 |
|
|
|
78 |
|
|
|
79 |
3. Capabilities and limitations
|
|
|
80 |
|
|
|
81 |
|
|
|
82 |
The only sub-sections that can appear in a virtual server section
|
|
|
83 |
are:
|
|
|
84 |
|
|
|
85 |
listen
|
|
|
86 |
client
|
|
|
87 |
authorize
|
|
|
88 |
authenticate
|
|
|
89 |
post-auth
|
|
|
90 |
pre-proxy
|
|
|
91 |
post-proxy
|
|
|
92 |
preacct
|
|
|
93 |
accounting
|
|
|
94 |
session
|
|
|
95 |
|
|
|
96 |
All other configuration parameters (modules, etc.) are global.
|
|
|
97 |
|
|
|
98 |
Inside of a virtual server, the authorize, etc. sections have their
|
|
|
99 |
normal meaning, and can contain anything that an authorize section
|
|
|
100 |
could contain in 1.x.
|
|
|
101 |
|
|
|
102 |
When a "listen" section is inside of a virtual server definition, it
|
|
|
103 |
means that all requests sent to that IP/port will be processed through
|
|
|
104 |
the virtual server. There cannot be two "listen" sections with the
|
|
|
105 |
same IP address and port number.
|
|
|
106 |
|
|
|
107 |
When a "client" section is inside of a virtual server definition, it
|
|
|
108 |
means that that client is known only to the "listen" sections that are
|
|
|
109 |
also inside of that virtual server. Not only is this client
|
|
|
110 |
definition available only to this virtual server, but the details of
|
|
|
111 |
the client configuration is also available only to this virtual
|
|
|
112 |
server.
|
|
|
113 |
|
|
|
114 |
i.e. Two virtual servers can listen on different IP address and
|
|
|
115 |
ports, but both can have a client with IP address 127.0.0.1. The
|
|
|
116 |
shared secret for that client can be different for each virtual
|
|
|
117 |
server.
|
|
|
118 |
|
|
|
119 |
|
|
|
120 |
4. More complex "listen" capabilities
|
|
|
121 |
|
|
|
122 |
The "listen" sections have a few additional configuration items that
|
|
|
123 |
were not in 1.x, and were not mentioned above. These configuration
|
|
|
124 |
items enable almost any mapping of IP / port to clients to virtual
|
|
|
125 |
servers.
|
|
|
126 |
|
|
|
127 |
The configuration items are:
|
|
|
128 |
|
|
|
129 |
virtual_server = <name>
|
|
|
130 |
|
|
|
131 |
If set, all requests sent to this IP / port are processed
|
|
|
132 |
through the named virtual server.
|
|
|
133 |
|
|
|
134 |
This directive can be used only for "listen" sections
|
|
|
135 |
that are global. i.e. It CANNOT be used if the
|
|
|
136 |
"listen" section is inside of a virtual server.
|
|
|
137 |
|
|
|
138 |
clients = <name>
|
|
|
139 |
|
|
|
140 |
If set, the "listen" section looks for a "clients" section:
|
|
|
141 |
|
|
|
142 |
clients <name> {
|
|
|
143 |
...
|
|
|
144 |
}
|
|
|
145 |
|
|
|
146 |
It looks inside of that named "clients" section for
|
|
|
147 |
"client" subsections, at least one of which must
|
|
|
148 |
exist. Each client in that section is added to the
|
|
|
149 |
list of known clients for this IP / port. No other
|
|
|
150 |
clients are known.
|
|
|
151 |
|
|
|
152 |
If it is set, it over-rides the list of clients (if
|
|
|
153 |
any) in the same virtual server. Note that the
|
|
|
154 |
clients are NOT additive!
|
|
|
155 |
|
|
|
156 |
If it is not set, then the clients from the current
|
|
|
157 |
virtual server (if any) are used. If there are no
|
|
|
158 |
clients in this virtual server, then the global
|
|
|
159 |
clients are used.
|
|
|
160 |
|
|
|
161 |
i.e. The most specific directive is used:
|
|
|
162 |
* configuration in this "listen" section
|
|
|
163 |
* clients in the same virtual server
|
|
|
164 |
* global clients
|
|
|
165 |
|
|
|
166 |
The directives are also *exclusive*, not *additive*.
|
|
|
167 |
If you have one client in a virtual server, and
|
|
|
168 |
another client referenced from a "listen" section,
|
|
|
169 |
then that "listen" section will ONLY use the second
|
|
|
170 |
client. It will NOT use both clients.
|
|
|
171 |
|
|
|
172 |
|
|
|
173 |
5. More complex "client" capabilities
|
|
|
174 |
|
|
|
175 |
The "client" sections have a few additional configuration items that
|
|
|
176 |
were not in 1.x, and were not mentioned above. These configuration
|
|
|
177 |
items enable almost any mapping of IP / port to clients to virtual
|
|
|
178 |
servers.
|
|
|
179 |
|
|
|
180 |
The configuration items are:
|
|
|
181 |
|
|
|
182 |
virtual_server = <name>
|
|
|
183 |
|
|
|
184 |
If set, all requests from this client are processed
|
|
|
185 |
through the named virtual server.
|
|
|
186 |
|
|
|
187 |
This directive can be used only for "client" sections
|
|
|
188 |
that are global. i.e. It CANNOT be used if the
|
|
|
189 |
"client" section is inside of a virtual server.
|
|
|
190 |
|
|
|
191 |
If the "listen" section has a "server" entry, and a matching
|
|
|
192 |
client is found ALSO with a "server" entry, then the clients server is
|
|
|
193 |
used for that request.
|
|
|
194 |
|
|
|
195 |
|
|
|
196 |
6. Worked examples
|
|
|
197 |
|
|
|
198 |
|
|
|
199 |
Listening on one socket, and mapping requests from two clients to
|
|
|
200 |
two different servers.
|
|
|
201 |
|
|
|
202 |
listen {
|
|
|
203 |
...
|
|
|
204 |
}
|
|
|
205 |
client one {
|
|
|
206 |
...
|
|
|
207 |
virtual_server = server_one
|
|
|
208 |
}
|
|
|
209 |
client two {
|
|
|
210 |
...
|
|
|
211 |
virtual_server = server_two
|
|
|
212 |
}
|
|
|
213 |
server server_one {
|
|
|
214 |
authorize {
|
|
|
215 |
...
|
|
|
216 |
}
|
|
|
217 |
...
|
|
|
218 |
}
|
|
|
219 |
server server_two {
|
|
|
220 |
authorize {
|
|
|
221 |
...
|
|
|
222 |
}
|
|
|
223 |
...
|
|
|
224 |
}
|
|
|
225 |
|
|
|
226 |
This could also be done as:
|
|
|
227 |
|
|
|
228 |
|
|
|
229 |
listen {
|
|
|
230 |
...
|
|
|
231 |
virtual_server = server_one
|
|
|
232 |
}
|
|
|
233 |
client one {
|
|
|
234 |
...
|
|
|
235 |
}
|
|
|
236 |
client two {
|
|
|
237 |
...
|
|
|
238 |
virtual_server = server_two
|
|
|
239 |
}
|
|
|
240 |
server server_one {
|
|
|
241 |
authorize {
|
|
|
242 |
...
|
|
|
243 |
}
|
|
|
244 |
...
|
|
|
245 |
}
|
|
|
246 |
server server_two {
|
|
|
247 |
authorize {
|
|
|
248 |
...
|
|
|
249 |
}
|
|
|
250 |
...
|
|
|
251 |
}
|
|
|
252 |
|
|
|
253 |
In this case, the default server for the socket is "server_one", so
|
|
|
254 |
there is no need to set that in the client "one" configuration. The
|
|
|
255 |
"server_two" configuration for client "two" over-rides the default
|
|
|
256 |
setting for the socket.
|
|
|
257 |
|
|
|
258 |
Note that the following configuration will NOT work:
|
|
|
259 |
|
|
|
260 |
listen {
|
|
|
261 |
...
|
|
|
262 |
virtual_server = server_one
|
|
|
263 |
}
|
|
|
264 |
client one {
|
|
|
265 |
...
|
|
|
266 |
}
|
|
|
267 |
server server_one {
|
|
|
268 |
authorize {
|
|
|
269 |
...
|
|
|
270 |
}
|
|
|
271 |
...
|
|
|
272 |
}
|
|
|
273 |
server server_two {
|
|
|
274 |
client two {
|
|
|
275 |
...
|
|
|
276 |
}
|
|
|
277 |
authorize {
|
|
|
278 |
...
|
|
|
279 |
}
|
|
|
280 |
...
|
|
|
281 |
}
|
|
|
282 |
|
|
|
283 |
In this example, client "two" is hidden inside of the virtual
|
|
|
284 |
server, where the "listen" section cannot find it.
|
|
|
285 |
|
|
|
286 |
|
|
|
287 |
7. Outlined examples
|
|
|
288 |
|
|
|
289 |
This section outlines a number of examples, with alternatives.
|
|
|
290 |
|
|
|
291 |
One server, multiple sockets
|
|
|
292 |
- multiple "listen" sections in a "server" section
|
|
|
293 |
|
|
|
294 |
one server per client
|
|
|
295 |
- define multiple servers
|
|
|
296 |
- have a global "listen" section
|
|
|
297 |
- have multiple global "clients", each with "virtual_server = X"
|
|
|
298 |
|
|
|
299 |
two servers, each with their own sockets
|
|
|
300 |
- define multiple servers
|
|
|
301 |
- put "client" sections into each "server"
|
|
|
302 |
- put a "listen" section into each "server"
|
|
|
303 |
|
|
|
304 |
Each server can list the same client IP, and the secret
|
|
|
305 |
can be different
|
|
|
306 |
|
|
|
307 |
two sockets, sharing a list of clients, but pointing to different servers
|
|
|
308 |
- define global "listen" sections
|
|
|
309 |
- in each, set "virtual_server = X"
|
|
|
310 |
- in each, set "clients = Y"
|
|
|
311 |
- define "clients Y" section, containing multiple clients.
|
|
|
312 |
|
|
|
313 |
This also means that you can have a third socket, which
|
|
|
314 |
doesn't share any of these clients.
|
|
|
315 |
|
|
|
316 |
|
|
|
317 |
8. How to decide what to do
|
|
|
318 |
|
|
|
319 |
|
|
|
320 |
If you want *completely* separate policies for a socket or a client,
|
|
|
321 |
then create a separate virtual server. Then, map the request to that
|
|
|
322 |
server by setting configuration entries in a "listen" section or in a
|
|
|
323 |
"client" section.
|
|
|
324 |
|
|
|
325 |
Start off with the common cases first. If most of the clients
|
|
|
326 |
and/or sockets get a particular policy, make that policy the default.
|
|
|
327 |
Configure it without paying attention to the sockets or clients you
|
|
|
328 |
want to add later, and without adding a second virtual server. Once
|
|
|
329 |
it works, then add the second virtual server.
|
|
|
330 |
|
|
|
331 |
If you want to re-use the previously defined sockets with the second
|
|
|
332 |
virtual server, then you will need one or more global "client"
|
|
|
333 |
sections. Those clients will contain a "virtual_server = ..." entry
|
|
|
334 |
that will direct requests from those clients to the appropriate
|
|
|
335 |
virtual server.
|