เหตุใดฉันสามารถติดตามไปยังที่อยู่ IP นี้ แต่ไม่ใช่การ ping

ฉันมีที่อยู่ IP และสามารถติดตามไปได้ แต่ฉันไม่สามารถส่ง Ping ได้

คุณเห็นฉันสามารถ 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

แต่ฉันไม่สามารถ ping ได้:

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 เป็นแอปพลิเคชั่น Windows ที่ใช้แพ็คเก็ต ICMP พร้อมกับเพิ่มฟิลด์ TTL เพื่อจับคู่ฮ็อพกับที่อยู่ปลายทางสุดท้าย

traceroute - traceroute เป็นแอปพลิเคชั่น * nix ที่มีอยู่ในระบบที่ใช้ Linux ส่วนใหญ่รวมถึงอุปกรณ์เครือข่ายและบนอุปกรณ์ Cisco สิ่งนี้ใช้แพ็คเก็ต UDP พร้อมฟิลด์ TTL ที่เพิ่มขึ้นเพื่อจับคู่ฮ็อพกับปลายทางสุดท้าย

ความแตกต่างระหว่างสิ่งเหล่านี้มีประโยชน์ที่จะทราบเนื่องจากบางเครือข่ายปิดกั้น ICMP โดยค่าเริ่มต้นดังนั้น PING และ tracert จากเครื่อง Windows จะล้มเหลว แต่ traceroute จากอุปกรณ์ Linux อาจยังทำงานได้

หากต้องการเพิ่มคำตอบของ@ naïveRSAหากมีการกรอง / ไฟร์วอลล์ในเส้นทางที่หนึ่งอาจมีสถานการณ์ที่แพ็คเก็ต ICMP "echo reply" (ping) ถูกบล็อก แต่ ICMP "เกินเวลา" (tracert) อนุญาต . สิ่งนี้จะให้ผลลัพธ์ที่เหมือนกันแม้ว่าจะใช้เฉพาะ ICMP (Windows)

ในทั้งสองกรณี (ผู้ส่งที่ใช้ UDP หรือ ICMP) การสื่อสารข้อผิดพลาดจะเป็น ICMP (เช่นโหนดที่ตอบกลับไปยัง ping หรือ tracer * packet)

เรามาดูกันว่าจะเกิดอะไรขึ้น

8.8.8.8 ทำให้เป็นตัวอย่างที่ดีเพราะอย่างน้อยจากสถานที่ของฉันฉันสามารถเข้าถึงได้ทั้งที่มีและtracerouteping

ก่อนอื่นให้เราลอง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

ดังนั้นจึงpingส่งคำขอ ICMP echo และคาดว่าจะมีการตอบกลับ 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เพื่อเพิ่ม verbosity) คือโพรบแรกมี ttl เป็น 1 จากนั้นจะเพิ่ม ttl สำหรับโพรบในภายหลัง นี่ทำให้เราเตอร์ระหว่างฉันและ 8.8.8.8 ตอบสนองด้วย ICMP ttl เกินข้อผิดพลาดซึ่งเป็นวิธีที่ traceroute ค้นพบเราเตอร์ระหว่างที่นี่และที่นั่น

ในที่สุด ttl ก็นานพอที่จะทำให้มันมาถึง 8.8.8.8 และ 8.8.8.8 ตอบสนองกับข้อผิดพลาดที่ไม่สามารถเข้าถึงพอร์ต ICMP ได้เนื่องจากมันไม่มีกระบวนการฟังบนพอร์ต UDP 44838 นี่คือวิธีที่ traceroute รู้ว่าถึงปลายทางสุดท้าย .

หากมีบางสิ่งระหว่างที่นี่กับที่ปิดกั้นICMP ทั้งหมดแสดงว่าไม่มีการ ping หรือ traceroute ทำงาน

แต่โดยทั่วไปไม่ใช่กรณีที่ICMP ทั้งหมดถูกปิดกั้นแม้ว่าจะไม่ได้หายาก การบล็อก ICMP ทั้งหมดเป็นปัญหา: ตัวอย่างเช่นจะหยุดการค้นพบพา ธ MTUซึ่งขึ้นอยู่กับข้อผิดพลาดที่จำเป็นในการแยกส่วน ICMP แพ็คเก็ต ICMP มีประเภทและรหัสและผู้ให้บริการเครือข่ายที่รับผิดชอบจะเลือกบล็อกหรือรหัสบางประเภทเท่านั้นผู้ที่มีแนวโน้มว่าจะถูกละเมิดหรือเปิดเผยข้อมูลเฉพาะ

ตัวอย่างเช่นบางโฮสต์จะไม่ตอบสนองต่อคำขอ ICMP echo เลยและ ping จะไม่ทำงาน ความคิดคือโดยไม่ตอบสนองต่อการปิงเป็นการยากยิ่งขึ้นที่ผู้โจมตีจะค้นพบว่ามีโฮสต์ใดบ้างบนเครือข่าย ในทางปฏิบัตินี่เป็นคำถามที่น่าสงสัยเนื่องจากมีวิธีอื่น ๆ ในการสอบสวนหาโฮสต์ ตัวอย่างเช่นหนึ่งสามารถส่ง TCP SYN ไปยังพอร์ต 80 เพื่อค้นหาเว็บเซิร์ฟเวอร์

โฮสต์จำนวนมากจะไม่ส่งข้อผิดพลาดที่ไม่สามารถเข้าถึงพอร์ต ICMP เมื่อพวกเขาได้รับดาตาแกรม UDP หรือ TCP SYN ไปยังพอร์ตที่พวกเขาไม่ได้รับฟังกระบวนการและนี่จะเป็นการหยุดพักชั่วคราว แนวคิดก็คือทำให้ผู้โจมตีทำแผนที่เครือข่ายได้ยากขึ้น แต่นี่เป็นเพียงความหงุดหงิดเล็กน้อยสำหรับผู้โจมตี

เนื่องจาก traceroute เป็นโปรแกรมและไม่ใช่โปรโตคอลเฉพาะใด ๆ จึงมีวิธีการตรวจสอบอื่น ๆ พวกเขาทั้งหมดพึ่งพาการเพิ่ม TTL เพื่อค้นหาเราเตอร์ แต่โพรบชนิดต่าง ๆ สามารถส่งซึ่งอาจมีโอกาสมากหรือน้อยที่จะล้วงเอาการตอบสนองจากจุดสิ้นสุด ตัวอย่างเช่นฉันman tcpdumpแสดงรายการ-Iตัวเลือกในการใช้ ICMP echo probes เหมือนกับ ping นอกจากนี้ยัง-Tต้องใช้โพรบ TCP SYN แทน UDP หากคุณรู้ว่าโฮสต์จะตอบสนองpingจากนั้น-Iทำให้รู้สึกมาก หากคุณรู้ว่าโฮสต์กำลังฟังบนพอร์ต TCP โดยเฉพาะ-Tอาจใช้งานร่วมกับ-pตัวเลือกในการเลือกพอร์ต

น่าเสียดายที่ตัวเลือกเหล่านี้อาจต้องการรูทหรือความสามารถพิเศษดังนั้น UDP จึงเป็นค่าเริ่มต้นที่ยุติธรรม ในความเป็นจริงเครื่องมือที่คล้ายกันtracepathมีสิ่งนี้จะพูดในหน้าคน:

รายละเอียด

มันติดตามเส้นทางไปยังปลายทางที่ค้นหา MTU ตามเส้นทางนี้ ใช้พอร์ตพอร์ต UDP หรือพอร์ตสุ่ม มันคล้ายกับ traceroute เพียงไม่ต้องการสิทธิ์ superuser และไม่มีตัวเลือกแฟนซี

TLDR; pings สามารถถูกบล็อก (ICMP block) บนรีโมตโฮสต์ แต่ traceroute ยังสามารถค้นหาเส้นทางไปยังมันได้โดยใช้การกำหนดเส้นทางเครือข่ายมาตรฐาน UDP หรือ TCP / IP (โปรโตคอลใด ๆ จริงๆอ้างอิง/networkengineering//a/36509/ 58968 ) โปรดทราบว่าการ ping ของคุณสามารถเข้าถึงโฮสต์ได้ (เว้นแต่คุณอาจมีไฟร์วอลล์อัจฉริยะที่บล็อกการรับส่งข้อมูล ping ของ ICMP ที่ใดที่หนึ่ง) โฮสต์ก็ไม่ตอบกลับ

Linuxใช้UDPแทนICMPสำหรับการติดตามไฟร์วอลล์ไม่ได้บล็อกพอร์ต UDP นั้น

คุณสามารถติดตั้ง nmap (insecure.org) และใช้ nping กับ UDP หรือ TCP และพอร์ตใดก็ได้ ใช้งานได้ดีบนเครือข่ายที่มีการ ping บล็อกขาออก

ในการ ping เว็บเซิร์ฟเวอร์ nping --tcp -p 80,443

ในการ ping เซิร์ฟเวอร์เวลา nping --udp -p 123

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

คำตอบสั้น ๆ สำหรับคำถามของคุณคือpingยูทิลิตี้นั้นใช้โปรโตคอล ICMP ซึ่งบางครั้งถูกบล็อกที่ไฟร์วอลล์เครือข่ายหรือไฟร์วอลล์บนอุปกรณ์นั้น สาเหตุที่พบบ่อยที่สุดที่ผู้ดูแลระบบเครือข่ายบล็อก ICMP คือการป้องกัน "สแกน" ของเครือข่ายที่พวกเขาคิดว่าเป็นปัญหาด้านความปลอดภัย tracerouteยูทิลิตี้บน Linux ใช้ UDP โปรโตคอลที่แตกต่างกันอย่างสิ้นเชิงซึ่งในกรณีนี้ในไม่ถูกบล็อกโดยผู้ดูแลระบบเครือข่าย UDP มีการใช้งานที่หลากหลายและการบล็อกสิ่งนี้จะทำให้หลายสิ่งไม่สามารถใช้งานได้บนเครือข่าย ประเภทของ 'ข้อความควบคุม' ที่ต้องการโดย ICMP pingคือชุดย่อยของโปรโตคอลซึ่งหมายถึงการปิดกั้นแพ็คเก็ต ICMP ประเภทนั้นทำให้เกิดปัญหาน้อยลงในเครือข่ายและมีแนวโน้มที่จะถูกบล็อกมากกว่า UDP