Ich habe gerade bemerkt, dass die IP-Adressen vieler Mitglieder in meinem Forum als 172.17.0.1 gespeichert werden. Ich betreibe keinen Reverse-Proxy oder ähnliches – zwischen euch und Discourses Docker-Container ist nichts. Habt ihr eine Idee?
Nutzen Sie Cloudflare oder etwas Ähnliches?
Nur für DNS (Grau-Modus). (Technisch gesehen habe ich meiner Meinung nach den Orange-Modus für www.intfiction.org, aber er wird auf die Apex-Domain intfiction.org umgeleitet, bevor er meinen Server erreicht.) In meiner app.yml habe ich Folgendes, obwohl ich nicht dachte, dass einer der beiden Teile relevant wäre:
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;
}
Ist das nicht nur relevant, wenn vor meinem Server ein Proxy steht?
Ich habe das gleiche Problem, nachdem ich mein Discourse auf einen neuen Server migriert habe und mich entschieden habe, Cloudflare NICHT zu verwenden.
Ich habe Discourse komplett neu installiert und anschließend mein Backup wiederhergestellt.
Ich habe die Cloudflare-Vorlage-Option aus app.yml nie wieder hinzugefügt.
Ich habe auch versucht, den Code aus dem anderen Thread hinzuzufügen:
- 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, aber das Problem besteht weiterhin:
Alle IPv6-Benutzer zeigen ihre letzte IP als 172.17.0.1 an.
IPv4-Benutzer-Adressen werden korrekt angezeigt.
Auf diesem Server wird kein Reverse-Proxy oder ähnliches verwendet – nur die standardmäßige Discourse-Installation, wie in den Dokumenten beschrieben, die den Verkehr auf Port 80/443 bedient.
Ich glaube, ich weiß, warum das passiert.
Für IPv4 fügt Docker Firewall-Regeln in iptables ein, um das NAT von der exponierten Host-Adresse/dem exponierten Host-Port zum Container-Host/Port umzukehren. Dadurch kann der Container die ursprüngliche Quelladresse sehen.
Für IPv6 verwendet Docker einen Userland-Proxy (docker-proxy), der einfach von einem Port zum anderen weiterleitet. Dadurch sieht der Container die Quelladresse als localhost. Dies ist kein HTTP-fähiger Proxy, sondern lediglich eine Portweiterleitung, sodass er keine X-Forwarded-For-Header einfügen kann.
Das Docker-Kernprojekt hat keine Unterstützung für NAT auf IPv6 hinzugefügt, entweder weil sie IPv6-NAT für unangenehm halten oder weil sie es einfach noch nicht umgesetzt haben.
Sie können dies jedoch beheben, indem Sie IPv6 für Docker aktivieren und dann einen Container ausführen, der automatisch die richtigen IPv6-NAT-Regeln einfügt.
Eine Anleitung zur Einrichtung finden Sie unter https://medium.com/@skleeschulte/how-to-enable-ipv6-for-docker-containers-on-ubuntu-18-04-c68394a219a2.
TLDR: Stellen Sie sicher, dass IPv6 in Ihren Containern funktioniert, und führen Sie dann GitHub - robbertkl/docker-ipv6nat: Extend Docker with IPv6 NAT, similar to IPv4 · GitHub aus.
Muss dies innerhalb der App/des Docker-Containers, extern oder beides geändert werden? Ich gehe von beidem aus, aber das klingt nach hochrangigen Admin-Aufgaben. Falls bestätigt, wäre ein leicht verständlicher Leitfaden zur Aktivierung von IPv6 für Discourse (Docker) sehr willkommen.
Ich werde später versuchen, dies auf meiner Website umzusetzen und meine Schritte dokumentieren. Ich bin keineswegs ein Docker-Experte, aber ich denke, es sollte nicht zu schwierig sein.
Leider war dies aufgrund meiner begrenzten Docker-Kenntnisse schwieriger als erwartet. Ich experimentiere derzeit damit, Discourse einfach über einen auf dem Heimserver laufenden Nginx zu proxyen, um diese Einschränkung zu umgehen. Falls alles andere scheitert, werde ich wieder Cloudflare nutzen, aber ich möchte mich für einen funktionsfähigen Standort lieber nicht auf sie verlassen.
Eine kurze Anmerkung für alle Interessierten: Discourse hinter nginx zu stellen, ist die einfachste Lösung für dieses Problem. Verwende den Link in den Standardkommentaren der app.yml, um Discourse auf einem Socket einzurichten. Ein zusätzlicher Vorteil für mich ist die Möglichkeit, eine benutzerdefinierte Fehlerseite während Neuaufbauten anzuzeigen.