「偽装転送」ポリシーでフレームがドロップされる仕組み

Table of contents

はじめに

今回の記事では仮想スイッチの「偽装転送」ポリシーについて動作の概要や、ポリシー違反が発生する具体的なケースを見ていきます。

「偽装転送」ポリシーにより仮想マシンから送信されるフレームの送信元 MAC アドレスのなりすましを防ぐことが可能になります。ただし、特定のネットワーク構成では本ポリシーを「承諾」とする必要があります。

「偽装転送」ポリシー

「偽装転送」ポリシーは仮想マシンから送出されるフレームのうち、送信元 MAC アドレスが書き換えられているフレームをドロップする機能です。具体的には以下の2つの MAC アドレスが一致しない場合は仮想マシンから送信されるフレームをドロップします。

• 送出されたフレームの送信元 MAC アドレス
• 仮想ネットワークアダプタの有効な MAC アドレス

初期 MAC アドレスと有効な MAC アドレスの違いは前回の記事を参照してください。

送信元 MAC アドレスの偽装

最も単純な例としては、ゲストOSから送信元 MAC アドレスを書き換えたフレームを実際に送信してみることです。以下、パケット操作ツールである Scapy のインタラクティブシェルを使って送信元 MAC アドレスを偽装したフレームを送信してみます。

1# pip install scapy
2# scapy
3  ...
4>>> sendp(Ether(src="00:11:22:33:44:55")/IP(dst="192.168.0.1"))
5.
6Sent 1 packets.
7>>>

ESXi 側で pktcap-uw を仕掛けておきフレームをキャプチャすると、以下のように「偽装転送」ポリシーによってドロップされた状況が確認できます。

1# pktcap-uw --capture Drop
2The session capture point is Drop.
3  ...
416:39:48.479640[1] Captured at Drop point, Drop Reason 'MAC Forgery Drop'. Drop Function 'L2Sec_FilterSrcMACForgeries'. TSO not enabled, Checksum not offloaded and not verified, SourcePort 67108984, length 60.
5        Segment[0] ---- 60 bytes:
6        0x0000:  001b 8bae d28a 0011 2233 4455 0800 4500
7        0x0010:  001c 0001 0000 4001 f98a c0a8 0004 c0a8
8        0x0020:  0001 0800 f7ff 0000 0000 0000 0000 0000
9        0x0030:  0000 0000 0000 0000 0000 0000

フレームの送信元 MAC アドレスが書き換えられる例としては Microsoft NLB のユニキャストモードがあります。

Microsoft NLB のユニキャストモード

前回の「MAC アドレス変更」ポリシーの記事で Micrsoft NLB のユニキャストモードに言及しましたが、ユニキャストモードの NLB では「偽装転送」ポリシーも「承諾」にする必要があります。

ユニキャストモードの NLB の場合、ノードのパケット受信は外部スイッチでの Unknown Unicast のフラッディングを利用しており、外部スイッチが仮想 MAC アドレス(02:BF:…)を学習してしまうと正常に動作しません。

外部スイッチに NLB の仮想 MAC アドレスを学習させないために、ユニキャストモードの NLB ではノードが送信元 MAC アドレスを 02:<ノード固有値>:… に書き換えてフレームを送信します。その結果、有効な MAC アドレスと送信元 MAC アドレスが以下のように異なる状況が発生します。

• 有効な MAC アドレスは 02:BF:…
• 送信元 MAC アドレスは 02:<ノード固有値>:…

このため、ESXi 上でユニキャストモードの NLB を実行する場合、「偽装転送」ポリシーが「拒否」だとノードからの送信フレームがドロップされる動作となります。

ゲストOS内の L2 ブリッジング

その他に「送信元 MAC アドレス≠有効な MAC アドレス」の状況が発生する例として、ゲストOS内で L2 ブリッジが構成されている場合が挙げられます。

例えば、Linux ゲストで以下の図のように macvlan を使用して外部ネットワークに直接接続される構成の場合、macvlan0 から送出されるフレームは「送信元 MAC アドレス≠有効な MAC アドレス」のためドロップされます。

1# ip link add link ens192 name macvlan0 type macvlan mode private
2# ip link set dev macvlan0 up
3# ip addr add dev macvlan0 192.168.0.64/24

以下のような veth を使用して外部ネットワークに直接接続される場合も同様です。

 1# ip link add dev br0 type bridge
 2# ip link set dev ens192 master br0
 3# ip link add dev veth0 type veth peer name veth-br0
 4# ip link set dev veth-br0 master br0
 5
 6# ip link set dev br0 up
 7# ip link set dev veth0 up
 8# ip link set dev veth-br0 up
 9
10# ip addr add dev veth0 192.168.0.64/24

こちらのケースではゲストOSの構成に存在する MAC アドレスを使用して送受信が行われるという点で、上述の Scapy や Microsoft NLB のケースと異なります。

また、このケースは受信フレームの宛先 MAC アドレスも有効な MAC アドレスではないため、既定では仮想スイッチは受信フレームを仮想マシンに転送しません。フレームの受信のためには「無差別モード」を「承諾」に設定する、または VDS や NSX-T の MAC アドレス学習を有効にする必要があります。

以下、類似の L2 ブリッジング構成により本ポリシーがフレームをドロップする例を紹介します。

Docker の macvlan ネットワーク

Docker の macvlan ネットワークを使用すると、macvlan インターフェースを使用して Docker コンテナを外部ネットワークに直接接続できます。

この場合、ネットワーク構成は上述した macvlan でブリッジングされるケースと同様の構成となり、コンテナの macvlan インターフェースの MAC アドレスが使用されるため「偽装転送」ポリシーが有効だとドロップされます。

vSAN File Service

vSAN にはファイル共有を提供する機能として vSAN File Service があります。本機能を有効にすると、vSAN File Service で使用するポートグループで「偽装転送」が「承諾」に変更されます。

• ファイル サービスの構成

MAC アドレスの学習と偽装転送は、指定された DVS ポート グループの vSAN ファイル サービス有効化プロセスで有効になります。

標準スイッチの場合、vSAN ファイル サービスを有効にすると、無作為検出モードと偽装転送が有効になります。

NSX ベースのネットワークを使用している場合は、NSX 管理コンソールで指定のネットワーク エンティティで MacLearning が有効になっており、すべてのホストとファイル サービス ノードが目的の NSX-T ネットワークに接続していることを確認します。

vSAN File Service ではファイルサービス仮想マシン (FSVM) を各ホストに展開され、FSVM 内部で実行される Docker コンテナに NFS や SMB のエンドポイントとなる IP アドレスが割り当てられます。

• vSAN ファイル サービス

このため、vSAN File Service の通信ではフレームの送受信にコンテナのインターフェース¹の MAC アドレスが使用されるため、ドロップされないよう「偽装転送」が有効になります。

Nested ESXi

vSphere に慣れている方だと「偽装転送」といえば Nested ESXi を思い浮かべる方も多いのではないでしょうか。以前の Nested ESXi の記事でも本ポリシーについて言及していました。

Nested ESXi では、送信元 MAC アドレスは仮想マシンのネットワークアダプタや VMkernel ポートの MAC アドレスになりますが、有効な MAC アドレスは vmnic の MAC アドレスになります。

このため、Nested ESXi 内で送出されたフレームが Nested ESXi の外部に出ると、ホスト側の ESXi が「送信元 MAC アドレス≠有効な MAC アドレス」であることを検出してドロップします²。

おわりに

今回の記事では仮想スイッチの「偽装転送」ポリシーについて動作の概要や実際にフレームがドロップされるケースを見ていきました。

仮想スイッチの3種類のセキュリティポリシーは単にドキュメントやナレッジベースを見ただけでは具体的な動作が分かりづらいところもありますので、いくつかの具体的なケースや検証を通して理解を深めておくと良いと思います。