On Fri, Nov 04, 2022 at 05:33:40PM +0100, Lukas Tribus wrote: > On Fri, 4 Nov 2022 at 16:50, Szabo, Istvan (Agoda) > <[email protected]> wrote: > > > > Yeah, that's why I'm curious anybody ever made it work somehow? > > Perhaps I should have been clearer. > > It's not supported because it's not possible. > > Haproxy the OSS uses the socket API, haproxy cannot forward IP packets > arbitrarily, which is required for DRS.
And in fact it goes beyond the API. The first and foremost reason is that if you want to intercept TCP and work on contents, you have to accept an incoming connection first. For this you need do respond to a SYN with a SYN-ACK that holds a locally-chosen sequence number. Then assuming the connection is validated and you're going to pass it to a server, while you could imagine replicating the SYN sequence number from the client, the server will chose its own sequence number for the SYN-ACK, which will not match the one you chosed previously, and as such if you send the server's response directly to the client, this last one will never understand this traffic because it's shifted by the difference between the two sequence numbers. Some large hosting platforms had worked around this in the late 90s and early 2000s by prepending a header to TCP segments sent to the server, containing all the front connection's parameters (a bit like the proxy protocol), and the servers' TCP stack was heavily modified to use the parameters presented in this header to create the connection, including ports, sequence numbers, options etc that the server had to use. For obvious reasons such servers ought never be exposed to the net or it would have been trivial to DoS them or even to hijack their connections! I remember that others had proposed TCP extensions to tell a peer to skip a range of sequence numbers to make this possible (i.e. "I'm sending you a 1.3 GB hole then the data comes") as a way to splice a server connection to an already accepted one. But similarly this totally disappeared because it was hackish and totally insecure. > This is a hard no, not a "we do not support this configuration because > nobody ever tried it and we can't guarantee it will work". Definitely ;-) Cheers, Willy
