[server] ARP 회신에 잘못된 MAC 주소가 포함되어 있습니다

유선 및 무선 어댑터로 Linux를 실행하는 로봇이 있습니다. 부팅 할 때 무선으로 연결됩니다. 유선 (정적으로 또는 DHCP로)에 IP를 할당하면 작동하는 것처럼 보입니다. 에서와 같이 ifconfig적절한 IP와 route적절한 경로를 보여줍니다. 그러나 유선 IP의 ARP 요청을 수행하면 ARP 응답에 무선 MAC이 포함됩니다.

??? 로봇에는 다리가 없으므로 유선 MAC을 얻지 못하는 이유는 무엇입니까 ???

유선 연결이 끊어지면 유선 IP가 Ping에 응답합니다.

로봇이 무선 인터페이스를 통해 유선의 IP 요청에 응답하는 이유는 무엇입니까 ???

편집 : 동일한 IP 서브넷의 유선 및 무선 어댑터. 동일한 IP 서브넷의 컴퓨터 (다른 컴퓨터와 함께 시도)에서 ARP 요청을합니다.

답변

동일한 네트워크에 두 개의 인터페이스가있는 경우 정상적인 동작입니다. 이 LWN 기사에 설명되어 있습니다.

답변

잘못된 인터페이스에 대한 ARP 응답을받을 때 실제로 트래픽을 덤프하거나 결과 ARP 테이블을보고 있습니까? 두 인터페이스 모두에 대해 ARP 응답을받을 수 있습니다 …

어쨌든, 나는 당신의 문제에 대한 답이 올바르게 조작 rp_filter하고 있다고 생각합니다 arp_filter. 각각에 대한 설명서가 아래에 포함되어 있습니다.

먼저 이것을 시도하는 것이 좋습니다.

echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

당신은 할 수 물론이 변경 사항을 확인해야합니다 :

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

rp_filter-부울 EAN
1-RFC1812에 지정된대로 역방향 경로로 소스 유효성 검증을 수행하십시오.
단일 홈 호스트 및 스텁 네트워크에 권장되는 옵션
라우터. 복잡한 문제를 일으킬 수 있음 (루프가 아님)
느리고 신뢰할 수없는 프로토콜 (RIP 종류)을 실행하는 네트워크
또는 정적 경로를 사용합니다.

0-소스 유효성 검증이 없습니다.

소스 확인을 수행하려면 conf / all / rp_filter도 TRUE로 설정해야합니다.
인터페이스에서

기본값은 0입니다. 일부 배포판에서는이를 활성화합니다.
시작 스크립트에서.

arp_filter-BOOLEAN
1-동일한 네트워크에 여러 네트워크 인터페이스를 가질 수 있습니다
각 인터페이스에 대한 ARP에 응답해야합니다.
커널이 패킷을 라우팅할지 여부에 따라
해당 인터페이스의 ARP IP 아웃 (따라서 소스를 사용해야 함)
이것이 작동하려면 기반 라우팅). 다시 말해 제어가 가능합니다
arp 요청에 응답 할 카드 (보통 1)입니다.

0-(기본값) 커널은 주소가있는 arp 요청에 응답 할 수 있습니다
다른 인터페이스에서. 이것은 잘못 보일 수 있지만 일반적으로
그것은 성공적인 의사 소통의 기회를 증가시키기 때문입니다.
IP 주소는 Linux가 아닌 전체 호스트가 소유합니다.
특정 인터페이스. 로드와 같은 더 복잡한 설정에만 해당
균형을 잡으면이 동작으로 문제가 발생합니까?

인터페이스에 대한 arp_filter는 다음 중 하나 이상인 경우 활성화됩니다.
conf / {all, interface} / arp_filter가 TRUE로 설정되었습니다.
그렇지 않으면 비활성화됩니다

보다 철저한 치료 방법은이 기사를 참조하십시오.

http://www.embedded-bits.co.uk/tag/rp_filter/

답변

나는 이것이 오래된 문제라는 것을 알고 있지만 최근에는 임베디드 장치와 동일한 상황이 발생했습니다. 이 장치에는 이더넷 및 Wi-Fi 인터페이스가 모두 필요하며 두 인터페이스 모두 언제든지 동일한 네트워크에서 활성화 될 수 있어야하지만 네트워크 트래픽은 “선호”인터페이스를 통해 라우팅되어야합니다.

대부분의 사용자는 이런 방식으로 장치를 구성하지 않지만 이론 상으로는 가능합니다.

우리는 IP 주소 충돌을보고하기 때문에 Netgear 라우터와 관련된 문제를 먼저 찾아 냈습니다. 2 개의 MAC 주소가 단일 IP를 공유하고있었습니다. 분명히이 시나리오에서는 라우터가 제대로 작동하지 않고 사용자 네트워크를 망칠 것입니다.

라우터 (이더넷 + wifi), Windows 랩톱 (이더넷 전용) 및 내장 장치 (이더넷 + wifi) 만 포함하는 개인 네트워크를 만들었습니다. wireshark, 장치의 tcpdump 및 Windows의 arp를 사용하면 다음과 같은 동작을 볼 수 있습니다.

장치의 구성에 고유 한 wln 및 이더넷 IP 및 고유 한 MAC 주소가 표시되는 경우
때때로 (매우 드물게) Windows의 arp –a가 올바른 IP-MAC 조합을 보여줍니다.
대부분의 경우 arp –a from windows는 wln과 eth0이 동일한 MAC 주소를 가지고 있음을 보여줍니다
창에서 wln 또는 eth0을 ping 할 때 ping 응답은 wln에서오고 eth0에서는 거의 발생하지 않습니다. tcpdump는 wln이 4 개의 핑 중 하나에 만 응답했음을 표시합니다 (예 🙂
Windows가 eth0 IP에 대해 arp“who have”메시지를 보내면 eth0 및 wln 인터페이스 모두 해당 IP가 있다고 응답합니다.

항목 3은 항목 5에 의해 발생한다고 생각합니다. wln이 eth0 만 응답해야하는 arp 메시지에 응답하기 때문에 arp 테이블이 엉망입니다. 항목 4도 항목 5에 의해 발생한다고 생각합니다. Ping은 MAC 주소를 기반으로 전송되며 수신 된 마지막 arp 메시지는 wln에서 eth0 IP를 가지고 있다는 메시지이므로 핑이 wln 인터페이스로 잘못 라우팅됩니다.

많은 파기 및 테스트 후 솔루션은 실제로 간단했습니다. 이 기사를 참조하십시오 -http : //blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html

Linux 커널 네트워크 드라이버는 알려진 인터페이스에 대한 arp 요청이 수신 될 때 (다른 인터페이스에서 수신 되더라도) arp에 응답하도록 구성됩니다.

이 설정은 문제를 해결합니다.

echo 1 > /proc/sys/net/ipv4/conf/wln/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

설명:

arp_ignore - INTEGER
Define different modes for sending replies in response to
received ARP requests that resolve local target IP addresses:
0 - (default): reply for any local target IP address, configured
on any interface
1 - reply only if the target IP address is local address
configured on the incoming interface
2 - reply only if the target IP address is local address
configured on the incoming interface and both with the
sender's IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope host,
only resolutions for global and link addresses are replied

답변

이전 버전의 OS (openembedded 기반)에서 제대로 작동했기 때문에 내 솔루션은 다음 버전의 OS를 기다리는 것입니다. 가장 좋은 추측은 무선 커널 모듈이 버그 였다는 것입니다.

답변

Insyte의 의견에 후속.

몇 가지 명명을 할 수 있습니다.

PC1-오른쪽 위
PC2-왼쪽 상단
PC3-왼쪽 하단

유선 및 무선 미디어를 통해 3 대의 PC에서 로봇에 도달 할 수 있습니다. 그리고 동일한 서브넷에 있기 때문에 유선 미디어에 대한 arp 요청이 어떤 방식으로 진행되었는지 알 수 없습니다. ARP 요청에 대한 스위치 방송, 로봇은 두 인터페이스에 수신되면 내 말하는 것이으로는의 유선 매체의 IP에 대한 ARP 요청 수신에 대해 너무 [다이어그램을 참조] 무선 매체 도 기회는을 박스에 대한 무선 미디어의 물리적 주소로 응답했습니다.

나는 과거 에이 문제를 겪어 왔지만, 당신에게는 정확하지 않았지만 비슷했습니다. 기본적으로 리눅스는 인터페이스의 물리적 주소로 응답하며 IP가 구성된 인터페이스에 관계없이 arp 요청을 수신합니다. 따라서 귀하의 경우 PC3을 로봇의 eth0 인터페이스에 직접 연결하고 192.168.0.101에 대한 arp 요청을 수행하면 ra0 대신 eth0 인터페이스의 물리적 주소로 응답합니다.

내 배포 시나리오는 다음과 같습니다.

[RTR] | ———— eth0 — [서버]
| ——– | switch1 | —– eth1 —– [서버]

동일한 인터페이스로 두 인터페이스가 모두 연결됩니다. 도움이 되길 바랍니다.

라우터에는 서버의 서로 다른 두 인터페이스에있는 서로 다른 두 네트워크에 대해 인터페이스에 기본 및 보조 IP 주소가 구성되어 있습니다. 그러나 eth0의 IP 주소에 대한 eth1에서 arp 요청을 수신하면 eth1의 실제 주소로 응답했습니다.

그것을 방지하기 위해 다음은 지금까지 나를 위해 일했습니다.

# echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
# echo 2 > /proc/sys/net/ipv4/conf/ra0/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/ra0/arp_ignore

로봇 어딘가에 놓으면 부팅시 적용 할 수 있습니다.

권장 사항 : 두 개의 서로 다른 서브넷을 구성하는 것이 좋습니다 (예 : ra0에서 192.168.1.x / 24 및 eth0에서 192.168.2.x / 24). PC에서 IP 별칭을 사용할 수 있으며 로봇은 모든 두 IP 중 동일한 호스트에서 동일한 서브넷에 대해 두 개의 아웃 바운드 경로를 가질 수 없습니다. 로봇이 다른 로봇을 선호하게하는 것이 없다면 말입니다. 로봇은 하나의 경로 만 사용하여 패킷을 보낼 수 있습니다.

일부 판독 값 :
arp_announce ,
arp_ignore

답변

무선 AP와 스위치간에 구성이 잘못되었다고 생각합니다. 스위치와 AP가 패킷을 보낼 위치를 혼동하고 있습니다. 그래도 확실하지 않습니다. 또한 프로그램이 패킷을 보낼 위치를 알 수있는 게이트웨이를 정의해야한다고 생각합니다. 같은

route add default gw 192.168.0.1