Ho appena notato che gli indirizzi IP di molti membri del mio forum vengono memorizzati come 172.17.0.1. Non sto utilizzando un reverse proxy o altro: non c’è nulla tra te e Docker di Discourse. Avete qualche idea?
Stai usando CloudFlare o qualcosa di simile?
Solo per DNS (modalità grigia). (Tecnicamente, penso di avere la modalità arancione per www.intfiction.org, ma verrà reindirizzata all’apice intfiction.org prima di raggiungere il mio server.) Nel mio file app.yml ho quanto segue, anche se non pensavo che nessuna delle due parti fosse rilevante:
after_web_config:
- replace:
filename: /etc/nginx/nginx.conf
from: /sendfile.+on;/
to: |
server_names_hash_bucket_size 64;
sendfile on;
- file:
path: /etc/nginx/conf.d/discourse_redirect_1.conf
contents: |
server {
listen 80;
server_name www.intfiction.org;
return 301 $scheme://intfiction.org$request_uri;
}
Non sarà rilevante solo se c’è un proxy davanti al mio server?
Anche io sto riscontrando questo problema, dopo aver migrato il mio Discourse su un nuovo server e deciso di NON utilizzare Cloudflare.
Ho reinstallato Discourse da zero e poi ripristinato il mio backup.
Non ho mai riaggiunto l’opzione del template di Cloudflare da app.yml.
Ho anche provato ad aggiungere il codice dall’altro thread:
- replace:
filename: /etc/nginx/conf.d/discourse.conf
from: "types {"
to: |
set_real_ip_from 10.0.0.0/24;
set_real_ip_from 172.17.0.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
types {
in app.yml, ma il problema persiste:
Tutti gli utenti IPv6 mostrano il loro ultimo IP come 172.17.0.1.
Gli indirizzi degli utenti IPv4 vengono visualizzati correttamente.
Non è in uso alcun reverse proxy o altro su questo server: solo l’installazione standard di Discourse come descritto nella documentazione, che gestisce il traffico sulle porte 80/443.
Penso di sapere perché sta succedendo.
Per IPv4, Docker inserisce regole del firewall in iptables per eseguire il reverse NAT dall’indirizzo/porta esposta dell’host alla porta/indirizzo del contenitore. Questo permette al contenitore di vedere l’indirizzo sorgente originale.
Per IPv6, Docker utilizza un proxy in userland (docker-proxy) che si limita a inoltrare da una porta all’altra. Questo fa sì che il contenitore veda l’indirizzo sorgente come localhost. Non si tratta di un proxy consapevole di HTTP, ma di un semplice inoltro di porte, quindi non è in grado di inserire gli header X-Forwarded-For.
Il progetto Docker principale non ha aggiunto il supporto per il NAT su IPv6, sia perché ritengono che il NAT IPv6 sia poco elegante, sia perché non hanno ancora avuto modo di implementarlo.
Tuttavia, puoi risolvere il problema abilitando IPv6 per Docker e poi eseguendo un contenitore che inserisce automaticamente le regole NAT IPv6 corrette.
Consulta https://medium.com/@skleeschulte/how-to-enable-ipv6-for-docker-containers-on-ubuntu-18-04-c68394a219a2 per una guida su come configurarlo.
TLDR: Assicurati che IPv6 funzioni nei tuoi contenitori e poi esegui GitHub - robbertkl/docker-ipv6nat: Extend Docker with IPv6 NAT, similar to IPv4 · GitHub
Questa è una modifica che deve essere effettuata all’interno dell’app/contenitore Docker, esternamente o in entrambi i casi? Immagino entrambi… ma sembra una questione amministrativa di alto livello. Se confermato, sarebbe molto apprezzata una guida semplice da seguire su come abilitare IPv6 per Discourse (Docker).
Proverò a implementarlo sul mio sito più tardi e cercherò di documentare i passaggi. Non sono assolutamente un esperto di Docker, ma penso che non dovrebbe essere troppo difficile.
Purtroppo questo si è rivelato più complicato del previsto a causa delle mie conoscenze limitate su Docker. Sto attualmente sperimentando il semplice proxy di Discourse tramite nginx in esecuzione sulla mia rete domestica per aggirare questa limitazione. Se tutto il resto fallisce, tornerò a utilizzare Cloudflare, ma preferirei non dipendere da loro per un sito funzionante.
Una rapida nota a chiunque sia interessato: mettere Discourse dietro nginx è la soluzione più semplice a questo problema. Usa il link nei commenti predefiniti di app.yml per configurare Discourse su una socket. Un vantaggio aggiuntivo per me è stata la possibilità di impostare una pagina di errore personalizzata da visualizzare durante le ricostruzioni.