On 11/19/2020 10:02 AM, Howard Chu wrote:
1. 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.
3. 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)