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

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

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

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の最上位のルールとして設定してみる。

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

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