proxy_protocol send incorrect header
Rozhuk Ivan
rozhuk.im at gmail.com
Mon Oct 30 14:47:17 UTC 2023
On Mon, 30 Oct 2023 17:00:38 +0400
Roman Arutyunyan <arut at nginx.com> wrote:
> > I got incorrect proxy header:
> > PROXY TCP4 172.16.0.208 unix:/var/run/nginx_443_test.sock 9795
> > 0\r\nSSH-2.0-OpenSSH_9.3\r\n
> >
> > Expect:
> > PROXY TCP4 172.16.0.208 172.16.0.254 9795
> > 443\r\nSSH-2.0-OpenSSH_9.3\r\n
> >
> Currently the realip module only changes the client address
> (c->sockaddr) and leaves the server address (c->local_sockaddr)
> unchanged. The behavior is the same for Stream and HTTP and is
> explained by the fact that initially the module only supported HTTP
> fields like X-Real-IP and X-Forwarded-For, which carry only client
> address.
>
> Indeed it does look inconsistent in scenarios like yours when address
> families are different. But do you really need the server address or
> you just highlight the inconsistency?
1. I am writing proxy protocol (PP) parser, and it uses:
inet_pton(family, straddr, sa_addr)
where family was taken from TCP4/TCP6 => AF_INET/AF_INET6
It fail by 2 reasons:
a. inet_pton() support only AF_INET/AF_INET6 at least on FreeBSD
b. It never get AF_UNIX - since it is not expected in
proxy protocol v1.
2. Even in case I do addr type auto detection, record for AF_UNUX
should be:
/var/run/nginx_443_test.sock
not
unix:/var/run/nginx_443_test.sock
3. Proxy protocol designed to pass info about client
connection, so it is impossible get mix of
AF_INET/AF_INET6/AF_UNIX in one connection.
__Current nginx implementation violate proxy protocol specification.__
4. I suppose other parser implementations of proxy protocol
will be also fail to parse mixed address families.
In my use case 443 shared between few services, one of them
support proxy protocol but does not support TLS+PP,
so I need terminate TLS using nginx and pass PP+plain text to service.
Few services does not support PP, and I must make additional proxy
inside nginx to remove PP because proxy_protocol option does not
support variables.
More information about the nginx
mailing list