---------- Forwarded message --------- From: Jorge Redondo Flames [email protected] Date: Wed, 14 Apr 2021 at 19:45 Subject: Re: [stunnel-users] Re: Local socket keeps listening To: Ludolf Holzheid [email protected]
Stunnel could listen on its local port *only* when the peer server is listening on its corresponding server socket. So if there is no serve on the other side, there should not be local listening socket. Does not that make sense?
On Wed, 14 Apr 2021 at 19:38, Ludolf Holzheid [email protected] wrote:
On Wed, 2021-04-14 19:13:03 +0200, Jorge Redondo Flames wrote:
[..]
Is there a way to configure Stunnel to *close* the local socket (not listening anymore) whenever the peer process (i.e. the server) has closed its socket?
Stunnel listens for connection request from the client(s) and connects to the server on behalf of the client(s). How will a client ever be able to connect through Stunnel again if Stunnel closes the listening socket?
Ludolf
--
Ludolf Holzheid
Bihl+Wiedemann GmbH Floßwörthstraße 41 68199 Mannheim, Germany
Tel: +49 621 33996-0 Fax: +49 621 3392239
mailto:[email protected] https://www.bihl-wiedemann.de
Sitz der Gesellschaft: Mannheim Geschäftsführer: Jochen Bihl, Bernhard Wiedemann Amtsgericht Mannheim, HRB 5796
Datenschutzerklärung: https://www.bihl-wiedemann.de/de/meta/datenschutz _______________________________________________ stunnel-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
On 14.04.21 19:58, Jorge Redondo Flames wrote:
Stunnel could listen on its local port *only* when the peer server is listening on its corresponding server socket. So if there is no serve on the other side, there should not be local listening socket. Does not that make sense?
No.
In the general situation (server *not* being on the same machine as stunnel), stunnel CANNOT know whether the server's listening short of trying to connect to it - which it will only do on behalf of an incoming client request, which would never happen if stunnel weren't listening.
Even if server and stunnel run on the same machine/OS, finding out about the server's state would require a bunch of special-purpose code.
Assuming that they *are* on a common Linux (or at least unixoid) system, however, it would be rather trivial to write a root cron job that checks the output of "ss"/"netstat" for the server's LISTEN and simply terminates stunnel if it isn't found.
Or even better, have the server *restarted* automatically whenever it croaks ...
Regards,
Understood. Although it still seems to me that the code doing more or less what the cron job would do might worth.
On Wed, 14 Apr 2021 at 20:19, Jochen Bern [email protected] wrote:
On 14.04.21 19:58, Jorge Redondo Flames wrote:
Stunnel could listen on its local port *only* when the peer server is listening on its corresponding server socket. So if there is no serve on the other side, there should not be local listening socket. Does not that make sense?
No.
In the general situation (server *not* being on the same machine as stunnel), stunnel CANNOT know whether the server's listening short of trying to connect to it - which it will only do on behalf of an incoming client request, which would never happen if stunnel weren't listening.
Even if server and stunnel run on the same machine/OS, finding out about the server's state would require a bunch of special-purpose code.
Assuming that they *are* on a common Linux (or at least unixoid) system, however, it would be rather trivial to write a root cron job that checks the output of "ss"/"netstat" for the server's LISTEN and simply terminates stunnel if it isn't found.
Or even better, have the server *restarted* automatically whenever it croaks ...
Regards,
Jochen Bern Systemingenieur
Binect GmbH
stunnel-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
On Wed, Apr 14, 2021 at 08:24:51PM +0200, Jorge Redondo Flames wrote:
On Wed, 14 Apr 2021 at 20:19, Jochen Bern [email protected] wrote:
On 14.04.21 19:58, Jorge Redondo Flames wrote:
Stunnel could listen on its local port *only* when the peer server is listening on its corresponding server socket. So if there is no serve on the other side, there should not be local listening socket. Does not that make sense?
No.
In the general situation (server *not* being on the same machine as stunnel), stunnel CANNOT know whether the server's listening short of trying to connect to it - which it will only do on behalf of an incoming client request, which would never happen if stunnel weren't listening.
Even if server and stunnel run on the same machine/OS, finding out about the server's state would require a bunch of special-purpose code.
Assuming that they *are* on a common Linux (or at least unixoid) system, however, it would be rather trivial to write a root cron job that checks the output of "ss"/"netstat" for the server's LISTEN and simply terminates stunnel if it isn't found.
Or even better, have the server *restarted* automatically whenever it croaks ...
Understood. Although it still seems to me that the code doing more or less what the cron job would do might worth.
So, three points here.
1. There are some services (some servers) that do not react very nicely to somebody connecting to them and disconnecting immediately. Some of them do some work at the moment of the connection (e.g. resolve the client's IP address, check it against firewall rules, or even do some actual, service-specific, work, e.g. allocate buffers, prepare some kind of data...). Some of them are configured in such ways as to avoid portscanners or denial of service attacks or spam or flood or... many other things. In general, unless you *know* that it is safe to connect and immediately disconnect from the remote service, it is very unwise to try to do that. In your particular case, you know that, but in general, it is not a good idea.
2. Even if stunnel would try to connect to the remote service, what happens if the connection fails? OK, you say stunnel should close its local listening socket, but what then - will it never open it again? And if here's the part when you say "it can try to connect to the remote server again and start listening again" - okay, how much time passes between these connection attempts? Even something like a second may be bad if a real client chooses exactly this second to try to connect to stunnel and... stunnel is not listening... even though the remote server has started listening immediately after stunnel's last unsuccessful attempt. So... whatever interval you pick, closing the local listening socket *will* result in real, live clients failing to connect.
3. A more general point: if you really want to check whether a service is operational, only checking whether it will accept a connection is not enough. I've seen *many* failure modes over the years: from an overloaded machine where the OS kernel will accept the connection, but none of the actual server processes will react, through an overloaded service process that accepts the connection but spends too much time processing other requests to pay any attention to it, to a firewall host gone crazy that will pass connection packets, but will then refuse to pass the actual payload (yes, I've seen that happen for at least three different reasons). So an actual service check would be to connect and then send some kind of simple request to the server that you know will not take it too much time and resources to process, but will give you some measure of confidence that the server is actually serving requests and data.
But in short, it is impossible for stunnel to know whether a remote server is listening for a connection without trying to connect, it may not be "polite" for it to try to connect too often, and trying to connect not-too-often *will* result in real clients being unable to connect in the intermediate intervals.
G'luck, Peter
Got it. Thank you very much!
On Wed, 14 Apr 2021 at 20:41, Peter Pentchev [email protected] wrote:
On Wed, Apr 14, 2021 at 08:24:51PM +0200, Jorge Redondo Flames wrote:
On Wed, 14 Apr 2021 at 20:19, Jochen Bern [email protected] wrote:
On 14.04.21 19:58, Jorge Redondo Flames wrote:
Stunnel could listen on its local port *only* when the peer server is listening on its corresponding server socket. So if there is no
serve on
the other side, there should not be local listening socket. Does not
that
make sense?
No.
In the general situation (server *not* being on the same machine as stunnel), stunnel CANNOT know whether the server's listening short of trying to connect to it - which it will only do on behalf of an
incoming
client request, which would never happen if stunnel weren't listening.
Even if server and stunnel run on the same machine/OS, finding out
about
the server's state would require a bunch of special-purpose code.
Assuming that they *are* on a common Linux (or at least unixoid)
system,
however, it would be rather trivial to write a root cron job that
checks
the output of "ss"/"netstat" for the server's LISTEN and simply terminates stunnel if it isn't found.
Or even better, have the server *restarted* automatically whenever it croaks ...
Understood. Although it still seems to me that the code doing more or
less
what the cron job would do might worth.
So, three points here.
There are some services (some servers) that do not react very nicely to somebody connecting to them and disconnecting immediately. Some of them do some work at the moment of the connection (e.g. resolve the client's IP address, check it against firewall rules, or even do some actual, service-specific, work, e.g. allocate buffers, prepare some kind of data...). Some of them are configured in such ways as to avoid portscanners or denial of service attacks or spam or flood or... many other things. In general, unless you *know* that it is safe to connect and immediately disconnect from the remote service, it is very unwise to try to do that. In your particular case, you know that, but in general, it is not a good idea.
Even if stunnel would try to connect to the remote service, what happens if the connection fails? OK, you say stunnel should close its local listening socket, but what then - will it never open it again? And if here's the part when you say "it can try to connect to the remote server again and start listening again" - okay, how much time passes between these connection attempts? Even something like a second may be bad if a real client chooses exactly this second to try to connect to stunnel and... stunnel is not listening... even though the remote server has started listening immediately after stunnel's last unsuccessful attempt. So... whatever interval you pick, closing the local listening socket *will* result in real, live clients failing to connect.
A more general point: if you really want to check whether a service is operational, only checking whether it will accept a connection is not enough. I've seen *many* failure modes over the years: from an overloaded machine where the OS kernel will accept the connection, but none of the actual server processes will react, through an overloaded service process that accepts the connection but spends too much time processing other requests to pay any attention to it, to a firewall host gone crazy that will pass connection packets, but will then refuse to pass the actual payload (yes, I've seen that happen for at least three different reasons). So an actual service check would be to connect and then send some kind of simple request to the server that you know will not take it too much time and resources to process, but will give you some measure of confidence that the server is actually serving requests and data.
But in short, it is impossible for stunnel to know whether a remote server is listening for a connection without trying to connect, it may not be "polite" for it to try to connect too often, and trying to connect not-too-often *will* result in real clients being unable to connect in the intermediate intervals.
G'luck, Peter
-- Peter Pentchev [email protected] [email protected] [email protected] PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
-
Jochen Bern -
Jorge Redondo Flames -
Peter Pentchev