On 11/19/2020 10:02 AM, Howard Chu wrote:
- Config directives for specifying IP address(es) and network(s)
expected and trusted to send proxy protocol header.
Sounds like unnecessary work. Just use an ACL.
I don't think an ldap level ACL would work for what he means? I think he wants to control what source IP addresses are allowed to connect to the proxy protocol port and arbitrarily say what the client IP address is which is passed down to the underlying ldap access control to be processed by ACLs. If you are using IP address based access control, you wouldn't want arbitrary clients to be able to connect and send a proxy header claiming to be somebody else.
However, given that the proxy protocol and regular access will be on different ports, this seems better handled at the network firewall level.
- Log the proxied peername separately, similar how session
tracking control is logged.
Again, kind of defeats the purpose of transparently relaying the client's address.
I'm not completely sure what he meant by this, but I was planning on modifying the initial connection log to indicate it was proxied, including both the address of the proxy and the proxied address.
so for a normal connection something like:
Nov 15 19:21:18 themis slapd[22846]: conn=482386 fd=89 ACCEPT from IP=134.71.247.3:54401 (IP=0.0.0.0:389)
and for a proxied connection something like:
Nov 15 19:21:18 themis slapd[22846]: conn=482386 fd=89 ACCEPT from IP=134.71.247.3:54401 proxyIP=10.128.1.0:34323 (IP=0.0.0.0:389)