IBM Cloud: 複数インターフェースを持つVSIのeth0以外となぜ通信できないのか？（非対称ルーティングによる解決）

#1. はじめに

[IBM Cloud: 複数インターフェースを持つVSIのeth0以外となぜ通信できないのか？](https://qiita.com/testnin2/items/b896ac54089a9bb22a0b)の解決案1である、非対称ルーティングでの構成例の紹介です。
この場合、Server-Bのeth1から受信したパケットはeth0を通って送信することになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/75c937b0-3c84-a87c-66d9-6e80c948d42e.png)


#2. カーネルパラメーターの設定変更

##2.1 rp_filterの設定変更
[ここ](https://qiita.com/testnin2/items/b896ac54089a9bb22a0b#3-server-b%E3%81%A7%E7%B5%8C%E8%B7%AF%E6%83%85%E5%A0%B1%E3%82%92%E7%A2%BA%E8%AA%8D%E3%81%99%E3%82%8B)で引用したrp_filterの説明としては、`The max value from conf/{all,interface}/rp_filter is used when doing source validation on the {interface}.`と書かれているので、最小の影響範囲に抑えるためには、受け入れ口となるeth1/eth2/eth3で`Strict mode`から`Loose mode`に変換します。
なお、今回は一時的な検証のために、Linuxでの設定例は非永続化構成としています。

```rp_filterの変更
[root@server-b ~]# echo 2 > /proc/sys/net/ipv4/conf/eth1/rp_filter
[root@server-b ~]# echo 2 > /proc/sys/net/ipv4/conf/eth2/rp_filter
[root@server-b ~]# echo 2 > /proc/sys/net/ipv4/conf/eth3/rp_filter
```

##2.2 rp_filterの設定変更後のテスト

```Server-Bのeth1にpingを実行
[root@server-a ~]# ping 172.16.5.4
PING 172.16.5.4 (172.16.5.4) 56(84) bytes of data.
（出力なし）
```

```Server-Bのeth1にはパケットが届いている
[root@server-b ~]# tcpdump -i eth1 icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
02:51:57.446324 IP 172.16.0.4 > 172.16.5.4: ICMP echo request, id 15160, seq 1, length 64
02:51:58.446066 IP 172.16.0.4 > 172.16.5.4: ICMP echo request, id 15160, seq 2, length 64
02:51:59.446042 IP 172.16.0.4 > 172.16.5.4: ICMP echo request, id 15160, seq 3, length 64
```

```Server-Bのeth0からパケットが送信されている
[root@server-b ~]# tcpdump -i eth0 icmp -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:51:57.446366 IP 172.16.5.4 > 172.16.0.4: ICMP echo reply, id 15160, seq 1, length 64
02:51:58.446100 IP 172.16.5.4 > 172.16.0.4: ICMP echo reply, id 15160, seq 2, length 64
02:51:59.446073 IP 172.16.5.4 > 172.16.0.4: ICMP echo reply, id 15160, seq 3, length 64
```

Linuxとしては応答を返すようになりましたが、それでもpingには失敗してます。よって、VPC側の構成で問題があることがわかります。

#3. IP Spoofingの設定

##3-1. eth0のIP Spoofingを有効化
Server-A(172.16.0.4)からServer-B(172.16.5.4)への応答は、もちろん

    Source IPが172.16.5.4
    Destination IPが172.16.0.4

であるべきです。この場合、eth0に紐づいている`172.16.4.2`以外のIPアドレスである`172.16.5.4`をsource IPとしたパケットがeth0から返信されようとしているため、IP Spoofingをブロックした環境では動かせません。よって、eth0のIP Spoofingを有効化します。

[ここ](https://qiita.com/testnin2/items/eef96d180583b6a87fda#4-ip-spoofing%E3%81%AE%E6%9C%89%E5%8A%B9%E5%8C%96)に解説しているとおり、`IP Spoofing Operatorロール`が有効化されている必要があるので注意してください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/962adfe6-01cd-36fc-c937-257215de0ce3.png)

##3-2. IP Spoofing有効化後のテスト

やっとpingが通るようになりました！

```
[root@server-a ~]# ping -c 3 172.16.5.4
PING 172.16.5.4 (172.16.5.4) 56(84) bytes of data.
64 bytes from 172.16.5.4: icmp_seq=1 ttl=64 time=6.30 ms
64 bytes from 172.16.5.4: icmp_seq=2 ttl=64 time=0.400 ms
64 bytes from 172.16.5.4: icmp_seq=3 ttl=64 time=0.531 ms

--- 172.16.5.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.400/2.410/6.301/2.751 ms

[root@server-a ~]# ping -c 3 172.16.6.4
PING 172.16.6.4 (172.16.6.4) 56(84) bytes of data.
64 bytes from 172.16.6.4: icmp_seq=1 ttl=64 time=0.539 ms
64 bytes from 172.16.6.4: icmp_seq=2 ttl=64 time=0.408 ms
64 bytes from 172.16.6.4: icmp_seq=3 ttl=64 time=0.467 ms

--- 172.16.6.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.408/0.471/0.539/0.056 ms

[root@server-a ~]# ping -c 3 172.16.7.4
PING 172.16.7.4 (172.16.7.4) 56(84) bytes of data.
64 bytes from 172.16.7.4: icmp_seq=1 ttl=64 time=0.485 ms
64 bytes from 172.16.7.4: icmp_seq=2 ttl=64 time=0.510 ms
64 bytes from 172.16.7.4: icmp_seq=3 ttl=64 time=0.458 ms

--- 172.16.7.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.458/0.484/0.510/0.027 ms
```