☰

アップデート：

tag-icon • tag-icon reverse-proxy
アップデート：

私はマトリックスホームサーバーとDjangoウェブアプリをそれぞれVMとVMにインストールしています192.168.81。192.168.83ホームサーバーはマトリックス-docker-ansible-deploynginx上で動作します。SSL証明書の取得と更新はトラエフィクと暗号化しましょう。

Web アプリは独自の Let's Encrypt 証明書を使用します。 個別に動作させることはできますが、同じ 80 および 443 ポートで連携して動作させることが困難です。

次のように、Web アプリ側でリバース プロキシを設定して、そのドメインからのトラフィックを転送します。

        SSLEngine On
        SSLCertificateFile /etc/letsencrypt/live/mysite.org/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/mysite.org/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/mysite.org/fullchain.pem

        # Enable SSL Proxy Engine
        SSLProxyEngine On
        ProxyPass / https://192.168.1.83/
        ProxyPassReverse / https://192.168.1.83/

次のような結果になります:

[Wed Jan 17 07:13:21.567813 2024] [core:notice] [pid 33994:tid 125031783462784] AH00094: Command line: '/usr/sbin/apache2'
[Wed Jan 17 07:15:23.409061 2024] [proxy:error] [pid 34272:tid 125031640188608] (20014)Internal error (specific information not available): [client 192.168.1.85:44054] AH01084: pass request body failed to 192.168.1.83:443 (192.168.1.83)
[Wed Jan 17 07:15:23.409180 2024] [proxy:error] [pid 34272:tid 125031640188608] [client 192.168.1.85:44054] AH00898: Error during SSL Handshake with remote server returned by /
[Wed Jan 17 07:15:23.409209 2024] [proxy_http:error] [pid 34272:tid 125031640188608] [client 192.168.1.85:44054] AH01097: pass request body failed to 192.168.1.83:443 (192.168.1.83) from 192.168.1.85 ()
[Wed Jan 17 07:15:23.715825 2024] [proxy:error] [pid 34273:tid 125031648581312] (20014)Internal error (specific information not available): [client 192.168.1.85:44070] AH01084: pass request body failed to 192.168.1.83:443 (192.168.1.83), referer: https://192.168.1.83/
[Wed Jan 17 07:15:23.715945 2024] [proxy:error] [pid 34273:tid 125031648581312] [client 192.168.1.85:44070] AH00898: Error during SSL Handshake with remote server returned by /favicon.ico, referer: https://192.168.1.83/
[Wed Jan 17 07:15:23.715970 2024] [proxy_http:error] [pid 34273:tid 125031648581312] [client 192.168.1.85:44070] AH01097: pass request body failed to 192.168.1.83:443 (192.168.1.83) from 192.168.1.85 (), referer: https://192.168.1.83/

アップデート：

2つのサーバーを同じポートで実行すると、SSL証明書がほぼ確実に台無しになるため（同じ証明書を共有し、別のサーバーでリバースプロキシを使用して、別のドメインからのトラフィックをそれぞれの内部サーバーにリダイレクトする場合を除く）、80と443以外のポートを使用するWeb アプリをホストします。

これをどうやってやればいいのでしょうか?

答え1

これは、バックエンドによって提示された SSL/TLS 証明書 192.168.1.83:443 が有効ではないためです。有効な証明書には常にドメイン名が必要です。

私はあなたが開く場所を信じていますhttps://192.168.1.83/ブラウザでは (もちろん IP 192.168.1.83 にアクセスできる場合)、「接続が安全ではありません」という警告が表示されます。

選択肢は次のとおりです（おおよそ難易度順）。

  1. バックエンド ネットワークを盲目的に信頼し、フォワード プロキシでのみ SSL を使用し、プレーン http 経由でバックエンドに接続します。Apache フォワード プロキシがこれらの VM と同じマシンで実行されており、フォワード プロキシと VM の両方を制御している場合は、これが私のやり方です。
  2. バックエンドネットワークを信頼せず、フロントエンドとバックエンドの両方で暗号化する場合は、
    • 証明書に有効なドメイン名を使用してバックエンドに接続し（ホストファイルでドメインのIPを構成する可能性があります）、証明書自体が有効であり、更新されていることを確認します。
    • Apache設定でこの接続の証明書の信頼を明示的に設定します
    • バックエンド サービス用に独自の CA を設定し、フォワード プロキシで信頼できるものとして構成します (ただし、独自の CA を扱うと、簡単に危険ゾーンに陥ってしまうことに注意してください)。
    • 証明書を適切に検証せずに (オプションを無効にするなど)、フォワード プロキシを SSL 経由で接続するように構成することはお勧めしませんSSLProxy*。代わりに、バックエンド ネットワークが信頼されている場合はオプション 1 を選択し、信頼されていない場合は上記の 3 つのうちのいずれかを選択します。
  3. バックエンドのみで暗号化し、Apache フォワード プロキシの代わりに SNI ロード バランシングを使用して、再暗号化せずに https トラフィックをバックエンドに転送します (私の意見では、オプション 1 よりも高度な設定であり、Apache がこのアプリケーションに適しているかどうかはわかりません)。

関連情報