Dlaczego niektóre popularne implementacje traceroute domyślnie używają sond UDP?


18

Niedawno rozwiązywałem problem meta-problemu z łącznością sieciową, ponieważ wiedziałem, że dany cel jest osiągalny, ale nie byłem w stanie tego zademonstrować, tracerouteponieważ ścieżka spadła po określonej liczbie przeskoków. Biorąc pod uwagę, że ostatni zaobserwowany przeskok był tuż powyżej interesującego węzła, wąchałem ruch, spodziewając się potwierdzić, że sondy do niego docierają i dowiedzieć się, która reguła filtrowania blokuje je. Rzeczywiście, dowiedziałem się, że sondami były datagramy UDP przeznaczone dla wysokiego (i zmiennego) portu, który oczywiście zablokowałem dla ruchu przychodzącego.

Zaskakuje mnie to, ponieważ założyłem, że wszystkie traceroutesondy będą domyślnie ustawione na ICMP, ponieważ odpowiedzi są ICMP. Przeprowadziłem ankietę dokumentacyjną i okazało się, że różne implementacje dokonują różnych wyborów, a niektóre nie pozwalają użytkownikowi na wybór domyślny.

Streszczenie metody sondy Traceroute i wnioskowanie o ścieżce IP do przodu wspiera moją intuicję, że sondom ICMP częściej uda się dotrzeć do miejsca docelowego.

Zezwolenie na różne metody sondy wydaje się świetnym pomysłem, ale domyślnie coś innego niż ICMP wydaje się złym pomysłem. Czy ktoś mógłby opisać uzasadnienie, dlaczego lepiej używać domyślnie UDP?

Odpowiedzi:


20

Pierwsza wersja traceroutezostała napisana przez Van Jacobsona i używała ICMP, ale nie działała zbyt dobrze. Interpretacja dostawcy ICMP w RFC792 była taka, że ​​routery nie powinny wysyłać komunikatu o błędzie ICMP w odpowiedzi na pakiet ICMP (patrz uwagi do edycji poniżej). Dlatego większość routerów nie wysłałaby komunikatu „przekroczony czas” w odpowiedzi na żądanie echa z TTL równym 1 lub 0. Więc zmienił go, aby używał UDP i lo, a oto działał świetnie i było dużo radości (i adopcji). tracerouteNarzędzie w systemie Linux i FreeBSD (i zakładam Cisco) opiera się na pracy Van Jacobsona.

Specyfikacja została później zmieniona na „w odpowiedzi na pakiet błędów ICMP ”. Świat się rozwijał, dostawcy wprowadzali zmiany w swoich stosach, pozwalając na komunikaty o błędach ICMP w odpowiedzi na żądania echa, a wraz ze wzrostem zapór ogniowych i list ACL czasami zbłąkane pakiety UDP czasami są blokowane, ale żądanie echa ICMP może się przedostać. Oczywiście Twój sukces w tej dziedzinie jest bardzo zróżnicowany. Spodziewałbym się, że tracerti inne narzędzia zostały napisane w czasie, gdy użycie odpowiedzi echa ICMP nie było tak problematyczne.

W dzisiejszych czasach nie można tak naprawdę powiedzieć, że UDP jest lepszy niż ICMP. Lub że którykolwiek z nich jest lepszy niż TCP. Zależy to całkowicie od ścieżki, którą przemierzasz i obowiązujących zasad bezpieczeństwa. Może być konieczne wypróbowanie jednej, obu lub wszystkich trzech implementacji.

Źródła:

http://ftp.arl.army.mil/~mike/ping.html http://www.inetdaemon.com/tutorials/trou Rozwiązywanie problemów/tools/traceroute/ definition.shtml

Edytuj :

Zmieniono RFC z IP (RFC791) na ICMP (RFC792), który mówi we wprowadzeniu:

Aby uniknąć nieskończonego regresu wiadomości o wiadomościach itp., Wiadomości ICMP nie są wysyłane o wiadomościach ICMP.

Jest to bit, który spowodował, że dostawcy nie wysyłali błędów „Przekroczono czas” dla żądań echa.

RFC1122, Wymagania dotyczące hostów internetowych, w sekcji 3.2.2. to aktualizacja informująca, że ​​hosty nie powinny odpowiadać na komunikaty o błędach ICMP .


Do Twojej wiadomości masz wystarczającą reputację, aby zostawić komentarz do pytania, o którym mi przesyłałeś e-maila
Mike Pennington,

Dobra robota. Szczególnie podobała mi się historia w pierwszym linku o komputerze krzyczącym „Ping! Ping! Ping!” na szczycie płuc.
neirbowj

Mike, tak, zaczynam
rozumieć,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.