이 IP 주소로 라우트를하는데 왜 핑 (ping)이되지 않습니까?

IP 주소가 있고 경로를 추적 할 수 있지만 핑할 수 없습니다.

알다시피, 나는 traceroute 할 수 있습니다 43.224.226.50:

dele-MBP:~ ll$ traceroute 43.224.226.50
traceroute to 43.224.226.50 (43.224.226.50), 64 hops max, 52 byte packets
 1  router.asus.com (192.168.2.1)  2.082 ms  1.039 ms  0.924 ms
 2  100.64.0.1 (100.64.0.1)  3.648 ms  3.795 ms  3.955 ms
 3  118.112.212.225 (118.112.212.225)  4.252 ms  4.569 ms  4.168 ms
 4  171.208.203.73 (171.208.203.73)  6.378 ms
    171.208.198.25 (171.208.198.25)  6.943 ms
    171.208.203.61 (171.208.203.61)  7.055 ms
 5  202.97.36.225 (202.97.36.225)  38.149 ms
    202.97.36.221 (202.97.36.221)  39.949 ms
    202.97.36.225 (202.97.36.225)  40.780 ms
 6  202.97.90.158 (202.97.90.158)  37.894 ms
    202.97.94.146 (202.97.94.146)  39.885 ms  39.354 ms
 7  202.97.38.166 (202.97.38.166)  45.324 ms
    202.97.39.149 (202.97.39.149)  40.097 ms
    202.97.94.77 (202.97.94.77)  40.580 ms
 8  202.97.51.118 (202.97.51.118)  374.218 ms
    202.97.27.238 (202.97.27.238)  187.573 ms
    202.97.86.138 (202.97.86.138)  197.524 ms
 9  218.30.53.190 (218.30.53.190)  201.597 ms
    218.30.54.190 (218.30.54.190)  194.194 ms
    218.30.53.190 (218.30.53.190)  204.027 ms
10  182.54.129.91 (182.54.129.91)  220.026 ms  282.360 ms
    et-11-1-5.r01.laxus01.us.bb.bgp.net (182.54.129.38)  185.700 ms
11  182.54.129.91 (182.54.129.91)  229.700 ms  508.509 ms  266.683 ms
12  * 212.95.128.2 (212.95.128.2)  565.161 ms *
13  43.224.226.50 (43.224.226.50)  200.531 ms  201.911 ms  191.566 ms

그러나 나는 그것을 핑 할 수 없다 :

dele-MBP:~ ll$ ping 43.224.226.50
PING 43.224.226.50 (43.224.226.50): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11

ICMP가 금지 된 경우에도 traceroute작동하지 않아야합니다. 그 이유는 무엇입니까?

서버의 방화벽이 중지되었는지 확인했습니다.

비슷한 질문 에서 Luke Savage는 그것을 완벽하게 설명했습니다.

Traceroute는 프로토콜 자체가 아니라 응용 프로그램이며 사용되는 프로토콜은 사용중인 구현에 따라 다릅니다. 주로 ICMP입니다.

두 가지 주요 구현이 있습니다.

tracert-tracert는 ICMP 패킷을 증분 TTL 필드로 사용하여 홉을 최종 대상 주소에 매핑하는 Windows 응용 프로그램입니다.

traceroute-traceroute는 네트워크 장치 및 Cisco 장치를 포함한 대부분의 Linux 기반 시스템에서 사용할 수있는 * nix 응용 프로그램입니다. 이것은 증가하는 TTL 필드와 함께 UDP 패킷을 사용하여 홉을 최종 대상에 매핑합니다.

이들 네트워크의 차이점은 일부 네트워크는 이제 기본적으로 ICMP를 차단하므로 Windows 시스템의 PING과 tracert는 모두 실패하지만 Linux 장치의 traceroute는 여전히 작동 할 수 있다는 점을 알고 있으면 유용합니다.

@ naïveRSA 의 답변에 추가하기 위해 경로에 필터링 / 방화벽이있는 경우 ICMP "에코 응답"(ping) 패킷은 차단되지만 ICMP "시간 초과"(tracert) 패킷은 허용 될 수 있습니다. . ICMP (Windows) 만 사용하는 경우에도 동일한 결과를 제공합니다.

두 경우 모두 (UDP 또는 ICMP를 사용하여 보낸 경우) 오류 통신은 ICMP가됩니다 (즉, 핑 또는 추적 프로그램 * 패킷에 응답하는 노드).

어떻게되는지 보자, 우리?

내 위치에서 적어도, 나는 모두와 그것에 도달 할 수 있기 때문에 8.8.8.8는 좋은 예를하게 traceroute하고 ping.

먼저 ping 8.8.8.8어떤 일이 일어나는지 살펴 보자 .

$ tcpdump -n host 8.8.8.8 or icmp
15:36:51.045994 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 0, length 64
15:36:51.062458 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 0, length 64
15:36:52.048350 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 1, length 64
15:36:52.073657 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 1, length 64

따라서 pingICMP 에코 요청을 보내고 ICMP 에코 응답이 필요합니다.

지금 traceroute -n 8.8.8.8:

15:41:31.803324 IP 10.4.27.179.44838 > 8.8.8.8.33435: UDP, length 24
15:41:31.815184 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.815343 IP 10.4.27.179.44838 > 8.8.8.8.33436: UDP, length 24
15:41:31.819654 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.819791 IP 10.4.27.179.44838 > 8.8.8.8.33437: UDP, length 24
15:41:31.824609 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.824754 IP 10.4.27.179.44838 > 8.8.8.8.33438: UDP, length 24
15:41:31.830506 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.830649 IP 10.4.27.179.44838 > 8.8.8.8.33439: UDP, length 24
15:41:31.834469 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.834565 IP 10.4.27.179.44838 > 8.8.8.8.33440: UDP, length 24
15:41:31.840962 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.841061 IP 10.4.27.179.44838 > 8.8.8.8.33441: UDP, length 24
15:41:31.847440 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.847634 IP 10.4.27.179.44838 > 8.8.8.8.33442: UDP, length 24
15:41:31.853664 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.853761 IP 10.4.27.179.44838 > 8.8.8.8.33443: UDP, length 24
15:41:31.859221 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.859269 IP 10.4.27.179.44838 > 8.8.8.8.33444: UDP, length 24
15:41:31.864149 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.864192 IP 10.4.27.179.44838 > 8.8.8.8.33445: UDP, length 24
15:41:31.870843 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.870922 IP 10.4.27.179.44838 > 8.8.8.8.33446: UDP, length 24
15:41:31.876200 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.876352 IP 10.4.27.179.44838 > 8.8.8.8.33447: UDP, length 24
15:41:31.882148 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.882249 IP 10.4.27.179.44838 > 8.8.8.8.33448: UDP, length 24
15:41:31.890076 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.890156 IP 10.4.27.179.44838 > 8.8.8.8.33449: UDP, length 24
15:41:31.896100 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.896163 IP 10.4.27.179.44838 > 8.8.8.8.33450: UDP, length 24
15:41:31.905037 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.905235 IP 10.4.27.179.44838 > 8.8.8.8.33451: UDP, length 24
15:41:31.913206 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.913283 IP 10.4.27.179.44838 > 8.8.8.8.33452: UDP, length 24
15:41:31.923428 IP 108.170.242.241 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.923520 IP 10.4.27.179.44838 > 8.8.8.8.33453: UDP, length 24
15:41:31.932266 IP 108.170.237.9 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.932441 IP 10.4.27.179.44838 > 8.8.8.8.33454: UDP, length 24
15:41:31.939961 IP 209.85.251.9 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.940043 IP 10.4.27.179.44838 > 8.8.8.8.33455: UDP, length 24
15:41:31.947460 IP 108.170.237.21 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.947508 IP 10.4.27.179.44838 > 8.8.8.8.33456: UDP, length 24
15:41:31.954824 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33456 unreachable, length 36
15:41:31.954888 IP 10.4.27.179.44838 > 8.8.8.8.33457: UDP, length 24
15:41:31.963601 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33457 unreachable, length 36
15:41:31.963671 IP 10.4.27.179.44838 > 8.8.8.8.33458: UDP, length 24
15:41:31.972407 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33458 unreachable, length 36

따라서 traceroute적어도 내가 설치 한 구현은 ICMP를 보내지 않습니다. 오히려 UDP 패킷을 보냅니다.

이 추적에서 보이지 않는 것은 ( 자세한 내용을 증가시키기 위해 tcpdumpa -v를 주면 ) 첫 번째 프로브의 ttl이 1이고 이후 프로브의 ttl이 증가한다는 것입니다. 이로 인해 나와 8.8.8.8 사이의 라우터가 ICMP ttl 초과 오류로 응답하므로 traceroute가 여기저기서 라우터를 발견하는 방식입니다.

결국 ttl은 8.8.8.8까지 도달하기에 충분히 길며 8.8.8.8은 UDP 포트 44838에서 수신 대기하는 프로세스가 없기 때문에 ICMP 포트에 도달 할 수없는 오류로 응답합니다. .

여기와 그 사이에 모든 ICMP 가 차단되어 있으면 ping이나 traceroute가 작동하지 않습니다.

그러나 일반적으로 모든 ICMP가 차단 되는 경우 는 아니지만 드물지는 않습니다. 모든 ICMP를 차단하는 것은 문제가됩니다. 예를 들어 경로 MTU 발견을 중단 합니다. 이는 ICMP 조각화 요구 오류에 의존합니다. ICMP 패킷에는 유형과 코드가 있으며 책임있는 네트워크 운영자는 일부 유형이나 코드 (선택적 정보를 남용하거나 공개 할 가능성이있는 코드) 만 선택적으로 차단합니다.

예를 들어 일부 호스트는 ICMP 에코 요청에 전혀 응답하지 않으므로 핑이 작동하지 않습니다. 아이디어는 핑에 응답하지 않음으로써 공격자가 네트워크에 존재하는 호스트를 발견하기가 더 어렵다는 것입니다. 실제로 호스트를 검사하는 다른 방법이 있기 때문에 이것은 의문의 여지가 있습니다. 예를 들어, 웹 서버를 찾기 위해 TCP SYN을 포트 80으로 보낼 수 있습니다.

많은 호스트는 UDP 데이터 그램이나 TCP SYN을 프로세스 수신 대기가없는 포트로 가져올 때 ICMP 포트에 도달 할 수없는 오류를 보내지 않으므로 추적 경로가 손상됩니다. 다시 한 번 아이디어는 공격자가 네트워크를 매핑하는 것을 더욱 어렵게 만드는 것이지만 다시 한 번 공격자에게는 약간의 좌절입니다.

traceroute는 특정 프로토콜이 아닌 프로그램이므로 다른 방법으로도 조사 할 수 있습니다. 이들은 모두 라우터를 발견하기 위해 TTL을 늘리는 데 의존하지만 엔드 포인트에서 응답을 이끌어 낼 수있는 기회가 다소있을 수있는 다양한 종류의 프로브를 전송할 수 있습니다. 예를 들어, ping과 같은 ICMP 에코 프로브를 사용 man tcpdump하는 -I옵션이 나와 있습니다. 또한 -TUDP 대신 TCP SYN 프로브를 사용해야합니다. 당신이 호스트가 응답 할 것입니다 알고있는 경우에 ping그 다음 -I많은 이해된다. 호스트가 특정 TCP 포트에서 수신 대기하고 있다는 것을 알고 있다면 -T아마도 -p포트 선택 옵션 과 함께 사용하는 것이 좋습니다.

불행히도 이러한 옵션에는 루트 또는 특수 기능이 필요할 수 있으므로 UDP는 적절한 기본값을 사용합니다. 실제로 비슷한 도구 인 tracepath이 매뉴얼 페이지에서 다음과 같이 말합니다.

기술

이 경로를 따라 MTU를 발견하는 대상까지의 경로를 추적합니다. UDP 포트 포트 또는 임의의 포트를 사용합니다. traceroute와 유사하며 수퍼 유저 권한 만 필요하지 않으며 멋진 옵션이 없습니다.

TLDR; 원격 호스트에서 ping을 차단할 수 있지만 (ICMP 블록) traceroute는 표준 네트워크 라우팅 UDP 또는 TCP / IP (실제로 프로토콜; ref /networkengineering//a/36509/를 사용하여 경로를 찾을 수 있습니다. 58968 ). ICMP 핑 트래픽을 차단하는 매우 스마트 한 방화벽이없는 경우 호스트는 응답하지 않습니다.

Linux 에서 traceroute 에 ICMP 대신 UDP 를 사용 하는 방화벽에서 해당 UDP 포트를 차단하지 않았습니다.

nmap (insecure.org)을 설치하고 UDP 또는 TCP 및 모든 포트와 함께 nping을 사용할 수 있습니다. 핑이 아웃 바운드를 차단 한 네트워크에서 잘 작동합니다.

웹 서버를 ping하려면 nping --tcp -p 80,443

시간 서버를 ping하려면 nping --udp -p 123

https://nmap.org/book/nping-man.html

귀하의 질문에 대한 간단한 대답은 ping유틸리티가 ICMP 프로토콜에 의존한다는 것입니다. ICMP 프로토콜은 때때로 네트워크 방화벽 또는 장치 자체의 방화벽에서 차단됩니다. 네트워크 관리자가 ICMP를 차단하는 가장 일반적인 이유는 보안 문제로 간주되는 네트워크의 "스캔"을 방지하기위한 것입니다. tracerouteLinux 의 유틸리티는 완전히 다른 프로토콜 인 UDP를 사용하며이 경우 네트워크 관리자가이를 차단하지 않습니다. UDP는 다양한 용도로 사용되며이를 차단하면 네트워크에서 많은 것을 사용할 수 없게됩니다. 필요한 ICMP '제어 메시지'의 유형은 ping프로토콜의 하위 집합으로, ICMP 패킷 유형을 차단하면 네트워크에서 문제가 덜 발생하므로 UDP보다 차단 될 가능성이 높습니다.