私がZimaCube 2を使って自宅ラボ全体のゼロトラストイングレスコントローラーにした方法
あなたのホームラボには玄関口があります。ほとんどのセルフホスターと同じなら、その玄関口はルーターのポートフォワードであり、完全に開放されています。
私は数週間かけて自分の環境を再構築しました。結果は：完全にZimaCube 2上で動作する本格的なイングレスレイヤー。ルーターに開放ポートなし。公開されているオリジンサーバーなし。すべての接続でエンドツーエンドTLS。すべてが静かにテレビの隣に置かれています。
ここでは私がどのように構築し、途中で何が壊れ、なぜZimaCube 2がこの仕事に最適なプラットフォームとなったのかを正確に説明します。
従来のホームラボイングレスの問題点
多くのホームラボはまだこのような状態です。:
- ルーターでポート443が転送され → リバースプロキシを指します。
- ポート80が転送され → 443にリダイレクトされます。
- IPアドレスがわかればサービスに直接アクセス可能です。
- オリジンインフラはポートスキャン一回で発見されてしまいます。
これには実際の問題が生じます。公開されたイングレスポート、直接アクセス可能なオリジンサーバー、認証前に応答する管理インターフェース。HTTPSを使っていても、インフラ自体は見えてしまい、その可視性が偵察を招きます。
私はまったく異なるモデルを求めていました。現代のクラウドインフラがイングレスを扱う方法に近いものです：アウトバウンドのみの信頼、インバウンドの露出ゼロ、そして起点を隠す暗号化トンネル。
なぜZimaCube 2なのか
この種のアーキテクチャには特定のハードウェア特性が求められます。単なるパワーではなく、信頼性、柔軟性、そして静音性です。
ZimaCube 2はすべての要件を満たしました：
|
常時稼働: 静かな24時間365日の運用。 イングレスレイヤーは常に稼働し続けなければなりません — ZC2の熱設計により、部屋を支配することなくそれが可能です。 |
デュアル2.5GbE: エッジネットワーク用のインターフェースと内部用のインターフェース。トラフィックのセグメンテーションは物理層から始まり、Docker内だけではありません。 | Dockerネイティブ: 高速なコンテナI/OのためのNVMeストレージ。複数のブリッジネットワークでもシステムが詰まることはありません。このプラットフォームはそれを前提に設計されています。 |
この時点で、ZimaCube 2は実質的に1台で4つの役割を果たしています：Dockerホスト、リバースプロキシプラットフォーム、イングレスレイヤー、そして集中型インフラストラクチャアプライアンスです。現代のセルフホスティングにおいて、この組み合わせは非常に実用的です。
新しいアーキテクチャ
ルーターのポートを開ける代わりに、新しい設計は次のように動作します：
- Cloudflare TunnelはCloudflareエッジへのアウトバウンド専用の暗号化接続を作成します
- Nginx Proxy Managerがルーティング、SSL終端、ACLを処理します
- Dockerブリッジネットワークがエッジトラフィックを内部ワークロードから分離します
- インバウンドNATルールはゼロ — ルーターは何も提供されていることを知りません
これはすぐに従来のポートフォワード型セルフホスティングよりも現代的なクラウドイングレスアーキテクチャに近いと感じました。
Dockerネットワークのセグメンテーション：エッジ ≠ 内部
最も重要な変更の1つはDockerブリッジネットワークを使ってトラフィックを分離したことでした。
docker network create \
--subnet 172.x.x.x/24 \
edge
エッジネットワークには正確に2つのコンテナだけが存在します：Cloudflare TunnelとNginx Proxy Manager。それだけです。アプリケーションは別の内部Dockerネットワーク上にあり、完全にイングレス層から隔離されています。
ZimaCube 2はこのセグメンテーションをきれいに処理します。複数のブリッジネットワークはプラットフォームにパフォーマンスのオーバーヘッドを生まず、NVMeストレージによりネットワークトポロジーが複雑化してもコンテナの起動やネットワークI/Oは高速に保たれます。
私をほぼ破滅させかけたTLSの問題
これがこのプロジェクト全体で最も興味深いエンジニアリングの教訓となりました。
セットアップは最初は簡単に思えました。Cloudflare TunnelとNginx Proxy Manager間のHTTPはすぐに動作しました：
http://reverse-proxy → ✅ 成功
そこでHTTPSを有効にしました。
https://reverse-proxy → ❌ 失敗
証明書は有効で、有効期限も問題なく、信頼チェーンも確認できました。すべて正しく見えたのにHTTPSは接続を拒否しました。
本当の問題はTLSホスト名検証でした。
証明書は私の公開ドメイン（example.com、app.example.com）用に発行されていました。しかしCloudflareトンネルは内部的にリバースプロキシに接続しており、それは証明書のどれとも一致しないDockerのホスト名でした。ホスト名の不一致がTLS検証の静かな失敗を引き起こしました。
修正方法：Cloudflareトンネルをオリジンサーバー名：example.comで設定しつつ、内部的には https://reverse-proxy:443. それにより暗号化された通信が維持され、適切なホスト名検証と完全なTLS検証が行われ、セキュリティチェックを無効にすることなく実現しました。
これは実際に構築してみないと学べない教訓です。
ACLとインフラのトラフィック経路に関する教訓
すぐに学んだ運用上の教訓の一つ：リバースプロキシは元のクライアントIPではなく、DockerブリッジIP、トンネルIP、内部プロキシIPをよく見ています。
Nginx Proxy Managerから誤って自分自身を締め出してしまい、このことを痛感しました。
ACLを設定して自分のLANサブネット（192.168.x.x/24）のみを許可しました。論理的には正しいと思いました — 自宅ネットワーク上のデバイスだけが管理パネルにアクセスできるはずです。
NPMは実際にはDockerブリッジネットワークからのトラフィックを見ていました。私のLANからではありません。アクセス制御は私を含めすべてをブロックしていました。
Dockerサブネットを許可リストに追加したらすぐに解決しました。しかし、インフラのトラフィック経路は紙の上で想定しているものと異なることが多いという非常に現実的な教訓でした。
なぜこのアーキテクチャがZimaCube 2で重要なのか
このスタックが特にZC2でうまく機能する理由があります：
- デュアル2.5GbE — イングレス層に専用帯域を確保、内部ネットワークトラフィックがインターネット向けサービスと競合しない
- NVMeストレージ — 高速なコンテナネットワーキングを実現、ブリッジネットワークのスループットが遅いディスクI/Oでボトルネックにならない
- 静かな常時稼働 — イングレス層は24時間365日リビングスペースで稼働、地下ラックではない
- Dockerネイティブプラットフォーム — トンネル、リバースプロキシ、ACLエンジン、すべてのサービスを同時に動かせる余裕あり
- 拡張性 — ネットワーク要件が増えたら専用NICやアクセラレータカードを後から追加可能
ZimaCube 2はこれらのサービスをホスティングするだけでなく、それらに最適なプラットフォームです。
最終スタック
現在ZimaCube 2で稼働しているもの：
- Cloudflareトンネル — アウトバウンド専用の暗号化接続、開放ポートゼロ
- Nginx Proxy Manager — リバースプロキシ、SSL、ACL
- Dockerブリッジネットワーク — エッジと内部トラフィックを分離
- エンドツーエンドTLS — クライアントからオリジンまで暗号化され、どこにも平文なし
- 隠されたオリジン — 公開IPで応答しない
それでもホームラボです。しかし運用モデルは従来のポートフォワード型セルフホスティングよりも現代的なイングレスエンジニアリングにずっと近いものになっています。
このプロジェクトから得た最大の気づき：現代のセルフホスティングは、ますます本番インフラで見られるイングレス、ネットワーキング、信頼境界の考え方を必要としています。そしてハードウェアもそれに応えなければなりません—静かで信頼性が高く、ネットワーク接続され、常時稼働。
ZimaCube 2はまさにそれを実現します。
ZimaCube 2でゼロトラストのホームラボを自分で構築しよう →
よくある質問
Cloudflareトンネルとは何か、そしてなぜZimaCube 2で使うのか？
Cloudflare TunnelはZimaCube 2からCloudflareエッジネットワークへのアウトバウンド専用の暗号化接続を作成します。ルーターのポートを開けてインフラをインターネットにさらす代わりに、すべてのトラフィックはこの暗号化トンネルを通ります。オリジンサーバーであるZimaCube 2は完全に外部から隠されています。
このセットアップでルーターのポートを開ける必要はありますか？
いいえ。それがポイントです。Cloudflare Tunnelはアウトバウンド接続のみを行います。ルーターにポートフォワードの設定は不要です。これによりホームラボネットワークで最も一般的な攻撃経路が排除されます。
ZimaCube 2はリバースプロキシとすべてのサービスを同時に実行できますか？
はい。Michael ZC2はCloudflare Tunnel、Nginx Proxy Manager、10以上のDockerコンテナを同時に実行しつつ、静かで冷却も十分に保っています。デュアル2.5GbEポートとNVMeストレージにより、ネットワークとコンテナのI/Oがボトルネックになりません。
なぜDockerのネットワーク分割が重要なのですか？
すべてのコンテナが同じネットワークを共有すると、1つのサービスが侵害されると攻撃者が他のすべてにアクセスできる経路を与えてしまいます。Cloudflare TunnelとNginx Proxy Managerだけを「エッジ」ネットワークに置き、アプリケーションは別の内部ネットワークに分けることで、公開トラフィックとプライベートサービスの間に制御された境界を作れます。
TLSホスト名の不一致問題とは何でしたか？
Cloudflare Tunnelが内部でNginx Proxy ManagerにDockerホスト名（例：reverse-proxy）を使って接続した際、example.comのような公開ドメイン用に発行されたTLS証明書と一致しませんでした。解決策は、Cloudflare Tunnelを正しいOrigin Server Nameに設定しつつ、内部のDockerホスト名へルーティングすることでした。これにより検証を無効にせずに完全な暗号化を維持できました。
このユースケースにおいて、ZimaCube 2のネットワークハードウェアは標準的なNASと比べてどう違いますか？
ほとんどの一般的なNASデバイスは、ギガビットイーサネットポートを1つだけ搭載しています。ZimaCube 2はデュアル2.5GbEを備えており、1つのインターフェースをエッジトラフィック（Cloudflare + リバースプロキシ）に、もう1つを内部サービスに専用できます。この物理層での分離は、シングルNICハードウェアでは実現できません。
おすすめ商品
Zimaキャンペーンハブ
もっと読む
SjslTechが初心者にも使いやすいホームサーバーOSとしてZimaOSをテストする方法
ZimaOSが初回起動を、スマートフォンの写真バックアップとJellyfinを備えた実用的なプライベートクラウドに変えながら、ストレージと復旧に関する選択肢をわかりやすく示す方法をご覧ください。
全国防災月間：ご家族のためにオフラインの緊急情報サーバーを構築しよう
停電や緊急事態に備えて、ご家族のデジタル情報を準備しましょう。地図、書類、写真、医療記録、バックアップ、その他の重要な家庭用ファイルにアクセスできるオフライン情報サーバーの構築方法をご紹介します。
インターネットの日：自分だけのパーソナルクラウドを構築する方法
Internet Day 2026を記念して、ファイル、写真、バックアップ、メディア、自分でホストするアプリのためのパーソナルクラウドを構築しましょう。ハードウェアの選び方、ストレージの計画、安全なリモートアクセスの有効化、データの保護方法を学び、シンプルなDIYサーバーから信頼性の高いホームクラウドへと発展させましょう。
