headscale
headscale copied to clipboard
support Proxy to get ip from a http Header instead from source IP (127.0.0.1)
Hi, I'm running headscale on a server that is servicing https via a caddy server. It works perfectly (Thanks for that). The only minor problem are the logfiles. Because I'm using a Reverse-proxy in front, the logfile look like this:
Nov 07 23:05:04 MYHOST headscale[3132606]: [GIN] 2021/11/07 - 23:05:04 | 200 | 1.003830109s | 127.0.0.1 | POST "/machine/MYID/map"
Could a new parameter be added to take the log file from a http-header instead of the source IP?
Sorry, I can't write go, or I would add it myself.
The most complicated part of solving this issue is that it requires creating a new config option.
Caddy is already setting X-Forwarded-For headers. However, for security reasons Gin does not look into that automatically. Instead, you need to set r.SetTrustedProxies([]string{"IP or CIDR"}) (docs). In headscale, it would be around here:
https://github.com/juanfont/headscale/blob/74f0d08f507ba6dd25ea69cf4faa38093e46be07/app.go#L407
However because the proxy's IP or CIDR depends on your environment, it needs to be something that is set in a config file.
Also note that the config should allow setting Gin's TrustedPlatform flag if the app is running on platforms like Google App Engine, Cloudflare, etc.
I also have the same issue using traefik 2 as proxy, I only ever see the proxy address instead of the remote client address.
@ItalyPaleAle those options are used commonly in other projects, so doesn't it seem sensible to have to set them here too when using a proxy?
For security reasons (and for the fact that certain CDNs require looking at different headers) I would not recommend enabling trusted proxies with 0.0.0.0/0 by default. Should really be a config option IMHO. Otherwise if someone is NOT running the app behind a proxy, a malicious actor could send requests with the X-Forwarded-For header to fake the IP.
That was my point, we should have to set them and yes likely 0.0.0.0/0 shouldn't be default, as it would be expected the proxy would be set to one specific IP or a range in the case of Cloudflare.
Is there a temporary workaround for this? Is the alpine docker image a fix?
Adding link for reference for the haproxy proxy protocol, which seems to be relatively widely adopted: https://www.haproxy.org/download/2.7/doc/proxy-protocol.txt
I reckon this is now