Re: PROXY protocol v2 support
Wietse Venema: > Willy Tarreau: > > On Tue, Dec 31, 2019 at 08:21:05AM +0100, Tam?s G?rczei wrote: > > > Thanks Wietse, this is what I thought and found out during my > > > experiments,That said, now knowing that only v1 is supported, may I ask > > > whether you have considered implementing v2 support? I'm about to > > > migrate to a setup where I'm behind a load balancer that only speaks v2. > > > > Maybe you can try to implement v2 support ? Parsing v2 when v1 is already > > supported is quite easy, especially at the same level of support (i.e. no > > TLV field support for TLS or whatever). You can have a look at > > conn_recv_proxy() in haproxy:src/connection.c which supports the two > > versions. Feel free to steal any code I wrote there, if that helps :-) > > I'm looking into this, and a Postfix-quality implementation including > tests(!) is going to take more than a few hours. Primarily, because > v2 uses a binary protocol, which complicates everything. I'll put a > few hours in today. I found that I first have to refactor the existing Postfix implementation, because of a change in the haproxy message format. The "diff -u" output is about 750 lines -- and that is refactoring before adding v2 support. The existing Postfix code completely separates the haproxy message reader from the haproxy message parser. The v1 haproxy message has a unique message terminator, and the haproxy message reader can pull the entire message from the input queue before handing it off to the haproxy message parser. With the new protocol, there is no unique message terminator. Instead, message length information is embedded in the message, and the reader has to pull the message from the input queue after the parser has figured out the message length. It's not super complicated, but this back-and-forth between reading and parsing is complicating the event-driven postscreen code a bit. Wietse
Re: PROXY protocol v2 support
On Tue, Dec 31, 2019 at 11:38:06AM -0500, Wietse Venema wrote: > I have a question about the v2 protocol spec. > > - \x0 : LOCAL : the connection was established on purpose by the > proxy without being relayed. The connection endpoints are the > sender and the receiver. Such connections exist when the proxy > sends health-checks to the server. The receiver must accept this > connection as valid and must use the real connection endpoints and > discard the protocol block including the family which is ignored. > > Real connection == the endpoints of the TCP connection from proxy to > Postfix? That would be my reading of that text, most likely a health-check or other proxy-initiated connection. > - 0x0 : AF_UNSPEC : the connection is forwarded for an unknown, > unspecified or unsupported protocol. The sender should use this > family when sending LOCAL commands or when dealing with > unsupported protocol families. The receiver is free to accept the > connection anyway and use the real endpoint addresses or to reject > it. The receiver should ignore address information. > > What does 'reject' mean in this context? If it means closing the > connection, what is the point of rejecting a connection that was > made for the purpose of a health check? Yes, reject == close, but presumably only if the connection was not proxy-originated, i.e. not LOCAL. For Postfix, if the proxy cannot provide any address information, for a forwarded connection (should "never" happen in practice) we probably should close the connection. -- Viktor.
Re: PROXY protocol v2 support
I have a question about the v2 protocol spec. - \x0 : LOCAL : the connection was established on purpose by the proxy without being relayed. The connection endpoints are the sender and the receiver. Such connections exist when the proxy sends health-checks to the server. The receiver must accept this connection as valid and must use the real connection endpoints and discard the protocol block including the family which is ignored. Real connection == the endpoints of the TCP connection from proxy to Postfix? - 0x0 : AF_UNSPEC : the connection is forwarded for an unknown, unspecified or unsupported protocol. The sender should use this family when sending LOCAL commands or when dealing with unsupported protocol families. The receiver is free to accept the connection anyway and use the real endpoint addresses or to reject it. The receiver should ignore address information. What does 'reject' mean in this context? If it means closing the connection, what is the point of rejecting a connection that was made for the purpose of a health check? Wietse
Re: PROXY protocol v2 support
Many thanks in advance for all your efforts in this regard, Wietse! On 12/31/19 5:08 PM, Wietse Venema wrote: > Willy Tarreau: >> On Tue, Dec 31, 2019 at 08:21:05AM +0100, Tam?s G?rczei wrote: >>> Thanks Wietse, this is what I thought and found out during my >>> experiments,That said, now knowing that only v1 is supported, may I ask >>> whether you have considered implementing v2 support? I'm about to >>> migrate to a setup where I'm behind a load balancer that only speaks v2. >> Maybe you can try to implement v2 support ? Parsing v2 when v1 is already >> supported is quite easy, especially at the same level of support (i.e. no >> TLV field support for TLS or whatever). You can have a look at >> conn_recv_proxy() in haproxy:src/connection.c which supports the two >> versions. Feel free to steal any code I wrote there, if that helps :-) > I'm looking into this, and a Postfix-quality implementation including > tests(!) is going to take more than a few hours. Primarily, because > v2 uses a binary protocol, which complicates everything. I'll put a > few hours in today. > > Wietse
Re: PROXY protocol v2 support
Willy Tarreau: > On Tue, Dec 31, 2019 at 08:21:05AM +0100, Tam?s G?rczei wrote: > > Thanks Wietse, this is what I thought and found out during my > > experiments,That said, now knowing that only v1 is supported, may I ask > > whether you have considered implementing v2 support? I'm about to > > migrate to a setup where I'm behind a load balancer that only speaks v2. > > Maybe you can try to implement v2 support ? Parsing v2 when v1 is already > supported is quite easy, especially at the same level of support (i.e. no > TLV field support for TLS or whatever). You can have a look at > conn_recv_proxy() in haproxy:src/connection.c which supports the two > versions. Feel free to steal any code I wrote there, if that helps :-) I'm looking into this, and a Postfix-quality implementation including tests(!) is going to take more than a few hours. Primarily, because v2 uses a binary protocol, which complicates everything. I'll put a few hours in today. Wietse
Re: Broken Resource Links
On 2019-12-31 Peter wrote: > Unfortunately it appears that Patrik Koetter's website is now defunct and > the domain has been taken over by someone else completely leaving a number > of resources linked to from postfix.org broken including (but probably not > limited to): > > The saslfinger utility linked to from DEBUG_README. > > The Postfix SASL Authentication and TLS howto linked to in two different > places on the docs page. > > ...possibly others. > > Fortunately There are copies of the above listed resources on Archive.org's > wayback machine: > > https://web.archive.org/web/20190327234908/http://postfix.state-of-mind.de/patrick.koetter/saslfinger/ > > https://web.archive.org/web/20190618125312/http://postfix.state-of-mind.de/patrick.koetter/smtpauth/ > > It might be useful if someone wants to copy those resources to a more > permanent location, or at least update the links. https://www.planetcobalt.net/patrick.koetter/saslfinger/ https://www.planetcobalt.net/patrick.koetter/smtpauth/ I adjusted links where it seemed appropriate. If I made a mistake somewhere please let me know. Regards Ansgar Wiechers -- "Abstractions save us time working, but they don't save us time learning." --Joel Spolsky
Re: PROXY protocol v2 support
On Tue, Dec 31, 2019 at 10:34:14AM +0100, Tamás Gérczei wrote: > Thanks Willy, I appreciate the clue and your helpful intention - > unfortunately this isn't something I can personally do owing to lack of > knowledge. I don't know whether the v1 implementation had been a > community patch or something Wietse or Viktor have done. Wietse did all the hard work in 2012. Back then it was tricky to implement v1 due to the non-atomicity of the protocol. I seem to remember that this is what led to the design of v2. But honestly, every time someone told me he lacked knowledge to contribute a patch, it took more time than average but was of better quality in the end than those who think they know. C is not difficult to read, it can only be tricky at times but I really think that all you need is already there. Thus if you have a few hours to spend there figuring how it's arranged, I'm pretty sure that you can figure how to proceed to have a first roughly working version :-) Regards, Willy
Re: PROXY protocol v2 support
Thanks Willy, I appreciate the clue and your helpful intention - unfortunately this isn't something I can personally do owing to lack of knowledge. I don't know whether the v1 implementation had been a community patch or something Wietse or Viktor have done. On 12/31/19 8:35 AM, Willy Tarreau wrote: > On Tue, Dec 31, 2019 at 08:21:05AM +0100, Tamás Gérczei wrote: >> Thanks Wietse, this is what I thought and found out during my >> experiments,That said, now knowing that only v1 is supported, may I ask >> whether you have considered implementing v2 support? I'm about to >> migrate to a setup where I'm behind a load balancer that only speaks v2. > Maybe you can try to implement v2 support ? Parsing v2 when v1 is already > supported is quite easy, especially at the same level of support (i.e. no > TLV field support for TLS or whatever). You can have a look at > conn_recv_proxy() in haproxy:src/connection.c which supports the two > versions. Feel free to steal any code I wrote there, if that helps :-) > > Regards, > Willy
