vEXPERTのブログ（vEXPERT2年目に突入） - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」

BIGLOBE鈴木(研)です。

無事に申請内容が受理されて、vEXPERT生活2年目に入ることが出来ました。星が2つになりました。 vExpertのポータルサイトのDirectoryで「japan」で絞り込んでみると、71名が日本のメンバのようです（ワールドワイドで2000名弱）。

f:id:biglobe-editor4:20200312142350p:plain:w300

本来は、3/5のUserCON2020というイベントのレポートでもしようかと思ってたんですが、新型コロナウイルスの影響で延期となったため、最近BIGLOBEでの作業でドタバタした技術ネタでも書きたいと思います。

■突然VMのMACアドレスが変わってしまうことがあるのか？

事象発生時の状況

通常、電源ON状態で仮想マシンのMACアドレスは変わることはないのですが、なぜか変わってしまった事象がありました。

事象の発端は「突然VMとの通信が出来なくなって、今もその状態が継続中なんだけど」でした。

初動調査

基盤側を調べたら、通信が出来なくなったタイミングでDRSのvMotionで対象VMが別ESXホストに移行されていて、どうもvMotionがトリガで発生した事象であることがおぼろげに見えてきました。すぐに分かったのは、ポートグループのセキュリティ設定のMACアドレス変更を「拒否」に設定しているのに引っかかり、このVMのポートがブロックされたということです。

f:id:biglobe-editor4:20200304114107j:plain

VMの設定を確認すると、MACアドレスは、上記とは違うものが設定されていることが分かり、このせいでポートブロックされたことはわかりました。

vCenterのイベント情報を確認すると、実際にVMのMACアドレスが変わっていることが確認できました。

Changed MAC address from 00:50:56:86:67:1a to 00:50:56:86:45:62 for adapter XXXXXXXX_3783

f:id:biglobe-editor4:20200311162157j:plain

ただし、最初の画面のとおり、ランタイムMACアドレスが"00:50:56:86:67:1a"になっているので、ゲストOSで設定されているMACアドレスは"00:50:56:86:67:1a"のまま（変更前）であるようでした。

しかし、vMotionのタイミングより1か月以上も前だったので、関係無いようもに見えました。

前提

BIGLOBE環境の前提として、下記があります。

vSphereは6.0u3
ポートグループのセキュリティ設定は全て「拒否」
- 「プロミスキャスモード」を「拒否」することで、宛先にかかわらず全てのパケットを受信することができなくなり，他の送信者や受信者に気付かれずにデータを傍受することができなくなります
- 「MACアドレス変更」を「拒否」することで、外からVMが受信する通信について、VMに割り振ったMACアドレスと違うMACアドレスをゲストOSで成りすまして使ったら、ESXホストが通信をブロックします
- 「偽装転送」を「拒否」することで、VMから外に送信する通信について、VMに割り振ったMACアドレスと違うMACアドレスをゲストOSで成りすまして使ったら、ESXホストが通信をブロックします

f:id:biglobe-editor4:20200304111606j:plain

VMのMACアドレス採番は「自動」

抱いた疑問

なぜvMotionがトリガで、このVMは通信できなくなったのか？
なぜvMotion実施前までは、このVMは通信できていたのか？
電源ON中のVMのMACアドレスが変わることがあるのか？

調査継続

VMware社に問合せした結果、VMを電源ONの状態でポートグループ変更するとMACアドレスが変わる場合がある（必ずそうなるわけではない）、変更が反映されるのはVMの電源OFF/ONや再起動後であるとのことでした。

このVMの初期設定で、ポートグループを初期→正規のものに切り替えたのですが、その際VMの電源はONのまま実施していました。

ここで、VMのMACアドレスが 00:50:56:86:67:1a → 00:50:56:86:45:62 に変わりました。 MACアドレス変更「拒否」の設定にここで引っかかっても良さそうですが、通信は継続されたままでした。

しばらく経ってある時に、このVMがDRSによるvMotionで別ESXホストに移動したタイミングで、MACアドレスが変更になっていたことにvSphereが気づいて、通信をブロックし出した、ということのようです。

謎解き

VMware社にいろいろ確認したところ、「下記の動きをしたのでは？」という結論になりました。

VMが電源ONのままvNICのMACが変わった場合は、変更前からできていた通信が保持される仕様とのことで、ポートグループのセキュリティポリシー（MACアドレス変更）には引っかからず、通信できていた
vMotionで別ESXホストに移行されたため、仮想スイッチのポートが変更になり、その時点でセキュリティポリシーに違反していることをvSphereが検知し、ポートがブロックされた

そんな仕様は想像もしてなかったです。

一連の動作の動きを整理するとこんな感じです。これで一連の動作の説明がついたのでスッキリしましたｗ

f:id:biglobe-editor4:20200304090811j:plain