1. はじめに
ある日、Classic InfrastructureのDNS(10.0.80.11/10.0.80.12)が使えないという事象が発生しているという相談がありました。今回は、その調査を実施した際の結果と、何が原因だったのかを共有したいと思います。
2. まずは事象を確認してみた
以下のように、あるVSIでDNSを引いてみましたが、確かに動いていないようです。
# cat /etc/resolv.conf
; Created by cloud-init on instance boot automatically, do not edit.
;
nameserver 10.0.80.11
nameserver 10.0.80.12
# dig www.yahoo.co.jp @10.0.80.11
(No response or freezed)
# dig www.yahoo.co.jp @10.0.80.11
(No response or freezed)
# dig www.yahoo.co.jp
(No response or freezed)
# nmap -sU 10.0.80.10 -p 53
Starting Nmap 6.40 ( http://nmap.org ) at 2021-07-21 14:11 JST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.07 seconds
# nmap -sU 10.0.80.11 -p 53
Starting Nmap 6.40 ( http://nmap.org ) at 2021-07-21 14:11 JST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.06 seconds
このあと、さらに調査した結果、
- Gateway ApplianceやSecurity Groupでブロックされている訳ではない。
- 周りで大騒ぎになっているようでもないし、Incidentも挙がっていない（他のアカウントでは問題になっていない）。
- 東京DCだけでなく、他のDCでも発生している。
つまり、このアカウント固有の問題であり、このアカウント全体で発生している問題だということが想像されました。また、新たに以下のことが判りました。
- VSIからは、DNSだけでなくNTP（10.0.77.54）にもpingができない
- SSL VPN経由で端末からVSIにpingができない。でもSSL VPN経由で10.0.80.11/10.0.80.12にはpingできる。SSL VPN利用時には、端末には10.2.x.xなどが割り当てられるので、逆にいうとVSIからは10.2.x.xへの通信ができないと考えられる。
- VSIからは、10.3.xx.xxなどに割り当てられたEndurance Storageにはpingができた。
- VSIからは、161.26.0.10(Service endpointに設けられたDNS)にはpingができた。
以上のことから、Classic Infrastructureのサービスネットワーク（10.0.0.0/14=10.0.0.0/24, 10.1.0.0/24, 10.2.0.0/24, 10.3.0.0/24)全てに接続できないのではなく、その一部にのみ繋がらないということが判りました。
3. Classic Infrastructureの経路を歪めているのは誰？
特定のネットワークだけ正しくない宛先にルーティングされているような動きに見えたので、ここで「はっ！？」と思ったのがTransit Gatewayです。Transit GatewayはClassic InfrastructureとVPCの間を接続することができ、VPCはIP Address Prefix単位でTransit Gatewayに対して広告をします。
果たして、実際に確認してみると、、、このアカウントにはTransit Gatewayが複数定義されており、複数のVPCと接続されていました。そのうち１つのVPCでは以下のようなaddress prefixを持つVPCがいました。
Transit Gatewayの接続先からこのVPCを削除すると、Classic InfrastructureのDNSにはちゃんとアクセスできるようになりました。
4. Lessons Learned
IBM Cloud docsには以下の記載があります。https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-addressing-plan-design&locale=en
When creating VPC instances that you intend to interconnect using IBM Cloud Transit Gateway, avoid selecting Default address prefixes when creating multiple instances. Make sure to create your VPC instances with non-overlapping prefixes for successful connectivity.
When creating VPC instances that you also intend to interconnect with your IBM Cloud classic infrastructure using IBM Cloud Transit Gateway, do not use IP addresses in your instances in the 10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15, and 10.254.0.0/16 blocks. You should also avoid using IP addresses from your classic infrastructure subnets.
また、こういう記載もあります。
https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-overlapping-vpc-prefixes-and-classic-subnets&locale=en
However, when a transit gateway is used to connect these formerly isolated networks and the networks have VPC prefixes and classic infrastructure subnets that overlap, this can cause networking issues. If traffic does not appear to be routing to the correct network, this could be the issue.
つまり、Classic Infrastructureと接続したいのであれば、VPC側にClassic Infrastructureのサービスネットワークと被ってしまうaddress prefixを定義してはいけない ということです。address prefixがClassic Infrastructureのサービスネットワークと被っていても、「Classic Infrastructureからすればそのaddress prefixから割り当てられたVPC上のサブネットと通信できなくなるだけであり、サービスネットワークに対して優先経路が設けられているので構成上は問題ない」と私も最初は思っていましたが、そういう訳ではないようです。
ちなみに、このVPCがTransit Gatewayで接続されている状態で、Classic Infrastructure上のVSIは、10.0.0.4というIPアドレスを持つVPC上のVSIと接続することもできませんでした。Classic Infrastructureからすると単にサービスネットワークへの経路が歪められただけでなく、そもそも被ってしまったVPC上のネットワークにも接続できないということですから、何も嬉しくないですね。
ということで、Classic Infrastrucutreと接続するVPCを構成する時は、Address prefixのデザインがとても重要だということを身にしみた一件でした。