VMware Cloud on AWS ～マニュアルはちゃんと読もうね編～

早いもので、令和2年も残り1か月を切りましたね。

コロナによって世界は変貌してしまった、といっても過言ではない衝撃の2020年でした。

一刻も早く、元の生活を取り戻したいですね。

さて、本日は、わたくしが引っ掛かってエラい目にあってしまった、VMware Cloud on AWS(以降VMC)の「前提条件」について、ご紹介したいと思います。

今回は、短めです。

ENI用サブネットについて

VMCの展開時、必ず必要なものがあります。

それは、「AWSのENI(Elastic Network Interface)用サブネット」です。

VMCは、デプロイ時にAWS側にENIを17個作成します。

これは、VMC環境が、既存のAWS環境と高速に通信を行うために必要なものです。

これにより、

VMCで作った仮想マシンと、

AWS環境に作ったEC2 との通信をENI経由で行うことができます。

文章で書いても、うまく伝わらないと思うので、簡単に図示するとこんな感じです。

↓

f:id:gokusan:20201221233740p:plain

VMC側には、「T0ルーター」と呼ばれるものがあって、そこから既存AWSのVPCと通信をすることができるのです。

上図の通り、T0ルーターが通信を行うセグメントこそが「ENI用サブネット」であり、そこからAWSのルートテーブルに従って任意のセグメントへルーティングされるというわけです。

ちなみに、このENI用サブネットですが、VMCのデプロイの時に選択します。

なので、あらかじめAWS側でこのENI用サブネットを用意しておく必要があります。

あれれー？EC２と通信ができないぞー？

悲劇は、VMCのデプロイが完了し、VMC上に仮想マシンをたてて、

EC2と通信させる時に起こりました。

僕「・・・通信がっ！できないっ・・・だと？」

VMC上の仮想マシンとEC2をENIを経由して通信させるために、

超えないといけない設定が、実は結構あります。

VMCのCustmer GateWay Firewallの設定
AWSのENIに付与されたセキュリティグループ
AWSのENI用サブネットに付与されたルートテーブル
AWSのEC2に付与されたセキュリティグループ
AWSのサブネットに付与されたACL

これらの通信が許可されていて、初めてEC2とVMC上の仮想マシンとの通信が叶います。

ところが、今回これらの通信を全てきちんと許可されているというのに、通信ができかったのです。

私に前世の徳が足りてなかったのかなぁ

などとも真剣に考えたのですが、

AWSのVPC Flow Logsを見ても、ENIからの通信が検知されていないではありませんか！

ということは、そもそもAWS側の設定がどうこうっていう話しでもなくて、そもそもVMC～AWSの通信が駄目っぽいぞぉ？？

ということで、VMC側の調査を行うことになりました。

原因判明…orz

結論から言うと、ENI用サブネットを払い出したVPCのCIDRが、「セカンダリCIDR」であったことが、すべての原因でした。

実は、ENI用サブネットは「プライマリCIDR」から払い出されたサブネットしか使用できません。という前提条件があったのです。

僕「(´・ω・`)ｿ､ｿﾝﾅｰ」

という感じでしたが、実はこの制限きちんとVMwareのドキュメントに記載されています。

ENI 接続に使用される VPC サブネットの CIDR ブロックの容量が十分にある場合、必要に応じて複数の SDDC を VPC にリンクできます。VPC 内のすべての SDDC が同じメインルートテーブルを使用するため、これらの SDDC 内のネットワークセグメントが相互に重複したり、VPC のプライマリ CIDR ブロックと重複したりしないようにする必要があります。経路指定された SDDC ネットワーク上のワークロード仮想マシンは、VPC のプライマリ CIDR ブロックのすべてのサブネットと通信できますが、VPC 内に存在する可能性がある他の CIDR ブロックは認識しません。

Oh…すっかり、見落としていました。

どうやら私に足りていなかったのは、徳ではなく、注意力のようでしたね、ハハ。

AWSでは、現在VPCに対して、最初に指定したCIDRに追加する形で、2つ以上のCIDRを指定できます。

f:id:gokusan:20201220005830p:plain