の更新後、すべてのユーザーの最終使用アドレスが Docker のゲートウェイ(例:172.17.0.1)に変更されました。
私の使用しているアーキテクチャは以下の通りです。
Cloudflare → VPS Nginx → Discourse Docker Nginx → Discourse
の更新後、すべてのユーザーの最終使用アドレスが Docker のゲートウェイ(例:172.17.0.1)に変更されました。
私の使用しているアーキテクチャは以下の通りです。
Cloudflare → VPS Nginx → Discourse Docker Nginx → Discourse
あなたと同じような設定をしています。ユーザーのIPアドレスを渡すために、私のホストのnginx設定に以下を追加しました:
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;
}
こんにちは @CLOUD_PHT - Meta へようこそ ![]()
同じマシン構成で複数のウェブサイト(WordPress と Discourse など)を運営されていると推測します。
問題は、Docker の内部ネットワーク(ポートマッピング)を介してトラフィックをルーティングしていることです。これにより、すべての着信リクエストが Docker ゲートウェイ IP(172.17.0.1)として認識されます。内部の Nginx が 172.17.0.1 を Cloudflare の IP として認識しないため、セキュリティ上の理由から CF-Connecting-IP ヘッダーが破棄されます。
この問題を解決するには、Unix ソケットを使用するように設定を変更する必要があります。これにより、外部の Nginx が Docker のネットワークが IP アドレスを壊すことなく、トラフィック(およびヘッダー)を Discourse に直接渡すことができます。
この公式ガイドに従い、再構築する際に app.yml ファイルに cloudflare.template.yml を保持するようにしてください。
そのコミットは、あなたが依存していた設定エラーを修正しましたが、同時にエンドユーザーがそのヘッダーを設定してIPアドレスをスプーフィングすることを可能にしたかもしれません。
他の何ものもあなたのコンテナにアクセスできないと確信している場合、ソケットを使用しないより簡単な方法があります。私はちょうど書きましたこの方法についてのガイドです。
@CLOUD_PHTのセットアップの場合、コンテナ定義にこれを追加する必要があります(runセクションが既に存在する場合は、これらのディレクティブを追加し、そうでなければrunセクションを追加します):
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;
また、以下も必要になるかもしれません:
- file:
# ホストとCloudFlareから少なくとも2つのエントリがあるため、再帰を有効にする必要があります
path: /etc/nginx/conf.d/outlets/server/real-ip-recursive.conf
chmod: 644
contents: |
real_ip_recursive on;
サーバー上で実行されているnginxが、エンドユーザーの実際のIPを決定するためにCloudflareのヘッダーを処理しているか(推奨)、それとも単にそれ自体のものを追加しているかによって異なります。詳細は https://meta.discourse.org/t/handling-the-chain-of-trust-of-the-end-users-real-ip/406372#p-2001772-more-than-one-proxy-7 を参照してください。
他の読者: このディレクティブには注意してください
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;
これはすべてのセットアップに適しているわけではありません。このIPからのDiscourseコンテナへの接続がすべて信頼できる場合にのみ、これを行ってください。
具体的には、IPv6セットアップで知られている問題は、サーバーへのIPv6接続がdockerによってIPv4経由で転送されることです。その方法により、すべての接続がホストのdocker0 IPアドレスから来ているように見えます。上記のディレクティブをセットアップに適用すると、IPv6で接続しているすべてのユーザーが自由にIPアドレスをスプーフィングできるようになります。