X-Git-Url: http://www.project-moonshot.org/gitweb/?a=blobdiff_plain;f=raddb%2Fproxy.conf;h=611287d94f467a42031f87165574330e7601e154;hb=HEAD;hp=1006821d664d14fe5c4fa2788b3bdea8e701e145;hpb=7ef66b7c2532381031dcc7036100beb5e9534d4d;p=freeradius.git diff --git a/raddb/proxy.conf b/raddb/proxy.conf index 1006821..611287d 100644 --- a/raddb/proxy.conf +++ b/raddb/proxy.conf @@ -1,9 +1,9 @@ -# -# proxy.conf - proxy radius and realm configuration directives -# -# This file is included by default. To disable it, you will need -# to modify the PROXY CONFIGURATION section of "radiusd.conf". -# +# -*- text -*- +## +## proxy.conf -- proxy radius and realm configuration directives +## +## $Id$ + ####################################################################### # # Proxy server configuration @@ -32,6 +32,13 @@ proxy server { # In 2.0, the server is always "synchronous", and setting # "synchronous = no" is impossible. This simplifies the # server and increases the stability of the network. + # However, it means that the server (i.e. proxy) NEVER + # originates packets. It proxies packets ONLY when it receives + # a packet or a re-transmission from the NAS. If the NAS never + # re-transmits, the proxy never re-transmits, either. This can + # affect fail-over, where a packet does *not* fail over to a + # second home server.. because the NAS never retransmits the + # packet. # # If you need to set "synchronous = no", please send a # message to the list @@ -80,7 +87,7 @@ proxy server { # # # Load-balancing and failover between home servers is handled via -# a "server_pool" section. +# a "home_server_pool" section. # # Finally, The "realm" section defines the realm, some options, and # indicates which server pool should be used for the realm. @@ -110,12 +117,16 @@ home_server localhost { # or Accounting-Request packets. # # Allowed values are: - # auth - send Access-Request packets - # acct - send Accounting-Request packets + # auth - Handles Access-Request packets + # acct - Handles Accounting-Request packets + # auth+acct - Handles Access-Request packets at "port", + # and Accounting-Request packets at "port + 1" + # coa - Handles CoA-Request and Disconnect-Request packets. + # See also raddb/sites-available/originate-coa type = auth # - # Configure ONE OF the following three entries: + # Configure ONE OF the following entries: # # IPv4 address # @@ -124,26 +135,59 @@ home_server localhost { # OR IPv6 address # ipv6addr = ::1 - # OR hostname, which will do address detection automatically + # OR virtual server + # virtual_server = foo + + # Note that while both ipaddr and ipv6addr will accept + # both addresses and host names, we do NOT recommend + # using host names. When you specify a host name, the + # server has to do a DNS lookup to find the IP address + # of the home server. If the DNS server is slow or + # unresponsive, it means that FreeRADIUS will NOT be + # able to determine the address, and will therefore NOT + # start. + # + # Also, the mapping of host name to address is done ONCE + # when the server starts. If DNS is later updated to + # change the address, FreeRADIUS will NOT discover that + # until after a re-start, or a HUP. + # + # If you specify a virtual_server here, then requests + # will be proxied internally to that virtual server. + # These requests CANNOT be proxied again, however. The + # intent is to have the local server handle packets + # when all home servers are dead. # - # Note that we do NOT recommend using hostnames, because - # it means that the server has to do a DNS lookup to - # determine the IP address of the home server. If the - # DNS server is slow or unresponsible, it means that - # FreeRADIUS will NOT be able to determine the IP - # address, and will therefore NOT start. + # Requests proxied to a virtual server will be passed + # through the pre-proxy and post-proxy sections, just + # like any other request. See also the sample "realm" + # configuration, below. # - # hostname = localhost + # None of the rest of the home_server configuration is used + # for the "virtual_server" configuration. # # The port to which packets are sent. # # Usually 1812 for type "auth", and 1813 for type "acct". # Older servers may use 1645 and 1646. + # Use 3799 for type "coa" # port = 1812 # + # The transport protocol. + # + # If unspecified, defaults to "udp", which is the traditional + # RADIUS transport. It may also be "tcp", in which case TCP + # will be used to talk to this home server. + # + # When home servers are put into pools, the pool can contain + # home servers with both UDP and TCP transports. + # + #proto = udp + + # # The shared secret use to "encrypt" and "sign" packets between # FreeRADIUS and the home server. # @@ -168,18 +212,76 @@ home_server localhost { ############################################################ # - # If the home server doesn't respond to the request within - # this time, this server will consider the request dead, and - # respond to the NAS with an Access-Reject. + # You can optionally specify the source IP address used when + # proxying requests to this home server. When the src_ipaddr + # it set, the server will automatically create a proxy + # listener for that IP address. + # + # If you specify this field for one home server, you will + # likely need to specify it for ALL home servers. + # + # If you don't care about the source IP address, leave this + # entry commented. + # +# src_ipaddr = 127.0.0.1 + + # RFC 5080 suggests that all clients SHOULD include it in an + # Access-Request. The configuration item below tells the + # proxying server (i.e. this one) whether or not the home + # server requires a Message-Authenticator attribute. If it + # is required (value set to "yes"), then all Access-Request + # packets sent to that home server will have a + # Message-Authenticator attribute. + # + # We STRONGLY recommend that this flag be set to "yes" + # for ALL home servers. Doing so will have no performance + # impact on the proxy or on the home servers. It will, + # however, allow administrators to detect problems earlier. + # + # allowed values: yes, no + require_message_authenticator = yes + + # + # If the home server does not respond to a request within + # this time, this server will initiate "zombie_period". + # + # The response window is large because responses MAY be slow, + # especially when proxying across the Internet. # # Useful range of values: 5 to 60 response_window = 20 # - # If the home server does not respond to ANY packets for - # a certain time, consider it dead. This time period is - # called the "zombie" period, because the server is neither - # alive nor dead. + # If you want the old behavior of the server rejecting + # proxied requests after "response_window" timeout, set + # the following configuration item to "yes". + # + # This configuration WILL be removed in a future release + # If you believe you need it, email the freeradius-users + # list, and explain why it should stay in the server. + # +# no_response_fail = no + + # + # If the home server does not respond to ANY packets during + # the "zombie period", it will be considered to be dead. + # + # A home server that is marked "zombie" will be used for + # proxying as a low priority. If there are live servers, + # they will always be preferred to a zombie. Requests will + # be proxied to a zombie server ONLY when there are no + # live servers. + # + # Any request that is proxied to a home server will continue + # to be sent to that home server until the home server is + # marked dead. At that point, it will fail over to another + # server, if a live server is available. If none is available, + # then the "post-proxy-type fail" handler will be called. + # + # If "status_check" below is something other than "none", then + # the server will start sending status checks at the start of + # the zombie period. It will continue sending status checks + # until the home server is marked "alive". # # Useful range of values: 20 to 120 zombie_period = 40 @@ -229,9 +331,9 @@ home_server localhost { # As a result, we recommend enabling status checks, and # we do NOT recommend using "revive_interval". # - # If the "status_check" entry below is not "none", then the - # "revive_interval" entry can be deleted, as it will not be - # used. + # The "revive_interval" is used ONLY if the "status_check" + # entry below is "none". Otherwise, it will not be used, + # and should be deleted. # # Useful range of values: 60 to 3600 revive_interval = 120 @@ -300,8 +402,93 @@ home_server localhost { # # Useful range of values: 3 to 10 num_answers_to_alive = 3 + + # + # The configuration items in the next sub-section are used ONLY + # when "type = coa". It is ignored for all other type of home + # servers. + # + # See RFC 5080 for the definitions of the following terms. + # RAND is a function (internal to FreeRADIUS) returning + # random numbers between -0.1 and +0.1 + # + # First Re-transmit occurs after: + # + # RT = IRT + RAND*IRT + # + # Subsequent Re-transmits occur after: + # + # RT = 2 * RTprev + RAND * RTprev + # + # Re-trasnmits are capped at: + # + # if (MRT && (RT > MRT)) RT = MRT + RAND * MRT + # + # For a maximum number of attempts: MRC + # + # For a maximum (total) period of time: MRD. + # + coa { + # Initial retransmit interval: 1..5 + irt = 2 + + # Maximum Retransmit Timeout: 1..30 (0 == no maximum) + mrt = 16 + + # Maximum Retransmit Count: 1..20 (0 == retransmit forever) + mrc = 5 + + # Maximum Retransmit Duration: 5..60 + mrd = 30 + } + + # + # Connection limiting for home servers with "proto = tcp". + # + # This section is ignored for other home servers. + # + limit { + # + # Limit the number of TCP connections to the home server. + # + # The default is 16. + # Setting this to 0 means "no limit" + max_connections = 16 + + # + # Limit the total number of requests sent over one + # TCP connection. After this number of requests, the + # connection will be closed. Any new packets that are + # proxied to the home server will result in a new TCP + # connection being made. + # + # Setting this to 0 means "no limit" + max_requests = 0 + + # + # The lifetime, in seconds, of a TCP connection. After + # this lifetime, the connection will be closed. + # + # Setting this to 0 means "forever". + lifetime = 0 + + # + # The idle timeout, in seconds, of a TCP connection. + # If no packets have been sent over the connection for + # this time, the connection will be closed. + # + # Setting this to 0 means "no timeout". + idle_timeout = 0 + } + } +# Sample virtual home server. +# +# +#home_server virtual.example.com { +# virtual_server = virtual.example.com +#} ###################################################################### # @@ -312,27 +499,102 @@ home_server localhost { # the same 10 realms, you would need 50 "realm" entries. # # In version 2.0, you would need 5 "home_server" sections, -# 10 'realm" sections, and one "server_pool" section to tie the +# 10 'realm" sections, and one "home_server_pool" section to tie the # two together. # -server_pool my_auth_failover { +home_server_pool my_auth_failover { + # + # The type of this pool controls how home servers are chosen. + # + # fail-over - the request is sent to the first live + # home server in the list. i.e. If the first home server + # is marked "dead", the second one is chosen, etc. + # + # load-balance - the least busy home server is chosen, + # where "least busy" is counted by taking the number of + # requests sent to that home server, and subtracting the + # number of responses received from that home server. + # + # If there are two or more servers with the same low + # load, then one of those servers is chosen at random. + # This configuration is most similar to the old + # "round-robin" method, though it is not exactly the same. + # + # Note that load balancing does not work well with EAP, + # as EAP requires packets for an EAP conversation to be + # sent to the same home server. The load balancing method + # does not keep state in between packets, meaning that + # EAP packets for the same conversation may be sent to + # different home servers. This will prevent EAP from + # working. + # + # For non-EAP authentication methods, and for accounting + # packets, we recommend using "load-balance". It will + # ensure the highest availability for your network. + # + # client-balance - the home server is chosen by hashing the + # source IP address of the packet. If that home server + # is down, the next one in the list is used, just as + # with "fail-over". + # + # There is no way of predicting which source IP will map + # to which home server. + # + # This configuration is most useful to do simple load + # balancing for EAP sessions, as the EAP session will + # always be sent to the same home server. + # + # client-port-balance - the home server is chosen by hashing + # the source IP address and source port of the packet. + # If that home server is down, the next one in the list + # is used, just as with "fail-over". + # + # This method provides slightly better load balancing + # for EAP sessions than "client-balance". However, it + # also means that authentication and accounting packets + # for the same session MAY go to different home servers. + # + # keyed-balance - the home server is chosen by hashing (FNV) + # the contents of the Load-Balance-Key attribute from the + # control items. The request is then sent to home server + # chosen by taking: # - # The type of this pool is either "fail-over" or "load-balance". + # server = (hash % num_servers_in_pool). # - # With "fail-over", the request is sent to the first live - # home server in the list. + # If there is no Load-Balance-Key in the control items, + # the load balancing method is identical to "load-balance". # - # With "load-balance", the request is load-balanced (randomly) - # between the live home servers. This is equivalent to the - # old per-realm configuration "round_robin". + # For most non-EAP authentication methods, The User-Name + # attribute provides a good key. An "unlang" policy can + # be used to copy the User-Name to the Load-Balance-Key + # attribute. This method may not work for EAP sessions, + # as the User-Name outside of the TLS tunnel is often + # static, e.g. "anonymous@realm". # + # + # The default type is fail-over. type = fail-over # + # A virtual_server may be specified here. If so, the + # "pre-proxy" and "post-proxy" sections are called when + # the request is proxied, and when a response is received. + # + # This lets you have one policy for all requests that are proxied + # to a home server. This policy is completely independent of + # any policies used to receive, or process the request. + # + #virtual_server = pre_post_proxy_for_pool + + # # Next, a list of one or more home servers. The names # of the home servers are NOT the hostnames, but the names # of the sections. (e.g. home_server foo {...} has name "foo". # + # Note that ALL home servers listed here have to be of the same + # type. i.e. they all have to be "auth", or they all have to + # be "acct", or the all have to be "auth+acct". + # home_server = localhost # Additional home servers can be listed. @@ -344,6 +606,17 @@ server_pool my_auth_failover { # home_server = bar.example.com # home_server = baz.example.com # home_server = ... + + + # + # If ALL home servers are dead, then this "fallback" home server + # is used. If set, it takes precedence over any realm-based + # fallback, such as the DEFAULT realm. + # + # For reasons of stability, this home server SHOULD be a virtual + # server. Otherwise, the fallback may itself be dead! + # + #fallback = virtual.example.com } ###################################################################### @@ -362,6 +635,24 @@ server_pool my_auth_failover { # # realm example.com { + # + # Realms point to pools of home servers. +# + # For authentication, the "auth_pool" configuration item + # should point to a "home_server_pool" that was previously + # defined. All of the home servers in the "auth_pool" must + # be of type "auth". + # + # For accounting, the "acct_pool" configuration item + # should point to a "home_server_pool" that was previously + # defined. All of the home servers in the "acct_pool" must + # be of type "acct". + # + # If you have a "home_server_pool" where all of the home servers + # are of type "auth+acct", you can just use the "pool" + # configuration item, instead of specifying both "auth_pool" + # and "acct_pool". + auth_pool = my_auth_failover # acct_pool = acct @@ -420,7 +711,6 @@ realm LOCAL { # prefix or suffix. User names like "bob" will match this one. # #realm NULL { -# type = radius # authhost = radius.company.com:1600 # accthost = radius.company.com:1601 # secret = testing123 @@ -430,9 +720,80 @@ realm LOCAL { # This realm is for ALL OTHER requests. # #realm DEFAULT { -# type = radius # authhost = radius.company.com:1600 # accthost = radius.company.com:1601 # secret = testing123 #} + +# This realm "proxies" requests internally to a virtual server. +# The pre-proxy and post-proxy sections are run just as with any +# other kind of home server. The virtual server then receives +# the request, and replies, just as with any other packet. +# +# Once proxied internally like this, the request CANNOT be proxied +# internally or externally. +# +#realm virtual.example.com { +# virtual_server = virtual.example.com +#} +# + +# +# Regular expressions may also be used as realm names. If these are used, +# then the "find matching realm" process is as follows: +# +# 1) Look for a non-regex realm with an *exact* match for the name. +# If found, it is used in preference to any regex matching realm. +# +# 2) Look for a regex realm, in the order that they are listed +# in the configuration files. Any regex match is performed in +# a case-insensitive fashion. +# +# 3) If no realm is found, return the DEFAULT realm, if any. +# +# The order of the realms matters in step (2). For example, defining +# two realms ".*\.example.net$" and ".*\.test\.example\.net$" will result in +# the second realm NEVER matching. This is because all of the realms +# which match the second regex also match the first one. Since the +# first regex matches, it is returned. +# +# The solution is to list the realms in the opposite order,. e.g. +# ".*\.test\.example.net$", followed by ".*\.example\.net$". +# +# +# Some helpful rules: +# +# - always place a '~' character at the start of the realm name. +# This signifies that it is a regex match, and not an exact match +# for the realm. +# +# - place the regex in double quotes. This helps the configuration +# file parser ignore any "special" characters in the regex. +# Yes, this rule is different than the normal "unlang" rules for +# regular expressions. That may be fixed in a future release. +# +# - use two back-slashes '\\' whenever you need one backslash in the +# regex. e.g. "~.*\\.example\\.net$", and not "~\.example\.net$". +# This is because the regex is in a double-quoted string, and normal +# rules apply for double-quoted strings. +# +# - If you are matching domain names, use two backslashes in front of +# every '.' (dot or period). This is because '.' has special meaning +# in a regular expression: match any character. If you do not do this, +# then "~.*.example.net$" will match "fooXexampleYnet", which is likely +# not what you want +# +# - If you are matching domain names, put a '$' at the end of the regex +# that matches the domain name. This tells the regex matching code +# that the realm ENDS with the domain name, so it does not match +# realms with the domain name in the middle. e.g. "~.*\\.example\\.net" +# will match "test.example.netFOO", which is likely not what you want. +# Using "~.*\\.example\\.net$" is better. +# +# The more regex realms that are defined, the more time it takes to +# process them. You should define as few regex realms as possible +# in order to maximize server performance. +# +#realm "~.*\\.example\\.net$" { +#}