コミュニティソリューション

ZimaOSアプリのHTTPS:リバースプロキシ、トンネル、証明書の境界

A user wanted all ZimaOS apps behind HTTPS; replies explained that each service needs an access architecture such as a reverse proxy, managed tunnel, or private overlay rather than one global toggle.

すべてのアプリに対応する、確認済みのグローバル HTTPS スイッチはありません

コミュニティのスレッドでは、インストール済みのすべてのアプリに有効な HTTPS エンドポイントを自動的に提供する ZimaOS のボタンは特定されていません。アプリごとに待ち受けるポート、対応するウェブ機能、必要なルーティング方法が異なる場合があります。

ユーザーはドメインと固定パブリック IP アドレスを使ってストレージにアクセスしていましたが、それでも安全でない接続に関する警告が表示されました。ドメイン名だけでは TLS は作成されません。ブラウザーは、そのホスト名に対して有効な証明書を提示するエンドポイントに接続する必要があります。

まず、各アプリ、内部ポート、使用したいホスト名、アクセス範囲がローカルのみ、プライベートなリモートアクセス、パブリックインターネットアクセスのいずれであるかを一覧にしてください。その範囲によって、適切なイングレス設計が決まります。

インストール済みアプリの HTTPS について質問している ZimaOS のインターフェース
トピックに表示された組み込みインターフェースでは、グローバルな証明書ワークフローは確立されていませんでした。

実際のアクセス目的に合わせて、1 つのイングレスモデルを選ぶ

リバースプロキシはポート 443 で TLS を終端し、異なるホスト名を個別の内部アプリポートにルーティングできます。1 つの管理されたフロントエンドから複数のアプリケーションを提供する、ドメインベースの設計に適しています。

管理型トンネルを使えば、ルーターからすべてのアプリケーションポートを直接転送せずに、HTTPS のエントリーポイントを提供できます。Tailscale などのプライベートオーバーレイは別の問題を解決します。認証されたデバイスがプライベートネットワークに参加し、サービスを一般公開せずに利用できるようにします。

証明書を設定する前に、どれか 1 つのモデルを選んでください。明確な理由なく直接ポート転送、トンネル、オーバーレイを重ねると、保護とトラブルシューティングが必要な経路が増えます。

証明書は TLS 終端ポイントに配置する

Let's Encrypt の証明書は、HTTPS 接続を制御するリバースプロキシやその他のサービスで使用できます。証明書は「ドメイン上」にインストールするものではなく、証明書を取得しただけで、すべてのバックエンドアプリが自動的に HTTPS を使えるようになるわけでもありません。

選択したプロキシまたはトンネルに 1 つのホスト名を割り当て、そこで証明書を発行または設定し、そのホスト名を 1 つの内部アプリにルーティングしてください。アーキテクチャ上、直接アクセスが明確に必要な場合を除き、バックエンドポートは非公開にしてください。

ブラウザーに警告が表示される場合は、証明書のホスト名、DNS の宛先、証明書チェーン、そして実際にポート 443 で応答しているコンポーネントを確認してください。恒久的な解決策として警告を無視しないでください。

パターンを繰り返す前に、1 つのアプリケーションを検証する

HTTPS のホスト名を通じて、ログイン、アップロード、ダウンロード、ライブ更新、WebSocket に依存する機能をテストしてください。ページが読み込めても、アップロードできなかったりセッションを維持できなかったりする場合は、完全には設定されていません。

プロキシまたはトンネルと対象アプリを再起動してから、同じワークフローを繰り返してください。HTTP からのリダイレクトが意図した場所でのみ行われ、バックエンドの生ポートが意図せずインターネットに公開されていないことを確認します。

1 つのアプリが動作したら、次のアプリについてもホスト名とバックエンドの対応付けを繰り返してください。サービスに特別なプロキシ要件がある場合は、動作している HTTPS エンドポイント全体を解体するのではなく、問題のあるルートだけをロールバックしてください。

リモート HTTPS はアクセス制御の代わりにはならない

TLS は通信を暗号化し、ホスト名を認証しますが、誰がアプリケーションを利用すべきかを判断するものではありません。強力なアプリ認証、公開範囲の制限、アップデート、監査ログを引き続き有効にしてください。

スレッドでは Cloudflare Tunnels、Tailscale、または Caddy などのリバースプロキシを調査することが推奨されていますが、導入完了までの手順は記録されていません。これらはアーキテクチャの方向性であり、情報源によって確認された ZimaOS の手順書ではありません。

選択した方法、証明書の管理主体、または認証境界が不明確な場合は、一般公開する前に中止してください。まず重要でないサービスで検証するか、公開経路を設計している間はプライベートなリモートアクセスを使用してください。

よくある質問

1 つの証明書で、すべての ZimaOS アプリを自動的に保護できますか?

証明書だけではできません。プロキシなどの TLS エンドポイントには、各バックエンドサービスのホスト名とルーティングルールが必要です。

リモート HTTPS のために、各アプリのポートを公開する必要がありますか?

必ずしも必要ではありません。リバースプロキシと管理型トンネルはイングレスを集約するように設計されており、プライベートオーバーレイを使えば一般公開を避けることができます。

Tailscale はリバースプロキシと同じですか?

いいえ。Tailscale は認証されたデバイス間でプライベートネットワークへの到達性を作成します。一方、リバースプロキシはウェブリクエストを受け付け、ホスト名をバックエンドサービスにルーティングします。