新規インストールで502 Bad Gatewayが発生

リバースプロキシの背後にあるようですね。公式のインストール方法を使用しながら、いくつかのテンプレートとディスコースを処理するいくつかの異なる方法を見つけました。

すぐにガイドを作成します。他の誰かがそれを使用する必要がある場合、または私がそれを再度使用する必要がある場合のために LOL。

私のインストールでは letsencrypt SSL を使用していないため、小さな問題があります。送信されたメールのアクティベーションリンクには、https ではなく http が含まれていました。すべての http を https にリダイレクトするリダイレクトがありますが、すべてのリンクが http ではなく https になるように、バックエンドから https を強制したいと思います。

編集:見つけました

#SSLを強制する
DISCOURSE_FORCE_HTTPS: true

Eh… リバースプロキシを使用しているのに、なぜバックエンドにHTTPSを送信するのですか?

force https を設定すると、Discourse はすべての参照を https に強制します。

はい、しかしそれは「なぜ」という質問には答えていません。

接続を暗号化するためです。

WAN → リバースプロキシ = HTTPS
リバースプロキシ → バックエンド = HTTPS

これにより、万が一私のサーバー ルームにアクセスできる人がいても、イーサネットケーブルを接続して通信を簡単に傍受することはできません。通信は引き続き HTTPS であり、侵入者にとっては少し厄介になります。WAN HTTPS → リバースプロキシ HTTP → バックエンドではなく、HTTPS チェーンを完成させたいのです。

そうでなければ、それは単なる卵殻セキュリティになってしまいます。

たとえ10年以上知っている人であっても、ゼロトラストです。

公平ですが、プライベートネットワークに移動するほどの信頼がない場合、またはゲートキーパーとしてリバースプロキシを維持した後にセキュアなネットワークを構築できない場合は、どうなりますか。

万全のセキュリティ対策を施しています。

ほとんどの情報漏洩は内部から発生していることに気づいていませんか? この方法なら、サーバーのセキュリティが鉄壁であることを確認でき、唯一の脆弱性は人間だけです。そして、私の従業員はそのことを100%理解しています。

私のところにいる著名なクラウドユーザーの中には、万が一、私のサーバーセキュリティが鉄壁であるにもかかわらず、データが流出した場合、カメラをチェックして、誰がデータ漏洩の原因であるかを正確に特定することができます。

AWSも同様の方法で実施していると思います。サーバーがどれほど安全であっても、人間の脆弱性は常に最優先事項であるべきです。USBメモリ1本で全てが終わってしまうのですから。

なぜなら、そうしないと、例えば、httpsではなくhttpへのメールリンクを送信したり、httpsではなくhttpの画像へのリンクを送信したりするからです。Discourseがhttpsであることを認識できる場合、デフォルトで有効になります。Discourseはhttpリンクがあるとほとんど機能しないため、現時点でデフォルトになっていない理由はよくわかりません。

これは、リバースプロキシとDiscourse間の接続ではなく、Discourseが自身に作成するリンクに関するものです。

「いいね!」 2

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.