Skip to Content

Discourse

Die offizielle ProxyTracer-Integration für Discourse. Dieses Plugin bringt Enterprise-Level-IP-Intelligence in Ihre Community, erkennt automatisch bekannte VPNs, Proxys, Rechenzentren und Tor-Knoten und gibt Ihnen die Möglichkeit, diese an der Registrierung, der Anmeldung oder sogar dem Zugriff auf Ihr Discourse-Forum vollständig zu hindern.

Das ProxyTracer Plugin wird über dieses Github-Repository bereitgestellt.

Funktionen

  • Granulare Kontrolle, die es Administratoren ermöglicht, IP-Validierungen bei neuen Benutzerregistrierungen, bei der Authentifizierung bestehender Benutzer oder global für alle Seitenbesucher zu erzwingen.
  • Integriertes Redis-Caching speichert aktuelle IP-Adressauswertungen, was externe API-Aufrufe drastisch reduziert und null Latenz garantiert.
  • Im Falle eines API-Timeouts oder Netzwerkausfalls priorisiert das Plugin den Benutzerzugriff, um weitreichende Sperren zu vermeiden. Dieses Verhalten kann in den Optionen angepasst werden.
  • Integrierte Unterstützung für White-Listing per genauer IP oder CIDR-Subnetz.

Installation

  1. Greifen Sie über SSH auf Ihren Server zu und navigieren Sie zu Ihrem Discourse-Verzeichnis:
    cd /var/discourse
  2. Öffnen Sie die Konfigurationsdatei Ihres Containers zur Bearbeitung:
    nano containers/app.yml
  3. Suchen Sie den Abschnitt hooks und fügen Sie den Befehl zum Klonen des Repositorys direkt unter der docker_manager-Installation ein:
    hooks: after_code: - exec: cd: $home/plugins cmd: - git clone https://github.com/discourse/docker_manager.git - git clone https://github.com/proxytracer/discourse-proxytracer.git
  4. Speichern Sie die Konfigurationsdatei und erstellen Sie Ihren Discourse-Container neu, um das Plugin zu kompilieren:
    ./launcher rebuild app

Konfiguration:

  1. Holen Sie sich Ihren geheimen API-Schlüssel aus dem ProxyTracer Dashboard.
  2. Navigieren Sie zu Ihren administrativen Discourse-Einstellungen: Admin → Plugins → proxytracer.
  3. Fügen Sie Ihren API-Schlüssel in das Feld proxytracer_api_key ein.
  4. Konfigurieren Sie Ihre gewünschten Durchsetzungsaktionen durch Aktivieren von proxytracer_block_registrations und proxytracer_block_logins.
  5. Fügen Sie vertrauenswürdige interne IP-Adressen oder CIDR-Blöcke zur Einstellung proxytracer_ip_whitelist hinzu (eine pro Zeile).
  6. (Optional) Passen Sie die Werte für proxytracer_api_timeout_ms und proxytracer_cache_ttl_seconds an die Anforderungen Ihres Servers an.
  7. (Optional) Passen Sie die Blockierungsnachricht an, die blockierten Benutzern angezeigt wird. Sie können beispielsweise Anweisungen hinzufügen, wie diese sich an die Administration wenden können, falls sie der Meinung sind, dass die Sperre nicht gerechtfertigt ist und sie nicht über einen Proxy oder VPN auf die Seite zugreifen.

Settings Screenshot

Netzwerkkonfiguration: Cloudflare & Reverse-Proxys

Damit ProxyTracer effektiv funktioniert, muss die Discourse-Anwendung die wahre Client-IP-Adresse empfangen. Wenn Ihre Infrastruktur Cloudflare oder einen anderen Reverse-Proxy nutzt, protokolliert Discourse möglicherweise standardmäßig die IP-Adresse des Proxy-Knotens, was die Arbeit von ProxyTracer unzuverlässig macht.

Bitte befolgen Sie die unten stehenden Konfigurationsrichtlinien, die zur Architektur Ihres Servers passen, um eine genaue IP-Weiterleitung sicherzustellen.

Direkte Cloudflare-Integration (Standardinstallation)

Dies gilt, wenn Ihr Discourse-Server direkt mit dem Internet verbunden ist und Cloudflare ausschließlich für DNS und als Edge-Proxy nutzt. Bei diesem Standard-Setup müssen Sie Discourse so konfigurieren, dass es den Cloudflare-IP-Bereichen vertraut und die wahre Client-IP aus den eingehenden Headern extrahiert.

  1. Verbinden Sie sich über SSH mit Ihrem Server und bearbeiten Sie die Konfiguration Ihres Containers: nano /var/discourse/containers/app.yml
  2. Suchen Sie den Block templates: und hängen Sie das offizielle Cloudflare-Template templates/cloudflare.template.yml an:
    templates: - "templates/postgres.template.yml" - "templates/redis.template.yml" - "templates/web.template.yml" - "templates/web.ratelimited.template.yml" - "templates/cloudflare.template.yml"
  3. Speichern Sie die Datei und erstellen Sie den Discourse-Container neu, um die Änderungen anzuwenden: ./launcher rebuild app

Multi-Layer Proxy-Architektur (Cloudflare + Lokaler Reverse-Proxy)

Dies gilt, wenn Ihre Discourse-Instanz über ein lokales Server-Management-Panel oder einen Reverse-Proxy (z. B. CloudPanel, Nginx Proxy Manager, Traefik, Plesk) geleitet wird, der hinter Cloudflare sitzt. In einer mehrschichtigen (oder „doppelten“) Reverse-Proxy-Architektur schlägt die Standard-Discourse-Vorlage cloudflare.template.yml fehl, da der Datenverkehr von Ihrer lokalen Netzwerkschnittstelle und nicht direkt von Cloudflare an Discourse übergeben wird. Verwenden Sie in diesem Szenario nicht die Cloudflare-Vorlage.

Stattdessen müssen Sie Ihren lokalen Reverse-Proxy so konfigurieren, dass er die wahre Client-IP aus dem CF-Connecting-IP-Header extrahiert, jedoch nur für Datenverkehr, der von vertrauenswürdigen Cloudflare-IP-Adressen stammt. Das unüberprüfte Weiterleiten dieses Headers ohne Prüfung der Quelle ermöglicht es böswilligen Nutzern, Rate-Limits und Sperren durch das Fälschen ihrer IP-Adresse zu umgehen.

Nginx-Beispiel: Definieren Sie zunächst Cloudflares IP-Bereiche als vertrauenswürdige Proxys in der Konfiguration Ihres Serverblocks:
# IPv4-Cloudflare-IPs, siehe https://www.cloudflare.com/ips/ set_real_ip_from 173.245.48.0/20; 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 141.101.64.0/18; set_real_ip_from 108.162.192.0/18; set_real_ip_from 190.93.240.0/20; set_real_ip_from 188.114.96.0/20; set_real_ip_from 197.234.240.0/22; set_real_ip_from 198.41.128.0/17; set_real_ip_from 162.158.0.0/15; set_real_ip_from 104.16.0.0/13; set_real_ip_from 104.24.0.0/14; set_real_ip_from 172.64.0.0/13; set_real_ip_from 131.0.72.0/22; # IPv6-Cloudflare-IPs set_real_ip_from 2405:b500::/32; set_real_ip_from 2405:8100::/32; set_real_ip_from 2803:f800::/32; set_real_ip_from 2c0f:f248::/32; set_real_ip_from 2a06:98c0::/29; real_ip_header CF-Connecting-IP;

Suchen Sie als Nächstes Ihre location / oder @reverse_proxy Direktive. Aufgrund der obigen Konfiguration löst Nginx nun $remote_addr nur dann sicher in die wahre Client-IP auf, wenn die Anfrage tatsächlich Cloudflare passiert hat. Ändern Sie Ihre IP-Weiterleitungsheader wie folgt:

location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ... }

Speichern Sie die Konfiguration und laden Sie den Nginx-Dienst Ihres Hosts neu. Ein Discourse-Container-Rebuild ist für diesen Schritt nicht erforderlich.

Validierung und Tests

So stellen Sie sicher, dass Ihre Netzwerkkonfiguration die korrekten Daten erfolgreich an ProxyTracer weitergibt:

  1. Navigieren Sie zu Ihrem administrativen Discourse-Dashboard: Admin → Users.
  2. Überprüfen Sie die Spalten Registration IP oder Last IP auf aktuelle Aktivitäten.
    • Fehlerhaftes Setup: Wenn Sie Cloudflare-IPs (vollständige Liste siehe hier) oder lokale Netzwerk-IPs (z. B. 127.0.0.1, 172.x.x.x) bemerken, schlägt die IP-Weiterleitung fehl. ProxyTracer kann Ihre Website in diesem Zustand nicht schützen.
    • Korrektes Setup: Wenn Sie normale, eindeutige Residential-IP-Adressen sehen, ist Ihre Netzwerkarchitektur korrekt konfiguriert und ProxyTracer überwacht Ihren Traffic aktiv.

Notfallzugriff

💡
Ausgesperrt? Wenn Sie versehentlich Ihre eigene IP-Adresse bei der Konfiguration von ProxyTracer blockieren (z. B. wenn Sie derzeit mit einem VPN verbunden sind), können Sie den Zugriff durch Deaktivieren des Plugins per SSH wiederherstellen:
cd /var/discourse ./launcher enter app rails c SiteSetting.proxytracer_enabled = false exit exit

Lizenz

Dieses Plugin ist unter der GNU Affero General Public License v3.0 (AGPLv3) lizenziert.

Zuletzt aktualisiert am