| 1. Virtual Servers. |
| |
| FreeRADIUS 2.0 supports virtual servers. This is probably the |
| single largest change that is NOT backwards compatible with 1.x. |
| |
| The virtual servers do NOT have to be set up with the |
| "sites-available" and "sites-enabled" directories. You can still have |
| one "radiusd.conf" file, and put the server configuration there: |
| |
| ... |
| server { |
| authorize { |
| ... |
| } |
| authenticate { |
| ... |
| } |
| ... |
| } |
| ... |
| |
| The power of virtual servers lies in their ability to separate |
| policies. A policy can be placed into a virtual server, where it is |
| guaranteed to affect only the requests that are passed through that |
| virtual server. In 1.x, the policies were global, and it sometimes |
| took much effort to write a policy so that it only applied in certain |
| limited situations. |
| |
| |
| 2. What do we mean by "virtual server"? |
| |
| |
| A virtual server is a (nearly complete) RADIUS server, just like a |
| configuration for FreeRADIUS 1.x. However, FreeRADIUS can now run |
| multiple virtual servers at the same time. The virtual servers can |
| even proxy requests to each other! |
| |
| The simplest way to create a virtual server is to take the all of |
| the request processing sections from radius.conf, ("authorize" , |
| "authenticate", etc.) and wrap them in a "server {}" block, as above. |
| |
| You can create another virtual server by: |
| |
| 1) defining a new "server foo {...}" section in radiusd.conf |
| 2) Putting the normal "authorize", etc. sections inside of it |
| 3) Adding a "listen" section *inside* of the "server" section. |
| |
| e.g. |
| |
| ... |
| server foo { |
| listen { |
| ipaddr = 127.0.0.1 |
| port = 2000 |
| type = auth |
| } |
| |
| authorize { |
| update control { |
| Cleartext-Password := "bob" |
| } |
| pap |
| } |
| |
| authenticate { |
| pap |
| } |
| } |
| ... |
| |
| With that text added to "radiusd.conf", run the server in debugging |
| mode (radiusd -X), and in another terminal window, type: |
| |
| $ radtest bob bob localhost:2000 0 testing123 |
| |
| You should see the server return an Access-Accept. |
| |
| |
| 3. Capabilities and limitations |
| |
| |
| The only sub-sections that can appear in a virtual server section |
| are: |
| |
| listen |
| client |
| authorize |
| authenticate |
| post-auth |
| pre-proxy |
| post-proxy |
| preacct |
| accounting |
| session |
| |
| All other configuration parameters (modules, etc.) are global. |
| |
| Inside of a virtual server, the authorize, etc. sections have their |
| normal meaning, and can contain anything that an authorize section |
| could contain in 1.x. |
| |
| When a "listen" section is inside of a virtual server definition, it |
| means that all requests sent to that IP/port will be processed through |
| the virtual server. There cannot be two "listen" sections with the |
| same IP address and port number. |
| |
| When a "client" section is inside of a virtual server definition, it |
| means that that client is known only to the "listen" sections that are |
| also inside of that virtual server. Not only is this client |
| definition available only to this virtual server, but the details of |
| the client configuration is also available only to this virtual |
| server. |
| |
| i.e. Two virtual servers can listen on different IP address and |
| ports, but both can have a client with IP address 127.0.0.1. The |
| shared secret for that client can be different for each virtual |
| server. |
| |
| |
| 4. More complex "listen" capabilities |
| |
| The "listen" sections have a few additional configuration items that |
| were not in 1.x, and were not mentioned above. These configuration |
| items enable almost any mapping of IP / port to clients to virtual |
| servers. |
| |
| The configuration items are: |
| |
| virtual_server = <name> |
| |
| If set, all requests sent to this IP / port are processed |
| through the named virtual server. |
| |
| This directive can be used only for "listen" sections |
| that are global. i.e. It CANNOT be used if the |
| "listen" section is inside of a virtual server. |
| |
| clients = <name> |
| |
| If set, the "listen" section looks for a "clients" section: |
| |
| clients <name> { |
| ... |
| } |
| |
| It looks inside of that named "clients" section for |
| "client" subsections, at least one of which must |
| exist. Each client in that section is added to the |
| list of known clients for this IP / port. No other |
| clients are known. |
| |
| If it is set, it over-rides the list of clients (if |
| any) in the same virtual server. Note that the |
| clients are NOT additive! |
| |
| If it is not set, then the clients from the current |
| virtual server (if any) are used. If there are no |
| clients in this virtual server, then the global |
| clients are used. |
| |
| i.e. The most specific directive is used: |
| * configuration in this "listen" section |
| * clients in the same virtual server |
| * global clients |
| |
| The directives are also *exclusive*, not *additive*. |
| If you have one client in a virtual server, and |
| another client referenced from a "listen" section, |
| then that "listen" section will ONLY use the second |
| client. It will NOT use both clients. |
| |
| |
| 5. More complex "client" capabilities |
| |
| The "client" sections have a few additional configuration items that |
| were not in 1.x, and were not mentioned above. These configuration |
| items enable almost any mapping of IP / port to clients to virtual |
| servers. |
| |
| The configuration items are: |
| |
| virtual_server = <name> |
| |
| If set, all requests from this client are processed |
| through the named virtual server. |
| |
| This directive can be used only for "client" sections |
| that are global. i.e. It CANNOT be used if the |
| "client" section is inside of a virtual server. |
| |
| If the "listen" section has a "server" entry, and a matching |
| client is found ALSO with a "server" entry, then the clients server is |
| used for that request. |
| |
| |
| 6. Worked examples |
| |
| |
| Listening on one socket, and mapping requests from two clients to |
| two different servers. |
| |
| listen { |
| ... |
| } |
| client one { |
| ... |
| virtual_server = server_one |
| } |
| client two { |
| ... |
| virtual_server = server_two |
| } |
| server server_one { |
| authorize { |
| ... |
| } |
| ... |
| } |
| server server_two { |
| authorize { |
| ... |
| } |
| ... |
| } |
| |
| This could also be done as: |
| |
| |
| listen { |
| ... |
| virtual_server = server_one |
| } |
| client one { |
| ... |
| } |
| client two { |
| ... |
| virtual_server = server_two |
| } |
| server server_one { |
| authorize { |
| ... |
| } |
| ... |
| } |
| server server_two { |
| authorize { |
| ... |
| } |
| ... |
| } |
| |
| In this case, the default server for the socket is "server_one", so |
| there is no need to set that in the client "one" configuration. The |
| "server_two" configuration for client "two" over-rides the default |
| setting for the socket. |
| |
| Note that the following configuration will NOT work: |
| |
| listen { |
| ... |
| virtual_server = server_one |
| } |
| client one { |
| ... |
| } |
| server server_one { |
| authorize { |
| ... |
| } |
| ... |
| } |
| server server_two { |
| client two { |
| ... |
| } |
| authorize { |
| ... |
| } |
| ... |
| } |
| |
| In this example, client "two" is hidden inside of the virtual |
| server, where the "listen" section cannot find it. |
| |
| |
| 7. Outlined examples |
| |
| This section outlines a number of examples, with alternatives. |
| |
| One server, multiple sockets |
| - multiple "listen" sections in a "server" section |
| |
| one server per client |
| - define multiple servers |
| - have a global "listen" section |
| - have multiple global "clients", each with "virtual_server = X" |
| |
| two servers, each with their own sockets |
| - define multiple servers |
| - put "client" sections into each "server" |
| - put a "listen" section into each "server" |
| |
| Each server can list the same client IP, and the secret |
| can be different |
| |
| two sockets, sharing a list of clients, but pointing to different servers |
| - define global "listen" sections |
| - in each, set "virtual_server = X" |
| - in each, set "clients = Y" |
| - define "clients Y" section, containing multiple clients. |
| |
| This also means that you can have a third socket, which |
| doesn't share any of these clients. |
| |
| |
| 8. How to decide what to do |
| |
| |
| If you want *completely* separate policies for a socket or a client, |
| then create a separate virtual server. Then, map the request to that |
| server by setting configuration entries in a "listen" section or in a |
| "client" section. |
| |
| Start off with the common cases first. If most of the clients |
| and/or sockets get a particular policy, make that policy the default. |
| Configure it without paying attention to the sockets or clients you |
| want to add later, and without adding a second virtual server. Once |
| it works, then add the second virtual server. |
| |
| If you want to re-use the previously defined sockets with the second |
| virtual server, then you will need one or more global "client" |
| sections. Those clients will contain a "virtual_server = ..." entry |
| that will direct requests from those clients to the appropriate |
| virtual server. |