リバースプロキシはホームサーバーのコンテナに対してTLSをどのように処理しますか？

リバースプロキシはホームサーバーコンテナのTLSを処理し、ブラウザの暗号化接続を受け入れ、要求されたホスト名の証明書を提示し、HTTPリクエストを復号し、一致するコンテナを選択し、そのサービスへの別のアップストリーム接続を作成します。

ブラウザからプロキシへの接続とプロキシからコンテナへの接続は異なるセキュリティ境界です。前者は通常、公開またはプライベートに信頼された証明書を使用し、後者は隔離されたHTTPネットワーク、別のHTTPS接続、またはバックエンドが秘密鍵を保持する場合はTLSパススルーを使います。

ブラウザのTLS接続はどこで終了しますか？

TLS終了では、リバースプロキシがクライアントTLSを終了します。ブラウザはプロキシエンドポイントを認証し、アプリケーションコンテナと直接ではなくプロキシと暗号化を交渉します。

したがってプロキシは証明書の秘密鍵を保持し、復号されたHTTPメソッド、ホスト名、パス、ヘッダー、クッキー、ボディを読み取れます。その可視性により、ルーティング、認証、フィルタリング、圧縮、キャッシュ、セキュリティヘッダーの追加が可能です。

終了（Termination）はバックエンドがパブリック証明書を所有することを意味しません。ブラウザの視点ではリバースプロキシがHTTPSサーバーであり、コンテナの視点ではプロキシが別のリクエストを行う新しいクライアントです。

1つのHTTPSポートが複数のコンテナにどう届くのですか？

パブリックDNS名はクライアントをリバースプロキシに誘導し、ホスト名が一致するコンテナルートを選択します。各ホスト名は独自の証明書とアップストリーム宛先を持ちつつ、ポート443を共有できます。

TLSハンドシェイク中、クライアントは通常、プロキシが一致する証明書を選択できるように意図されたサーバー名を提供します。復号後、HTTP Hostヘッダーと設定されたルートにより、リクエストがJellyfin、Home Assistant、Vaultwarden、または他のコンテナに送られるかが決まります。

デフォルトルートは、不明なホスト名を任意のダッシュボードに転送するのではなく拒否するべきです。エントリを集中管理しても、すべての内部サービスがパブリックプロキシを通じてアクセス可能になる必要はありません。

証明書はどのように発行および更新されますか？

リバースプロキシはACMEクライアントとして機能でき、DNSチャレンジは要求されたドメインの制御を証明する一時的なDNSレコードを作成して証明書更新を自動化します。

HTTPチャレンジはウェブエンドポイントを通じて制御を証明し、DNSチャレンジは各コンテナを直接公開せずに内部サービスやワイルドカード名の証明書を発行できます。検証方法は露出と資格情報の要件を変えます。

自動化により証明書の有効期限管理は手動のカレンダー作業からインフラの状態管理に移行します。また、プロキシのDNS APIトークン、ACMEアカウントデータ、証明書ストレージは狭い権限とバックアップが必要な機密資産になります。

プロキシとコンテナ間のトラフィックは暗号化されていますか？

上流は独立して設定されているため、上流リンクはHTTPまたはHTTPSを使用できます。公開TLSを終了しても内部接続が暗号化されているかは自動的には決まりません。

プライベートなコンテナネットワークで信頼されたホスト1台に限定されている場合はプレーンHTTPも合理的ですが、プロキシはそのトラフィックを読み取り変更できます。上流がホスト間、信頼されていないネットワーク、またはより強い信頼境界を越える場合は、別の検証済みHTTPS接続が露出を減らします。

再暗号化は2つのTLSセッションと2つの証明書の判断を生みます。プロキシはバックエンド証明書と期待される名前を検証しなければなりません。検証をスキップしてHTTPSを有効にするだけでは、暗号化が認証されていないトンネルに置き換わります。

コンテナはどのようにして元のクライアントコンテキストを知るのですか？

上流のTCP接続はプロキシから発信されるため、プロキシ接続は元のクライアントアドレスを隠します。転送ヘッダーはアプリケーションに必要なクライアントIP、元のスキーム、ホスト名、ポートを運びます。

元のHTTPSスキームがなければ、アプリケーションはHTTPリダイレクトを生成したり、セキュアクッキーを誤ってマークしたり、誤ったコールバックURLを構築したりする可能性があります。信頼できるクライアントアドレスがなければ、ログ、レート制限、アクセスポリシーはプロキシのみを識別するかもしれません。

プロキシはこれらの値を一貫して設定しなければならず、コンテナフレームワークは正しいホップ数またはプロキシネットワークを信頼するように設定されている必要があります。ヘッダーの転送と安全な解釈は別の作業です。

TLS終了はどのような新しい信頼境界を作り出しますか？

クライアントは偽造された転送ヘッダーを自ら送信できるため、信頼されたプロキシは転送ヘッダーをサニタイズし、バックエンドがセキュリティ判断に使う前に処理する必要があります。

アプリがプロキシ提供のIDを信頼する場合、コンテナへの直接アクセスはブロックすべきです。そうしないとクライアントはプロキシを回避し、自身のX-Forwarded-Forやスキームの値を送信して、アプリケーションが信頼するイングレスから来たと想定するコンテキストを偽装できます。

コンテナイングレスは見えるクライアントパスを書き換えます。プロキシの秘密鍵を保護し、管理インターフェースを制限し、意図したルートのみを公開し、証明書の更新と上流の健全性を監視してください。プロキシは共有のセキュリティ依存関係となるためです。

よくある質問

すべてのコンテナに独自の公開TLS証明書が必要ですか？

TLSをリバースプロキシが終了する場合はそうではありません。プロキシは複数のホスト名の証明書を保持し、復号されたリクエストを別々の内部コンテナに転送できます。

プロキシからコンテナへのHTTPは常に安全でないのでしょうか？

信頼境界によります。隔離された同一ホストネットワークは、ルーティングされた共有ネットワークとは異なるリスクがあります。証明書検証付きのHTTPSは、信頼されていない区間を越える際により強力な保護を提供します。

リバースプロキシはHTTPSを復号せずにルーティングできますか？

はい。TLSパススルーはSNIなどのハンドシェイク情報を使ってルーティングできますが、バックエンドがTLSを終了するため、プロキシは通常のHTTPレイヤーの可視性とフィルタリングを失います。

なぜコンテナは直接の外部アクセスを拒否すべきなのでしょうか？

アプリが転送ヘッダーを信頼する場合、直接アクセスによりクライアントはプロキシのサニタイズを回避し、偽造されたID、スキーム、またはホスト名の値を送信できます。

最終的な結論

リバースプロキシはTLSを処理し、公開された暗号化エンドポイントとなり、各コンテナへの別々に管理される二つ目の接続を作成します。信頼できるセキュリティは、正しいホスト名ルーティング、自動化されつつ保護された証明書の更新、意図的な上流の暗号化、適切に処理された転送ヘッダー、および信頼されたプロキシを迂回する経路のブロックに依存します。