Proxy servers are used to forward packets to other servers. Routing is usually performed by the realm portion of the User-Name attribute. Other attributes may be used like Called-Station-Id.
Realms are used in routing. They look like email addresses with the '@' separating the login name from the realm like michael@company.com. The realm is not a domain name but an arbitrary string. RADIUS servers do not use the domain name system (DNS) to route packets. Routing is fixed using a table of IP addresses and realm names. A User-Name could also be michael@company.
If the realm portion is missing or matches the name of the local server the packet is handled locally. Chains of these forwarding servers may be used.
The final authenticating or accounting server is sometimes called the terminal RADIUS server. The Proxy-State attribute is added to request packets and used to track the return path of the response.
RADIUS servers commonly handle authentication and accounting locally but
there are cases where a server may simple forward packets to another server
for processing. This is commonly done when a local RADIUS server is used to
handle a
number of different internet service providers (ISP) at a local dial up center.
Many ISPs will offer a presence in a city although their authentication and
accounting services are handled elsewhere. The local RADIUS server will forward
(act as a proxy server) to the final (terminal) server. The packets may pass
through a number of these forwarding servers on their way to the final RADIUS
server.
The most common mechanism for forwarding is the use of a 'realm' attached to the User-Name attributes. This looks something like an email address 'mjl@systemx.com'. The format is name @ realm. The name is the User-Name separated from the realm by the '@'. The realm is not a domain name although it can look appear that way. RADIUS servers map the realm to an IP address in their configuration files. There is no direct link between the realm and the DNS (domain name system). A realm could be a simple name like 'newyork' or 'newyork.ny'. It is not a domain name. There are other routing characters used but they are not standard and must be interpreted by your code.
Other attributes may be used to route packets. For example Calling-Station-Id or Called-Station-Id may be used. In this case some translation must be made within the server to route the packet.
There are three ways to handle packet forwarding. The easiest is to add 'synonyms' to a ProxyTarget class. All realms matching the ProxyTarget's name or any of it's synonyms will be forwarded to that server.
// Set up a proxy target called 'companyx.com' which also handles // companya.com and companyb.com automatically.
ProxyTarget pt = new ProxyTarget("companyx.com", 192.168,1,100, ...); String realmList[] = { "companya.com", "companyb.com" }; pt.setSynonyms(realmList);
This code will cause User-Name's with the realm @companyx.com, @compnaya.com, and @companyb.com to be forwarded to the server called companyx.com.
A special entry, the empty string, can be included in a ProxyTarget's synonym
list. This will cause that ProxyTarget server to be the default server for
User-Name attributes that have no realms. The ProxyTarget used to configure
the local server (RADIUSServer.setServerInfo(ProxyTarget pt) can
also use a synonym list to handle realms locally. It does not require the empty
synonym to handle it's own or the empty realm automatically.
No check is made to determine overlap of synonyms handled by different ProxyTargets.
There is also a ProxyImpl class that allows
you to customize forwarding based on any information, either internally from
the attributes or from external information. The ProxyImpl
class can also be used to handle methods other than realm routing. It can also
handle dynamic routing based on load balancing and fail over. Your ProxyImpl
code can route the packet to another server by modifying attributes or by forcing
a route. It can also arrange to locally or handle the packet. Special conditions
may warrant the use of the ProxyClient class described below. Several examples
are found in the com/theorem/radserver3/examples/server directory.
Look for files called Proxy*.java.
The third method is to use the ProxyClient class.
This is a special method to be used only in circumstances where the previous
two methods cannot work. It must not be used for general proxying as there
are some penalties and limitations on it's effectiveness.
The ProxyClient can send a packet to any server and even multiple servers.
It acts like a cross between a RADIUSClient and a forwarding server. It can
be used by a ProxyImpl class to perform fail over processing. It can be used
by an AccountingImpl class to provide redundant accounting to other servers.
An example of usage is found in Proxy.java.
While very flexible the ProxyClient class blocks the current session while
running and consumes another session for
itself. This means two RADIUS sessions are consumed for the duration of the
round trip or time out.