Details
Critical Description
When the proxy_protocol is in use, the IP address of the proxy is replaced with the IP address of the client being proxied for authentication. This replaced IP is then also used in all error messages and other information that is logged. This makes it very difficult to diagnose any network errors that happen for a client that's behind a proxy which uses proxy_protocol.
Here's an example: we have two proxies, proxy A at 192.168.0.200 and proxy B at 192.168.0.300, and a client at 192.168.0.100. If there's a problem on proxy A that results in a network error, the error that is logged is:
[Warning] Aborted connection 123 to db: 'foo' user: 'bar' host: '192.168.0.100' (Got an error reading communication packets)
|
What I think would be an improvement is an error like this:
[Warning] Aborted connection 123 to db: 'foo' user: 'bar' host: '192.168.0.100' proxy: '192.168.0.200' (Got an error reading communication packets)
|
With this, it'd be immediately known that the proxy A is the origin of the error and the link between these two nodes is the problem. With the current error message, all links that connect to the database must be inspected.
As can be seen, for setups where there are multiple proxies, finding out which proxy to look into when looking for related errors takes a lot of work and leads to potentially ambiguous results if the connection IDs on the database aren't logged by the proxy for any errors that it faces. The improved error would both remove the ambiguity and reduce that amount of work that needs to be done to find the proxy to look at.
Attachments
Issue Links
- relates to
-
MDEV-29942 Provide insight on proxy_protocol usage
-
- Open
-
Activity
The motivation for making the IP spoofing visible is quite clear and in my opinion sensible:
As can be seen, for setups where there are multiple proxies, finding out which proxy to look into when looking for related errors takes a lot of work and leads to potentially ambiguous results if the connection IDs on the database aren't logged by the proxy for any errors that it faces. The improved error would both remove the ambiguity and reduce that amount of work that needs to be done to find the proxy to look at.
If you have one proxy the argument doesn't really hold but when you have 50 proxies and one of them had an error, it becomes very hard to figure out exactly where the problem originated from.
Still, it is technically new feature, task or RFE, rather than a bug. If something does not work as designed, it is a bug. If someone comes up with new requirements, because another software fails to log connection id on error, it is a feature , task or RFE.
Given that 99.99% of all installations have no use of proxy protocol always showing equal IPs and "proxy: ", will only confuse the use.
So it is a new feature. For proxy-protocoled connections we might want to show it, but Original requirements did not contain it, in fact, IP spoofing was completely transparent to user, and there was no idea that it should not be. Who, how, and when did disconnect ,one could argue this is the proxy thing, and should/could be logged at proxy site, rather than making IP spoofing on server visible