%20%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4%EC%99%80%20%EC%97%B0%EA%B2%B0%EB%90%9C%20%EA%B2%BD%EC%9A%B0%20Linux%EB%8A%94%20ARP%20%EC%9A%94%EC%B2%AD%20%EB%A9%94%EC%8B%9C%EC%A7%80%EC%97%90%20%EC%9D%91%EB%8B%B5%ED%95%98%EC%A7%80%20%EC%95%8A%EC%8A%B5%EB%8B%88%EB%8B%A4..png)
나는 컴퓨터(커널)를 가지고 있습니다.3.2.0-23-일반)는 인터페이스 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가 192.168.1.2인터페이스의 ARP 요청에 응답합니다.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:~#
이것이 예상되는 동작입니까? 커널이 라우팅 테이블을 무시하는 이유는 무엇입니까?
답변1
정확하게 말하면 라우팅 테이블은 무시되지 않습니다. 우선순위가 더 높은 라우팅 테이블로 재정의됩니다.
어떻게 되어가나요?
입력할 때 표시되는 라우팅 테이블은 ip route show커널에서 사용되는 유일한 라우팅 테이블이 아닙니다. 실제로 라우팅 테이블은 기본적으로 3개가 존재하며, 다음 명령에 표시된 순서대로 검색됩니다 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테이블에서 경로를 찾았으므로 더 이상 경로를 검색하지 않으며 굳이 테이블을 main확인 하지도 않습니다.default
왜 테이블이 여러 개인가요?
최소한 ip route입력할 수 있으면서 "명백한" 경로가 복잡하게 얽혀 있는 것을 볼 수 없다면 좋을 것입니다( route printWindows 시스템에서 입력해 보십시오). 또한 잘못된 구성에 대한 최소한의 보호 역할도 합니다. 기본 라우팅 테이블이 난독화되었더라도 커널은 여전히 자체 통신 방법을 알고 있습니다.
(애초에 로컬 경로를 보존하는 이유는 무엇입니까? 그러면 커널은 다른 모든 것과 동일한 조회 코드를 사용하여 로컬 주소를 찾을 수 있습니다. 이로 인해 내부적으로 작업이 더 간단해집니다.)
이 다중 테이블 구성표를 사용하여 수행할 수 있는 다른 흥미로운 작업이 있습니다. 특히, 자신만의 테이블을 추가하고 검색 규칙을 지정할 수 있습니다. 이를 "정책 라우팅"이라고 하며 해당 정책을 기반으로 패킷을 라우팅하려는 경우원천주소, 이것이 Linux에서 작동하는 방식입니다.
특히 까다롭거나 실험적인 작업을 수행하는 경우 local명령에서 경로를 지정하여 직접 경로를 추가하거나 제거할 수 있습니다. 그러나 당신이 무엇을 하고 있는지 알지 못한다면 커널을 혼란스럽게 할 가능성이 매우 높습니다. 물론 커널은 계속해서 자체 경로를 추가하고 제거하므로 경로를 덮어쓰지 않도록 주의해야 합니다.table localip route
마지막으로 모든 라우팅 테이블을 한 번에 보려면 다음을 수행하십시오.
# ip route show table all
자세한 내용은 다음을 확인하세요.ip-rule(8)맨 페이지 또는iproute2 문서. 당신은 또한 시도할 수 있습니다고급 라우팅 및 트래픽 제어 방법수행할 수 있는 작업의 몇 가지 예입니다.
답변2
당신의역방향 경로 필터링구성에 문제가 있을 수 있습니다.RFC3704- 섹션 2.4
엔터프라이즈 Linux 배포판(RHEL, CentOS, Scientific Linux 등)에서 이 문제를 해결하는 가장 좋은 방법은 아마도 /etc/sysctl.conf수정하는 것 입니다.rp_filter = 2