[PATCH] proxy-protocol dst variables and proxy-proxy-protocol

[Bjørnar Ness]

2016-11-10 0:52 GMT+01:00 Maxim Dounin <mdounin at mdounin.ru>:
> Hello!
>
> On Wed, Nov 09, 2016 at 08:52:14PM +0100, Bjørnar Ness wrote:
>
>> On Nov 9, 2016 19:20, "Maxim Dounin" <mdounin at mdounin.ru> wrote:
>
> The implementation of PROXY protocol in nginx basically mimics
> what is available via X-Forwarded-For in http.
>
> Extending it with destination data may simplify some use cases.
> But it will also complicate things and will make other use cases
> less intuitive.  It is also more or less clear that destination
> can be identified using a separate destination within nginx
> itself.n

It is true that the way proxy protocol support in nginx is currently
implemented,
it discards half of the information available, and only gives us access to the
src part. I think this is strange "halfway" implementation anyway.

> As previously said, I'm not convinced this should be merged, as
> suggested changes have obvious downsides in common cases and only
> beneficial for very specific use cases.

When one uses proxy-protocol, one allways has something in front that
generates it. Using multiple configurations (can be _lots_) and having to
do configuration management/reloads/whatever, seems like going backwards.
The overhead of this impl if proxy protocol is not used in listed is
just a couple
ptr's, and can for sure be reduced at the cost of more complex code.

>> > If you have some ideas on how to properly support PROXY protocol
>> > in mail - please comment on the relevant patch.
>>
>> Reason for mentioning it here, is the mail proxy-protocol patch has the
>> functionality mentioned here as a dependency. Both exim and dovecot
>> understands proxy-protocol, and I want to pass it on after the auth is done,
>> hence proxy-proxy-protocol.
>
> Current question is:
>
> What "listen ... proxy_protocol" should mean in case of mail.  In
> other modules, it just means that PROXY protocol header is parsed
> and appropriate variables are available for use.  It would be good
> to have similar meaning in mail, but there are realip module and
> no variables in mail.

But Auth module can get the variables passed via headers, which is
certainly a usecase, also, to be able to send same proxy protocol header out
as you get in, the proxy-proxy-protocol scenario, it needs to be
stored somewhere.
This will work seemlessly on both mail, http and stream when proxy-protocol is
enabled in both listen and outgoing, think of it as a "transparent
smart-proxy" :)

> In the stream module similar problem was resolved by not
> introducing "listen ... proxy_protocol" till variables support was
> added, and by adding realip module at the same time.  May be there
> are better options.
>
> I certainly dislike what is currently suggested, that is, just
> passing an address provided via PROXY protocol to backends via
> XCLIENT.
>
> Introducing PROXY protocol to backends instead of XCLIENT looks
> as a separate thing.

I think adding more support for XCLIENT these days is not needed, as the
software in common use today supports proxy protocol native.

-- 
Bj(/)rnar