Proxmox VE向け仮想ルーターの選択肢：一般的なアプローチの比較
Proxmox Virtual Environment（PVE）上で分離されたステージング環境やホームラボを構築する際、適切なルーティングソフトウェアの選定は仮想ネットワークトポロジーの基盤を決定づけます。本番環境や検証クラスタを問わず、主に以下の3つの仮想化アプローチが用いられます。
- Linuxブリッジと生のiptables/nftablesの組み合わせ: 柔軟性が極めて高く、ホストカーネルネイティブで動作しますが、ファイアウォールポリシー、ルーティングテーブル、VLANが大規模化するにつれて運用管理が困難になります。
- FreeBSDベースのファイアウォール（pfSense / OPNsense）: 優れたステートフルインスペクション、直感的なWebGUI、強固なコミュニティサポートを備えています。ただし、動的なキャリアグレードのルーティングやISPスタイルのラボシミュレーションよりも、セキュリティアプライアンスとしての設計に重点が置かれています。
- MikroTik Cloud Hosted Router (CHR): ハイパーバイザー（KVM、Proxmox、VMware、Hyper-V）向けに特化して設計されたRouterOSバージョンです。極めて少ないリソース消費で、真のL3スイッチング制御、ポリシールーティング、MPLS、OSPF、BGP、WireGuard、CAPsMANを提供します。
機能・スペック比較
Proxmox上でホストした場合の一般的なアプローチの比較は以下のとおりです。
| 機能 / 指標 | Linuxブリッジ + IPTables | pfSense / OPNsense | MikroTik CHR |
|---|---|---|---|
| 必要メモリ | ホストネイティブ（追加約0 MB） | 1024 MB – 2048 MB | 128 MB – 256 MB |
| ストレージ容量 | なし（ホスト領域を使用） | 8 GB – 20 GB | 1 GB – 2 GB（RAWディスクイメージ） |
| 起動時間 | 即時 | 45 – 90 秒 | 3 – 5 秒 |
| 対応ルーティングプロトコル | FRRまたはBirdが別途必要 | プラグイン経由の基本的なBGP/OSPF | ネイティブRouterOSコア（BGP、OSPF、MPLS、VPLS） |
| 管理UI | Bash / Systemd | Webブラウザ | WinBox GUI、WebFig、SSH、API |
Proxmox上でMikroTik CHRを運用するメリットとデメリット
ハイパーバイザー内部に仮想ルーターを導入することにはアーキテクチャ上のトレードオフが伴うため、その上に仮想ネットワーク全体を構築する前に分析しておく価値があります。
メリット
- 圧倒的な軽量リソース設計: RouterOS CHRは、仮想ネットワーク内でギガビットレートのパケットをルーティングするのに、わずか1基の仮想CPUと128 MB〜256 MBのRAMしか必要としません。
- ネイティブなWinBoxによる管理: WinBoxデスクトップユーティリティにより、ブラウザのキャッシュ遅延なしに、リアルタイムのトラフィックグラフ表示、即座のパケットスニッフィング、セーフモードでの確実な設定変更が可能です。
- 寛容な無料枠: 無料のCHRライセンスは、有効期限の制限なしにすべてのエンタープライズ向けソフトウェア機能を利用でき、インターフェースあたり1 Mbpsの帯域制限のみが適用されます。この帯域制限は、安価なP1永久ライセンスを購入する前にルーティングプロトコル、アクセスリスト、VPNトンネルをテストするには十分です。
- ハードウェア非依存のバックアップ: Proxmox内のスナップショットおよびディスクエクスポート機能により、RouterOSのメジャーアップデート適用前のロールバックが容易に行えます。
デメリット
- ハイパーバイザーへの依存: 冗長化された高可用性（HA）クラスタを運用していない限り、Proxmoxノードが再起動したり停電したりすると、ルーティングインフラ全体がオフラインになります。
- デフォルトトライアル時の1 Mbps帯域制限: 完全な速度検証を行うには、60日間のトライアル登録を行うか、手頃な有料ライセンスを購入する必要があります。
- KVMイメージ導入のハードル: MikroTikはProxmox用の公式ISOインストーラーを配布していないため、導入にはPVEのコマンドライン経由でrawディスクイメージをインポートする作業が必要です。
Proxmoxネットワーク検証環境の推奨アーキテクチャ
実践的な経験から言えば、これは再現可能なステージング環境を設計する上で習得しておくべき必須スキルの1つです。すべての仮想マシンをホームLANに直接ブリッジするのではなく、物理ネットワークと内部のプライベートブリッジの間の境界ルーターとしてMikroTik CHRを配置するのが理想的なアーキテクチャです。
最大限の分離と柔軟性を実現するアーキテクチャパターンは以下のとおりです。
- WANインターフェース（vmbr0）: 物理ネットワークインターフェース（`eth0`または`eno1`）に接続します。CHRはホームルーターや上位ゲートウェイからDHCP経由でIPを取得します。
- LAN / 分離ラボブリッジ（vmbr1）: 物理ネットワークポートを割り当てずにProxmox内部で作成された、内部専用の非ブリッジ仮想インターフェースです。すべての検証用仮想マシンやコンテナはこのブリッジに接続します。
- 管理 / DMZブリッジ（vmbr2、オプション）: 外部公開用のリバースプロキシや隔離されたワークロードを検証するために確保された個別のブリッジです。
すべてのトラフィックをCHR経由でルーティングすることで、ローカルの物理ネットワークに影響を与えることなく、厳格なファイアウォールフィルタルールの適用、トラフィックの監視、WAN障害のシミュレーションが可能になります。
ステップバイステップ導入ガイド
Proxmox上での仮想マシンのプロビジョニングと、RouterOSでのベースラインネットワーク設定の手順を順を追って進めましょう。
ステップ 1: 分離されたProxmoxブリッジを作成する
まず、Proxmoxホストに物理イーサネットポートに紐付けられていない内部仮想ブリッジが存在することを確認します。CLI経由で既存のネットワーク設定を確認できます。
cat /etc/network/interfaces専用の内部ブリッジがまだ存在しない場合は、/etc/network/interfacesの末尾に以下の記述を追加して`vmbr1`を作成します。
auto vmbr1
iface vmbr1 inet manual
bridge-ports none
bridge-stp off
bridge-fd 0
# 仮想内部ラボブリッジホストを再起動せずに変更を即時反映します。
ifreload -aステップ 2: MikroTik CHRディスクイメージのダウンロードと展開
SSHでProxmoxサーバーに接続します。一時ディレクトリに移動し、MikroTikのソフトウェアリポジトリからRAWディスクイメージをダウンロードします。RouterOS v7が現在の安定版（Stable）ブランチです。
cd /tmp
wget https://download.mikrotik.com/routeros/7.16.1/chr-7.16.1.img.zip
# RAWディスクイメージを展開
apt-get install -y unzip
unzip chr-7.16.1.img.zipステップ 3: 仮想マシンの外枠を作成する
qmユーティリティを使用して空のVMシェルをプロビジョニングします。この例ではVM IDとして900を使用します。
qm create 900 \
--name "MikroTik-CHR" \
--memory 256 \
--cores 1 \
--cpu host \
--net0 virtio,bridge=vmbr0 \
--net1 virtio,bridge=vmbr1 \
--ostype other \
--onboot 1 \
--boot order=scsi0ステップ 4: ディスクイメージのインポートとVMへのアタッチ
展開したイメージを対象のProxmoxストレージプールに直接インポートします（ストレージバックエンドに応じてlocal-lvmをlocal-zfsやcephに適宜置き換えてください）。
qm importdisk 900 chr-7.16.1.img local-lvmディスクのインポートが完了したら、VirtIO SCSIを使用してSCSIコントローラー0にアタッチします。
qm set 900 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-900-disk-0ストレージ領域を圧迫しないよう、ダウンロードしたインストーラーファイルを削除します。
rm -f /tmp/chr-7.16.1.img /tmp/chr-7.16.1.img.zipステップ 5: ルーターの起動と初期セットアップ
ProxmoxのCLIから仮想ルーターを起動します。
qm start 900Proxmox Web UIからVM 900のコンソールを開きます。以下のデフォルト認証情報でログインします。
- ログイン名:
admin - パスワード: （デフォルトではパスワードが設定されていないため、Enterキーを押します）
ライセンス契約の表示を求められたらnを押し、プロンプトが表示されたら安全な管理者パスワードを設定します。
ステップ 6: インターフェース、アドレッシング、NATマスカレードの設定
コンソール内で以下の初期RouterOSコマンドを実行し、インターフェース名の分かりやすい設定、内部ゲートウェイIPの割り当て、検証用マシン向けのインターネット接続の有効化を行います。
# 1. 識別しやすいようにインターフェース名を変更
/interface set ether1 name=ether1-WAN
/interface set ether2 name=ether2-LAN
# 2. WAN側でDHCPクライアントを設定
/ip dhcp-client add interface=ether1-WAN disabled=no
# 3. 内部ラボブリッジに静的ゲートウェイアドレスを割り当て
/ip address add address=10.10.10.1/24 interface=ether2-LAN
# 4. ラボ内クライアント向けの内部DHCPプールとサーバーを作成
/ip pool add name=lab-pool ranges=10.10.10.50-10.10.10.200
/ip dhcp-server add name=lab-dhcp interface=ether2-LAN address-pool=lab-pool disabled=no
/ip dhcp-server network add address=10.10.10.0/24 gateway=10.10.10.1 dns-server=1.1.1.1,8.8.8.8
# 5. ラボ内VMがインターネットに接続できるよう送信元NAT（マスカレード）を有効化
/ip firewall nat add chain=srcnat out-interface=ether1-WAN action=masquerade
# 6. 内部名前解決用にDNSキャッシュを有効化
/ip dns set allow-remote-requests=yes servers=1.1.1.1,8.8.8.8ステップ 7: アウトバウンド接続の確認
CLIから直接簡単なpingを実行し、RouterOSが上位ネットワークと正常に通信できているかをテストします。
/ping 1.1.1.1 count=4これで、vmbr1に接続された新しい仮想マシンやLXCコンテナは自動的に10.10.10.0/24サブネットのIPを受信するようになり、ローカルの物理環境からファイアウォールで完全に隔離された状態で仮想MikroTikルーター経由で通信できるようになります。
