10 Jun
2021
10 Jun
'21
10:50 a.m.
I would agree its a connection reuse issue, #1107 is probably a more relevant discussion
to have.
As an experiment I tried a modified version of tcp_main.c with the connection lookup
modified to not return an existing connection and the expected behaviour was observed.
Thinking the further the ideal solution from my point of view would be a pair of config
values, one to enable a enhanced matching mechanism, and a complementary value list of ips
which need to be outbound sni aware and takes the tls profile into account when a
configured ip is matched as the destination. Unfortunately this would be non trivial as
correct me if I'm wrong but the tls profile is attached after the connection is
created so a chicken and egg problem? I agree this isnt vast majority use case territory
but would be invaluable for offering hosted services and allows me to keep the rest of the
architecture and network config the same. As surely an outbound connection with a
different servername specified should be treated as distinct connections even if the
destination is the same?
The issue I have with aliases is that I would swap the admin burden of adding sans to the
ssl and doing a tls.reload to having to restart the service, and increase the number of
open ports at the edge, basically its not scalable enough, I can just about cope with slow
tls reload when you have more than one cert loaded (trivial load test with 30 certs took
over 60 secs to reload) The whole impetus for trying to use sni with kamailio would be
offer a scalable, automatable provisioning for direct routing customers, which doesn't
have a restriction on number of sans defined on the cert (think simplicity of adding a
vhost in nginx). Currently provisioning can be done live by expanding a cert, updating
the dispatcher with new entries and reloading tls and dispatcher with kamcmd.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2760#issuecomment-858396771