Je viens de remarquer que les adresses IP de nombreux membres de mon forum sont enregistrées sous la forme 172.17.0.1. Je n’utilise pas de proxy inverse ni rien de tel — il n’y a rien entre vous et le Docker de Discourse. Des idées ?
1 « J'aime »
Utilisez-vous CloudFlare ou quelque chose de similaire ?
Uniquement pour le DNS (mode gris). (Techniquement, je pense avoir le mode orange pour www.intfiction.org, mais il sera redirigé vers le domaine racine intfiction.org avant d’atteindre mon serveur.) Voici ce que j’ai dans mon app.yml, bien que je ne pensais pas que l’une ou l’autre partie soit pertinente :
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;
}
1 « J'aime »
Cela ne sera-t-il pertinent que s’il y a un proxy devant mon serveur ?
Je rencontre également ce problème après avoir migré mon Discourse vers un nouveau serveur et décidé de NE PAS utiliser Cloudflare.
J’ai réinstallé Discourse à partir de zéro, puis restauré ma sauvegarde.
Je n’ai jamais réajouté l’option du modèle Cloudflare dans app.yml.
J’ai également essayé d’ajouter le code mentionné dans l’autre fil de discussion :
- 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 {
dans app.yml, mais le problème persiste :
Tous les utilisateurs IPv6 affichent leur dernière adresse IP comme étant 172.17.0.1.
Les adresses des utilisateurs IPv4 sont affichées correctement.
Il n’y a pas de proxy inverse ni d’autre élément en cours d’utilisation sur ce serveur — juste une installation standard de Discourse telle que décrite dans la documentation, servant le trafic sur les ports 80/443.
3 « J'aime »
Je pense savoir pourquoi cela se produit.
Pour IPv4, Docker insère des règles de pare-feu dans iptables pour effectuer un NAT inverse de l’adresse/port exposé de l’hôte vers l’adresse/port du conteneur. Cela permet au conteneur de voir l’adresse source originale.
Pour IPv6, Docker utilise un proxy en mode utilisateur (docker-proxy) qui se contente de transférer le trafic d’un port à l’autre. Cela fait que le conteneur voit l’adresse source comme étant localhost. Ce n’est pas un proxy conscient du protocole HTTP, mais simplement un transfert de port, il est donc incapable d’insérer les en-têtes X-Forwarded-For.
Le projet Docker principal n’a pas ajouté de support pour effectuer du NAT sur IPv6, soit parce qu’ils considèrent que le NAT IPv6 est peu élégant, soit parce qu’ils n’ont pas encore eu le temps de l’implémenter.
Cependant, vous pouvez corriger cela en activant IPv6 pour Docker, puis en exécutant un conteneur qui insère automatiquement les règles de NAT IPv6 correctes.
Consultez https://medium.com/@skleeschulte/how-to-enable-ipv6-for-docker-containers-on-ubuntu-18-04-c68394a219a2 pour un guide sur la configuration de cette solution.
TLDR : Assurez-vous que IPv6 fonctionne dans vos conteneurs, puis exécutez GitHub - robbertkl/docker-ipv6nat: Extend Docker with IPv6 NAT, similar to IPv4 · GitHub
9 « J'aime »
Est-ce quelque chose qui doit être modifié dans l’application/le conteneur Docker, de manière externe ou les deux ? Je suppose que les deux… mais cela ressemble à des tâches administratives de haut niveau. Si cela est confirmé, un guide facile à suivre sur la façon d’activer Discourse (Docker) pour IPv6 serait grandement apprécié.
2 « J'aime »
Je vais essayer de mettre cela en œuvre sur mon site plus tard et tenter de documenter mes étapes. Je ne suis absolument pas un expert de Docker, mais je pense que cela ne devrait pas être trop difficile.
2 « J'aime »
Malheureusement, cela s’est avéré plus complexe que prévu en raison de mes connaissances limitées en Docker. J’expérimente actuellement une solution consistant à faire passer Discourse par un proxy nginx installé sur le serveur principal pour contourner cette limitation. Si tout échoue, je reviendrai à l’utilisation de Cloudflare, mais je préfère ne pas dépendre d’eux pour un site fonctionnel.
1 « J'aime »
Une petite note à toute personne intéressée : Placer Discourse derrière nginx est la solution la plus simple à ce problème. Utilisez le lien présent dans les commentaires du fichier app.yml par défaut pour configurer Discourse sur un socket. Pour ma part, l’avantage supplémentaire a été la possibilité de configurer une page d’erreur personnalisée qui s’affiche pendant les reconstructions.
4 « J'aime »