Чому деякі поширені реалізації traceroute за замовчуванням використовують зонди UDP?


18

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

Це мене дивує, тому що я припускав, що всі tracerouteзонди за замовчуванням для ICMP, оскільки відповіді - це ICMP. Я зробив опитування документації та виявив, що різні реалізації роблять різний вибір, а деякі не дозволяють користувачеві зробити вибір за замовчуванням.

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

Дозволити різні методи зондування здається чудовою ідеєю, але дефолт до чогось іншого, ніж ICMP, здається поганою ідеєю. Чи може хтось описати обґрунтування того, чому краще використовувати UDP за замовчуванням?

Відповіді:


20

Першу версію tracerouteнаписав Ван Якобсон, і вона використовувала ICMP, але вона не дуже добре працювала. Інтерпретація ICMP в RFC792 полягає в тому, що маршрутизатори не повинні надсилати повідомлення про помилку ICMP у відповідь на пакет ICMP (див. Примітки редагування нижче). Тому більшість маршрутизаторів не надсилають повідомлення "перевищений час" у відповідь на ехо-запит з TTL 1 або 0. Тож він змінив його на використання UDP і ось, і ось він спрацював чудово, і було дуже радісно (і прийняття). tracerouteІнструмент на Linux і FreeBSD (і я вважаю , Cisco) заснований на роботі Ван Якобсона.

Пізніше специфікацію було змінено на "у відповідь на пакет помилок ICMP ". Світ прогресував, постачальники вносили зміни до своїх стеків, дозволяючи повідомленням про помилки ICMP у відповідь на запити ехо, а із зростанням брандмауерів та ACL, бродячі пакети UDP іноді блокуються, але ICMP-запит ехо може пройти. Звичайно, ваш успіх у цьому сьогодні різко змінюється. Я б очікував, що tracertта інші інструменти були написані в той час, коли використання ехо-відповідей ICMP не було настільки проблематичним.

У наші дні ви не можете сказати, що UDP кращий, ніж ICMP. Або що будь-який з них кращий, ніж TCP. Це повністю залежить від шляху, який ви проходите, та політики безпеки. Можливо, вам доведеться спробувати одну, обидві або всі три реалізації.

Джерела:

http://ftp.arl.army.mil/~mike/ping.html http://www.inetdaemon.com/tutorials/troubleshooting/tools/traceroute/definition.shtml

Редагувати :

Змінено RFC з IP (RFC791) на ICMP (RFC792), що у вступі говорить:

Щоб уникнути нескінченного регресу повідомлень про повідомлення тощо, ICMP-повідомлення про ICMP-повідомлення не надсилаються.

Саме цей біт змусив продавців не надсилати помилки "Перевищено час" для ехо-запитів.

RFC1122, Вимоги до Інтернет-хостів, в розділі 3.2.2. це оновлення, яке говорить, що хости не повинні відповідати на повідомлення про помилки ICMP .


FYI тепер у вас достатньо репутації, щоб залишити коментарі до питання, про яке ви мені надіслали електронну пошту
Майк Пеннінгтон,

Молодці. Особливо мені сподобалася історія в першому посиланні про комп’ютерний крик "Пінг! Пінг! Пінг!" у верхній частині легенів.
neirbowj

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