今回は、
というタイトルで、お送りします。
VMware Security Advisories の
VMSA-2022-0027で公開された話ですが、
VMware Cloud Foundation updates address multiple vulnerabilities.
パッチ適用されないはずのVにまで
パッチを提供しているとのことなので、
該当される方はご確認ください。
とりあえず、今回はこれだけ、、。
ご参考まで。
Spring4Shellの脆弱性について
2022もvExpartに選んで頂きました
本年も認定？頂きました！
相変わらず、王道なところからは外れた話ばかりですが、
ご覧いただければ幸いです！！
NSXの分散ファイアウォールについて
今回は、
というタイトルで、（いつもどおり、、、？）ハマった話をお送りします。
触っていたのはNSX-V（サポート切れますが）の分散FWなのですが、
気づけば単純、気づかないと、、、ということで、
おおよそ1か月間、色々なポイントを調査し、、、たどり着きました。
事象（結論？）としては、
「分散ファイアウォールでブロックされていた」
なんですが、、、
『勿論、普通に許可するポリシーを入れているのに』ブロックされていたので、
分散FWでブロックされていると断定できずに時間が掛かってしまった。。。というわけですね。
そんなわけで、分散FWの、、、というか、
NSXのService Composer？での処理のされ方？という部分で
そういうことか！と知っていれば引っかからない話が分かったので、
共有します。。。
「分散ファイアウォールのルールに仮想マシンオブジェクトを登録しても
想定通りの動作をしない！！」
いつも通り、（ピンポイントな）限定するキーワードを書いてますが、
通信を許可するセキュリティグループに動的に登録されるようにした仮想マシンが、Service Composerから見てもしっかり登録されているのに通信が行えないという不思議な事象が発生しまして、、、分かったことは、
ということです。
勿体ぶった言い回しになりましたが、
VMware Toolsが把握していないIPアドレスは、ESXi、vCenterでも認識されず、、
結果NSXでも「そんなどこの馬の骨だかわからない…」存在として認識されるわけで、
「分散ファイアウォール」くんとしては「聞いてないものは知らないよ」と、しっかりブロックしてくれるわけですねー。。
（暗黙のdenyが最後に入れてあるホワイトリスト方式で運用してる環境なので。。）
うーん、、「忖度」してほしい。。笑
ということで、今回のこの事象、、、
自分はCitrix社のADC（Application Delivery Controler：旧NetScaler）のVPX（Virtual Appliance版）で起こったわけですが、Sub InterfaceとかをLinuxで有効にしても発生するんじゃないですかね。。
↑ADCは管理用のNSIP（これはToolsに拾われる）の他にSNIP（Subnet IP）と
ADCの中の仮想サーバ（LBだったりICAのリバプロにしたり）が持つVIPがあり
このようなことが発生したというわけです。。。
ひとまず解決して良かった。。。
ということで、
ご参考まで。
仮想環境で完全にクローズな疑似テスト環境を作る際に便利なこと
今回は、
「仮想環境で完全にクローズな疑似テスト環境を作る際に便利なこと」
というタイトルでお送りします。
本番環境のホスト（ESXi）を使って、
その中で完全にクローズな環境にしてしまっていると、
検証用のデータだったり、設定ファイルを本番環境から
どうやって持ち込もう？？となりますよね。
そんなときには！
ISOファイルをlinuxで作ってしまいましょう。
mkisofs -r -J -V "xxxxxxx" -o xxxxxxxx.iso /tmp/yyyyyyyy.tgz
上記のコマンドでyyyyyyyyy.tgzを中に仕込んだxxxxxxxx.isoという
ファイルが出来上がります。
このisoファイルをデータストアにuploadして、
該当の仮想マシンにマウントすれば、、、
仮想のNetworkを一切触らずにクローズな検証環境の中にデータが持ち込めます。
まぁ、データ受け渡し用の仮想マシンを作って、、
本番環境のネットワークラベルと検証環境のネットワークラベルを
切り替えてあげればいいだけではありますが。。。
まぁ、設定を変えなくて良いということで、
不測の事故は防げるのではないか、、、と。（汗
IP変え間違えた！とか、
別のマシンのネットワークラベルを変えてしまった！！とか、、
よくやりそうになりますよねー？
そんなことやりそうになるのは、
お前だけだってツッコミが入りそうですが（笑
「本番環境と一緒にやってる検証環境」と縛りを入れたのは、
そういう環境でわざわざリスク背負う必要ない方法がありますよ、と
いうことが言いたかっただけです。
ご参考まで。
vSAN環境のディスク個別の容量の話
今回は、
「vSAN環境のディスク個別の容量の話」
というタイトルでお送りします。
前回、
「vSANデータストアに関する障害の話 - 器用貧乏、仮想化をあつかう
https://masaod94.hatenablog.com/entry/2021/10/23/000000」
で書いた話のときに知ったことで、
以下に記載のコマンドを実行すると、、、
vSANクラスタ内のホストに搭載された
Capacity TierのDiskそれぞれの使用容量が一覧で表示可能です。
cmmds-tool find -t HOSTNAME -f json | egrep "uuid|hostname" | sed -e 's/\"content\"://g' | awk '{print $2}' | sed -e 's/[\",\},\,]//g' | xargs -n 2 | while read hostuuid hostname; do echo -e "\n\nHost Name: $hostname::: Host UUID: $hostuuid\n Disk Name\t\t| Disk UUID\t\t | Disk Usage | Disk Capacity | Usage Percentage" ; cmmds-tool find -f json -t DISK -o $hostuuid | egrep "uuid|content" |sed -e 's/\"content\":|\\"uuid\"://g' | sed -e 's/[\",\},\]//g' | awk '{printf $0}' | sed -e 's/isEncrypted: [0-9]/\n/g'| awk '{print $37 " " $2 " " $5 " " $45}'| while read disknaa diskuuid diskcap maxcomp; do diskcapused=$(cmmds-tool find -f json -t DISK_STATUS -u $diskuuid |grep content |sed -e 's/[\",\},\]//g' | awk '{print $3}'); diskperc=$(echo "$diskcapused $diskcap" | awk '{print $1/$2*100}'); if [ "$maxcomp" != 0 ];then echo -en " $disknaa\t| $diskuuid\t| $diskcapused\t | $diskcap\t | $diskperc%\n"; fi; done; done
ちなみに出力例は、こんな感じになります。
（実データなので固有の情報は省いて転記してますが）
HostName: ESXihostname::: Host UUID:
DiskName|Disk UUID| Disk Usage | Disk Capacity | Usage Percentage
naa. | | 894307540929 | 1515646136320 | 59.005%
naa. | | 945761351297 | 1515646136320 | 62.3999%
naa. | | 1285277856646 | 1820566986752 | 70.5977%
naa. | | 987305565919 | 1515646136320 | 65.1409%
naa. | | 987305565919 | 1515646136320 | 65.1409%
naa. | | 1132718718976 | 1515646136320 | 74.735%
naa. | | 945761351297 | 1515646136320 | 62.3999%
上記の物がクラスタ内のホスト台数分ズラーっと出てくる感じですね。
ご参考まで。
