はじめに
IBM CloudにはTransit GatewayというVPC間およびVPC-Classic Infrastructure間を接続できるサービスがあります。これらのサービスを利用している時にClassic Infrastructureとうまく接続できないという相談を受けることがありますが、そのよくある原因についてまとめておきたいと思います。
公式docsは下記に記載があります。
https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-helpful-tips&locale=en
https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-faqs-for-transit-gateway&locale=en
1. Classic InfrastructureでVRFが有効になっていない。
Transit Gatewayを利用するためにはVRFを有効にしておく必要があります。こちらも参考にしてください。
2. Classic Infrastructureがすでに他のTransit Gatewayで利用されている。
Classic Infrastructureは１つのTransit Gatewayでしか利用できません。
3. 自アカウントのTransit Gatewayと別アカウントのClassic Infrastructureを接続しようとしている。
自アカウントのTransit Gatewayと接続できるのは自アカウントのClassic Infrastructureのみです。
4. Classic Infrastructureのサーバーでstatic routeを設定されていない。
Classic InfrastructureのVSIやベアメタルの場合、例えばpublic interfaceを持っているサーバーであれば、デフォルトゲートウェイはInternetに出ていくように構成されています。そのため、VPCが172.16.0.0/16のようなアドレス帯である場合、そのままだとpublic側に通信しようとしてしまいます。VPCへの通信がprivate NWを通るようにClassic Infrastructureのサーバーではstatic routeを構成する必要があります。
（private onlyのサーバーであれば、デフォルトゲートウェイがprivate NWになるように構成された状態でプロビジョニングされているので、追加設定は不要だと思われます）
5. Classic Infrastructure内に優先ルートのあるサブネットをVPC上に定義し、そのサブネットとClassic Infrastructureに通信しようとしている。
10.0.0.0/14、10.200.0.0/14, 10.198.0.0/15, 10.254.0.0/16および各アカウントごとに割り当てられたサブネットはClassic Infrastructure側に優先ルートが設定されているため、VPC側にこれらのサブネットが存在していてもClassic Infrastructure側のサブネット帯と通信してしまいます。
6. Classic InfrastructureのSingle Zone Regionに接続しようとしている。
Classic InfrastructureのMZR対応リージョンはTransit Gateway経由でVPCと接続することができます。例えばClassic InfrastrcutreのDAL13にあるサーバーが東京のTransit Gateway経由でVPCと接続することは可能です。しかし、SingaporeやHongKongやSeoulのようなSZRリージョンは、現在Transit Gateway経由でVPCと接続することはできません。こちらは今後改善されていく予定です。
VPC(Tokyo)とClassic Infrastructure(Singapore)をテストしてみたところ、VPC(Tokyo)とClassic Infrastructure(Singapore)へはパケットは到達しているのですが、その逆が届きませんでした。
[root@vpc ~]# ping 10.117.8.139
PING 10.117.8.139 (10.117.8.139) 56(84) bytes of data.
^C
[root@classincsng ~]# tcpdump -i any icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
18:25:43.634653 IP 172.16.0.4 > 10.117.8.139: ICMP echo request, id 31907, seq 82, length 64
18:25:43.634680 IP 10.117.8.139 > 172.16.0.4: ICMP echo reply, id 31907, seq 82, length 64
18:25:44.634616 IP 172.16.0.4 > 10.117.8.139: ICMP echo request, id 31907, seq 83, length 64
18:25:44.634658 IP 10.117.8.139 > 172.16.0.4: ICMP echo reply, id 31907, seq 83, length 64
18:25:45.634803 IP 172.16.0.4 > 10.117.8.139: ICMP echo request, id 31907, seq 84, length 64
18:25:45.634847 IP 10.117.8.139 > 172.16.0.4: ICMP echo reply, id 31907, seq 84, length 64
18:25:46.634692 IP 172.16.0.4 > 10.117.8.139: ICMP echo request, id 31907, seq 85, length 64
18:25:46.634735 IP 10.117.8.139 > 172.16.0.4: ICMP echo reply, id 31907, seq 85, length 64