Subversion Repositories configs

Rev

Details | Last modification | View Log | RSS feed

Rev Author Line No. Line
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.