IBM Cloud: Network ACLはsubnet内通信では効かない

# 1. はじめに

IBM CloudのNetwork ACLはsubnet内通信では効かないことの動作確認をしてみた。
Network ACLが対象subnetに対するinbound/outboundルールを設定するものであることを鑑みると、対象subnetに外部から入ってくるわけでも出ていくわけでもない通信はNetwork ACLの制御の対象外であることは想像できるが、念の為確認してみた。

# 2. 環境情報

```
$ ibmcloud is instances | grep -e ID -e syasuda-test
ID                                          Name                                                Status    Reserved IP    Floating IP       Profile    Image                                              VPC                Zone       Resource group
02e7_5334b268-df7a-4faf-8742-1a9ac343f629   syasuda-test1                                       running   10.0.0.9       -                 bx2-2x8    ibm-centos-stream-9-amd64-5                        vpc-tok-syasuda1   jp-tok-1   Default
02e7_7b215ae3-13cd-4b2a-a665-1a026540fc06   syasuda-test2                                       running   10.7.0.6       -                 bx2-2x8    ibm-centos-7-9-minimal-amd64-12                    vpc-tok-syasuda1   jp-tok-1   Default
02e7_116efe09-0ef4-499a-8838-38f9b90a568f   syasuda-test3                                       running   10.0.0.15      -                 bx2-2x8    ibm-centos-stream-9-amd64-5                        vpc-tok-syasuda1   jp-tok-1   Default

$ ibmcloud is instance syasuda-test1 | grep -e "Network Interfaces" -e eth0
Network Interfaces                    Interface   Name   ID                                          Subnet            Subnet ID                                   Floating IP   Security Groups          Allow source IP spoofing   Reserved IP
                                      Primary     eth0   02e7-b56b666c-0724-4b4b-b44f-4dad5d417908   sub-10-0-0-0-24   02e7-ff96ff2a-fa27-4d88-b855-98fb85112636   -             sg-tok-syasuda-default   false
$ ibmcloud is instance syasuda-test2 | grep -e "Network Interfaces" -e eth0
Network Interfaces                    Interface   Name   ID                                          Subnet            Subnet ID                                   Floating IP   Security Groups          Allow source IP spoofing   Reserved IP
                                      Primary     eth0   02e7-d0643d03-6f59-43e5-86cc-894d3e55d20c   sub-10-7-0-0-24   02e7-6e131498-ed24-4bd3-9399-24636a8e71b8   -             sg-tok-syasuda-default   false

$ ibmcloud is instance syasuda-test3 | grep -e "Network Interfaces" -e eth0
Network Interfaces                    Interface   Name   ID                                          Subnet            Subnet ID                                   Floating IP   Security Groups          Allow source IP spoofing   Reserved IP
                                      Primary     eth0   02e7-33381cff-fca3-4555-a4ff-396dbffe06b0   sub-10-0-0-0-24   02e7-ff96ff2a-fa27-4d88-b855-98fb85112636   -             sg-tok-syasuda-default   false
                                      
```

上記のように、VSI syasuda-test1(`10.0.0.9`), syasuda-test3(`10.0.0.15`)は同一subnet(`sub-10-0-0-0-24`)に所属し、syasuda-test2(`10.7.0.6`)は異なるsubnet(`sub-10-7-0-0-24`)に所属している。

また、以下の結果から分かるように、このVPC内のsubnetは全て`acl-tok-syasuda-default`というNetwork ACLに紐づいている。

```
$ ibmcloud is network-acl acl-tok-syasuda-default | grep Subnets -A 100
Subnets
ID                                          Name
02g7-a0cfc9d8-3caa-4cc2-9b22-b64667a4e034   sub-10-9-0-0-24
02f7-304ec82e-f0b9-40fc-a1b5-f80b13f2d282   sub-10-8-0-0-24
02e7-6e131498-ed24-4bd3-9399-24636a8e71b8   sub-10-7-0-0-24
02e7-daa2ff86-aa50-46ae-a0be-c169da2624d7   sub-100-64-0-0-24
02g7-976cb6d1-918f-4dc6-ae27-08c23af0dd5f   sub-10-6-0-0-24
02f7-16893afd-0d76-406e-be90-112c6a34b0b7   sub-10-5-0-0-24
02e7-b50228c7-2431-4854-ad4c-b68f6c7382a7   sub-10-4-0-0-24
02e7-cc434307-168d-4cb8-bbde-eb45839c8e59   sub-172-16-0-0-24
02g7-a65939b2-6b69-443a-b149-d7f241d7a6c1   sub-10-2-0-0-24
02f7-21b7d86a-093c-484d-ac1e-a865acd209a7   sub-10-1-0-0-24
02e7-ff96ff2a-fa27-4d88-b855-98fb85112636   sub-10-0-0-0-24
```

# Network ACLテスト1

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/890704ab-f2cc-e6f7-b299-f094d79f6f68.png)

Network ACL的に全て許可されているため、期待通り。

```txt:syasuda-test1からsyasuda-test2へのping
$ ping 10.7.0.6
PING 10.7.0.6 (10.7.0.6) 56(84) bytes of data.
64 bytes from 10.7.0.6: icmp_seq=1 ttl=64 time=12.4 ms
64 bytes from 10.7.0.6: icmp_seq=2 ttl=64 time=0.601 ms
64 bytes from 10.7.0.6: icmp_seq=3 ttl=64 time=0.505 ms
64 bytes from 10.7.0.6: icmp_seq=4 ttl=64 time=0.524 ms
64 bytes from 10.7.0.6: icmp_seq=5 ttl=64 time=0.475 ms
```
```txt:syasuda-test1からsyasuda-test3へのping
$ ping 10.0.0.15
PING 10.0.0.15 (10.0.0.15) 56(84) bytes of data.
64 bytes from 10.0.0.15: icmp_seq=1 ttl=64 time=0.595 ms
64 bytes from 10.0.0.15: icmp_seq=2 ttl=64 time=0.433 ms
64 bytes from 10.0.0.15: icmp_seq=3 ttl=64 time=0.444 ms
64 bytes from 10.0.0.15: icmp_seq=4 ttl=64 time=0.461 ms
64 bytes from 10.0.0.15: icmp_seq=5 ttl=64 time=0.454 ms
```

# Network ACLテスト2

以下のように、syasdua-test1のIPアドレスをsource IPとするようなruleをInboundの最上位のルールとして設定してみる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/1443db9f-4e3f-688f-58da-ca646a47a91e.png)

```txt:syasuda-test1からsyasuda-test2へのping。pingに失敗する（期待通り）。
$ ping 10.7.0.6
PING 10.7.0.6 (10.7.0.6) 56(84) bytes of data.
^C
```
```txt:syasuda-test1からsyasuda-test3へのping。pingはできてしまう（subnet内通信では効かない）
$ ping 10.0.0.15
PING 10.0.0.15 (10.0.0.15) 56(84) bytes of data.
64 bytes from 10.0.0.15: icmp_seq=1 ttl=64 time=0.371 ms
64 bytes from 10.0.0.15: icmp_seq=2 ttl=64 time=0.365 ms
64 bytes from 10.0.0.15: icmp_seq=3 ttl=64 time=0.444 ms
64 bytes from 10.0.0.15: icmp_seq=4 ttl=64 time=0.385 ms
64 bytes from 10.0.0.15: icmp_seq=5 ttl=64 time=0.346 ms
```