cjnotes

CJです。

この投稿は、vExperts Advent Calendar 2019 – Adventar の 23日目です。

初めて VMware Cloud on AWS (以下、VMC on AWS)をお試しいただく場合、”VMC上の仮想マシンと AWS上の仮想マシン (EC2)”間での疎通確認テストを行うケースが多くあるかと思います。
今回は、そのシナリオに合わせた手順およびチェックポイントをご紹介したいと思います。では、早速イメージ図から見ていきましょう。

イメージ図

事前準備

・VMC SDDC より、Connected VPC 情報を確認。

VPC ID	vpc-xxxxxxxxxxxxxxxxx
VPC Subnet	subnet-yyyyyyyyyyyyyyyyy
Active Network Interface (ENI)	eni-zzzzzzzzzzzzzzzzz

VMC SDDC > Networking & Security > System > Connected VPC

・VMC上の仮想マシンは予め作成してください。

設定の流れ

VMC：Segments 作成
VMC：Groups 作成
VMC：Gateway Firewall 作成
AWS：EC2 Instance 作成
疎通確認 (CJ-VM01 と CJ-AWS01 間)
チェックポイント (EC2 から VMC へ疎通ができない場合)
チェックポイント (疎通確認)

1. VMC：Segments 作成

テスト用仮想マシン(CJ-VM01)のセグメント(192.168.100.0/24)を作成。

VMC SDDC > Networking & Security > Network > Segments > [ADD SEGMENTS] より、CJ-Net 作成

2. VMC：Groups 作成

次の手順である Firewall 設定を簡単に行うため、テスト用仮想マシン(CJ-VM01)が属するグループ (CJ-VM)を作成。

*VMC SDDC > Networking & Security > Inventory > Groups > Workload Groups > [ADD GROUP] より、CJ-VM グループ作成*

3. VMC：Gateway Firewall 作成

Firewall の設定は、In & Outbound の両方を設定する必要があります。ここではテストのため、Anyで開放してあります。本番環境においては適切なセキュリティ設定をお勧めします。

*VMC SDDC > Networking & Security > Security > Gateway Firewall > Compute Gateway > [ADD NEW RULE] より、*
*CJ-VM グループの In & Outbound を開放*

ここまでで、VMC側の設定は終了となります。後ほど疎通テストのために、NAT設定も行なっておりますが、本記事では省略させていただきます。NAT設定方法については、こちらの記事をご参照ください。

4. AWS：EC2 Instance 作成

EC2のインスタンス作成方法については外部に情報が多いため、本記事では省略させていただきます。外部情報をご参照ください。なお、本テストインスタンスの作成において CJ-AWS01のセキュリティグループは “default VPC ssecurity group” を選択しています。

AWS Console > EC2 > Instances > [Launch Instance] より、仮想マシン (CJ-AWS01)を作成

以下の通りに、”default VPC security group” の In & Outbound はデフォルトで全て許可となっていることが確認できます。

*AWS Console > EC2 > NETWORK & SECURITY > Security Groups より、”default VPC security group” の In & Outbound 確認*

5. 疎通確認 (CJ-VM01 と CJ-AWS01 間)

問題なく、VMC上の仮想マシンと EC2間で ENI経由での内部疎通が可能であることが確認できました。

CJ-VM01 → CJ-AWS01 : PING OK
*CJ-VM01 ← CJ-AWS01 : PING OK*

6. チェックポイント (EC2 から VMC へ疎通ができない場合)

上記の手順4で、セキュリティグループを少し強調しましたが、お気付きでしょうか。EC2 インスタンスを作成する際に、デフォルト外のセキュリティグループを使う場合もあるかと思います。その際に、実際どうなるでしょうか。

結論からお伝えすると、VMCから EC2への疎通は可能ですが、EC2 から VMCへの疎通ができなくなります。

以下のイメージ図の通りに、AWS側にデフォルト外のセキュリティグループ (CJ-SG)に属している新規の EC2 (CJ-AWS02)を作成し、実動作を確認したいと思います。

*VMC on AWS上の VM(CJ-VM01)から、AWS上の EC2(CJ-AWS01 と CJ-AWS02)間の疎通イメージ図*

新規で作成したセキュリティグループ (CJ-SG)の In&Outbound は全て許可としている状態です。

*AWS Console > EC2 > Instances > [Launch Instance] より、仮想マシン (CJ-AWS02)を作成*

7. チェックポイント (疎通確認)

なぜか、セキュリティグループ (CJ-SG)の In & Outbound が全て許可となっているにも関わらないず、CJ-AWS02 から CJ-VM01 への疎通ができない状態が確認できました。

*CJ-VM01 → CJ-AWS01* & 02 : PING OK
*CJ-VM01 ← CJ-AWS01 : PING OK*
*CJ-VM01 ← CJ-AWS02 : PING NG*

なぜ、このようなことが起きるのか？

既に Brianさんのブログに詳しく紹介されているため、引用させていただきます。

When you deploy an SDDC and select a VPC to attach, it is extremely important to note that the ‘Default Security Group’ of that VPC will become the Security Group for the Elastic Network Interfaces (ENI). …省略 … However, with the Security Group for the ENI, ‘Inbound’ is actually EXITING the VPC and ENTERING the VMware Cloud on AWS SDDC.
Source : http://www.brianjgraf.com/2019/02/04/understanding-how-aws-security-groups-work-with-vmware-cloud-on-aws/

重要なポイントとして、以下の 2点があります。

・ENI のセキュリティグループは、VPC の ‘Default Security Group’ である。

・ENI のセキュリティグループの Inbound は、VMC on AWS への接続許可設定となる。

より簡単にイメージ化すると、以下の図の通りとなります。’Default Security Group’ の Inbound ルールの Source は、’Default Security Group’ 自身になっていることがわかります。つまり、’Default Security Group’ に属しているインスタンスのみが、VMC on AWSへの接続許可になるという意味になります。

ENIのセキュリティグループの Inbound は、VMware Cloud on AWS へに入ることを意味する

応用すると、’CJ-SG’ を ‘Default Security Group’ の Inbound ルールの Source に追記することで、’CJ-SG’ に属しているインスタンスからも VMC on AWS への接続を許可することになります。※注意：管理が煩雑になり、トラブルを招く可能性があるため、お勧めはしません。

また、Connected VPC の Route Tables には、CJ-VM01が繋がっているセグメント (192.168.100.0/24)が、自動的に登録されており、eni-zzzzzzzzzzzzzzzzz へ流していることがわかります。