1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

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

Last updated at Posted at 2020-11-15

1. はじめに

IBM Cloud: 複数インターフェースを持つVSIのeth0以外となぜ通信できないのか?の解決案1である、非対称ルーティングでの構成例の紹介です。
この場合、Server-Bのeth1から受信したパケットはeth0を通って送信することになります。
image.png

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

2.1 rp_filterの設定変更

ここで引用した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での設定例は非永続化構成としています。

[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の設定変更後のテスト

[root@server-a ~]# ping 172.16.5.4
PING 172.16.5.4 (172.16.5.4) 56(84) bytes of data.
(出力なし)
[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
[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を有効化します。

ここに解説しているとおり、IP Spoofing Operatorロールが有効化されている必要があるので注意してください。

image.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
1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?