Setting up a virtual server to handle incoming proxied requests
Hi again all :) I have a primary and secondary server, each of which receive accounting requests from multiple NAS servers. Both my servers proxy these requests to each other to stay in sync. I would like to setup a virtual server on my secondary to handle the incoming proxy requests from the primary. My secondary is running freeradius 2.1.3 I have read the sites-available/README documentation and have a few questions. First I include my current configuration for your consideration. radiusd.conf ------------ listen { ipaddr = * port = 0 # Use /etc/services for ports type = auth } listen { ipaddr = * port = 0 # Use /etc/services for ports type = acct } proxy_requests = yes $INCLUDE proxy.conf ... clients.conf ------------ Nothing proxy.conf ---------- home_server copy-acct-to-home-server { type = acct ipaddr = primary_server_ip port = 1813 secret = shared_key response_window = 20 zombie_period = 40 revive_interval = 120 } home_server_pool my_acct_failover { home_server = copy-acct-to-home-server } realm DEFAULT { acct_pool = my_acct_failover nostrip } Currently my clients reside in the nas table in my database. With the above config I have listen sections for auth and acct. Do I understand the documentation correctly if I add this to the above existing config: client primary_server { ipaddr = primary_server_ip secret = shared_secret require_message_authenticator = no nastype = other virtual_server = requests_from_primary } server requests_from_primary { listen { ipaddr = * port = 0 type = acct } proxy_requests = no # Can this be done here? If not how would I disable proxying for this virtual server? # Do I just exclude my detail-radrelay in the accounting section? # Since this is just processing accounting requests do I still need to define the authorize, authenticate & other sections? preacct { preprocess acct_unique } accounting { detail sql # detail-radrelay - Exclude this so that these requests are not proxied? } } I *think* Im on the right track but would appreciate any pointers :) Many thanks Patric
With the above config I have listen sections for auth and acct. Do I understand the documentation correctly if I add this to the above existing config:
client primary_server { ipaddr = primary_server_ip secret = shared_secret require_message_authenticator = no nastype = other virtual_server = requests_from_primary }
OK.
server requests_from_primary { listen { ipaddr = * port = 0 type = acct }
proxy_requests = no # Can this be done here?
No.
# Do I just exclude my detail-radrelay in the accounting section?
Yes.
# Since this is just processing accounting requests do I still need to define the authorize, authenticate & other sections?
No. It will just be getting accounting requests. Ivan Kalik Kalik Informatika ISP
Ivan Kalik wrote:
With the above config I have listen sections for auth and acct. Do I understand the documentation correctly if I add this to the above existing config:
client primary_server { ipaddr = primary_server_ip secret = shared_secret require_message_authenticator = no nastype = other virtual_server = requests_from_primary }
OK.
Thanks for your response Ivan & Alan, Im finally starting to understand how they fit together :) I started implementing this but ran into a snag Im not sure which is the correct way to get around. As I mentioned all my clients reside in the nas table of my database, and my sql.conf has readclients = yes to load them from there. When I attempt to define the above client so that I can set the virtual_server parameter, I get the following error (obviously...) rlm_sql (sql): Adding client primary_server_ip (Primary, server=<none>) to clients list Failed to add duplicate client Primary rlm_sql (sql): Failed to add client primary_server_ip (Primary) to clients list. Maybe there's a duplicate? Failed to load clients from SQL. To resolve this should I now remove the primary server from my nas table as I am defining it in the clients.conf ? Or is there a way to leave it in the nas table and assign a virtual_server directive to it? Thanks for the time and patience Patric
To resolve this should I now remove the primary server from my nas table as I am defining it in the clients.conf ?
Yes, pick one.
Or is there a way to leave it in the nas table and assign a virtual_server directive to it?
Yes. In 2.1.7 schema supports virtual servers but that line is commented out in nas.sql by default. You can add (and use) the server column. Ivan Kalik Kalik Informatika ISP
Ivan Kalik wrote:
To resolve this should I now remove the primary server from my nas table as I am defining it in the clients.conf ?
Yes, pick one.
Or is there a way to leave it in the nas table and assign a virtual_server directive to it?
Yes. In 2.1.7 schema supports virtual servers but that line is commented out in nas.sql by default. You can add (and use) the server column.
Thanks so much for your help Ivan & Alan, I believe I have it running correctly now :D According to the debug info when I get an accounting request from my primary it adds it to the detail file, runs the sql update and returns a response - 100% what I was trying to achieve! Have a great weekend! Patric
Patric wrote:
server requests_from_primary { listen { ipaddr = * port = 0 type = acct }
Delete that listen section. It conflicts with the global one. The global one will accept packets on the accounting port, IP *, and will look up the client. If the client is the primary, it will run the "requests_from_primary" virtual server. You do NOT need to put another "listen" section in the virtual server.
proxy_requests = no # Can this be done here? If not how would I disable proxying for this virtual server?
You don't "disable" proxying. You just configure it so that it doesn't proxy.
# Do I just exclude my detail-radrelay in the accounting section?
Yes.
# Since this is just processing accounting requests do I still need to define the authorize, authenticate & other sections?
No. Alan DeKok.
Alan DeKok wrote:
Patric wrote:
server requests_from_primary { listen { ipaddr = * port = 0 type = acct }
Delete that listen section. It conflicts with the global one.
The global one will accept packets on the accounting port, IP *, and will look up the client. If the client is the primary, it will run the "requests_from_primary" virtual server.
I see I see, so I would only add a listen section if I were listening on a different interface or port?
proxy_requests = no # Can this be done here? If not how would I disable proxying for this virtual server?
You don't "disable" proxying. You just configure it so that it doesn't proxy.
I think I get the proxying now :) proxy_requests = yes just makes the server process the detail-combined log right? So by not writing to the detail-combined you are effectively disabling proxying to a specified client. Thanks guys!
Patric wrote:
I see I see, so I would only add a listen section if I were listening on a different interface or port?
Yes.
I think I get the proxying now :) proxy_requests = yes just makes the server process the detail-combined log right?
No. The listen section that references it tells the server to process it. The detail module that references it tells the server to write the data which will be processed later by the listen section.
So by not writing to the detail-combined you are effectively disabling proxying to a specified client.
No. By not setting Proxy-To-Ream in the virtual server, you are telling it to not proxy the requests. Alan DeKok.
Alan DeKok wrote:
Patric wrote:
I see I see, so I would only add a listen section if I were listening on a different interface or port?
Yes.
I think I get the proxying now :) proxy_requests = yes just makes the server process the detail-combined log right?
No. The listen section that references it tells the server to process it. The detail module that references it tells the server to write the data which will be processed later by the listen section.
So by not writing to the detail-combined you are effectively disabling proxying to a specified client.
No. By not setting Proxy-To-Ream in the virtual server, you are telling it to not proxy the requests.
Ah ok, thanks for the clarification :)
participants (3)
-
Alan DeKok -
Ivan Kalik -
Patric