The SYN-ACK tracking works in transparert mode with haproxy. I have setup haproxy to rebind all connections before and basically proxy the internet (and use NAT for udp). That said, I assume the point of DSR is that it's not always going to take the same path and that is where the real issue is. Haproxy can handle an initial SYN-ACK man in the middle, but moving the end point would be the problem.
On Mon, Nov 7, 2022 at 2:12 AM Willy Tarreau <[email protected]> wrote: > 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 > >
