IBM Cloud: Egress route tableのnext hopの指定でfloating IP(public IP)は利用できないことの確認

1. はじめに

egress route tableを利用した際にnext hopとしてprivate IPを指定したケースと、floating IP(public IP)を指定したケースについての挙動を確認を確認した。

• ServerA: Floating IP(public IP)が紐づいている。
  
• ServerB: Floating IP(public IP)が紐づいている。
  
• Egress Route table
  • Server-Bのprivate IPを指定した経路と、Server-Bに紐づいているFloating IPを指定した経路を準備
    

2. Private IPをnext hopとするEgress custom routeのテスト

• Server-Aにはfloating IPが紐づいているが、VPC-SDN内でsource IPがglobal IPにNATされてインターネットに出ていく前に、custom routeによってServer-Bに転送されている。
• 今回のcustom routeは(X)で実行されていると想像される。egress route tableが有効なのはあくまで指定したprivate subnetなのだから、(X)で経路が変更されると考えるのは自然であろう。また、仮にNATされた後の(Y)で実行されているならば、tcpdumpのsourceがFloating IP(Public IP)になっているはずである。

Server-B(10.0.0.4) ->  (X) -> VPC SDN(AWSにおけるInternet Gatewayみたいなもの） - > (Y) -> Internet
          　　　　　　　　　　　　　　　　　　　　　　　　　　　　|
　          　　　　　　　　　　　　　　　　　　　　　　　　　　　|
　          　　　　　　　　　　　　　　　　　　　　　　　　　　　|--->   Server-A(10.0.0.12)

Server-A

[root@server-a ~]# ping 8.8.8.101
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:00:01:02:70:58 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.4/24 brd 10.0.0.255 scope global dynamic eth0
       valid_lft 265sec preferred_lft 265sec
    inet6 fe80::1ff:fe02:7058/64 scope link
       valid_lft forever preferred_lft forever

[root@server-a ~]# ping 8.8.8.101
PING 8.8.8.101 (8.8.8.101) 56(84) bytes of data.
^C
--- 8.8.8.101 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 4999ms

Server-B

[root@server-b ~]# tcpdump -i any icmp -nn
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
00:29:25.444501 IP 10.0.0.4 > 8.8.8.101: ICMP echo request, id 10709, seq 1, length 64
00:29:26.443771 IP 10.0.0.4 > 8.8.8.101: ICMP echo request, id 10709, seq 2, length 64
00:29:27.443810 IP 10.0.0.4 > 8.8.8.101: ICMP echo request, id 10709, seq 3, length 64
00:29:28.443767 IP 10.0.0.4 > 8.8.8.101: ICMP echo request, id 10709, seq 4, length 64
00:29:29.443828 IP 10.0.0.4 > 8.8.8.101: ICMP echo request, id 10709, seq 5, length 64
00:29:30.443826 IP 10.0.0.4 > 8.8.8.101: ICMP echo request, id 10709, seq 6, length 64

3. Floating IP(public IP)へ転送するcustom routeのテスト

• そもそもnext hopとしてVPCのaddress prefixで定義されていないIPは指定しても無効なのだろう。

Server-A

[root@server-a ~]# ping 8.8.8.101
PING 8.8.8.102 (8.8.8.102) 56(84) bytes of data.
^C
--- 8.8.8.102 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 4999ms

Server-B

[root@server-b ~]# tcpdump -i any icmp -nn
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
（受信なし）