Re: HAProxy and proxy protocol support

Sam:

> [not postfix]

doh! A cognitive slip. Forgive me, I must have been writing from somewhere
in hyperspace.

PROXY v1 is indeed easier and should suffice in OP's use case. I would
imagine OP (and any other users sophisticated enough to be using HAProxy)
can ensure that TCP Fast Open is in use (see "tfo" option on the "backend"
stanza). In this case the header should be included in the SYN packet. This
should allow you to (perhaps optionally) immediately fail the connection if
you cannot read the header bytes with no delay. YMMV given that I haven't
tested this explicitly myself, but "tfo" is documented :) A configurable
timeout that can be set to 0=drop immediately if no bytes available should
do the trick for now, I imagine.

Thanks for all the fish, er, courier!

On Tue, Jun 11, 2024 at 6:05 PM Sam Varshavchik <[email protected]>
wrote:

> Andrew Athan writes:
>
> > It sounds like you've completed the important parts of the
> implementation. I
> > would strongly advocate you base your implementation on PROXY v2, as it
> > allows for passing of arbitrary values in variable length fields--which
> would
> > subsequently allow the HAProxy front end to potentially signal to
> features
> > within postfix if you expand the feature e.g., providing values to
> insert
> > into X- headers, or values that can be used in filtering rules. After
> all the
> > "source IP" can be seen as just one such special case value in a fixed
> > special case field of the PROXY protocol.
>
> Version 1 has the minimal functionality that's needed. I don't exclude
> the
> possibility of handling version 2, it's just that version 1 was the
> minimal
> effort.
>
> > I can't quite completely parse the last paragraph, but it sounds like
> your
> > concern is whether the header bytes are transmitted immediately by
> HAProxy
> > upon connection setup so as to not delay tcp.c's forking. It does send
> the
> > bytes immediately. PROXY is not a bidirectional protocol, and I believe
> the
> > implementation in HAProxy pushes those bytes immediately EXCEPT that
> there
> > are some configuration options which can tell HAProxy to delay
> adjudicating
> > the connection until enough bytes have been transmitted by the origin
> > connection so that HAProxy can extract necessary headers for itself.
> For
> > example, in order to receive the SNI. Anyway, in such cases, I believe
> > HAProxy would not have opened the downstream proxy connection until that
> has
> > already happened. Thus, nothing to worry about.
>
> I surmised that. But a network hiccup can throw a monkey wrench in it.
> Not
> parallelizing at this point has a bigger impact because of that. Ideally
> a
> subprocess gets forked immediately for a new socket, and the proxy header
> gets read by the subprocess. However the current couriertcpd design
> precludes this possibility. Significant surgery would be required.
>
> > btw, I find HAProxy's choice of naming the protocol PROXY unfortunate.
> The
> > word is terribly overloaded already, and it becomes difficult to know
> if
> > one's talking about the protocol, the instance of HAProxy, the
> downstream
> > connection, or the politics ;)
> >
> > Thanks for postfix!
>
> I'm not involved with Postfix. You have me mixed up with Wietse Venema.
> But
> I appreciate the kind words, nevertheless.
>
> _______________________________________________
> courier-users mailing list
> [email protected]
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
>

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users