☰

패킷이 반환되지만 경로 추적이 실패함

tag-icon • tag-icon wireshark networking
패킷이 반환되지만 경로 추적이 실패함

Traceroute에서 다음 출력을 얻습니다.

#traceroute -i eth1 -s 192.168.12.14 192.168.1.72

1  192.168.12.1 (192.168.12.1)  1.410 ms  2.076 ms  2.251 ms
2  * * *
3  * * *
etc..

그러나 다른 터미널에서는 대상 호스트로부터 올바른 응답(포트 도달 불가)이 도착하는 것을 볼 수 있습니다.

9.964867 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)     
9.964879 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964886 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964904 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964923 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964927 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)

처음에는 방화벽 문제인 줄 알았으나 확인해 보니 패킷이 삭제되지 않습니다. 유일하게 떠오르는 것은 이것이 두 번째 NIC라는 것입니다.

첫 번째 NIC에서 동일한 호스트에 대해 Traceroute를 실행하면 위와 동일한 Wireshark 추적을 얻습니다(분명히 다른 소스 IP를 사용하여). 하지만 Traceroute 명령은 성공합니다.

Wireshark가 어떻게 응답을 볼 수 있는지 이해가 안 되지만 두 번째 NIC에서는 Traceroute가 실패합니다.

여기에 아주 기본적인 것이 빠져있는 것 같아요 ....

답변1

Wireshark는 네트워크 인터페이스에 도착하는 내용을 보여줍니다. 커널은 분명히 이러한 패킷을 보았지만 어떤 이유로 인해 해당 패킷이 Traceroute 명령으로 전달되지 않기로 결정했습니다.

커널이 해당 패킷을 전달하지 않기로 결정하게 만드는 몇 가지 문제가 있을 수 있습니다.

  • 역방향 경로 필터링에 적합하지 않지만 활성화된 상태로 남아 있는 비대칭 라우팅이 있을 수 있습니다 rp_filter.
  • 커널이 ICMP 오류 메시지의 내용을 로컬 소켓과 일치시키지 못할 수도 있습니다. 이는 그러한 결정을 내리는 데 사용할 수 있는 정보가 부족하여 패킷이 잘렸기 때문에 발생할 수 있습니다. 이는 한 방향의 패킷이 NAT를 통해 라우팅되지만 다른 방향으로는 라우팅되지 않는 일부 손상된 NAT 구성으로 인해 발생할 수도 있습니다.
  • 잘못된 체크섬으로 인해 커널이 패킷을 삭제할 수 있습니다.

그중에서 나는 이것이 rp_filter가장 그럴듯한 설명처럼 들린다고 생각한다. 운영 체제를 지정하지 않았지만 Linux 시스템인 것 같으니 다음 명령을 시도해 보세요 head /proc/sys/net/ipv4/conf/*/rp_filter. 1필터가 활성화되었음을 의미하는 모든 항목에 표시될 가능성이 높습니다 . 0패킷이 삭제되는 인터페이스에 해당하는 이름과 장치 이름에 a를 써 보십시오 all.

답변2

각 상자의 라우팅 테이블 출력을 여기에 게시할 수 있습니까? 유효하지 않거나 누락된 기본 경로가 있는 경우 패킷에는 반환 경로가 없습니다. 다음 출력을 게시하십시오.

# IP 경로 목록

각 리눅스 박스에.

관련 정보