Ping이 작동하지 않지만 Wireshark가 ICMP 요청 및 응답을 감지합니다.

Question 1

실제로 설정이 설명대로라고 가정하면(실수로 잘못 구성된 것은 없습니다) 클라이언트 10.10.11.1/30에 10.10.11.9/30(기본 게이트웨이, 고정 경로 등을 통해)으로 라우팅하는 방법에 대한 정보가 없으면 ICMP가 없습니다. 패킷을 보내야 합니다.

Cisco Paket Tracer에서 사용해 보세요. 두 개의 클라이언트와 그 사이에 하나의 스위치가 있는 네트워크를 설정하십시오. 구성된 기본 게이트웨이가 없고 클라이언트가 다른 브로드캐스트 도메인에 있는 한 클라이언트는 ARP 패킷을 보내지도 않습니다.

이는 현재 구성이 일종의 "라우팅 확인"을 제공하므로 ICMP 패킷이 실제로 전송되고 수신된다는 의미입니다. 기본 게이트웨이, 정적 경로 등을 통해 가능합니다. 프레임이 어떤 MAC 주소로 설정되어 있는지 레이어 2를 확인하세요. 클라이언트 또는 라우터에 직접 연결됩니까? 내 의견에 쓴 것처럼 :

ICMP 패키지는 라우터, 고정 경로, "proxy-arp" 등과 같은 일부 "이국적인" 구성을 통해 전송되어야 했습니다. 레이어 2에서는 어떤 일이 발생합니까? IP 주소가 MAC 주소로 어떻게 확인됩니까? 나는 이것이 애초에 응답이 있는 이유(그러면 안 되는)에 대한 해결책으로 이어질 것이라고 생각합니다.

수신된 패킷이 핑 통계에 표시되지 않는 이유는 또 다른 문제입니다. 방화벽이 이를 차단할 수도 있습니다(ping 명령은 개별 ping에 대한 오류나 확인을 제공하지 않기 때문에 요약만 제공하는 것 같습니다).

내가 가진 유일한 다른 설명은 시스템을 엉망으로 만드는 다른 종류의 엉뚱한 구성이 있다는 것입니다(예: 대상과 동일한 IP 주소를 갖고 소스와 같은 브로드캐스트 도메인 내에 있는 두 번째 클라이언트 등). 프레임의 MAC 주소를 실제 클라이언트의 MAC 주소와 비교하여 레이어 2에서도 이를 확인할 수 있습니다.

보적: 기본 게이트웨이, 고정 경로 등을 설정했을 수 있나요? 라우터에 24비트 네트워크 마스크가 있습니까? 이 경우 서브넷은 다르지만 라우터와 클라이언트의 브로드캐스트 도메인이 겹칩니다. 이것은 현재의 행동을 설명할 수 있습니다.

Answer