Hi, just switching from a 1.1.7 with an incredibly sophisticated policy engine to a virtual-server based, simple 2.0 setup here. From what I see so far, virtual servers really rock. There's just one use case not entirely clear to me: I receive requests from a proxy who in turn has multiple clients behind. I want to decide stuff based on who *that other server's* clients are. It works today by tagging packets on that proxy with a VSA, upon which the home server decides the applicable policy. If I want to get that done with 2.0, I'm unsure how to proceed. If I get a tagged packet from the proxy and assign this proxy's IP address to a virtual server, I could process its VSAs in that server. But then I would ideally like to re-distribute the packets after that to their own virtual servers. Kind of like: in authorize, find out about the VSA, then set a magic variable "Handoff-to-Virtual-Server := someserver", and then the packet gets handed to that other virtual server automatically. Does that make any sense? How do I do that? Greetings, Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Stefan Winter wrote:
If I want to get that done with 2.0, I'm unsure how to proceed.
You should be able to do it exactly as in 1.1.x. However, you likely want to do it via a *simpler* method.
If I get a tagged packet from the proxy and assign this proxy's IP address to a virtual server, I could process its VSAs in that server. But then I would ideally like to re-distribute the packets after that to their own virtual servers. Kind of like: in authorize, find out about the VSA, then set a magic variable "Handoff-to-Virtual-Server := someserver", and then the packet gets handed to that other virtual server automatically.
Does that make any sense? How do I do that?
It makes sense. It may even be relatively easy to do. I would want the syntax to be part of the configuration and not in RADIUS attributes, though. e.g. if (blah) { server = foo # may not return } That's a little awkward, though. Doing something like this would be a lot easier, even if the syntax is a little more awkward: if (blah) { server[foo] } That way, the reference to server "foo" follows the existing configuration de-reference model. (Which isn't really documented...) Hmm... if that kind of syntax seems OK, then it looks to be actually very small amounts of code. Even adding the ability to do: if (blah) { server[%{Attr-Foo}] } would be relatively easy. That would let you do run-time selection of virtual servers. Does this sound reasonable? Alan DeKok.
Hi,
Hmm... if that kind of syntax seems OK, then it looks to be actually very small amounts of code. Even adding the ability to do:
if (blah) { server[%{Attr-Foo}] }
would be relatively easy. That would let you do run-time selection of virtual servers.
Does this sound reasonable?
Wow. That's even more than what I'd hoped for. Because by coincidence, my virtual Servers carry the name of the service being referenced in the attribute... This would make my stuff *incredibly* easy. Needless to say: I'm fine with the syntax. :-) Just curious: where would the stanza go? authorize { } of default server? Greetings, Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
participants (2)
-
Alan DeKok -
Stefan Winter