search

FAForever / server

The servercode for the Forged Alliance Forever lobby
http://www.faforever.com
GNU General Public License v3.0
67 stars 62 forks source link

Add support for the PROXY protocol #964

Closed Askaholic closed 1 year ago

Askaholic commented 1 year ago

Adds a new option to the LISTEN config which can enable the PROXY protocol for the given socket. This allows the lobby server to be placed behind a TCP proxy and still receive correct IP information for logging and GEOIP location. When a socket is placed into PROXY mode it should ONLY be accessed via the proxy. Direct traffic to the socket must be blocked by a firewall.

Proxy mode supports both v1 and v2 of the PROXY protocol which will be automatically detected from the connection headers.

Askaholic commented 1 year ago

How would it interfere with websockets? I figured the websocket bridge would just connect to the lobby via the PROXY protocol and handle the population of the original IP fields. I have been able to connect to the lobby server via websockets using this proxy in the past: https://github.com/Askaholic/lobby-bridge/

I also figured you would set up a dedicated context for websockets anyway to simplify the code required to get nice log messages.

Sheikah45 commented 1 year ago

I wasn't sure if websockets utilize the same proxy protocol or if they would even require a proxy in the same way since they could be protected by cloudflare.

If they use the same protocol then great, although just becomes a question of if they need the proxy, but no technical limitations.

Sheikah45 commented 1 year ago

And it looks like your bridge is for converting the websocket to raw TCP where as I was thinking of having the websockets connect directly to the lobby server

Sheikah45 commented 1 year ago

Admittedly I am also not clear on why websockets requires a separate bridge but that is out of scope for this pr

Askaholic commented 1 year ago

It's because the websocket library in python doesn't integrate well with our code. We need to be able to make fire-and-forget calls to the message sending interface for broadcasts, however the websocket library doesn't support that. They have their own broadcast function to work around that, but it wouldn't support the complex filtering that we do for game visibility. Plus I have big concerns about performance. IMO it's easier and safer to write a separate bridge application to handle websockets in Rust instead and just convert the websocket messages into our normal protocol that the lobby server can already handle reliably.

p4block commented 1 year ago

My only comment is that, yes, we will firewall it, but the code is supposed to reject non-PROXY calls anyway (and it does!)