IBM Cloud: 여러 인터페이스가 있는 VSI의 eth0 이외와 통신할 수 없는 이유는 무엇입니까? (정책 기반 라우팅으로 해결)

1. 소개

IBM Cloud: 여러 인터페이스가 있는 VSI의 eth0 이외와 통신할 수 없는 이유는 무엇입니까? 의 해결안 2인, 정책 베이스 라우팅에서의 구성예의 소개입니다.
이 경우 Server-B의 eth1에서 수신한 패킷은 eth1을 통해 전송됩니다.

2. 설정 키모

물론 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에서 전송되는 패킷의 Source IP가 172.16.5.4임에도 불구하고 라우팅 정보를 우선하여 eth0가 사용되었기 때문에 비대칭 라우팅이 발생하고 있었다. 따라서,

Source IP가 172.16.5.0/24 일 때 eth1을 사용합니다.

Source IP가 172.16.6.0/24 일 때 eth2를 사용합니다.

Source IP가 172.16.7.0/24 일 때 eth3을 사용합니다.

라는 규칙을 강제할 수 있으면 비대칭 라우팅은 발생하지 않습니다.

3. 정책 라우팅 구성

3-1. eth1에 대한 정책 기반 라우팅

이번에는 일시적인 검증을 위해 Linux에서의 설정 예는 비지속화 구성으로 하고 있습니다.

기본 라우팅 테이블 구성

[root@server-b ~]# ip rule show
0:  from all lookup local
32766:  from all lookup main
32767:  from all lookup default

[root@server-b ~]# ip route show table main
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

아래에서 정책 기반 라우팅을 구성하고 확인합니다.

table1000 초기화

[root@server-b ~]# ip route flush table 1000

table1000에 기본 게이트웨이 및 서브넷 정보 설정

[root@server-b ~]# ip route add table 1000 to default via 172.16.5.1 dev eth1
[root@server-b ~]# ip route add table 1000 to 172.16.5.0/24 dev eth1

어떤 서브넷의 패킷이 table1000을 사용하는지 지정 (우선 순위는 100)

[root@server-b ~]# ip rule add from 172.16.5.0/24 table 1000 priority 100

설정 확인

[root@server-b ~]# ip rule show
0:  from all lookup local
100:    from 172.16.5.0/24 lookup 1000
32766:  from all lookup main
32767:  from all lookup default

[root@server-b ~]# ip route show table 1000
default via 172.16.5.1 dev eth1
172.16.5.0/24 dev eth1 scope link

마찬가지로 eth2, eth3에 대해서도 정책 기반 라우팅을 설정합니다.

3-2. 테스트

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.
64 bytes from 172.16.5.4: icmp_seq=1 ttl=64 time=0.328 ms
64 bytes from 172.16.5.4: icmp_seq=2 ttl=64 time=0.479 ms
64 bytes from 172.16.5.4: icmp_seq=3 ttl=64 time=0.382 ms

--- 172.16.5.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.328/0.396/0.479/0.064 ms

Server-B에서 eth1로 수신하고 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
07:59:17.595554 IP 172.16.0.4 > 172.16.5.4: ICMP echo request, id 15007, seq 1, length 64
07:59:17.595585 IP 172.16.5.4 > 172.16.0.4: ICMP echo reply, id 15007, seq 1, length 64
07:59:18.595938 IP 172.16.0.4 > 172.16.5.4: ICMP echo request, id 15007, seq 2, length 64
07:59:18.595969 IP 172.16.5.4 > 172.16.0.4: ICMP echo reply, id 15007, seq 2, length 64
07:59:19.595811 IP 172.16.0.4 > 172.16.5.4: ICMP echo request, id 15007, seq 3, length 64
07:59:19.595840 IP 172.16.5.4 > 172.16.0.4: ICMP echo reply, id 15007, seq 3, length 64

Reference

이 문제에 관하여(IBM Cloud: 여러 인터페이스가 있는 VSI의 eth0 이외와 통신할 수 없는 이유는 무엇입니까? (정책 기반 라우팅으로 해결)), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/testnin2/items/635787697e59ab94ce98

텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.

우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)

좋은 웹페이지 즐겨찾기

개발자 우수 사이트 수집

개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다