Add configuration parameter that allows to skip discovering interfaces

[fdellwing]

This adds a new configuration parameter that allows the user to completly skip calling is_same_machine which is very expensive once the machine has a critical mass of interfaces.

This comes with the downside of having to do more work in setting up potential unnecessary binds.

---

We have a server with around 10k network interfaces and current versions of sslh are absolutly unusable there.

[yrutschle]

Thanks for the contribution.
I don't remember the rationale for some of the code in that area: does your patch not affect transparent proxying?
(I'm a bit confused about how transparent proxying still works if the target is on localhost: I feel it should still need to bind the server-side connection)

[fdellwing]

We found later after more testing, that for transparent proxying on localhost we can not return there. So we need to actually skip calling is_same_machine but run the following code regardless. For this the config check could be moved into the is_same_machine function or and additional layer of if could be used. Which one do you prefer?

[yrutschle]

neither, as long as I am confused :-)

Ok, in what follows, sockets are presented as "addr1:addr2" (with addr being IP+port)

The basic setup, where sslh listens to clients on one side and connects non-transparently to servers on the other side:

   ssl.cfg: listen on ext_target, connect to fin_target
client  <-------> sslh <------> server
   peer:ext_target     loc_soc:fin_target

When doing transparent proxying, sslh binds the local address of its servers-side socket to that of the peer, so we have:

client  <-------> sslh <------> server
   peer:ext_target     peer:fin_target

My understanding of the is_same_machine() code is that if the client connects to the same target address as the server, bind fails:

   ssl.cfg: listen on fin_target, connect to fin_target
client  <-------> sslh <------> server
   peer:fin_target     peer:fin_target

bind fails because we end up with the same socket twice.
But, I'm not clear on how the sslh configuration would work to achieve that, and I have the feeling that this could not happen with the new transparent proxying setup using additional network interfaces, meaning we could pull out is_same_machine entirely.

@ftasnetamot, you poked around that area about doing transparent daisy-chaining: do I understand this correctly?

[fdellwing]

I can't actually answer you any of this. I can tell you what we did and what worked for us:

We run sslh in Docker with network mode set to host. We use openvpn, https and http in transparent mode. We patched is_same_machine to always return false without looking at any network interface. This does work for our setup and is not that the PR currently does.