「ネットワーク仮想化」をセールスやマーケティングではなく、エンジニアとしてアーキテクチャを正しく理解することが、今回のブログシリーズ「ネットワーク仮想化をネットワークの基本から理解する」のテーマです。最終回「第4回：分散ファイアウォール -Layer4 の世界」では、ネットワーク仮想化環境でのセキュリティを見ていきます。
■ 目次
・はじめに
・物理ネットワーク環境におけるセキュリティ
・ネットワーク仮想化環境におけるセキュリティ
・物理ネットワーク環境とネットワーク仮想化環境の比較
・補足情報
■ はじめに
仮想化環境でのセキュリティを検討するとき、適用するポイントには、仮想マシン、ハイパーバイザ、物理ネットワークと3つのポイントが考えられます。この中で管理性とセキュリティの粒度を考えたとき、最も適したポイントはどこになるでしょうか。
一般的に、よりサービスに近い方が粒度の細かいセキュリティポリシーの適用が可能になります。仮想マシンは最もサービスに近いポイントとなりますが、個々の仮想マシンにセキュリティを適用していくのは運用管理上のオーバヘッドが大きいことに加え、ゲストOSが乗っ取られた場合はセキュリティ機能そのものを停止されてしまう可能性があります。
一方で物理ネットワークではどうでしょうか。物理ネットワークでのセキュリティは、L2 のネットワークセグメント境界を通るトラフィックにかけることになります。この方式では、セキュリティの適用ポイントが仮想マシンから離れることで、同一L2 ネットワークセグメント内における仮想マシン間の通信制御は困難です。
パイパーバイザでセキュリティを適用することで、従来のL2 ネットワークセグメント境界にとらわれない柔軟なセキュリティの実装が可能になります。しかしながら個々のハイパーバイザにセキュリティを適用することで運用管理上のオーバヘッドが大きくなってしまっては意味がありません。
VMware NSX の提供する分散ファイアウォール（FW）は、ハイパーバイザ上でセキュリティを提供します。分散FW の設定はNSX Manager から行うことができます。従来のFW と同じように送信元、宛先、サービスと、アクションを指定することができます。各項目は、vCenter のオブジェクト単位（仮想マシン、クラスタ、リソースプール等）で指定することが可能で、従来のIPアドレス単位の管理と比べた際に運用管理の負担を大きく軽減することができます。
また、GUIからだけではなくAPIを介した設定が可能となり、クラウドマネジメントプラットフォームと連携させることで設定作業そのものの自動化が可能になります。例えば、仮想マシンを展開すると同時にセキュリティポリシーを適用するといった運用が可能になります。
分散FW は、第2回の論理スイッチ（VXLAN）、第3回の分散ルーティングと同様にハイパーバイザを活用することで、仮想化環境に最適なセキュリティを提供します。前回と同様に、物理の世界との比較を「テーブル」の観点から見ていきたいと思います。
■ 物理ネットワーク環境におけるセキュリティ
物理ネットワーク環境でのセキュリティは、FW やL3スイッチ（ルータ） といった物理ネットワーク機器に実装します。FW は外部ネットワークとの境界に設置され、フィルタリングのルールを記載したフィルタリングテーブルを持っています。また、L3スイッチやルータの セキュリティ機能として、ACL（Access Control List）があります。
L3スイッチでは、専用のコマンドラインからACL の設定を行い、設定の確認もコマンドラインから実施します。例えばL3スイッチのACL を確認するには、以下のコマンドを実施します。
|
1 2 3 4 5 |
# show access-list permit ip host “送信元IPアドレス” host “宛先IPアドレス” permit tcp host “送信元IPアドレス” host “宛先IPアドレス” eq “ポート番号” permit udp host “送信元IPアドレス” “宛先ネットワークアドレス” eq “ポート番号” permit icmp any any |
出力から送信元、送信先のアドレス、及びプロトコルタイプを指定したテーブルを確認できます。このフィルタリングテーブルにより、L3 スイッチを経由するトラフィックに対してセキュリティをかけることが可能になります。ACL はステート情報を管理しない、ステートレスなセキュリティ機能となるため、フィルタリング情報は双方向の通信に対して明記します。
一方、FW の提供するステートフルなセキュリティ機能では、フィルタリングテーブルとは別に、通信のフロー情報を管理するためのステートテーブルを持ちます。通信が発生した際にステートテーブルがダイナミックに作成されます。
例えばTCP ステートテーブルでは、送信元IPアドレス、ポート番号、宛先IPアドレス、ポート番号、TCPステート情報、タイムアウト値等が含まれます。この情報を基に、対応する戻り方向の通信を自動的に許可し、適合しない不正な通信をブロックすることができます。
フィルタリング及びステート管理の考え方 はネットワーク仮想化環境になっても変わりませんが、ネットワーク仮想化環境では物理ネットワーク機器の持つセキュリティ機能を、分散FW としてハイパーバイザに実装することができます。分散FW のアーキテクチャについて、「テーブル」に注目する形でこの後見ていきます。
■ ネットワーク仮想化環境におけるセキュリティ
分散FW は、L2 – L4レベルのステートフルなFW 機能をハイパーバイザで提供します。個々のハイパーバイザ内でセキュリティ機能を提供することで、処理を分散して行うことのできるスケールアウト型のアーキテクチャになります。
分散FW も、従来の物理環境のセキュリティ製品と同様に内部にフィルタリングテーブル（ルールテーブル）を持っています。フィルタは、仮想マシンの仮想NICとハイパーバイザの間にあるdvfilterと呼ばれるポイントに適用されます。これにより、L2 ネットワーク境界にとらわれない粒度の細かいセキュリティの実装（マイクロセグメンテーション）が可能になります。
ハイパーバイザ上で、dvfilterに適用されているフィルタリングテーブルを確認することが出来ます。ESXi ホストにログインし、仮想マシン（web-sv-01a）に適用されているフィルタリング情報を確認します。
# summarize-dvfilter
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
# summarize-dvfilter world 145244 vmm0:<span style="color: #fe9a2e;">web-sv-01a</span> vcUuid:'50 26 c7 cd b6 f3 f4 bc-e5 33 3d 4b 25 5c 62 77' port 50331662 web-sv-01a.eth0 vNic slot 2 name: <span style="color: #fe9a2e;">nic-145244-eth0-vmware-sfw.2</span> agentName: vmware-sfw state: IOChain Attached vmState: Detached failurePolicy: failClosed slowPathID: none filter source: Dynamic Filter Creation vNic slot 1 name: nic-145244-eth0-dvfilter-generic-vmware-swsec.1 agentName: dvfilter-generic-vmware-swsec state: IOChain Attached vmState: Detached failurePolicy: failClosed slowPathID: none filter source: Alternate Opaque Channel |
上記出力から、仮想マシン（web-sv-01a）に対応したフィルタ（nic-145244-eth0-vmware-sfw.2）を確認し、仮想マシンに適用されているフィルタリングテーブル（ルールテーブル）を下記コマンドで確認します。
# vsipioctl getrules -f フィルタ名
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# vsipioctl getrules -f <span style="color: #fe9a2e;">nic-145244-eth0-vmware-sfw.2</span> ruleset domain-c25 { # Filter rules rule 1006 at 1 inout protocol tcp from addrset <span style="color: #fe9a2e;">ip-vm-33</span> to addrset <span style="color: #fe9a2e;">ip-vm-36</span> port 22 accept with log; rule 1005 at 2 inout protocol any from any to addrset ip-ipset-2 accept; rule 1004 at 3 inout protocol ipv6-icmp icmptype 135 from any to any accept; rule 1004 at 4 inout protocol ipv6-icmp icmptype 136 from any to any accept; rule 1003 at 5 inout protocol udp from any to any port 67 accept; rule 1003 at 6 inout protocol udp from any to any port 68 accept; rule 1002 at 7 inout protocol any from any to any reject with log; } ruleset domain-c25_L2 { # Filter rules rule 1001 at 1 inout ethertype any from any to any accept; } |
分散FW は、vCenter のオブジェクト単位（仮想マシン、クラスタ、リソースプール等）で設定することができます。オブジェクトに含まれる仮想マシンは、仮想マシンにインストールされたVMware Tools によりIP アドレスに変換して適用されます。オブジェクトとIPアドレスの対応は下記で確認ができます。なお、オブジェクト名（ip-vm-33 等）はvCenter のMoRef（Managed Object Reference）に対応しています。
# vsipioctl getaddrsets -f フィルタ名
|
1 2 3 4 5 6 7 8 9 10 |
# vsipioctl getaddrsets -f <span style="color: #fe9a2e;">nic-145244-eth0-vmware-sfw.2</span> addrset ip-ipset-2 { ip 192.168.110.10, } addrset <span style="color: #fe9a2e;">ip-vm-33</span> { ip 172.16.10.12, } addrset <span style="color: #fe9a2e;">ip-vm-36</span> { ip 172.16.10.11, } |
また、分散FW はフロー情報を管理するステートフルなファイアウォール機能を提供します。ステート情報は、ステートテーブル（コネクショントラッカーテーブル）で管理されています。コネクショントラッカーテーブルを表示させる際はFlow Monitoring を有効にします。下記の例では、SSHを許可するルールに対応したステート情報が管理されていることが分かります。
# vsipioctl getflows -f フィルタ名
|
1 2 3 |
# vsipioctl getflows -f <span style="color: #fe9a2e;">nic-145244-eth0-vmware-sfw.2</span> Count retrieved from kernel active(L3,L4)=3, active(L2)+inactive(L3,L4)=0, drop(L2,L3,L4)=0 558a796d00000000 Active tcp 0800 1 1006 0 0 172.16.10.12:Unknown(44194) 172.16.10.11:ssh(22) 2413 EST 3017 2957 19 18 |
テーブル情報は、仮想マシンがvMotion で異なるESXi ホスト上に移動した際も仮想マシンに追従して適用されます。これによりvMotion 後もサービスを継続することが可能です。
■ 物理ネットワーク環境とネットワーク仮想化環境の比較
物理ネットワーク環境では、フィルタリングテーブルは物理ネットワーク機器が持ち、単一のポイントでフィルタリングの処理を実施します（集中処理）。また、複数のポイントでセキュリティを適用するような構成では、個々の物理ネットワーク機器に対して設定作業を行うことになります（分散管理）。
分散FW は仮想化環境のセキュリティを、適切なポイントで、運用管理性を損なわずに実現しています。各テーブルの情報を確認してみると、従来の物理ネットワーク環境で物理ネットワーク機器が持っているのと同等の情報をハイパーバイザの中で管理していることが分かります。
ポイント1 ハイパーバイザでテーブル情報を持つことで、ネットワークセグメント境界にとらわれない粒度の細かいセキュリティを実装できる（マイクロセグメンテーションの実装）
また、サーバが増えるのに比例して処理するポイントも増えるスケールアウト型のアーキテクチャになります。
ポイント2 ホストの増加に比例して処理するポイントが増える、拡張性のあるスケールアウト型のアーキテクチャを取ることができる（データプレーンにおける分散処理）
分散FW 環境のセットアップは、NSX Manager を介して、GUI もしくはAPI 経由で簡単に行うことが出来ます。
ポイント3 NSX Manager から一括して設定管理を行うことで、運用管理性を損なうことなく容易に実装できる（マネジメントプレーンにおける集中管理）
ネットワーク仮想化環境における分散FW は、分散処理、集中管理のアプローチをとることで、運用管理性を維持しつつ、ネットワークセグメント境界にとらわれない粒度の細かいセキュリティ（マイクロセグメンテーション）を実装することを可能にしています。
ネットワークサービスは、トラフィックのフローと、フローを制御する「テーブル」から成り立ちます。この「テーブル」にフォーカスして見ていくと、物理ネットワーク環境で管理していたテーブルと同じ情報が、ネットワーク仮想化環境では異なるレイヤー（ハイパーバイザ）で管理されていることが分かります。ハイパーバイザを活用するアプローチは、今までの物理ネットワーク環境でユーザが得られなかった利便性を提供することを可能にします。
シリーズを通して、「ネットワーク仮想化」は既存のテクノロジーと断絶したものではなく、従来の仮想化及びネットワークテクノロジーの延長線上にあることを説明してきました。「ネットワークエンジニア」も「仮想化エンジニア」も、それぞれのバックグラウンドを活かしつつ、「ネットワーク仮想化」を通して新しい分野のスキルを身につけることができます。従来の役割分担にとらわれない、新しい世界に入る一つのきっかけとして本シリーズを活用いただけますと幸いです。
■ 補足情報 分散FW を提供するVMware NSX のコンポーネント
分散FW 環境で、NSX を構成する各コンポーネントがどういった役割を果たしているのか解説を行います。
・NSX Manager（マネジメントプレーン）
NSX を構築する際に最初に展開するコンポーネントで、仮想アプライアンスとして提供されています。NSX Manager は初期構築時に ESXi ホストへのカーネルモジュールのインストールを担います。また、NSX Manager はAPI のエントリポイントとなり、GUI だけでなくAPI 経由でNSX 環境の設定を可能にします。
・NSX コントローラクラスタ（コントロールプレーン）
NSX コントローラクラスタは分散FW に関与しません。分散FW はコントロールプレーンのコンポーネントを使用しません。
・論理ルータコントロールVM（コントロールプレーン）
論理ルータコントロールVM は分散FW に関与しません。分散FW はコントロールプレーンのコンポーネントを使用しません。
・ハイパーバイザ カーネルモジュール（データプレーン）
NSX 環境を構築する際、ホストの準備のステップで各ESXi にインストールされるカーネルモジュールとなります。VIB(vSphere Installation Bundle)ファイルとしてインストールされ、分散FW ではカーネルモジュール（vsip）としてロードされます。カーネルモジュールは、ハイパーバイザ内で分散FW のテーブルの管理とフィルタリング処理を行います。
ハイパーバイザからは、NSX Manager にコネクションを張り、NSX Manager からフィルタリングテーブル（ルールテーブル）を受け取ります。 NSX Manager へのコネクションはUWA vsfwd(TCP/5671)を介して確立します。
|
1 2 3 4 |
# esxcli network ip connection list | grep 5671 Proto Local Address Foreign Address State World Name ----- -------------------- -------------------- ----------- ---------- tcp 192.168.210.51:23251 192.168.110.42:5671 ESTABLISHED vsfwd |
上記出力より、ESXi ホストの管理用IP アドレスからNSX Manager に、vsfwd を介して接続していることが確認できます。NSX Manager からは分散FW の設定情報（ルールテーブル）を取得します。
ルールテーブルは、仮想マシンがvMotion で異なるESXi ホスト上に移動した際も仮想マシンに追従して適用されます。これによりvMotion 後もサービスを継続することが可能です。
補足情報：NSX 6.1.2 以前のバージョンで、vMotion 実行後にコネクションが切断される事象が報告されています。オンラインのハンズオン環境（バージョン6.1.1）で動作確認される場合この不具合が該当します。詳細は下記KBを参照ください。
Performing VMware vMotion migration when using VMware NSX for VMware vSphere 6.1.2 and earlier Distributed Firewall causes virtual machines to lose network connectivity for 30 seconds (2096529)
・NSX Edge（データプレーン）
仮想アプライアンスとして提供され、単体で各種ネットワークサービス機能（ロードバランサ、ルーティング、NAT、ファイアウォール、VPN、 DHCP 等）を提供する「スイスのアーミーナイフ」のようなコンポーネントです。従来の物理のネットワーク機器が仮想アプライアンスとして置き換わったイメージです。分散FW 機能には関与せず、アプライアンス単体でFW 機能を提供します。
■関連リンク
今回ご紹介した内容をオンラインのハンズオン環境上で確認することができます。コマンドラインの出力はハンズオン環境をベースに作成しています。
http://labs.hol.vmware.com/HOL/
VMware HOL Online
HOL-SDC-1403 – VMware NSX Introduction
NSX の機能全般及び、ネットワーク仮想化環境の設計に興味のあるかたは下記テックペーパーを参照ください。
http://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf
VMware® NSX for vSphere (NSX-V) Network Virtualization Design Guide
ネットワーク仮想化をネットワークの基本から理解する
第1回：理解するために必要なことを整理する
第2回：論理スイッチ（VXLAN）–Layer2 の世界
第3回：分散ルーティング –Layer3 の世界
第4回：分散ファイアウォール -Layer4 の世界（本稿）
