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!
Michael
-----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!
Michael _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
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
On Fri, Jul 31, 2015 at 2:04 PM, Michal Trojnara [email protected] 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!
Michael _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJVu+LDAAoJEC78f/DUFuAUCqkQAL957JFjxSF4lDIL7NagurFT hoenCP/kJsFroZkli9pWImdTyF4Qjard40uavAycx25VBBf4h3/sHdqs861Tmv7i jsjrUvMWYQP8VqH7fgmHaFjQN17RxkeUUf6ZFUTkYqf+yoHfPRFGjHqIbr4foXsI Z+FVEQ08bp30OYkoLWNibZtlkGSLwMeeZ2jv4vGPpwfNefniYzsIJd4FQvVln4te fRKIdfY0v1C7hksnWCMb+OSOMvdgbDd4EG5oeGCpEzNcwwpeh8iUFawhzsLQTpav wcZ6L+eQznQjy5wSdgUfVBxMhL0gZSHmFzr8+c0ES8JlEAZl4G6vviSADLUhhu1m ck9dPE+hxBLDfJGHYnXzbcKSp3Eae2Cuz9tvzs7ppnzOBGLQVtfcA+CvKfeWTNcD L+zpI/CcEMIFbwxu3YA9O6/tVs1qZrWiB2bfSh2T3nJrGDO2rIn/AxQAzLzMdBym FINeM6yJkelUTcy1BbvF6m8fHpd9UVdNneQtZp2bFaiO4xcd7AicP56VD19SfqBf /h7ykHJyU8Fsfx6juLVALV/nsVinPiNQ0t3TSujzFkWvTZdClyQ748uvQ0RvHfV1 7MShfesMh3tINmijVyW8A20qVHpQ7FVS/1dzXiRi/4BS21JALZVdRVFnCI5GKvns m9HnpMzbVj5vVbGdNFjK =jkOV -----END PGP SIGNATURE----- _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
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 [email protected] 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!
-
Michael Gebis -
Michal Trojnara -
Peter Pentchev