登録情報および最終IPの不一致・欠落

Discourse インストール環境を数年間運用していますが、現在は最新の Docker イメージを使用し、最新バージョン(2.4.0beta2)で、パブリック IP アドレス上でプロキシや他の中間機器なし、Let’s Encrypt 証明書で動作しています。

ユーザー登録時の IP アドレスと最終 IP アドレスの表示が、完璧に機能することもあれば、機能しないこともあります。その理由には一貫性が見当たりません。例えば、7 時間前に作成されたユーザーには、意味のないアドレスが表示されています。

一方、17 時間前に作成された別のユーザーは正常に表示されています。

このように、一部のユーザーでは問題ないのに、他のユーザーでは機能しないという状況が続いています。何か原因がわかる方はいますか?

今確認して気づいたのですが、これらのユーザーが IPv6 経由で接続している可能性があります。これらのフィールドに IPv6 アドレスを見たことがないからです。Discourse は IPv6 を認識していないのでしょうか?それとも Docker プロキシが関連情報を透過的に通過させていないのでしょうか?あるいは他の要因でしょうか?

Discourse は確かに対応していますが、サーバーと、その手前にある他の構成要素を適切に設定して IPv6 が機能するようにする必要があります。

IPv6 は非常に機能的で、推奨される Docker イメージを Web とデータテンプレートでセットアップしています。その前に配置するものは何もありません。調整すべき点はありますか?

なお、コンテナの yml ファイルは数年間使用されていますが、最新のテンプレートを含んでおり、イメージ自体も頻繁に再構築されています。この間に何か変更があった可能性がありますか?

デフォルトの Docker 設定で運用している他のユーザーも同様の問題を抱えているようです。

https://meta.discourse.org/t/why-are-my-301-redirects-not-working-ipv6-users-also-show-as-localhost/80442/9

断定は難しいです。私は直近の約8人の新規ユーザーが talk.commonmark.org にサインアップした際の利用状況を監査しました。これは非常に標準的なデフォルトインストールであり、すべてのユーザーの「最後のIP」と「登録IP」が有効なIPv4アドレスでした(場合によっては、これら2つが異なることもありました)。

SSOやその他の特殊な経路を通じてユーザーアカウントが作成された場合、そこに表示されるIPに影響を与える可能性があります。あなたが言及しているこれらのユーザーは、すべてDiscourseの標準的な新規ユーザー登録ダイアログを通じた通常のサインアップでしょうか?

それらのアドレスのいずれかが IPv6 でしたか?

いいえ、どれもそうではありませんでしたが、この共同設置ホストがIPv6に対応しているかどうかはわかりません。

であれば、IPv6 で接続してくるユーザーに対して localhost が表示されてしまうという問題はないはずです。ただし、問題が存在しないという意味ではありません。

公式の Discourse ホスティングでは少なくともこの問題は発生しておらず、そこは IPv6 に対応しています。また、ランダムなコロケーションホストでのバニラインストールでも問題は見当たりません。他に何と言おうか分かりませんが、あなたが私の非常に重要な質問に答えていないこと以外には。

ああ、はい、それらは通常の登録で、SSO や関連アカウントは含まれていません。

あなたのホスティング環境では動作しているとは思います。ただ、多くのユーザーが使用する「標準的な」Docker 設定は使っていないのではないでしょうか?つまり、プロキシが適切なヘッダーを設定するなどすれば、動作させることは可能だとは確信していますが、問題はそのデフォルト設定がそれをやっているかどうか、そしてそうでない場合、それを可能にできるかどうかです。

あなたの app.yml に、nginx が IPv6 アドレスを認識し、クライアントアドレスを透過的に渡すように指示する部分を少し追加する必要があると、私はかなり確信しています。ただし、自分自身でそれをどうやって行うかはまだ見つけていません。リバースプロキシの運用に関するトピックには IPv6 の例があり、ヒントが得られます。

これは私が解決しようとしている課題の一つですが、そのリストは結構長いです。私は最終的に IPv6 を無効にしました。おそらくこの問題が原因だったのでしょうが、IPv6 に関する他の無知さによるものかもしれません。

(Jeff さん、IPv6 のブロックをルーティング可能にすることはできますが、それをリクエストして、その後ホストをそれを使用するように設定する必要があります。)

Meta は標準的な Docker インストールと外部のリバースプロキシを組み合わせたもので、IPv6 のサポートも非常に優れています。

あなたの discourse.conf に、IPv6 アドレスで set_real_ip を設定するセクションはありますか?以下のようなものです:

    - replace:
        filename: /etc/nginx/conf.d/discourse.conf
        from: "types {"
        to: |
          set_real_ip_from 192.168.1.0/24;
          set_real_ip_from 172.18.0.0/24;
          set_real_ip_from 172.17.0.0/24;
          set_real_ip_from <SOME_IP_V6_ADDRESS_THING_HERE?>
          real_ip_recursive on;
          real_ip_header X-Forwarded-For;
          types {

外部リバースプロキシが鍵だと思います。Docker コンテナ内だけでは、この問題は全く解決できないか、少なくとも容易には解決できないでしょう。

私は現在、Discourse の Docker を Unix ソケットでリッスンさせ、同じマシン上の Docker 外で Caddy を前面に配置することで解決しました。Caddy の設定は非常に簡単で、Let’s Encrypt も含まれており、IPv6 でも期待通りに動作するようになりました。

forum.example.com {
  proxy / unix:/var/discourse/shared/web-only/nginx.http.sock {
    transparent
    websocket
  }
}