Posted inVirtualization

Proxmox VEでOPNsenseを構築・設定する実践ガイド：仮想化ファイアウォールの本番運用

Virtualization tutorial - IT technology blog
Virtualization tutorial - IT technology blog

仮想マシンが同一サブネットを共有する実質的なリスク

筆者のProxmox VE環境では、12台の仮想マシン（VM）とLXCコンテナが稼働しています。当初は設定の手軽さから、すべてのVMを共通のブリッジvmbr0に接続していました。そのため、全VM、コンテナ、家庭内デバイスがプロバイダのルーターから直接192.168.1.x/24のIPアドレスを取得する構成になっていました。

このフラットなネットワーク構成は、外部公開サービス（ステージング用Webアプリ、Nextcloud、Nginx Proxy Manager）をインターネットに公開するまでは問題なく動作していました。しかし公開からわずか2週間後、自動スキャンボットにステージングコンテナのSSHポートを発見され、毎時12,000回もの総当たり攻撃（ブルートフォースアタック）を受ける事態が発生しました。

攻撃者は即座にコンテナのroot権限を奪取。さらに深刻だったのは、そのコンテナを踏み台にして、Synology NAS、RTSP監視カメラ群、個人のPCへと一切の障壁なく内部スキャンを実行できてしまったことです。このような横移動（ラテラルムーブメント）による侵入拡大は、テスト用コンテナを1台乗っ取られることより遥かに危険です。

家庭用ルーターおよび組み込みファイアウォールの限界

インシデント対応の完了後、既存インフラを見直したところ、主に3つのボトルネックが浮き彫りになりました：

  • プロバイダルーターのネットワーク分離機能の不足: 一般的な市販ルーターはNATセッションテーブルの容量が非常に小さく（大半が8,000セッション未満）、本格的な802.1Q VLANによる論理分離やサブネット間のステートフルインスペクションに対応していません。
  • PVE Firewallの集中管理の難しさ: Proxmoxにはnftables/iptablesベースのpve-firewallが備わっています。しかし、VMやインターフェースごとに個別のルールを手動記述するのは設定ミスの原因になりやすく、トラフィックログの可視化ダッシュボード、IDS/IPSの運用、Unbound DNSの一括管理といった機能も不足しています。
  • 外部ルーター利用時の帯域ボトルネック: 外付けルーター（MikroTik hEXなど）を1GbpsのLANケーブル1本で接続すると、いわゆるRouter-on-a-Stick構成になります。異なるVLANに属する2台のVM間でファイルを転送する際、トラフィックがいったん物理LANケーブルを経由してホストに戻ってくるため、帯域が物理上限の約940Mbpsで頭打ちになります。

Proxmoxにおける3つのルーティング設計

DMZ（公開サービス）、LAN（作業用端末）、Internal（データベースやストレージ）を適切に分離するためには、以下の3つの実装アプローチが考えられます：

  1. 専用の物理ルーター（ハードウェアアプライアンス）: OPNsense専用にミニPCなどを導入する方法。ハードウェアが完全に独立しているため、ルーターに障害が発生してもProxmox本体は影響を受けないメリットがあります。一方、常時稼働による消費電力（15〜25W）の増加、スイッチのポート消費、物理NICのリンク速度に縛られるといったデメリットが存在します。
  2. Debianホスト上でiptables/nftablesを直接構成: メモリ消費を最小限に抑えられます。しかし運用上のリスクが極めて高く、nftablesの構文を1行間違えただけでWeb管理画面（ポート8006）から締め出され、物理ディスプレイとキーボードを直接繋いでレスキュー作業を行う事態に陥ります。
  3. Proxmox上でOPNsenseを仮想化: OPNsenseに仮想Linux Bridgeを割り当て、中核となるゲートウェイおよびファイアウォールとして動作させる手法です。VirtIOドライバによりVLAN間の通信がCPUとメモリ上でダイレクトに処理されるため、一般的な物理LANケーブルを大幅に超える高速なスループットを実現できます。

Proxmox VEへのOPNsenseインストール・設定手順

6か月以上にわたる実運用において、OPNsenseの仮想化構成は既存の同一ハードウェアで最大のパフォーマンスを発揮しました。高価な10GbE NICを追加導入することなく、VM間のスループットは12〜15Gbpsに達しています。

ステップ1: ProxmoxホストでのLinux Bridgeの作成

最小構成として、2つの独立したブリッジを用意します：

  • vmbr0: WANポート。インターネットへ抜けるため、ホストの物理NICに直接バインドします。
  • vmbr1: 内部LANポート。物理ポートを割り当てず（bridge-ports none）、完全な仮想内部スイッチとして機能させます。

Proxmoxホストの/etc/network/interfacesを編集するか、GUI（ノード -> システム -> ネットワーク）から設定します：

auto lo
iface lo inet loopback

iface eno1 inet manual
# サーバーの物理NIC

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
# WANブリッジ - 外部モデム/ルーターへ接続

auto vmbr1
iface vmbr1 inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0
# 仮想LANブリッジ - ホスト内部通信専用

サーバーを再起動せずに設定を即座に反映します：

ifreload -a

ステップ2: OPNsense仮想マシンの作成

OPNsense公式サイトからamd64アーキテクチャのISOイメージ（dvdイメージ）をダウンロードし、ProxmoxのISOストレージにアップロードします。続いて、以下の標準構成でVMを作成します：

  • 全般: VM名を入力（例: OPNsense-Gateway）、起動時に開始にチェックを入れ、起動順序: 1に設定。
  • OS: アップロードしたOPNsenseのISOを選択、種別: Other。
  • システム: Qemuエージェント: 有効、SCSIコントローラ: VirtIO SCSI single。
  • ディスク: バス: SCSI、ディスクサイズ: 32GB。SSD/NVMe運用の場合はDiscardを有効化。
  • CPU: 2 vCPU。CPU種別をhostに変更してAES-NIハードウェア暗号化アクセラレーションを認識させ、OpenVPN/WireGuardの処理を高速化。
  • メモリ: 4096 MiB。Ballooningデバイスのチェックは必ず外すこと。動的なメモリ割り当てはFreeBSDカーネルの予期せぬクラッシュを引き起こす原因になります。
  • ネットワーク:
    • NIC 1（WAN）: ブリッジ vmbr0、モデル VirtIO (paravirtualized)。
    • VM作成後、ハードウェア -> 追加 -> ネットワークデバイス からNIC 2（LAN）を追加: ブリッジ vmbr1、モデル VirtIO。

ステップ3: OSのインストールとインターフェースの割り当て

VMを起動し、Proxmoxのコンソールタブを開きます：

  1. ライブ環境が起動したら、ユーザー名installer、パスワードopnsenseでログインします。
  2. キーボードレイアウトを選択後、Install (ZFS)またはInstall (UFS)を選択します。単一ディスクのVM構成であれば、UFSが最も安定しておりメモリ消費も軽量です。
  3. インストールが完了したらRebootを選択します。その際、仮想CD/DVDドライブからISOファイルをアンマウントしてください。
  4. 再起動後、コンソールに13項目のメニューが表示されます。キーボードの1を押してインターフェースを割り当てます：
    • Do you want to configure LAGGs now? Nを選択。
    • Do you want to configure VLANs now? Nを選択。
    • WAN interface: vtnet0に割り当て（vmbr0に接続）。
    • LAN interface: vtnet1に割り当て（vmbr1に接続）。
  5. 2を押してLANポートのIPアドレスを設定します：
    • 新しいゲートウェイIPを入力: 10.0.0.1、サブネットマスクのビット数: 24。
    • DHCPサーバーの有効化: Yを選択し、割り当て範囲を10.0.0.100から10.0.0.200に指定。

ステップ4: VirtIO Offloadの無効化（極めて重要）

KVM/QEMU上で稼働するFreeBSDは、VirtIOドライバのハードウェアオフロード機能と競合を起こしやすい傾向があります。よく見られる症状として、Pingは通るのにWebページの読み込みが極端に遅くなり、パケットロスが40〜60%に達します。必ず以下の設定を行ってください：

  1. テスト用のVM（UbuntuまたはWindows）を作成し、ネットワークをvmbr1に接続します。これにより10.0.0.xのIPが自動取得されます。
  2. そのVMのブラウザからhttps://10.0.0.1にアクセスし、rootユーザーでログインします。
  3. Interfaces -> Settings へ移動します。
  4. Hardware Acceleration項目で、ハードウェアオフロードを無効化するために以下の3項目すべてにチェックを入れます：
    • Disable Hardware Checksum Offload
    • Disable Hardware TCP Segmentation Offload
    • Disable Hardware Large Receive Offload
  5. Saveをクリックし、OPNsenseを再起動して設定を適用します。

ステップ5: 安全なDMZとポートフォワーディングの構築

この段階で、ネットワーク境界は明確に分離されています：

  • 内部VM（Database、Graylog、NAS）はvmbr1のみに接続されているため、インターネット上のボットネットによるスキャンから完全に隔離されます。
  • Webアプリを外部公開する必要がある場合は、Firewall -> NAT -> Port Forward でルールを作成し、WAN IPのポート443をNginx Proxy Managerの内部IPへ正確にフォワードします。
  • サービスグループをさらに拡張したい場合も、同一の仮想スイッチvmbr1上でOPNsenseにVLANタグ（例: VLAN 20 DMZ、VLAN 30 IoT）を割り当てるだけで対応可能です。

6か月間の実運用データ

半年間の連続稼働における実測値は以下の通りです：

  • 信頼性: カーネルパニックゼロで182日間の連続稼働を記録。ファームウェアアップグレード時の再起動所要時間はわずか38〜45秒でした。
  • リソース消費量: OPNsenseの動作は極めて軽量です。CPU使用率は平均0.8%〜2.5%で推移し、メモリ消費量は約950MBで安定（Unbound DNSおよび150,000ドメインの広告ブロックリストを有効化した状態）。
  • iperf3によるスループット測定: OPNsenseを経由した異なるサブネットのVM間スループットは11.4Gbpsを記録しました。これは外部の1Gbps物理ルーターを経由した場合と比較して約12倍の高速通信です。

現場運用の教訓：ProxmoxのWeb GUI（ポート8006）は、必ず独立した物理NICの静的IPで待ち受けるようにしてください。Proxmoxホストへのアクセスを仮想OPNsenseのDHCPサービスに依存させる設計は厳禁です。万が一ファイアウォールVMの起動に問題が生じても、管理画面へのアクセス権を常に確保しておくことが重要です。

Share:
Tags: