IBM Cloud: BM for VPCで同一サブネット内の通信でSecurity Groupを強制する方法

#1. はじめに

[IBM Cloud docs](https://cloud.ibm.com/docs/vpc?topic=vpc-bare-metal-servers-network#nic-limits&locale=en)にも記載されているが、同一ホスト上の同一Port GroupでのSecurity Groupは機能しない。例えば、以下のような構成で、guestvm01とguestvm02間の通信はSecurity Groupで許可していないにも関わらず通信できてしまう。

```
[root@guestvm01 ~]# ping 172.16.0.254
PING 172.16.0.254 (172.16.0.254) 56(84) bytes of data.
64 bytes from 172.16.0.254: icmp_seq=1 ttl=64 time=0.454 ms
64 bytes from 172.16.0.254: icmp_seq=2 ttl=64 time=0.376 ms
64 bytes from 172.16.0.254: icmp_seq=3 ttl=64 time=0.385 ms
64 bytes from 172.16.0.254: icmp_seq=4 ttl=64 time=0.391 ms
64 bytes from 172.16.0.254: icmp_seq=5 ttl=64 time=0.429 ms

[root@guestvm01 ~]# ping 172.16.0.5
PING 172.16.0.5 (172.16.0.5) 56(84) bytes of data.
64 bytes from 172.16.0.5: icmp_seq=1 ttl=64 time=0.882 ms
64 bytes from 172.16.0.5: icmp_seq=2 ttl=64 time=0.558 ms
64 bytes from 172.16.0.5: icmp_seq=3 ttl=64 time=0.447 ms
64 bytes from 172.16.0.5: icmp_seq=4 ttl=64 time=0.412 ms
64 bytes from 172.16.0.5: icmp_seq=5 ttl=64 time=0.437 ms
```


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/1756f70e-6b57-0d5f-8566-dfe7d28daba0.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/8fd151f8-c5b2-cf7b-d3f8-06f76c3d161e.png)

これは、VM間通信は下図のように仮想スイッチ内で行われてしまうため、そもそもSecurity Groupが機能するSmartNICの部分までパケットが到達しないためである。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/33469182-93ef-261b-7954-3303300c9a80.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/8feaedee-90bb-8e6b-c469-456ce7a532ed.png)



#2. 回避策
**たとえ同一サブネットであったとしても、1つのVLAN Interfaceごとに一意のVLAN/Port Groupを構成**すれば、必ずSmartNIC経由で通信が行われるため、仮想スイッチ内での直接通信を避けることができる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/f3a7488a-7fb1-56ad-ea87-c7c285e2ac85.png)

:::note warn
この方法は、スケーラビリティーのある方法とは言えない。

- 同一サブネット内で通信を制御する必要が本当にあるのか？（本当はサブネットを分けるべきなのではないのか？）
- OS FirewallやVMware NSXなど他の方法で代替できないのか？
- Port groupの上限(https://configmax.esp.vmware.com/guest?vmwareproduct=vSphere&release=vSphere%207.0&categories=2-0)に抵触していないか？

なども併せて検討するべきである。
:::




#3. 手順

今回は、以下のように構成する

- guestvm01: VLAN100, SecurityGroup=bm-vpc-vm-sg, IP=172.16.0.4（作成済み）
- guestvm02: VLAN101, SecurityGroup=bm-vpc-vm-sg, IP=172.16.0.254（CLIで再作成）
- guestvm03: VLAN102, SecurityGroup=bm-vpc-vm-sg, IP=172.16.0.5（CLIで再作成）


##3-1. PCI InterfaceにAllowed VLANとしてVLAN 101, 102を追加する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/d4599373-873a-0e93-29ba-1382d5cd1417.png)

##3-2. 既存のVM(guestvm02/guestvm03)のVLAN Interfaceを削除し、新規に再作成する。


```
$ ibmcloud is bare-metal-server-network-interface-create 02b7-b416f1c2-63c8-4707-972d-65eb19ecb87e  --name eth0-100-guestvm02 --interface-type vlan --subnet bm-vpc-sub-172-16-0-0-24 --ip 172.16.0.254 --vlan 101 --allow-interface-to-float true --security-groups bm-vpc-vm-sg
$ ibmcloud is bare-metal-server-network-interface-create 02b7-b416f1c2-63c8-4707-972d-65eb19ecb87e  --name eth0-100-guestvm03 --interface-type vlan --subnet bm-vpc-sub-172-16-0-0-24 --ip 172.16.0.5 --vlan 102 --allow-interface-to-float true --security-groups bm-vpc-vm-sg
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/4d104489-4016-b446-e297-4e5b82abbaa7.png)


##3-3. VLANごとにPort Groupを作成しVMを割り当てる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/d43f97f1-1cfb-c855-3f86-e19d3cb87436.png)

##3-4. （DHCP構成時のみ）

- 新規に作成されたVLAN InterfaceのMACアドレスをVMに割り当てて再起動。
- VM上で、`dhclient -r;dhclient`を実行して再度DHCPからIPアドレスを取得（キャッシュ切れまで時間がかかるので即時に変更したい時に利用）


#4. テスト

- bastionサーバー(VSI)からguestvm1/guestvm2/guestvm3にSSHできることを確認。
- Security Groupが機能して、VM間の通信ができないようになったことを確認。

```
[root@guestvm01 ~]# ping 172.16.0.254
PING 172.16.0.254 (172.16.0.254) 56(84) bytes of data.
^C
--- 172.16.0.254 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 6999ms

[root@guestvm01 ~]# ping 172.16.0.5
PING 172.16.0.5 (172.16.0.5) 56(84) bytes of data.
^C
--- 172.16.0.5 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 5999ms

```