Proxmox VE、BSをインターネットと切断して運用するには
- Proxmox VE、BSをインターネットと切断して運用するには
※本ノートは Proxmox VE 8.x/9.x 系（2024〜2026年時点）を前提として記載しています。
Air Gap運用における課題の整理
Proxmox VE をインターネットに接続しない閉域環境（Air Gap）で運用したいという要望は、官公庁・金融・防衛関連など、外部ネットワークとの接続を制限する必要がある環境で多く聞かれます。
本テクニカルノートでは、オンプレミス用のProxmox VE、InfiniCloud® HV Suite KVMを、Air Gapで運用する方法について記載します。
2〜3の「更新すべき」もの
Proxmox VEは大きく分けて2つの、InfiniCloud® HV Suite KVMは3つの更新要素があります。
- Proxmox VEのサブクスリプション(Enterpriseレポジトリへのアクセス権)の更新
- 1年/2年/3年などの単位で更新が可能。
- Proxmox VEのパッチ更新
- Enterprise レポジトリの中身から配信されるソフトウェア群。
- aptなどのコマンドでダウンロード＋インストールされる
- InfiniCloud® HV KVMのパッケージ更新
- 備考) 簡単に言えば、InfiniCloud® HV Suite KVMは、InfiniCloud® HV KVMのパッケージ＋Proxmox VE Standard Edition＋InfiniCloudの日本語サポート＋InfiniCloudによるHCLです。
Air Gap環境を実現するためには、この2〜3をオフライン状態でインストールする必要があります。
サブスクリプションのアクセス権の更新
Proxmox VEのStandard / Premium Editionにある「Offline subscription key activation」機能をもちいることで、オフラインでサブスクリプションを更新することが可能です。しかし、「Offline subscription key activation」機能は、APTで配布される更新パッチをどう閉域へ持ち込むかは考慮対象外です。
InfiniCloud® HV Suite KVMは、Proxmox VE Standard Editionのライセンスが含まれているため、同じように更新することができます。
Proxmox VEのパッチ更新
aptで実際に配られるパッチ更新を、Air Gapで提供するためにはdebmirrorを用い、必要なレポジトリを全てミラーするなどがあります。ただし、debmirrorをAir Gap環境に持ち込むためには、相当なデータ量をUSB HDDなどを用いて持ち込む必要がありますし、そもそもProxmox VEのEnterprise レポジトリは認証が必要であり、このレポジトリのミラーが必要な場合はPOM（proxmox-offline-mirror）が必要とされています。
「レポジトリの更新サーバだけはInternet接続を許す」のであれば、apt-cacher-ngなどを用いてキャッシュサーバを作ることができ、初めてアクセスのあるファイルの時は外部のレポジトリに接続されます。つまり、外部接続性のあるサーバはapt-cacher-ngの動くサーバのみとなりますし、このサーバは外向きにしかセッションを接続しないため、Firewallの中に閉じることもできます。
InfiniCloud® HV KVM
InfiniCloud® HV KVMのハイパーバイザーパッケージ群は、dpkgでインストールができるため、ファイルを直接送るだけですみます。
POM（Proxmox Offline Mirror）とは
POMは名前の通り「Offline Mirror」ですが、実務上は サブスクリプションの更新と、Proxmox VEのパッチ更新をまとめて運用するための公式ツール という位置づけです。
- Offline Keys（権利情報の搬送）
- サブスクリプションキーをPOMに登録し、有効であれば署名済みのステータスファイルを受け取ることができます。これを媒体へエクスポートし、閉域内のホストへ搬送・適用することで、ホスト側はインターネット接続なしにサブスクリプション状態を反映できます。なお、ステータスファイルを取得する地点（POMを実行するマシン）は外部への到達性が必要です。
- Offline Repository Mirrors（パッケージの搬送）
- APTリポジトリをミラーし、スナップショットとして固定した状態で媒体へ搬送できます。閉域側ではHTTP配布または媒体マウントにより、通常のAPT操作でパッケージを取得できます。
enterprise リポジトリをミラーしたい場合は、POM側に「製品サブスクリプションキー」と「POMサブスクリプション」の両方が必要です。POMサブスクリプションはProxmox社が提供する別途の有償サブスクリプションであり、POM自体の利用権とenterprise リポジトリへのミラーアクセス権を含みます。
サブスク認証とAPT更新の「できること」の違い
ここまでの整理を踏まえ、よく聞かれる質問を取り上げます。
サブスク認証（権利情報）について
Q. POMを使えば「Proxmox VEホストは1台も外に出さず、ファイル運搬だけ」で済みますか？
はい、ホスト側については外部接続は不要です。POMが生成した署名済みステータスファイルを媒体で搬送し、各ホストへ適用するだけで権利情報を反映できます。ただし、ステータスファイルを取得するPOM自体は、インターネットへの到達性が必要です。
Q. Standard/PremiumのOffline activationも同様にファイル運搬だけで済みますか？
はい、ホスト側についてはファイル運搬だけで済みます。ただし「ステータスファイルをどう取得し、どう配布・適用するか」という運用を自前で設計する必要があります。POMはこの運用フローを一貫して実装するためのツールです。
Q. 8台のStandardライセンスがある場合、更新は8台とも手作業ですか？
最終的な「反映」は各ホストで行う必要があります。ただしPOMを使うことで「取得→媒体またはHTTP配布→一括適用（スクリプトや構成管理ツール）」という形に落としやすくなり、手作業の手間は大幅に削減できます。
ミラーサーバ（APT更新）について
Q. POMでDebianやCeph等のリポジトリをファイル運搬で持ち込めますか？
はい。APTリポジトリをミラー・スナップショット化して媒体へ搬送できます。enterprise リポジトリについては、前述の通り製品サブスクリプションとPOMサブスクリプションの両方が必要です。しかしながらPOM自体はインターネットへの到達性が必要です。
Q. apt-cacher-ngでは1台は外に出す必要がありますか？
原則として必要です。キャッシュミス時に上流のリポジトリへ取りに行くため、プロキシ自体が外部へ到達できない環境では更新が進みません。
代表的な運用パターン
Air Gap環境でのProxmox VE更新は、組織のセキュリティポリシーやネットワーク構成に応じて、いくつかの典型的なパターンに分類できます。
パターンA：完全Air Gap（更新物は媒体搬送）
もっとも厳格な構成です。更新作業用の隔離セグメントにPOMを配置し、更新窓（メンテナンスウィンドウ）でのみ外部と接続してステータスファイルとリポジトリスナップショットを取得します。取得後はUSBストレージ等の物理媒体で閉域へ搬送し、閉域側は媒体をマウントしてapt upgrade やoffline-keyの適用を行います。
パターンB：準Air Gap（POMのみアウトバウンド接続）
POMをNAT配下またはファイアウォール内に配置し、インバウンド接続を完全に遮断した上で、アウトバウンドのみ宛先ホワイトリスト（download.proxmox.com 等の必要最小限）に制限する構成です。閉域内のPVEホストはPOMを「社内更新元」として参照します。
パターンC：出口集約（帯域節約・簡素化）
apt-cacher-ngを配置し、全ホストがそこを経由してAPTパッケージを取得する構成です。初回アクセスやキャッシュミス時には上流リポジトリへの到達が必要なため、 &style(bold){完全Air Gapではありません} 。帯域節約や更新経路の簡素化が主な目的であり、セキュリティ上のAir Gap要件を満たすものではない点にご注意ください。
境界設計（踏み台リスクの扱い）
パターンB/CのようにPOMやapt-cacher-ngを「社内で唯一の外部接続点」として使う場合、それ自体が攻撃者にとっての侵入経路（踏み台）となるリスクがあります。
現実的には、以下の対策を単独または組み合わせて適用します。
- 更新窓のみ外部接続：通常時は外部接続を完全に遮断し、更新作業時のみ一時的に開放します。
- アウトバウンドのみ許可：インバウンド接続を遮断し、NAT配下に配置します。外部からPOMへの直接アクセスを不可能にします。
- 宛先ホワイトリスト：アウトバウンド通信の宛先を、APTリポジトリやサブスクリプション認証に必要な最小限のFQDNに制限します。
- 媒体搬送（物理分離）：POMをオンライン側のネットワークに配置し、閉域側へはオフラインコピーのみを搬送します。もっとも厳格な分離ですが、運用負荷は高くなります。
ここで重要なのは、「1点でも外部到達があるなら、それはAir Gapではない」と定義するか、「更新窓のみの一時的な接続は許容する」とするか、 組織としての定義を最初に明確にする ことです。この定義が曖昧なまま設計を進めると、後から「これはAir Gapと呼べるのか」という議論が発生し、手戻りの原因になります。
よくある誤解
誤解1：Offline activationがある＝更新も全部オフラインで回る
Offline activationが扱うのは主に「権利情報」のレイヤです。サブスクリプション状態をオフラインで反映できることと、APTパッケージを閉域へ持ち込めることは別の問題です。パッケージの搬送には、POMによるリポジトリミラーや媒体搬送などの別設計が必要です。
誤解2：apt-cacher-ngはWSUSと同じで「完全Air Gap」もいける
Windows Server Update Services（WSUS）はリポジトリの完全なローカルコピーを保持しますが、apt-cacher-ngはキャッシュ・プロキシであり、キャッシュミス時に上流へ取りに行くことが前提の設計です。完全Air Gap環境でのパッケージ搬送の主役は、ミラー/スナップショットによる搬送（POM）です。
誤解3：POMがあれば「どこも外部通信ゼロ」で永遠に更新できる
更新パッケージは外部（Proxmox社/Debian等）で生成されるものですから、どこかの地点・タイミングで必ず取得して持ち込む必要があります。POMは「取得と搬送を効率化する」ツールであり、「外部との接触を完全にゼロにする」ものではありません。更新窓・隔離セグメント・媒体搬送など、何らかの形での外部接触は運用として受け入れる必要があります。