[stunnel-users] "Chained" stunnel instances
roam at ringlet.net
Sun Aug 2 01:00:57 CEST 2015
On Fri, Jul 31, 2015 at 02:28:36PM -0700, Michael Gebis wrote:
> Michal, thank you for the quick response!
> This is a great idea, but sadly I left out a relevant detail. All of
> the server machines are actually running a collection of services. My
> focus is limited to a subset, which is why I forgot to mention the
> other services. The stunnel instance on each machine is acting as an
> encryption service for *all* of the services on these machines.
> (Stunnel is very useful and thus very popular. :)
> The consequence is that if I kill st1 when my service is down, it
> fixes the problem for my service, but it causes problems for the other
> services on that machine.
Well, you could dynamically update its configuration file, disabling
a section for a service that is down and reenabling it when the service
comes back up...
Of course, this has to be done very carefully... I personally shiver
a little every time somebody mentions dynamically generating
a configuration file, but yes, it can be done safely and reliably.
> On Fri, Jul 31, 2015 at 2:04 PM, Michal Trojnara
> <Michal.Trojnara at mirt.net> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > Hi Michael,
> > One solution might be to run a tiny watchdog script on each of the
> > server machines that would periodically test whether S1/S2/S3 is alive
> > and start/stop the corresponding st1/st2/st3 service.
> > What do you think?
> > I can think of some other solutions, but none of them is remotely as
> > simple and flexible as the one described above.
> > Best regards,
> > Mike
> > On 31.07.2015 20:12, Michael Gebis wrote:
> >> Hello.
> >> I have a question about a strange stunnel configuration;
> >> specifically, I'm like to use 'chained' stunnel instances, and I'm
> >> running into an issue.
> >> We have a conceptually simple setup: a client that connects to a
> >> server. We use stunnel both for encryption and for the failover
> >> mechanism. Here's a diagram of our simplest setup:
> >> /----S1 / C--st0-----S2 \ \----S3
> >> We have a client that connects to stunnel. Our stunnel
> >> configuration lists three connections with "prio" failover mode. So
> >> usually, connections go from C thru st and onto Server 1. If S1 is
> >> down, st0 fails to connect to S1 and instead tries S2, and all is
> >> good.
> >> However, sometimes we may place an optional second instance of
> >> stunnel in front of the servers.
> >> /----st1--S1 / C--st0-----st2--S2 \ \----st3--S3
> >> The failover mode of stunnel does not work so well in this
> >> configuration. If S1 is down, st0's failover algorithm does not
> >> kick in. Instead, st0 happily connects to st1, which is still
> >> alive and running. st1 then detects S1 is down and immediately
> >> closes the connection, but st0 does not care. Since the initial
> >> connection was successful, it does not initiate the failover
> >> algorithm.
> >> You may ask "why not change to round-robin mode?" The answer is
> >> that S1 is a dedicated machine, and S2/S3 are underpowered backups
> >> that have other primary responsibilities. We really want to direct
> >> all connections to S1 and only use S2/S3 in emergencies.
> >> You may also ask, "Why the second layer of
> >> stunnel?"--unfortunately, there are several hairy
> >> implementation-specific details that make this hard to change.
> >> My question is: is there any stunnel configuration option that can
> >> help us out? We would like the failover to work with and without
> >> the second layer of stunnel. From looking at the source code, I
> >> think I'm out of luck, but I figured it couldn't hurt to ask.
> >> Thanks!
Peter Pentchev roam at ringlet.net roam at FreeBSD.org pp at storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the stunnel-users