1. 소개

IBM Cloud VPC에서 다음과 같은 구성 중에

Server-A (172.16.0.4)에서 Server-B의 첫 번째 인터페이스 인 eth0이있는 172.16.4.2는 ping을 통과합니다.

그러나 Server-A에서 Server-B의 eth1-eth3의 IP는 ping을 통과하지 않습니다.

라고 했습니다. 왜? 그것을 이해하는 것이이 기사의 목적입니다.

[root@server-a ~]# ping -c 3 172.16.4.2
PING 172.16.4.2 (172.16.4.2) 56(84) bytes of data.
64 bytes from 172.16.4.2: icmp_seq=1 ttl=64 time=3.86 ms
64 bytes from 172.16.4.2: icmp_seq=2 ttl=64 time=0.444 ms
64 bytes from 172.16.4.2: icmp_seq=3 ttl=64 time=0.455 ms

--- 172.16.4.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.444/1.589/3.868/1.611 ms

[root@server-a ~]# ping -c 3 172.16.5.4
PING 172.16.5.4 (172.16.5.4) 56(84) bytes of data.
（出力なし）

[root@server-a ~]# ping -c 3 172.16.6.4
PING 172.16.6.4 (172.16.6.4) 56(84) bytes of data.
（出力なし）

[root@server-a ~]# ping -c 3 172.16.7.4
PING 172.16.7.4 (172.16.7.4) 56(84) bytes of data.
（出力なし）

2. Server-B에서 tcpdump 얻기

이러한 문제를 파싱하는 데 도움이되는 것은 (일반적으로) tcpdump입니다.

Server-A에서 Server-B(eth1)로의 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.

（応答なし）

Server-B(eth1)에 도착했지만 응답하지는 않습니다.

[root@server-b ~]# 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

02:17:49.498516 IP 172.16.0.4 > 172.16.5.4: ICMP echo request, id 14512, seq 1, length 64
02:17:50.497642 IP 172.16.0.4 > 172.16.5.4: ICMP echo request, id 14512, seq 2, length 64
02:17:51.497650 IP 172.16.0.4 > 172.16.5.4: ICMP echo request, id 14512, seq 3, length 64

Server-B에서 tcpdump를 사용하면 패킷 자체가 도착했음을 알 수 있습니다. 즉, Security Group 등에서 차단되고 있다는 것은 아닐 것 같습니다.
또, 수신한 패킷의 응답을 하고 있지 않기 때문에, 원인은 Server-B 자신에게 있을 것 같다는 목성이 붙습니다.

3. Server-B에서 라우팅 정보 확인

물론 Server-A(172.16.0.4)에서 Server-B(172.16.5.4)에 대한 응답은 물론

Source IP 172.16.5.4

Destination IP가 172.16.0.4

해야 합니다. 이 경우 Server-B는 어떤 경로를 사용합니까?

[root@server-b ~]# ip r
default via 172.16.4.1 dev eth0
169.254.0.0/16 dev eth0 scope link metric 1002
172.16.4.0/24 dev eth0 proto kernel scope link src 172.16.4.2
172.16.5.0/24 dev eth1 proto kernel scope link src 172.16.5.4
172.16.6.0/24 dev eth2 proto kernel scope link src 172.16.6.4
172.16.7.0/24 dev eth3 proto kernel scope link src 172.16.7.4

172.16.0.4로의 경로는 어디가 사용되는가?

[root@server-b ~]# ip route get 172.16.0.4
172.16.0.4 via 172.16.4.1 dev eth0 src 172.16.4.2
    cache

즉, Server-A(172.16.0.4)에는 eth0를 통해 전송하는 설정이 되어 있습니다. eth1로 패킷을 받았음에도 불구하고! .
이러한 수신된 인터페이스와 응답하는 인터페이스가 다른 네트워크 구성을 비대칭 라우팅이라고 하며 기본적으로 허용되지 않습니다.

[root@syasuda-router ~]# sysctl -ar '\.rp_filter'
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.eth2.rp_filter = 1
net.ipv4.conf.eth3.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 0

rp_filter - INTEGER
    0 - No source validation.
    1 - Strict mode as defined in RFC3704 Strict Reverse Path
        Each incoming packet is tested against the FIB and if the interface
        is not the best reverse path the packet check will fail.
        By default failed packets are discarded.
    2 - Loose mode as defined in RFC3704 Loose Reverse Path
        Each incoming packet's source address is also tested against the FIB
        and if the source address is not reachable via any interface
        the packet check will fail.

    Current recommended practice in RFC3704 is to enable strict mode
    to prevent IP spoofing from DDos attacks. If using asymmetric routing
    or other complicated routing, then loose mode is recommended.

    The max value from conf/{all,interface}/rp_filter is used
    when doing source validation on the {interface}.

    Default value is 0. Note that some distributions enable it
    in startup scripts.

4. 솔루션

제안 1 : eth1에서 수신한 패킷을 eth0를 통해 반환하도록 커널 매개변수를 변경합니다.
제안 2 : eth1에서 수신된 패킷은 eth1에서 반환되도록 정책 기반 라우팅을 구성한다.

방안 1은 비대칭 라우팅을 허용한다는 것이므로 그에 따른 취약성도 감수해야 합니다. 또한 eth0의 IP Spoofing도 활성화해야합니다. 따라서, 만약 eth1-eth3에 통신시킬 필요가 있다면, 개인적으로는 안 2쪽을 추천합니다. 구체적인 순서에 대해서는 각각의 안에 있어서의 링크처를 참조해 주세요.