Чому я можу простежити цю IP-адресу, але не пінг?

21

Я маю IP-адресу і можу простежити її, але не можу пінг.

Розумієте, я можу простежити 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також не слід працювати. У чому причина?

Я перевірив, що брандмауер сервера зупинений

ping  networking  icmp  traceroute 
— 244бой
джерело
чи може бути, що тайм-аут для ping є занадто обмежуючим, і він був би успішним, враховуючи більш м'які часові обмеження? Traceroute дав понад 500 мс для деяких вузлів.
— vsz
Чи допомогла вам якась відповідь? Якщо так, то слід прийняти відповідь, щоб питання не з’являлося вічно, шукаючи відповідь. Крім того, ви можете надати та прийняти власну відповідь.
— Рон Моупін

Відповіді:

39

На подібному питанні тут Люк Савідж пояснив це ідеально:

Traceroute - це не сам протокол, це програма, і використовувані протоколи залежать від реалізації, яку ви використовуєте. В першу чергу це ICMP.

Є дві основні реалізації:

tracert - tracert - це програма для Windows, яка використовує пакети ICMP з наростаючим полем TTL для картографування переходів до кінцевої адреси призначення.

traceroute - traceroute - це програма * nix, доступна для більшості систем на базі Linux, включаючи мережеві пристрої та пристрої Cisco. Для використання пакетів UDP із збільшенням TTL-поля для картографування переходів до кінцевого пункту призначення.

Різницю між ними корисно знати, оскільки деяка мережа тепер блокує ICMP за замовчуванням, тому і PING, і трекер з машини Windows не вдасться, але трасування з пристрою Linux все ще може працювати.

— наївнаRSA
джерело
2
Отже, чому мій IP-сервер може простежити, але не пінг?
— 244бой
10
З вашого спільного виводу я бачу, що ви використовуєте tracerouteкоманду, а не tracertщо змусило мене думати, що ви використовуєте операційну систему на базі Unix або gnu. У відповідь я вже говорив ви можете побачити , що системи на основі UNIX не використовується ICMPдля traceroute. Іншими словами, оскільки PINGвикористання ICMP(яке, на мою думку, заблоковане системою, до якої ви намагаєтесь дістатися), і traceroute використовує UDPпакети з методом інкрементації TTLполя (який, на мою думку, не заблокований у системі, до якої ви намагаєтесь дістатися) PINGне вдається. але Tracerouteвдається.
— naïveRSA
4
Замість того, щоб додавати новий коментар до своєї публікації, коли хтось, як 244boy, пропонує покращення, було б краще відредагувати свою публікацію, щоб майбутнім людям, які читають відповідь, не потрібно було прочитати всі коментарі, щоб отримати повну відповідь.
— Keeta - відновити Моніку
@ NaïveRSA Строго кажучи, tracerouteце з допомогою ICMP, навіть якщо він посилає UDP, а саме він очікує і оцінює TTL exceededповідомлення від перельотів на шляху. Хост, який блокує всі ICMP, є поганою ідеєю, але він pingбуде невдалий, коли ICMP echoзапити чи відповіді будуть заблоковані у цільового хоста
— Хаген фон Ейтцен
17

Щоб додати відповідь @ naïveRSA , якщо в шляху є фільтрування / брандмауер, також може виникнути ситуація, коли пакет ICMP "echo reply" (ping) блокується, але пакет ICMP "перевищував час" (tracert) . Це дало б однакові результати, навіть якщо використовується тільки ICMP (Windows).

В обох випадках (відправник, що використовує або UDP, або ICMP) повідомлення про помилку буде ICMP (тобто вузол, що відповідає на пакет ping або tracer *).

— Арджан
джерело
6

Подивимося, що станеться, чи не так?

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

Таким чином, pingнадсилає запит ехо-сигналу ICMP і очікує відповіді відлуння 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.

Що не видно в цьому сліді (хоча це було б, якби я дав збільшити подробиця) є те , що перші зонди мають ТТЛ 1, а потім збільшує Время_жізні для наступних зондів. Це призводить до того, що маршрутизатори між мною та 8.8.8.8 реагують на помилку ICMP ttl, перевищену помилкою, і саме так traceroute виявляє маршрутизатори тут і там.tcpdump-v

Врешті-решт, ttl досить довгий, щоб зробити його до 8.8.8.8, і 8.8.8.8 відповідає на порт ICMP недоступною помилкою, оскільки він не має процесу прослуховування на порту UDP 44838. Ось як traceroute знає, що він досяг кінцевого пункту призначення .

Якщо щось тут і там блокує всі ICMP, то ні ping, ні traceroute не працюватимуть.

Але зазвичай це не так, що всі ICMP заблоковані, хоча це також не рідко. Блокування всіх ICMP є проблематичним: наприклад, він порушує шлях виявлення MTU , який спирається на необхідну помилку фрагментації ICMP. Пакети ICMP мають тип і код, і відповідальні оператори мережі блокують лише вибірково деякі типи чи коди, ті, що створюють потенцію для зловживань або розкриття певної інформації.

Наприклад, деякі хости взагалі не відповідатимуть на запит ехо в ICMP, і тому ping не працюватиме. Ідея полягає в тому, що, не реагуючи на пінг, зловмиснику важче виявити, які хости існують у мережі. На практиці це сумнівно, оскільки існують інші способи перевірити хоста. Наприклад, можна надіслати TCP SYN на порт 80 для пошуку веб-серверів.

Багато хостів також не надсилають ICMP-порту недоступною помилкою, коли отримують дейтаграму UDP або TCP SYN до порту, на якому вони не мають прослуховування процесу, і це порушує трасування. Знову ідея полягає в тому, щоб зловмиснику ускладнити карту мережі, але знову це лише незначне розчарування для зловмисника.

Оскільки traceroute - це програма, а не конкретний протокол, вона має інші способи зондування. Всі вони покладаються на збільшення TTL для виявлення маршрутизаторів, але можуть надсилатися різні види зондів, які можуть мати більш-менш шанси отримати відповідь від кінцевої точки. Наприклад, у моєму man tcpdumpсписку є -Iможливість використовувати ехолоки ICMP, такі ж, як і ping. Він також -Tповинен використовувати зонди TCP SYN замість UDP. Якщо ви знаєте, що хост буде реагувати на pingте -Iробить багато сенсу. Якщо ви знаєте, що хост прослуховує певний порт TCP, то -Tмає сенс, можливо, спільно з -pможливістю вибору порту.

На жаль, ці параметри можуть вимагати кореневих чи спеціальних можливостей, тому UDP робить справедливим за замовчуванням. Насправді аналогічний інструмент, tracepathмає це сказати на своїй довідковій сторінці:

ОПИС

Він простежує шлях до місця призначення, відкриваючи MTU по цьому шляху. Він використовує порт порту UDP або якийсь випадковий порт. Він схожий на traceroute, лише не вимагає привілеїв суперпользователя і не має фантазійних варіантів.

— Філ Мороз
джерело
2

TLDR; pings може бути заблокований (блок ICMP) на віддаленому хості, але traceroute все ще може знайти маршрут до нього за допомогою стандартної мережевої маршрутизації UDP або TCP / IP (дійсно будь-який протокол; ref /networkengineering//a/36509/ 58968 ). Зауважте, що ваш ping, ймовірно, також може дістатися до хоста (якщо, можливо, у вас дуже розумний брандмауер блокує ICMP ping-трафік десь), хост просто не відповідає.

— Роель Ван де Паар
джерело
0

Ви можете встановити nmap (insecure.org) і використовувати nping за допомогою UDP або TCP та будь-якого порту. Відмінно працює в мережах із блокуванням вихідного каналу.

Для пінг-сервера на nping --tcp -p 80,443

Для пінг-сервера часу nping --udp -p 123

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

— Майкл Хаббард
джерело
0

Коротка відповідь на ваше запитання полягає в тому, що pingутиліта покладається на протокол ICMP, який іноді блокується мережевим брандмауером або брандмауером самого пристрою. Найпоширеніша причина, по якій мережевий адміністратор блоку ICMP - це запобігання "скануванню" мережі, яку вони вважають проблемою безпеки. tracerouteУтиліта на Linux використовує UDP, зовсім інший протокол, який в даному випадку не блокованих мережевих адміністраторів. UDP має різноманітне використання, і блокування цього може призвести до непридатності багатьох речей у мережі. Тип ICMP 'повідомлення управління', який потрібен, ping- це підмножина протоколу, що означає блокування цього типу пакету ICMP спричиняє менше проблем у мережі і, отже, швидше блокується, ніж UDP.

— Кібернавт
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.