仮想マシンのネットワーク設定って大変!?
近年、Linuxを使用した仮想化が様々な場所で用いられるようになってきています。
仮想デスクトップ環境を作成した場合、基本的なセキュリティ設定は各仮想マシン内で出来ますが、ユーザーによって解除されてしまう可能性があります。また、古いOSを延命利用する場合等は仮想マシンのセキュリティに問題が起きている可能性が高くなります。
そういった危機を回避するため、仮想マシンのホストOSによって仮想マシンの通信を制御する方法をご紹介します。
1. 仮想マシンにおけるネットワークの種類
仮想マシンのネットワーク構築は、物理マシンのネットワーク構築と基本は同じです。仮想マシン毎に仮想インターフェースが渡されて、そこにIPアドレスを与え、通信を行います。違いが出る点は繋がり方です。
一般的な仮想マシンハイパーバイザーである、VMware ESXiとXenserverでは、内部に仮想HUBを作成し、仮想HUBの上流に物理インターフェースを、下流に仮想マシンのインターフェースを接続する流れになります。
デフォルトでは物理ネットワークと同じセグメントに配置する事になります。複雑なネットワーク構成の際には仮想HUBを増やし、仮想マシンルーターを作成してセグメント管理等を行います。
Linux + KVM + libvirtdの場合では一般的に二つの接続方法が存在します。
一つはブリッジインターフェースが仮想マシンのみと接続し、NATで仮想ネットワークと物理ネットワークのルーティングを行う方法です。この方式は、既存のネットワークを変更する必要がないため、VMware Server等で用いられています。
NAT方式だと必然的に仮想マシンのセグメントと物理ネットワークのセグメントが別になります。セグメントが変わることによって外部から直接アクセスするのは難しくなります（スタティックルートで通じる事は通じる）
メリット：
既存のネットワークに変更がない。物理ネットワークのセグメントが変わっても仮想ネットワークの設定に変更がない。デメリット：
物理ネットワークからのアクセスが難しくなる。物理ネットワークの共有空間の検索等ができない
もう一つはブリッジインターフェースが物理NIC、仮想マシンの両方と接続する方法です。基本的にOSをインストールした直後は物理NICにネットワーク設定が行われているため、設定の変更が必要になります。
また、XenserverやVMwareとは違い、単独のインターフェースにぶら下がるため、内部で独立したネットワークを構築する事は出来ません。
そのため、仮想マシンは物理ネットワークと同じセグメントに属する事になります。
メリット：
物理ネットワークからアクセスが容易である。物理ネットワークの共有空間の検索が可能。デメリット：
既存のネットワーク設定を変更する必要がある。物理ネットワークのセグメントが変更された場合、全ての仮想マシンの設定を変更する必要がある。
※OpenFlowを用いることで、KVMでも仮想ネットワークの構築が可能かもしれませんが、今回は検証できていないため除外しています。
2. ホストOSによる通信制御
ホストOSによる通信制御ですが、今回はiptablesを使用します。NAT接続方式の場合はlibvirtdによってiptablesの先頭にNATセグメントの通信を許可する設定が追加されます。iptablesを再起動する事で解除できますが、マシンの再起動時のことを考えNAT接続方式ではホストによる通信制御は難しいと判断しました。
ブリッジ接続方式の場合は特別な設定が必要になります。XenserverやVMware ESXIに似たような機能があるか探したところ、以下の結果になりました。
3. 設定方法
ブリッジ接続の場合はOSの基本設定によって、iptablesを通過します。
/etc/sysctl.confに以下の記述を行う事でこれを解除します。
net.bridge.bridge-nf-call-iptables = 1
sysctlの設定読み込みに以下のコマンドを実行します。
# sysctl -p /etc/sysct.conf
これを行うとブリッジの通信もiptablesのポリシーに従うため、設定次第では仮想マシンが外部と通信できなくなるので、十分に注意する必要があります。
iptablesでブリッジ通信を指定する時に以下のオプションが必要になります。
-m physdev –physdev-is-bridged
例１：特定アドレスからのhttp要求を拒否する場合-A FORWARD -s xxx.xxx.x.xxx -m physdev –physdev-is-bridged -p tcp –dport 80 -j REJECT例２：全てのブリッジ通信を許可する場合-A FORWARD -m physdev –physdev-is-bridged -j ACCEPT
今回店頭のデモ環境では、実験のデモとして二つの仮想マシンを起動し、ホストOSのiptablesでそれぞれhttp、httpsの通信を制限してあります。制御した通信はログに残る設定になっておりますのでぜひ店頭でご覧ください。
最後に
今回、ホストOSで制御するという内容でお送りしました。環境を構築する上でXenserverやVMwareではホストOSが管理する設定は余り見受けられませんでした。ただ、XenserverやVMwareの機能は複数台での分散起動等を想定しており、複数の物理インターフェースにまたがる仮想ネットワークを構築しソフトウェアで制御を行う運用もあります。
そういった点を考えると、複数台運用の妨げになるため実装していない可能性もあります。libvirtdとほかのソフトウェアを組み合わせる事でXenserverやVMwareの構成に何処まで近づけられるか、今後も検証を行って参ります。