요청한 IP 주소가 다른 (비활성화 된) 인터페이스와 연결된 경우 Linux가 ARP 요청 메시지에 응답하지 않습니다

인터페이스 를 구성하고 인터페이스를 사용 하고 주소를 지정 하는 PC (커널 3.2.0-23-generic )가 192.168.1.2/24있습니다 .eth0192.168.1.1192.168.1.2tun0

root@T42:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:16:41:54:01:93 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 scope global eth0
    inet6 fe80::216:41ff:fe54:193/64 scope link
       valid_lft forever preferred_lft forever
3: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
4: irda0: <NOARP> mtu 2048 qdisc noop state DOWN qlen 8
    link/irda 00:00:00:00 brd ff:ff:ff:ff
5: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:13:ce:8b:99:3e brd ff:ff:ff:ff:ff:ff
    inet 10.30.51.53/24 brd 10.30.51.255 scope global eth1
    inet6 fe80::213:ceff:fe8b:993e/64 scope link
       valid_lft forever preferred_lft forever
6: tun0: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc pfifo_fast state DOWN qlen 100
    link/none
    inet 192.168.1.1 peer 192.168.1.2/32 scope global tun0
root@T42:~# ip route show dev eth0
192.168.1.0/24  proto kernel  scope link  src 192.168.1.2 
root@T42:~# 

위에서 볼 수 있듯이 tun0관리적으로 비활성화되어 있습니다 ( ip link set dev tun0 down). 에 대한 ARP 요청을 받으면 192.168.1.2PC가 해당 요청에 응답하지 않습니다.

root@T42:~# tcpdump -nei eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:30:34.875427 00:1a:e2:ae:cb:b7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.2 tell 192.168.1.1, length 46
15:30:36.875268 00:1a:e2:ae:cb:b7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.2 tell 192.168.1.1, length 46
15:30:39.138651 00:1a:e2:ae:cb:b7 > 00:1a:e2:ae:cb:b7, ethertype Loopback (0x9000), length 60:
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
root@T42:~#

내가 삭제 한 후에 만 tun0인터페이스를 ( ip link del dev tun0)에 PC가에 대한 ARP 요청에 응답 할 것이다 192.168.1.2에 eth0인터페이스를 제공합니다.

라우팅 테이블은 전후에 똑같이 보입니다 ip link del dev tun0.

root@T42:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.30.51.254    0.0.0.0         UG        0 0          0 eth1
10.30.51.0      0.0.0.0         255.255.255.0   U         0 0          0 eth1
192.168.1.0     192.168.1.2     255.255.255.0   UG        0 0          0 eth0
root@T42:~# ip link del dev tun0
root@T42:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.30.51.254    0.0.0.0         UG        0 0          0 eth1
10.30.51.0      0.0.0.0         255.255.255.0   U         0 0          0 eth1
192.168.1.0     192.168.1.2     255.255.255.0   UG        0 0          0 eth0
root@T42:~# 

아래의 라우팅 항목은 이미 ip link set dev tun0 down명령으로 제거되었습니다 .

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.1.2     0.0.0.0         255.255.255.255 UH        0 0          0 tun0

그러나 라우팅 테이블은 ip link del dev tun0명령 전후에 정확히 동일하지만 커널이 실제로 결정할 라우팅 결정은 다음과 같습니다.

T42:~# ip route get 192.168.1.1
local 192.168.1.1 dev lo  src 192.168.1.1 
    cache <local> 
T42:~# ip link del dev tun0
T42:~# ip route get 192.168.1.1
192.168.1.1 dev eth0  src 192.168.1.2 
    cache  ipid 0x8390
T42:~# 

이것이 예상되는 동작입니까? 커널이 라우팅 테이블을 무시하는 이유는 무엇입니까?

라우팅 테이블은 정확하게 무시되지 않습니다. 우선 순위가 높은 라우팅 테이블이 우선합니다.

무슨 일이야

입력 할 때 표시되는 ip route show라우팅 테이블은 커널이 사용하는 유일한 라우팅 테이블이 아닙니다. 실제로 기본적으로 세 개의 라우팅 테이블이 있으며 ip rule명령에 표시된 순서대로 검색됩니다 .

# ip rule show
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

가장 익숙한 main테이블은이지만 우선 순위가 가장 높은 라우팅 테이블은 local입니다. 이 테이블은 로컬 및 브로드 캐스트 경로를 추적하기 위해 커널에 의해 관리됩니다. 즉, local테이블은 커널에게 자체 인터페이스의 주소로 라우팅하는 방법을 알려줍니다. 다음과 같이 보입니다 :

# ip route show table local
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
broadcast 192.168.1.0 dev eth0  proto kernel  scope link  src 192.168.1.2
local 192.168.1.1 dev tun0  proto kernel  scope host  src 192.168.1.1
local 192.168.1.2 dev eth0  proto kernel  scope host  src 192.168.1.2
broadcast 192.168.1.255 dev eth0  proto kernel  scope link  src 192.168.1.2

해당 라인을 참조하십시오 tun0. 그로 인해 이상한 결과가 발생했습니다 route get. 192.168.1.1은 로컬 주소이므로 192.168.1.1에 ARP 응답을 보내려면 쉽습니다. 우리는 그것을 우리 자신에게 보냅니다. 그리고 우리는 local테이블 에서 경로를 찾았 으므로 경로 검색을 중단하고 mainor 또는 default테이블 검사를 방해하지 않습니다 .

왜 여러 테이블입니까?

최소한, ip route"분명한"경로가 화면을 어지럽히는 것을 입력 하고 볼 수 없는 것이 좋습니다 ( route printWindows 시스템에서 입력 을 시도하십시오 ). 또한 구성 오류를 방지하기위한 최소한의 보호 기능을 제공 할 수 있습니다. 기본 라우팅 테이블이 혼잡 해지더라도 커널은 여전히 ​​자신과 대화하는 방법을 알고 있습니다.

(로컬 루트를 먼저 유지하는 이유는 무엇입니까? 따라서 커널은 다른 모든 주소와 동일한 로컬 주소에 대해 동일한 조회 코드를 사용할 수 있습니다. 내부적으로 더 단순 해집니다.)

이 다중 테이블 구성표로 수행 할 수있는 다른 흥미로운 작업이 있습니다. 특히, 고유 한 테이블을 추가하고 검색시기에 대한 규칙을 지정할 수 있습니다. 이를 "정책 라우팅"이라고하며, 소스 주소를 기반으로 패킷을 라우팅하려는 경우 Linux에서 패킷 을 수행하는 방법입니다.

당신이 특히 까다로운 또는 실험적인 일을하는 경우, 추가 또는 제거 할 수 있습니다 local지정하여 경로를 직접 table local에 ip route명령. 당신이하고있는 일을 알지 못한다면 커널을 혼란스럽게 할 것입니다. 물론 커널은 여전히 ​​자체 경로를 계속 추가하고 제거하므로 경로를 덮어 쓰지 않도록주의해야합니다.

마지막으로 모든 라우팅 테이블을 한 번에 보려면 다음을 수행하십시오.

# ip route show table all

자세한 내용은 ip-rule(8)매뉴얼 페이지 또는 iproute2 docs를 확인하십시오 . 수행 할 수있는 몇 가지 예를 보려면 Advanced Routing and Traffic Control HOWTO 를 사용해보십시오 .

귀하의 역 경로 필터링 설정은 아마 문제입니다. RFC3704- 섹션 2.4

Enterprise Linux 배포판 (RHEL, CentOS, Scientific Linux 등)에서이 문제를 해결하는 가장 좋은 방법은 다음을 사용하여 수정하는 것 /etc/sysctl.conf입니다.rp_filter = 2

RHEL에 여러 IP가 구성되어 있으면 원격 네트워크에서 하나만 연결할 수 있습니다. 또는 아웃 바운드 트래픽의 경로가 들어오는 트래픽의 경로와 다른 경우 RHEL이 패킷을 무시하는 이유는 무엇입니까?