Thanks Willy for responding. I’ll read over the code soon to see if it makes 
sense to expose some of the TLVs that aren’t already.

I shared your residence to abuse the protocol and maintain transparency.

My circumstance is that I have an environment of a very large enterprise 
inter-network with a large number of intranets (many with overlapping address 
space) that need to be proxied through a series of proxies to a shared / 
inter-network service.Being able to track / log flows across the series of 
proxies and or knowing the origin of a request is very useful from an 
operations perspective. 

There is also a security requirement to track the client source IP address and 
origin network - thus the interest in the namespace TLV which in our 
circumstance would represent the origin network.

The service right now isn’t proxy protocol aware, but that is being explored to 
pass the origin information into the service for security policies.

I’m trying to avoid terminating the TLS or otherwise interfere with it since 
most flows have client certificates. Server certificate replication is fairly 
simple, however a large number of client certificate proxying isn’t somewhere 
I’d want to go.

Regards,

Marc


> On 4 Jul 2017, at 6:12 pm, Willy Tarreau <[email protected]> wrote:
> 
> On Mon, Jul 03, 2017 at 10:11:29PM +1000, Marc Boschma wrote:
>> Is there anyway to log details from the PROXY protocol version 2, such as
>> namespace or any other TLVs? Especially custom...
>> 
>> On TLVs I'm looking at someway to pass through a unique ID across a series
>> of proxies. So being able to inspect TLV and or passed in namespace values
>> and make processing decisions based on that; even if having to utilise Lua
>> to effect the inspection...
> 
> There's no such thing for now. The proxy protocol is used to pass front
> connection information to the next hop, so in general, the next hop will
> replace its own information extraction methods with the information
> retrieved from the proxy protocol header. It's possible that haproxy is
> still missing certain sample fetch methods to extract certain information
> (I don't think we can extract a namespace ID for example, but I could be
> wrong ; maybe that just needs to be added). So once the information is
> properly available, what you pass over proxy protocol should be
> transparently available.
> 
> Now, regarding the ability to pass extra information, I'm not fond of this
> idea. Not for the idea itself, it would be great. It's regarding the purpose
> of the proxy protocol. It's not meant to be used to transport metadata for a
> connection, just to forward connection information. So in general you should
> keep in mind that it must not do something that would not be possible without
> the proxy in the middle, if the server would simply receive the original
> connection itself. If we start to do this, we'll see people abuse this
> protocol and use it everywhere as an intermediary layer to carry extra
> information and that opens a new can of worms.
> 
> Regards,
> Willy


Reply via email to