IBM Cloud: 여러 인터페이스가 있는 VSI의 eth0 이외와 통신할 수 없는 이유는 무엇입니까? (비대칭 라우팅으로 해결)
1. 소개
IBM Cloud: 여러 인터페이스가 있는 VSI의 eth0 이외와 통신할 수 없는 이유는 무엇입니까? 의 해결안 1인, 비대칭 라우팅에서의 구성예의 소개입니다.
이 경우 Server-B의 eth1에서 수신한 패킷은 eth0을 통해 전송됩니다.
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}.
변환합니다.
덧붙여 이번은 일시적인 검증을 위해서, 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
리눅스로서는 응답을 돌려주었습니다만, 그래도 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에 연결하고 있는 Strict mode
이외의 IP 주소인 Loose mode
를 source IP로 한 패킷이 eth0로부터 회신하려고 하고 있기 때문에, IP Spoofing를 블록한 환경에서는 움직일 수 없습니다. 따라서 eth0의 IP Spoofing을 활성화합니다.
여기 에 설명된 대로 172.16.4.2
가 활성화되어 있어야 합니다.
3-2. IP Spoofing 활성화 후 테스트
드디어 핑이 통과하게 되었습니다!
[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
Reference
이 문제에 관하여(IBM Cloud: 여러 인터페이스가 있는 VSI의 eth0 이외와 통신할 수 없는 이유는 무엇입니까? (비대칭 라우팅으로 해결)), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/testnin2/items/ec2c0f3b626699f1c326
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
2.1 rp_filter 설정 변경
여기 에서 인용한 rp_filter 의 설명으로서는
The max value from conf/{all,interface}/rp_filter is used when doing source validation on the {interface}.
변환합니다.덧붙여 이번은 일시적인 검증을 위해서, 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
리눅스로서는 응답을 돌려주었습니다만, 그래도 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에 연결하고 있는 Strict mode
이외의 IP 주소인 Loose mode
를 source IP로 한 패킷이 eth0로부터 회신하려고 하고 있기 때문에, IP Spoofing를 블록한 환경에서는 움직일 수 없습니다. 따라서 eth0의 IP Spoofing을 활성화합니다.
여기 에 설명된 대로 172.16.4.2
가 활성화되어 있어야 합니다.
3-2. IP Spoofing 활성화 후 테스트
드디어 핑이 통과하게 되었습니다!
[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
Reference
이 문제에 관하여(IBM Cloud: 여러 인터페이스가 있는 VSI의 eth0 이외와 통신할 수 없는 이유는 무엇입니까? (비대칭 라우팅으로 해결)), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/testnin2/items/ec2c0f3b626699f1c326
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
Source IPが172.16.5.4
Destination IPが172.16.0.4
[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
Reference
이 문제에 관하여(IBM Cloud: 여러 인터페이스가 있는 VSI의 eth0 이외와 통신할 수 없는 이유는 무엇입니까? (비대칭 라우팅으로 해결)), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/testnin2/items/ec2c0f3b626699f1c326텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)