설명이 복잡할수 있으니 잘 봐야함.
좀 특이한 환경에서 발생할수 있는 부분이니 환경도 잘 봐야함.
환경:
S_I#1 서버
– eth0 : 1.1.1.49
– 추가카드 eth1 : 2.2.2.169
L3 스위치: 2.2.2.1 IP와 2.2.2.2 IP를 가지도록 구성. 2.2.2.2가 Inbound를 맡음.
본래 2.2.2.30와 연결될때 srcIP를 1.1.1.49 를 가지고 접속 했다.
2.2.2.30은 srcIP가 1.1.1.49 에 대해서 허용하도록 ACL이 걸려있었다.
eth1을 추가했는데, 2.2.2.x대와 동일 대역이어서 2.2.2.30 이 srcIP가
1.1.1.49 가 아니라 2.2.2.169 라서 거부하길래 다음과 같이 강제 라우팅을
넣었다.
목적은 2.2.1.10 서버를 eth1에서 연결하도록 하기 위해서 세팅을 저렇게 했음.
1) Before
# /sbin/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
2.2.0.0 2.2.2.1 255.255.0.0 UG 0 0 0 eth1
default 1.1.1.1 0.0.0.0 UG 0 0 0 eth0
2) After
# /sbin/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
2.2.2.0 1.1.1.1 255.255.255.0 UG 0 0 0 eth0
2.2.0.0 2.2.2.1 255.255.0.0 UG 0 0 0 eth1
default 1.1.1.1 0.0.0.0 UG 0 0 0 eth0
2)를 적용한 시점부터 문제가 발생하였다.
4시간 마다, 2.2.2.30 이 아니라 2.2.1.10 서버랑 연결이 끊기는 것이다.
이유는 2.2.2.2 가 arp를 요청하는데 1.1.1.49(S_I#1) 서버가 응답하지 않았기
때문이었다.
응답을 하지 않은 이유는, 다음 이유들 때문이었다.
1) 커널단에서 arp의 필터 검사를 한다.
http://lxr.linux.no/linux+v3.2.6/net/ipv4/arp.c 를 보면
static int arp_filter(__be32 sip, __be32 tip, struct net_device *dev) 함수에서
라우팅 테이블을 보고 out i/f를 검사하는 부분이 있다.
2) net.ipv4.conf.eth1.rp_filter 가 1인 경우
# /sbin/sysctl -a |grep rp_f
net.ipv4.conf.eth1.arp_filter = 0
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.lo.rp_filter = 1
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.all.rp_filter = 1
…
* 결론
다음 중 한가지를 따르면 된다.
1) net.ipv4.conf.eth1.rp_filter 를 0으로 변경한다.
2) 2.2.2.30 로 향하는 route를 -net이 아닌 -host로 설정하고 2.2.2.0 에 대한것을
제거하는 방법
3) 2.2.2.0 를 제거하고 2.2.2.30 에 2.2.2.169 로 ACL을 Accept로 여는 방법.
테스트
ex) 2.2.2.30 서버에서
arping -I bond0 -c 3 2.2.2.169
해서 테스트.