私がZimaCube 2を使って自宅ラボ全体のゼロトラストイングレスコントローラーにした方法
あなたのホームラボには玄関があります。ほとんどのセルフホスターのように、その玄関はルーターのポートフォワードであり、完全に開放されています。
私は数週間かけて自分の環境を再構築しました。結果は：完全にZimaCube 2上で動作する本格的なイングレスレイヤー。ルーターのポートは一切開けていません。公開されている起点サーバーもありません。すべての接続でエンドツーエンドTLS。すべてが静かにテレビの隣に置かれています。
ここで私が実際に構築した方法、途中で壊れた点、そしてなぜZimaCube 2がこの仕事に最適なプラットフォームとなったのかを説明します。
従来のホームラボイングレスの問題点
多くのホームラボはまだこのような状態です:
- ルーターでポート443が転送され → リバースプロキシを指します
- ポート80が転送され → 443にリダイレクトされます
- IPを知っていればサービスに直接アクセス可能です
- 起点インフラはポートスキャン一回で発見されてしまいます
これが実際の問題を生み出します。公開されたイングレスポート。直接アクセス可能な起点サーバー。認証前に応答する管理インターフェース。HTTPSであってもインフラ自体は見えており、可視性は偵察を招きます。
私はまったく異なるモデルを求めていました。現代のクラウドインフラがイングレスを扱う方法に近いもの：アウトバウンドのみの信頼、インバウンドの露出ゼロ、そして起点を隠す暗号化トンネル。
なぜZimaCube 2なのか
この種のアーキテクチャには特定のハードウェア特性が求められます。単なるパワーではなく、信頼性、柔軟性、そして静音性です。
ZimaCube 2はすべての要件を満たしました：
|
常時稼働: 静かな24時間運用。 イングレスレイヤーは常時稼働する必要があります — ZC2の熱設計により、部屋を支配することなくそれが可能です。 |
デュアル2.5GbE: エッジネットワーク用のインターフェース1つ、内部用のインターフェース1つ。トラフィックのセグメンテーションは物理層から始まっており、Dockerだけではありません。 | Dockerネイティブ: 高速なコンテナI/OのためのNVMeストレージ。複数のブリッジネットワークでもシステムが詰まることはありません。このプラットフォームはそれを前提に構築されています。 |
この時点で、ZimaCube 2は実質的に1台のマシンで4つの役割を果たしています：Dockerホスト、リバースプロキシプラットフォーム、イングレスレイヤー、そして集中管理型インフラ機器。現代のセルフホスティングにはこの組み合わせが非常に実用的です。
新しいアーキテクチャ
ルーターのポートを開ける代わりに、新しい設計は次のように機能します：
- Cloudflareトンネルは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 Tunnelは内部的にリバースプロキシに接続しており、それは証明書のどれとも一致しないDockerのホスト名でした。ホスト名の不一致がTLS検証の静かな失敗を引き起こしました。
修正方法：Cloudflare TunnelをOrigin Server Name: 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 Tunnelとは何で、なぜ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）を使って接続した際、TLS証明書（example.comのような公開ドメイン用に発行されたもの）が一致しませんでした。解決策は、Cloudflare Tunnelを正しいOrigin Server Nameで設定しつつ、内部のDockerホスト名にルーティングすることでした。これにより検証を無効にせずに完全な暗号化を維持できました。
このユースケースにおいて、ZimaCube 2のネットワークハードウェアは標準的なNASと比べてどう違いますか？
ほとんどの一般的なNASデバイスはシングルギガビットイーサネットポートを搭載しています。ZimaCube 2はデュアル2.5GbEを備えており、1つのインターフェースをエッジトラフィック（Cloudflare + リバースプロキシ）に、もう1つを内部サービスに専用できます。この物理層の分離は、シングルNICハードウェアでは実現できません。
おすすめ商品
Zimaキャンペーンハブ
もっと読む
ZimaCube 2 Pro 開封レビュー — デザインオブジェクトのように感じる初のNAS
ZimaCube 2 Proを発見してください：ホームラボハードウェアを再定義するプレミアムでコンパクトなNAS。Intel i5、10GbE、Thunderbolt 4、そして洗練されたアルミニウムシャーシを備え、究極のパフォーマンスを実現しています。
なぜ私はラックサーバーをZimaCube 2に置き換えたのか — ホームラボ進化の物語
ZimaCube 2は、騒音の多いラックサーバーや制限のあるミニPCのセットアップに代わり、Docker、ZFSストレージ、NVMe、バックアップ、自宅ホスティング、24時間365日のインフラワークロードに対応した静かなオールインワンのホームラボを提供します。
ZimaCube 2でDocker、CI/CD、10以上のセルフホストサービスを運用する方法
このコミュニティスポットライトでは、ZimaCube 2 PioneerのMichael Luckenbillによる完全セルフホスト型インフラストラクチャのテストを紹介します。10以上のDockerコンテナ、ローカルGitHub Actions CI/CD、デュアルZFS HDD/NVMeストレージプール、デュアル2.5GbEネットワーキング、Cloudflareトンネルを搭載し、標準の8GB DDR5 RAMで動作。コンパクトで静かなシャーシは、冷却性能を保ちながら連続稼働をこなし、ストレージ、コンピュート、オートメーションを一つにまとめたオールインワンのパーソナルクラウドボックスを実現しています。
