7:49 a.m.
Hi Paul,
On 23.03.21, 13:04, "Paul Dekkers" <paul.dekkers(a)surf.nl> wrote:
radsecproxy will start to send the request to fallback.server.here
because the dynamic part didn't resolve yet: it's not blocking. Only as
soon as the config for the dynamic realm is in place, when the
dynamicLookupCommand had a result, it will continue with that host.
Just reading from the code:
The first request for a new realm will trigger the dynamic process. Essentially, a copy of
the realm structure is created (for the actual realm to look up), including a copy of the
dynamic server spec, but now including the realm to look up. This first request is
implicitly placed in the queue for the dynamic server (before the lookupCommand has even
been called).
Now the server processes are started, which first calls the dynamicLookupCommand. During
this time, the server is in 'startup' state, in which it will not be considered a
valid server and will not get any more requests queued.
If any more requests arrive for this realm, they will get sent to the other servers
configured for the realm (if any). This is so that if the first request is retransmitted,
as it took too long to resolve and connect to the dynamic server, it will fall back to the
others. The clients timeout acting as an implicit timeout for the dynamic lookup (really,
if it the lookup takes longer than the clients timeout we shouldn’t wait for it any
longer)
This results in part of the conversation going via one path, part of it
via another. This breaks "the first" authentication for a realm.
Of course there is the race condition if two clients happen to send their request within
the time to resolve the dynamic server, one will get sent to the fallback server
immediately and subsequent requests might get sent to the dynamic server later when it is
established. From what I've seen in production, this case has been very rare (but
maybe in larger countries its another story).
However, even if the packets take different paths, this shouldn’t break the authentication
- changing the paths due to lost requests (udp) or reset connections (tls) can happen any
time.
Regards,
Fabian
--
SWITCH
Fabian Mauchle, Network Engineer
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
Phone +41 44 268 15 30, direct +41 44 268 15 39