다음과 같은 간단한 네트워크 토폴로지가 있습니다.
이 서버에서 보낸 사람 주소(192.168.1.15) 및 대상(10.10.10.252):
server:~ # tcpdump -nei eth0 host 10.10.10.252
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:56:36.152174 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
16:56:37.150442 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
16:56:38.150449 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
16:56:39.159566 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
^C
4 packets captured
5 packets received by filter
0 packets dropped by kernel
server:~ #
느슨한 기본값(0)arp_공지설정?
답변1
커널이 이러한 ARP를 수락/실행하는 이유에 대한 귀하의 가정은 정확하지만 설명하겠습니다.왜그런 일이 일어나고 있습니다.
요점은 실제로 두 개의 네트워크 블록이 있는 브로드캐스트 도메인이 있다는 것입니다.
정의에 따르면 일반적으로 서브넷과 통신할 때 해당 서브넷에 연결된 인터페이스에 속한 네트워크와 통신합니다. 반면 Linux에서는 일반적으로 인터페이스의 기본 IP와 통신합니다.
따라서 r1과 통신할 때 Linux 시스템은 인터페이스(또는 테스트해야 하는 첫 번째 인터페이스의 기본 IP arp_announce)를 소스로 사용하므로 이러한 ARP도 마찬가지입니다.
이를 수락한 이유에 대한 가정으로 돌아가서 올바르게 지적하셨습니다.
arp_announce - INTEGER 인터페이스에서 전송된 ARP 요청의 IP 패킷에 로컬 소스 IP 주소를 알리기 위한 다양한 제한 수준을 정의합니다. 0 - (기본값) 모든 인터페이스에 구성된 로컬 주소 사용
답장을 보내는 데에도 사용할 수 있습니다.
arp_filter - 0 - (기본값) 커널은 다른 인터페이스의 주소를 사용하여 arp 요청에 응답할 수 있습니다. 이는 잘못된 것처럼 보일 수도 있지만 성공적인 의사소통 가능성을 높이기 때문에 종종 의미가 있습니다. IP 주소는 특정 인터페이스가 아닌 Linux의 전체 호스트가 소유합니다. 이 동작은 로드 밸런싱과 같은 보다 복잡한 설정에서만 문제를 발생시킵니다.
게다가:
arp_ignore - INTEGER 로컬 대상 IP 주소를 확인하는 수신된 ARP 요청에 대한 응답으로 응답을 보내는 다양한 모드를 정의합니다. 0 - (기본값): 모든 인터페이스에 구성된 모든 로컬 대상 IP 주소에 응답합니다.
따라서 우리는 Linux 서버가 서버 수준에서 매우 쉬운 방법으로 ARP를 처리한다는 결론을 내릴 수 있습니다.기본적으로.
이는 그림의 라우터 r1의 경우가 아니며 운영 체제/펌웨어의 로컬 기본값과 구성에 따라 달라집니다.