Quellcode commit ha corretto un errore di configurazione su cui ti affidavi, ma che potrebbe anche aver consentito a qualsiasi utente finale di falsificare il proprio indirizzo IP impostando quella intestazione.
In realtà esiste un metodo più semplice che non richiede l’uso di una socket: ho appena scritto una guida su come procedere.
Per la tua configurazione @CLOUD_PHT dovresti aggiungere quanto segue alla definizione del container (se esiste già una sezione run, aggiungi queste direttive ad essa, altrimenti aggiungi la sezione run):
run:
- file:
path: /etc/nginx/conf.d/outlets/server/real-ip-header.conf
chmod: 644
contents: |
real_ip_header x-forwarded-for;
- file:
path: /etc/nginx/conf.d/outlets/server/set-real-ip-from-host.conf
chmod: 644
contents: |
set_real_ip_from 172.17.0.1;
Potrebbe essere necessario anche quanto segue:
- file:
# dobbiamo abilitare la ricorsività poiché avremo almeno due voci: una dall'host, una da CloudFlare
path: /etc/nginx/conf.d/outlets/server/real-ip-recursive.conf
chmod: 644
contents: |
real_ip_recursive on;
Dipende dal fatto che nginx in esecuzione sul tuo server elabori l’intestazione Cloudflare per determinare l’indirizzo IP reale dell’utente finale (come suggerito) o aggiunga semplicemente la propria sopra.
Altri lettori: tieni presente che questa direttiva
run:
- file:
path: /etc/nginx/conf.d/outlets/server/set-real-ip-from-host.conf
chmod: 644
contents: |
set_real_ip_from 172.17.0.1;
non è adatta a tutte le configurazioni. Applicala solo se tutte le connessioni al container Discourse da questo indirizzo IP sono affidabili.
In particolare, un problema noto con le configurazioni IPv6 è che le connessioni IPv6 al server sono inoltate da docker tramite IPv4: il modo in cui viene fatto fa sì che tutte le connessioni sembrino provenire dall’indirizzo IP docker0 dell’host. Se applichi la direttiva sopra alla tua configurazione, consentirai a tutti gli utenti che si connettono tramite IPv6 di falsificare il proprio indirizzo IP a piacimento.