Chetan Gaonker | 7f4bf74 | 2016-05-04 15:56:08 -0700 | [diff] [blame] | 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. |