はじめに

最近のMiniPC、かなり強いです。
自宅ラボでも小規模な会社環境でも、MiniPC一台にProxmox VEを入れるだけで、かなり色々なことができます。
私の環境では、Intel NUC13ANHi7にProxmox VEを入れて、以下のような用途をまとめています。

Nextcloud
Samba / ファイル共有
DNS / Unbound / Pi-hole的な用途
Squid
VPNサーバ
検証用Windows VM
プロジェクトごとの開発用VM
ローカルLLM検証用VM
Proxmox Backup Server連携
商用Webサーバ、デモ予約・管理機能
セルフデモ環境
マルチプロジェクト開発環境

スペック感としては、ざっくり以下です。

MiniPC: Intel NUC13ANHi7
CPU: Core i7-1360P
Memory: 64GB
Storage: NVMe 2TB + SATA SSD 1TB
Hypervisor: Proxmox VE

これで月の電気代は、私の使い方ではだいたい1,500円前後です。
もちろん電力単価や負荷次第で変わりますが、クラウドに同じようなVM群を並べることを考えると、かなりコスパは良いです。
MiniPC一台で、会社のちょっとした基盤サービスも、チームの開発環境も動かせる。
これはかなり便利です。

ただし、ここには大きな落とし穴があります。 それは、

基幹サービス用VMと、開発環境用VMを、何も考えずに同じネットワークへ並べると危ない

という点です。

この記事では、MiniPC一台で便利なプライベートクラウドっぽい環境を作るときに、どこを気を付けるとよいかを書きます。

基幹サービスとは何か

ここで言う「基幹サービス」は、会社やチーム、または自宅ラボで普段使う土台側のサービスです。
例えば、以下のようなものです。

Nextcloud
TrueNAS / Samba / NFS
DNSサーバ (Pi-hole / Unbound)
グループウェア
プロジェクト管理ツール
Gitサーバ
Wiki
パスワード管理ツール
購買管理
監視ツール
バックアップサーバ
社内向けWebアプリ
自宅ならJellyfinなどのメディアサーバ

これらは、言ってしまえば「社内もしくは個人用のサービス」です。
会社であれば、社内情報、案件情報、ファイル、認証情報、バックアップなどに近い場所にあります。
自宅ラボであっても、写真、動画、個人ファイル、家族向けサービスなどに近い場所にあります。
つまり、あまり外部の人に見せたくないものです。

Proxmoxを使っていると、こうしたVMを vmbr0 に接続して、普通のLAN上に並べる構成はよくあります。

vmbr0 / Main LAN
  ├─ Nextcloud VM
  ├─ TrueNAS VM
  ├─ DNS VM
  ├─ Git VM
  ├─ Project Management VM
  └─ Monitoring VM

自分だけが使う環境なら、これでも運用できる場面は多いです。
問題はここに「開発環境」を追加で作り始め、外部の人と共有たときです。

開発環境とは何か

ここで言う「開発環境」は、プロジェクトやチームのメンバーが触るVM群です。
例えば、以下のようなものです。

Webアプリ検証用VM
DB検証用VM
CI/CD検証用VM
顧客案件ごとの検証VM
業務委託メンバー用VM
外部パートナー用VM
一時的なPoC用VM
デモ環境
ステージングに近い検証環境
ローカルLLMやGPU検証用VM

開発環境では、SSH、SCP、RDP、X転送、Web管理画面など、いろいろな接続が必要になります。さらに、開発用VMでは利用者にroot権限やsudo権限を渡すこともあります。
これは開発環境としては自然です。
アプリのインストール、ミドルウェアの設定、ログ確認、ポート開放、コンテナ起動などを毎回管理者に依頼していたら、開発速度が落ちます。

ただし、root権限を渡すということは、そのVMの中ではかなり自由に操作できるということです。

そして、ここで大事なのは「誰がそのVMを触るのか」です。
例えば、こんなケースは普通にありそうです。

新しく入った業務委託メンバーにVMを一個渡した
外部パートナーに検証用VMを貸した
顧客デモ用に一時的なVMを作った
インターンや新人にLinux練習用VMを渡した
別プロジェクトのメンバーに、VPS感覚でVMを貸した
AI検証用にGPU付きVMをチームに開放した
「ちょっと検証したいだけだから」と一時VMを作って、そのまま残った

どれも現場でありそうな話です。

ここで問題になるのは、開発VMの利用者が必ずしも基幹サービスを見えてよい人とは限らない、という点です。

社内メンバーでも、別プロジェクトの情報は見せたくないことがあります。
外部パートナーや業務委託であれば、なおさらです。

ありがちな危ない構成

Proxmoxを使っていると、最初はだいたいこうなりがちです。

vmbr0 / Main LAN
  ├─ Nextcloud VM
  ├─ TrueNAS VM
  ├─ Pi-hole VM
  ├─ Git VM
  ├─ Project Management VM
  ├─ Dev VM for Project A
  ├─ Dev VM for Project B
  └─ Dev VM for Contractor

全部同じ vmbr0 に並んでいます。
これは簡単です。VMを作るときにBridgeへ vmbr0 を選ぶだけです。

IPアドレスも同じLANから払い出されます。
自宅や会社のPCからもアクセスしやすいです。
でも、これは言い換えると、

開発VMから基幹サービスが丸見え

ということです。

たとえば、開発VMに入ったユーザが以下のようなことをできる可能性があります。

ip route
ip neigh　または　arp -a
nmap 192.168.1.0/24
curl http://表示されたIP
ssh user@表示されたIP

もちろん、各サービス側で認証はあります。
でも、そもそもネットワーク的に到達できる状態になっている時点で、攻撃面は広がっています。

「ログインできないから大丈夫」ではなく、「見えている時点で、攻撃対象として認識できる」という状態です。

これはかなり危険です。

何が危ないのか

同じネットワークに全部置くと、主に次のような問題が出ます。

1. 開発VMから基幹サービスが見える

開発VMからNextcloud、TrueNAS、DNS、管理画面、Git、監視ツールなどが見える状態になります。
攻撃するつもりがなくても、利用者がスキャンしただけで見えてしまいます。

「このVM、何がいるのかな？」くらいの軽い気持ちで nmap を打ったら、社内サービスが全部見える。
これはあまり嬉しくありません。いやいや、かなり危険です。

例えばdnf install squidと打たれれば、この開発用VM経由で、社内ネットワーク上のWEBサーバに接続できるように簡単になってしまいます。　必ずしも開発者が悪意をもってこれを実行するとは限りません。　「これもし見えちゃったらやばいかな？確認してみよう」という気持ちかもしれません。

2. 開発VMの侵害が横展開につながる

開発VMは、基幹サービスよりも雑に扱われがちです。

検証用だからパスワードが弱い
一時VMだからセキュリティパッチの適用がされていない
Dockerコンテナを雑に起動している
SSHを開けたまま
rootログインを許可している。またはsudo権限がある
外部から持ってきたスクリプトを実行している

こうしたVMが基幹サービスと同じネットワークにいると、開発VMが侵害されたときに、そこから他のVMへ横展開される可能性が出ます。

3. プロジェクト間の境界が曖昧になる

Project AのVMとProject BのVMが同じネットワークにいると、プロジェクト間の境界も曖昧になります。

Project A Dev VM
Project B Dev VM
Contractor VM
PoC VM

これらが同じLANにいると、本来プロジェクト内の機密情報が漏れる可能性があります。
どの利用者がどの範囲を見てよいのか、ネットワーク上は区別されず、権限管理を人間の注意力に頼る形になります。

人間の注意力は、金曜夕方のリリース作業くらい信用してはいけません。

4. 一時VMが一時で終わらない

検証用VMは「一時的に作っただけ」のはずが、なぜか長生きします。

あとで消す
もう少し使う
念のため残す
誰が使っているかわからない
消すと怒られそう

こうして謎のVMが増えていきます。

そして、それらが基幹サービスと同じLANにいると、時間が経つほどリスクの所在が見えにくくなります。

必要なのはネットワーク分離

ここで必要になるのが、ネットワーク分離です。

考え方としてはシンプルです。

Main LAN / 基幹サービス
  ├─ Nextcloud
  ├─ TrueNAS
  ├─ DNS
  ├─ Git
  └─ Project Management

Isolated Dev Network / Project A
  ├─ Dev VM A1
  └─ Dev VM A2

Isolated Dev Network / Project B
  ├─ Dev VM B1
  └─ Dev VM B2

Isolated Dev Network / Contractor
  └─ Contractor VM

開発VMは、基幹サービスと同じLANに直接置かない。
プロジェクトごとに分離されたネットワークへ置く。

これだけで、見える範囲をかなり制限できます。

理想は以下のような状態です。

開発VMから基幹サービスへは原則到達できない
Project AからProject Bへは到達できない
外部メンバーは自分のプロジェクトVMだけ見える
管理者は必要に応じて各環境へ入れる
インターネット接続やDNSなど、必要な通信だけ許可する

これはいわゆる「ネットワークセグメンテーション」や「マイクロセグメンテーション」に近い考え方です。

大きな会社では普通に出てくる考え方ですが、MiniPC一台のhomelabや小規模な会社環境でも、同じ問題は起きます。

規模が小さいだけで、境界が不要になるわけではありません。

Proxmoxでも分離はできる

Proxmoxには、ネットワークを分離するための機能があります。

代表的には以下のような方法があります。

Linux Bridgeを分ける
VLANを使う
Proxmox SDNを使う
Firewallで通信を制御する
ルータVMやFirewall VMを置く
VPNと組み合わせる

ちゃんと設計すれば、Proxmoxだけでもかなり柔軟なネットワーク分離ができます。
ただし、ここで難しいのは「作れること」と「安全に運用できること」は別だという点です。
例えば、以下のようなことを考える必要があります。

どのネットワークを基幹サービス用にするか
どのネットワークを開発環境用にするか
プロジェクトごとにどう分けるか
開発VMからMain LANへ何を許可するか
DNSはどうするか
インターネットへどう出すか
VPNユーザをどのプロジェクトに紐づけるか
ルーティングはどうするか
Firewallルールはどこに書くか
既存ネットワークとアドレスが衝突しないか
設定変更後に本当に遮断されているか
将来プロジェクトが増えたときに破綻しないか

このあたりを手作業で作ることはできます。

ただ、自己責任で設計、実装、テスト、運用を行う必要があります。
特に会社の開発環境として使う場合は、ネットワークやセキュリティの観点で確認しておいた方が安心です。

もっと簡単にしたくてMSL Setupを作った

このあたりを毎回手作業で作るのが面倒だったので、MSL Setupというものを作りました。

MSL Setupは、Proxmox上にプロジェクトごとの分離された開発環境を作るためのセットアップツールです。

やりたいことはシンプルです。

MiniPC一台のProxmoxを、基幹サービスを守りながら、チーム用の開発環境も安全に提供できる基盤にする。

MSL Setupでは、プロジェクトごとに分離された開発ネットワークを作り、必要に応じてVPN経由でチームメンバーがアクセスできるようにします。

イメージとしてはこうです。

Main LAN / 基幹サービス
  ├─ Nextcloud
  ├─ TrueNAS
  ├─ Pi-hole
  ├─ Git
  └─ Project Management

MSL Setup / 分離された開発環境
  ├─ Project 01 Network
  │    ├─ Dev VM
  │    └─ Test VM
  │
  ├─ Project 02 Network
  │    ├─ Dev VM
  │    └─ DB VM
  │
  └─ Project 03 Network
       └─ Contractor VM

開発環境の利用者は、自分が参加するプロジェクトのネットワークへだけアクセスします。
基幹サービスや他プロジェクトは、ネットワーク的に見えない構成にします。

これにより、以下のような使い方がしやすくなります。

業務委託メンバーにVMを渡す
外部パートナーに検証環境を渡す
プロジェクトごとに開発ネットワークを分ける
PoC環境を安全に切り出す
デモ環境を外部から触れるようにする
homelabの基幹サービスを守りつつ、開発VMを増やす

無償版もあります

MSL Setupには無償で使える版があります。

「まずは自宅ラボや小規模な検証で試してみたい」という用途であれば、無償版から触ってみるのが良いと思います。

まとめ記事はこちらです。

リポジトリはこちらです。

公式サイトはこちらです。

この記事では細かい実装方式には踏み込みません。
なぜなら、この記事で伝えたいことは「どの技術で実現しているか」よりも、
基幹サービスと開発環境を同じネットワークに雑に置くのは危ない
という考え方だからです。

まずは、

基幹サービス
開発環境
外部から触る人
プロジェクトごとの境界

を分けて考えることが大事です。

クラスタ構成にも拡張できる

MiniPC一台でもかなり便利ですが、開発環境として使っていると、だんだん欲が出てきます。

例えば、

もっとCPUが欲しい
メモリが欲しい
GPUを使いたい
ローカルLLMを動かしたい
バックアップ専用ノードが欲しい
一部VMを別ノードに逃がしたい

こういう場面です。

私の環境では、別のProxmoxノードも持っていて、そこにGPU付きのVMを用意しています。
プロジェクトによっては、ローカルLLMを使えるようにしています。

例えばAIスタートアップや、社内AI活用を試したい小規模チームであれば、

通常の開発VMはMiniPC側
LLMやGPUが必要なVMはGPUノード側
それでもプロジェクトごとのネットワーク境界は維持する

という構成が候補になります。
クラウドGPUを毎回借りるのも便利ですが、検証が多い場合はローカルGPUノードを持つのも選択肢になります。
MiniPC一台から始めて、必要に応じてノードを増やし、プロジェクト単位の開発環境を広げていく。
こういう「小さく始めるプライベート開発クラウド」は、もっと使われてもよいと思っています。

まとめ

MiniPC一台にProxmoxを入れると、かなり便利です。
Nextcloud、TrueNAS、Pi-hole、Git、プロジェクト管理、開発VM、検証VM、デモ環境まで、いろいろ載せられます。
ただし、便利だからといって全部を同じ vmbr0 に並べると、基幹サービスと開発環境の境界がなくなります。
特に、以下のようなケースでは注意が必要です。

業務委託にVMを渡す
外部パートナーにVMを貸す
複数プロジェクトを同じProxmox上で動かす
root権限付きの開発VMを提供する
自宅ラボの基幹サービスと開発VMを同居させる
MiniPCを会社の小さな開発基盤として使う

必要なのは、巨大なエンタープライズ製品とは限りません。
MiniPC一台でも、ネットワーク分離の考え方を入れるだけで、かなり安全に使えます。
そして、それをProxmox上で簡単に作るために、MSL Setupを作りました。
興味があれば、ぜひ試してみてください。

https://qiita.com/masa-555/items/f8f092b308dd28a55533
https://github.com/zelogx/msl-setup
https://www.zelogx.com/

MiniPC一台を、ただのVM置き場ではなく、基幹サービスとチーム開発環境を両立する小さなプライベートクラウドにする。

この方向性、かなり面白いと思います。