TL;DR
- TailscaleはProxmoxへの外部アクセスを簡単にするが、「どのVMにどこまでアクセスさせるか」は自分で設計する必要がある
- Proxmoxのデフォルト構成（フラットなvmbr0）では、1台のVMに侵入されると他の全VMに横展開できる
- 複数プロジェクトや複数メンバーがいる環境では、SDNでネットワーク分離してからTailscaleを使うのが正しい順番
はじめに
ProxmoxにTailscaleを入れると、外出先からSSHやWeb UIに簡単にアクセスできるようになります。VPN設定の手間がなく、NATやポートフォワードも不要。非常に便利です。
ただ、「どのVMに」「誰が」「どこまで」アクセスできるかを意識せずにTailscaleを入れると、意図しないリスクを作り込んでしまうことがあります。
この記事では、Proxmox + Tailscale構成でよくある見落としと、複数プロジェクトや複数メンバーが関わる環境での正しい設計順序を整理します。
よくある構成とその問題
典型的なやり方
[外部] → Tailscale → Proxmoxホスト or VM → vmbr0 → 全VM
Proxmoxホスト自体にTailscaleを入れる、またはVM1台にTailscaleを入れてそこからSSHで各VMに入る、という構成はよく見られます。
何が問題か
Proxmoxのデフォルト構成では、全VMが同じブリッジ（vmbr0）に接続されています。
vmbr0（フラット）
├── VM-A（開発環境・プロジェクトX）
├── VM-B（開発環境・プロジェクトY）
├── VM-C（データベース）
└── VM-D（Tailscaleが入っているVM）
この状態でVM-DにTailscale経由でアクセスできるようにすると：
- VM-Dに正規ユーザーがSSHでアクセス
- そのユーザーが（意図せず、あるいは悪意を持って）同一ブリッジ上のVM-A、VM-B、VM-Cをスキャン
- 脆弱なVMがあれば横展開（ラテラルムーブメント）が可能
「Tailscaleで認証した」はVM-Dへのアクセスを制御しているだけで、その先のVM間通信は何も制御していません。
さらに、そのブリッジ上にProxmoxホスト自身の管理IPがある場合、問題は他VMへの横展開だけではありません。侵害されたVMからProxmoxの管理プレーン（たとえばWeb UIやSSH）への到達も試みられます。つまり、フラットなvmbr0構成では、1台のVMを安全に公開したつもりが、最悪の場合はホスト側の管理面までBlast Radiusに含めてしまいます。
さらに外部からアクセスさせているVMに脆弱性があった場合、攻撃者はTailscaleの認証を通らずとも、そのVMを踏み台にして同一ブリッジ上の全VMに到達できます。
これはProxmox固有の問題ではなく、外部公開したワークロードをフラットな内部ネットワークにそのまま接続したときに、どの仮想化基盤やクラウドでも起こり得る設計上の問題です。
具体例
実際、フラットな vmbr0 に接続されたVMの中で近隣情報を確認すると、少なくとも同一L2上のホスト情報が普通に見えてしまいます。
例:
masa@zelogx:~$ ip neigh show
192.168.1.105 dev enp6s18 lladdr ac:f4:73:xx:xx:xx STALE
192.168.1.117 dev enp6s18 lladdr 00:e0:4c:xx:xx:xx REACHABLE
...
192.168.1.2 dev enp6s18 lladdr 48:21:0b:xx:xx:xx STALE
...
この出力だけでは各IPの正体までは断定できませんが、少なくとも「公開VMを1台置いたら、同一セグメント上の他ホスト情報が見える」ことは分かります。
ラテラルムーブメントとBlast Radius
ラテラルムーブメント（横展開）とは、攻撃者が最初に侵入した1台のVMを起点に、同じネットワーク上の他のVMへと侵害を広げていく動きです。
Blast Radius（爆発半径）とは、1台のVMが侵害された場合に影響が及ぶ範囲のことです。
フラットなvmbr0構成では：
- Blast Radius = ブリッジに繋がった全VM + 同一L2上に露出している管理プレーン
これは開発環境に外部からアクセスさせるとき、特に問題になります。
- 外部メンバー（フリーランサー、オフショアメンバー）にVM環境を渡している
- プロジェクトAのメンバーがプロジェクトBのVMにアクセスできてしまう
- 1台のVMが侵害されると、開発環境全体が止まる可能性がある
正しい設計順序
Tailscaleを使って外部からアクセスさせる前に、まずネットワークの分離を設計するべきです。
ステップ1：SDNでプロジェクトごとにネットワークを分離する
Proxmox SDNのVXLAN Zone + VNetを使うと、プロジェクトごとに完全に隔離されたL2ネットワークを作れます。
AWSであれば、Security Group やネットワーク分離設計で同じ問題に対処できます。
vnetpj01（プロジェクトX用）
├── VM-A
└── VM-B
vnetpj02（プロジェクトY用）
├── VM-C
└── VM-D
vmbr0（メインLAN・管理用）
└── Proxmoxホスト
PVEファイアウォールにより、vnetpj01とvnetpj02の間の通信はホストレベルで遮断します。VM内からネットワーク設定を変更しても、この隔離境界はホスト側が維持します。
ステップ2：アクセス方法を設計する
分離されたネットワークにどうアクセスさせるか、用途によって選択肢が変わります。
| 用途 | アクセス方法 |
|---|---|
| 自分一人が管理目的でアクセス | Tailscale（ホストに直接） |
| 複数メンバーをプロジェクト単位で招待 | プロジェクト専用VPN（Pritunlなど） |
| 特定のサービスだけ公開 | Cloudflare Tunnel + リバースプロキシ |
Tailscaleはシンプルですが、「プロジェクト単位でアクセス範囲を分ける」という用途には不向きです。1人のユーザーがアクセスできる範囲をVNet単位で制限する仕組みがないからです。
複数メンバー・複数プロジェクトがある場合は、プロジェクト専用のVPNサーバーを立ててメンバーごとにVPNプロファイルを発行する方が、アクセス制御の粒度が上がります。
まとめ
| 項目 | フラット構成 + Tailscale | SDN分離 + 専用VPN |
|---|---|---|
| 外部アクセスの手軽さ | ◎ | ○ |
| プロジェクト間の分離 | ✗ | ◎ |
| ラテラルムーブメントの防止 | ✗ | ◎ |
| メンバー単位のアクセス制御 | △ | ◎ |
| スイッチなどの追加機器 | 不要 | 不要 |
Tailscaleは便利なツールですが、「外部からアクセスできる」と「安全に外部アクセスさせている」は別の話です。
特に複数のプロジェクトや複数のメンバーが関わる環境では、先にネットワークの分離設計をしてからアクセス手段を選ぶのが正しい順番です。
参考：この構成を自動化するツール
本記事で説明したProxmox SDN（VXLAN Zone）+ プロジェクト専用VPN（Pritunl）の構成を自動構築するツールとして MSL Setup を公開しています。
- プロジェクト数分のVNet・ファイアウォールルールを自動生成
- プロジェクトごとのPritunl VPNサーバーを自動プロビジョニング
- スイッチなどの追加ネットワーク機器は不要
👉 zelogx.com
👉 GitHub（無料版）
👉 構築の詳細手順はこちらのQiita記事
👉 まず試してみたい方はこちら