Wie erhalte ich die Benutzer-IP nach dem Commit b4a3389-Update?

[CLOUD_PHT]

Nach dem Update

FIX: nginx sample configuration should be setting x-f-f to the end user IP

wurde die letzte verwendete IP-Adresse aller Benutzer zur Docker-Gateway-Adresse, z. B. 172.17.0.1.

Mein Setup sieht wie folgt aus:

Cloudflare → VPS Nginx → Discourse Docker Nginx → Discourse

[iamntz (Ionuț Staicu)]

Ich habe eine ähnliche Einrichtung wie du. Hier ist, was ich meiner Host-Nginx-Konfiguration hinzugefügt habe, damit die IP-Adresse des Benutzers weitergeleitet wird:

location / {
  set_real_ip_from 103.21.244.0/22;
  set_real_ip_from 103.22.200.0/22;
  set_real_ip_from 103.31.4.0/22;
  set_real_ip_from 104.16.0.0/13;
  set_real_ip_from 104.24.0.0/14;
  set_real_ip_from 108.162.192.0/18;
  set_real_ip_from 131.0.72.0/22;
  set_real_ip_from 141.101.64.0/18;
  set_real_ip_from 162.158.0.0/15;
  set_real_ip_from 172.64.0.0/13;
  set_real_ip_from 173.245.48.0/20;
  set_real_ip_from 188.114.96.0/20;
  set_real_ip_from 190.93.240.0/20;
  set_real_ip_from 197.234.240.0/22;
  set_real_ip_from 198.41.128.0/17;
  set_real_ip_from 2400:cb00::/32;
  set_real_ip_from 2405:8100::/32;
  set_real_ip_from 2405:b500::/32;
  set_real_ip_from 2606:4700::/32;
  set_real_ip_from 2803:f800::/32;
  set_real_ip_from 2a06:98c0::/29;
  set_real_ip_from 2c0f:f248::/32;

  real_ip_header X-Forwarded-For;

  proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:;

  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header Host $http_host;
  proxy_set_header X-Forwarded-Proto $scheme;

  proxy_http_version 1.1;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto https;
}

• Zusätzliche Informationen: Restoring original visitor IPs · Cloudflare Support docs
• Die IP-Adressen stammen von hier: IP Ranges | Cloudflare

[Lilly (Lillian)]

Hallo @CLOUD_PHT – willkommen bei Meta

Ich nehme an, du betreibst mehrere Websites auf derselben Serverkonfiguration? (z. B. eine WordPress-Seite + Discourse)

Das Problem ist, dass du den Traffic über das interne Docker-Netzwerk (Port-Mapping) leitest, wodurch alle eingehenden Anfragen als Docker-Gateway-IP (172.17.0.1) maskiert werden. Da der interne Nginx 172.17.0.1 nicht als Cloudflare-IP erkennt, wird aus Sicherheitsgründen der CF-Connecting-IP-Header verworfen.

Um dies zu beheben, musst du deine Konfiguration auf einen Unix-Socket umstellen – dies ermöglicht es deinem äußeren Nginx, den Traffic (und die Header) direkt an Discourse weiterzuleiten, ohne dass das Docker-Netzwerk die IP-Adressen verfälscht.

Folge dieser offiziellen Anleitung und stelle sicher, dass du cloudflare.template.yml in deiner app.yml-Datei behältst, wenn du neu aufbaust.

Andere Webseiten auf derselben Maschine wie Discourse ausführen

@pfaffman hat dies am 2022.02.24 stark bearbeitet. Gebt mir die Schuld, wenn es kaputt ist. Wenn Sie andere Websites auf demselben Rechner wie Discourse ausführen möchten, müssen Sie einen zusätzlichen NGINX- oder HAProxy-Proxy vor dem Docker-Container einrichten. HINWEIS: Dies ist für fortgeschrittene Administratoren Diese Anleitung setzt voraus, dass Discourse bereits funktioniert – wenn dies nicht der Fall ist, kann es schwierig sein festzustellen, ob die Konfiguration funktioniert oder nic…

[supermathie (Michael Brown)]

Dieser Commit hat einen Konfigurationsfehler behoben, auf den du dich verlassen hast, aber der es möglicherweise auch jedem Endbenutzer ermöglicht hätte, seine IP-Adresse zu fälschen, indem er diesen Header gesetzt hat.

@Lilly

um dies zu beheben, musst du deine Einrichtung so ändern, dass ein Unix-Socket verwendet wird

Es gibt tatsächlich einen einfacheren Weg, der keinen Socket erfordert – ich habe gerade einen Leitfaden geschrieben, wie man das macht.

@CLOUD_PHT

Cloudflare → VPS Nginx → Discourse Docker Nginx → Discourse

@Lilly

der interne nginx erkennt 172.17.0.1 nicht

Für deine Einrichtung @CLOUD_PHT solltest du Folgendes zu deiner Container-Definition hinzufügen (wenn bereits ein run-Abschnitt existiert, füge diese Direktiven dort hinzu, sonst füge den run-Abschnitt hinzu):

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;

Möglicherweise benötigst du auch Folgendes:

  - file:
      # wir müssen rekursiv aktivieren, da wir mindestens zwei Einträge haben werden; einen vom Host, einen von CloudFlare
      path: /etc/nginx/conf.d/outlets/server/real-ip-recursive.conf
      chmod: 644
      contents: |
        real_ip_recursive on;

je nachdem, ob der auf deinem Server laufende nginx den Cloudflare-Header selbst verarbeitet, um die echte IP des Endbenutzers zu bestimmen (dies wird empfohlen), oder einfach nur seinen eigenen Header darüber legt. Siehe https://meta.discourse.org/t/handling-the-chain-of-trust-of-the-end-users-real-ip/406372#p-2001772-more-than-one-proxy-7 für weitere Details.

---

Andere Leser: Seid euch bewusst, dass diese Direktive

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;

nicht für alle Einrichtungsarten geeignet ist. Mache dies nur, wenn alle Verbindungen zum Discourse-Container von dieser IP vertrauenswürdig sind.

Insbesondere ist ein bekanntes Problem bei IPv6-Einrichtungen, dass IPv6-Verbindungen zum Server von Docker über IPv4 weitergeleitet werden – die Art und Weise, wie dies geschieht, lässt alle Verbindungen so aussehen, als kämen sie von der docker0-IP-Adresse des Hosts. Wenn du die obige Direktive auf deine Einrichtung anwendest, ermöglicht es allen Benutzern, die über IPv6 verbinden, ihre IP-Adresse nach Belieben zu fälschen.