[stunnel-users] "Chained" stunnel instances

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.
> 
> Michael

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.

G'luck,
Peter

> 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...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20150802/ce86fef7/attachment.sig>