Traceroute vs Tracert | Хто круче?

Traceroute vs Tracert | Хто круче?

Traceroute vs Tracert | Хто круче?

Per hop behavior

У чому відмінність маршруту пакета від його пройденого шляху?

Стандартний механізм маршрутизації пакетів в інтернеті – per hop behavior – тобто кожен вузол в мережі приймає рішення куди йому відправити пакет на основі інформації, отриманої від протоколів динамічної маршрутизації і статично зазначених адміністраторами маршрутів.

Маршрут – це інтерфейс, в який нам треба послати пакет для досягнення якогось вузла призначення і адреса наступного маршрутизатора (next-hop):

R1#sh ip rou | i 40.  
	 40.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O        40.0.0.0/31 [110/3] via 20.0.0.0, 00:01:54, FastEthernet0/0
O        40.1.1.1/32 [110/4] via 20.0.0.0, 00:00:05, FastEthernet0/0

Що таке шлях (який проходить пакет)?

Шлях – це список вузлів, через які пройшов (пройде) пакет:

 1  10.0.0.1  16.616 ms  16.270 ms  15.929 ms
 2  20.0.0.0  15.678 ms  15.157 ms  15.071 ms
 3  30.0.0.1  26.423 ms  26.081 ms  26.744 ms
 4  40.0.0.0  48.979 ms  48.674 ms  48.384 ms
 5  100.0.0.2  58.707 ms  58.773 ms  58.536 ms

Шлях пакета можна подивитися за допомогою tracert в Windows і traceroute в GNU / Linux і Unix-подібних системах.
Вважаться що в цих утилітах один і той же принцип роботи, але це не так.

Tracert:

В основі роботи даної утиліти лежить протокол icmp. Розглянемо ось таку схему:

Host відправляє по вказаному в його маршрутизаторі маршруту ICMP Echo-Request з ttl 1. Маршрутизатор 1, отримавши такий пакет, перевірить адреса призначення – може бути пакет йому. Через те, що ця пакет адресована до іншого host, Router1 вважає себе транзитним вузлом, зменшує пакети ttl і відкидає його, тому, що час життя пакета стає рівним 0. Оскільки пакет впав, Router1 відправляє джерело пакета icmp повідомлення з указанням причини падіння – Time Exceeded. Утиліта tracert, отримавши дану ICMP повідомлення, вказує Router1 як перший хоп (інформація про адресу вказана в ICMP повідомленні). Далі процес повторяється з інкрементами ttl, поки ICT-повідомлення не буде рівною кількості копій між вузлом – відправником і вузлом одержувача. В даному прикладі Server1 є вузлом призначення. Отримавши пакет, він перевірить адреса призначення, побачивши, що запит адресований йому і відправить ICMP Echo-Reply, який і буде представляти для трасування утиліт тригером до закінчення трасування.

Висновок:
Icmp – Протокол третього рівня, і про порти він не знає нічого. Тому зробити tracert із зазначенням порту неможливо. Сподіваюся тут ми розібралися.

Traceroute – дана утиліта працює за іншим принципом, хоч і висновок команди схожий на висновок попередньої.

Traceroute заснована не на ICMP Echo-Request, а на відправці udp фрагментів і отримання повідомлення про доступність / недосяжності порту. Повернемося до минулого схемою. Host генерує udp фрагмент, інкапсулює його в IP пакет і виставляє ttl = 1. Router1, бувши транзитним вузлом, відповість на даний пакет icmp повідомленням про закінчення часу життя пакета. Утиліта traceroute, отримавши це повідомлення, вказує адресу джерела icmp пакета (Router1) як адреса першого хопу. Далі процес повторюється з інкрементірованіе ttl пакета. Все практично так само, як і в tracert. Але ж ми не відправляємо ICMP Echo-Request, як утиліта traceroute зрозуміє, що трасування закінчена? Все просто – в udp заголовку є поля source і destination порт. Логічно, що source порт буде будь-яким портом вище 1023. А яким вказати destination порт? Як було сказано вище, робота утиліти traceroute заснована на отриманні повідомлення про недосяжність або доступності порту призначення. Тобто ми відправляємо udp фрагмент з порту 45000 (наприклад) на порт 33434 (саме цей порт використовується за умовчанням). Як і в попередньому випадку, Server1 є вузлом призначення. Отримавши пакет, він розпаковує його і повинен передати його протоколам вищого рівня. Але через те, що порт 33434 по замовчуванню буде закритий на сервері, то Server1 формує icmp повідомлення про недосяжність порту призначення (ICMP Type 3 «Destination Unreachable» Code 3 «Port Unreachable»). Отримавши це повідомлення, утиліта traceroute вважає трасування закінченою. В процесі трасування номер порту призначення буде інкрементіровать при кожній спробі (33434, 33435 і тощо). Може вийде так, що порт призначення буде відкритий. В даному випадку сервер відправить на host і ініціатор наприклад TCP ACK якщо для трасування використовуються TCP SYN пакети, що теж буде тригером до закінчення трасування.

Висновок:
Утиліта traceroute дозволяє зробити трасування із зазначенням порту призначення.
Для цього розглянемо приклад нижче:

Візьмемо попередню схему і зробимо трасування:

З використанням TCP SYN пакетів:

bormoglots@ubuntu-server-s1:~$ sudo traceroute -T -p 22 -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
 1  10.0.0.1  16.616 ms  16.270 ms  15.929 ms
 2  20.0.0.0  15.678 ms  15.157 ms  15.071 ms
 3  30.0.0.1  26.423 ms  26.081 ms  26.744 ms
 4  40.0.0.0  48.979 ms  48.674 ms  48.384 ms
 5  100.0.0.2  58.707 ms  58.773 ms  58.536 ms

C використанням UDP пакетів:

bormoglots@ubuntu-server-s1:~$ sudo traceroute -U -p 22 -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
 1  10.0.0.1  7.102 ms  6.917 ms  6.680 ms
 2  20.0.0.0  17.021 ms  16.838 ms  17.051 ms
 3  30.0.0.1  31.035 ms  30.859 ms  30.658 ms
 4  40.0.0.0  41.124 ms  40.941 ms  40.728 ms
 5  100.0.0.2  51.291 ms  51.045 ms  50.720 ms

Як бачите трасування пройшла успішно. Ми бачимо шлях до зазначеного hostname.

А тепер повісимо на інтерфейс Router4 фільтр на in (як зазначено на малюнку):

R4#sh run int fa0/0
Building configuration...

Current configuration : 121 bytes
!
interface FastEthernet0/0
 ip address 40.0.0.0 255.255.255.254
 ip access-group deny-to-server in
 duplex half
 !
end

R4#sh access-lists deny-to-server
Extended IP access list deny-to-server
    10 deny tcp any host 100.0.0.2 log (32 matches)
    20 deny udp any host 100.0.0.2 log (29 matches)
    30 permit ip any any (128 matches)

Знову зробимо трасування:

bormoglots@ubuntu-server-s1:~$ sudo traceroute -T -p 22 -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
 1  10.0.0.1  4.575 ms  4.490 ms  4.367 ms
 2  20.0.0.0  18.431 ms  18.359 ms  29.573 ms
 3  30.0.0.1  30.579 ms  30.690 ms  30.722 ms
 4  40.0.0.0  52.518 ms !X  62.977 ms !X  62.898 ms !X

bormoglots@ubuntu-server-s1:~$ sudo traceroute -U -p 22 -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
 1  10.0.0.1  5.614 ms  5.523 ms  5.689 ms
 2  20.0.0.0  18.364 ms  18.629 ms  18.556 ms
 3  30.0.0.1  42.289 ms  42.225 ms  42.143 ms
 4  40.0.0.0  41.984 ms !X  41.898 ms !X  41.815 ms !X

Тепер трасування закінчилася на передостанньому хопі й у висновку з’явилися знаки! Х. Чому це сталося? Router4 отримавши пакет до Server1 Втратив його, через те, що він потрапляє під правило заборони на вхідному інтерфейсі і відправляє host – ініціатору повідомлення про те, що пакет був за фільтрованих (ICMP Type 3 «Destination Unreachable» Code 13 – «Communication Administratively Prohibited»). Це теж повідомлення про недосяжність порту призначення. Тому утиліта traceroute отримавши таке повідомлення, закінчує свою роботу так не діставшись до hosta призначення. В даному випадку у висновку важливо зрозуміти, що пакети були саме за фільтровані, про що нам підказує знак! X (в Unix) або знак! A (в Cisco):

R1#traceroute 100.0.0.2
Type escape sequence to abort.
Tracing the route to 100.0.0.2
  1 20.0.0.0 24 msec 24 msec 16 msec
  2 30.0.0.1 16 msec 36 msec 40 msec
  3 40.0.0.0 !A  !A  !A

Примітка: Можливий випадок, коли пакети будут Втрачені без відправкі ICMP Повідомлень (відправки в Null-інтерфейс в Cisco / Huawei або discard в Juniper). У даного випадка трасування буде йти поки НЕ скінчіться максимально TTL, Вказаним в утіліті traceroute (за замовчуванню максимум 30 хопов, но можна Задати вручну до 255, правда зазвічай Досить 15-18 хопов) або ее НЕ Перерва адміністратор, а у висновка будут зірочки.

Примітка: з’явилися зірочок вместо адреса хостів может буті зумовлене різнімі причинами.

Власне Кажучи, утіліта traceroute может працювати як и утіліта tracert з Використання ICMP Echo-Request. Для цього ее слід запустіті з ключем -I. В прикладом вищє фільтр НЕ блокує ICMP, тому трасування з Використання даного протоколу покаже нам весь шлях пакета:

bormoglots@ubuntu-server-s1:~$ sudo traceroute -I -w 1 -n 100.0.0.2
traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets
 1  10.0.0.1  4.073 ms  3.986 ms  3.890 ms
 2  20.0.0.0  19.474 ms  19.389 ms  19.294 ms
 3  30.0.0.1  30.147 ms  30.276 ms  30.826 ms
 4  40.0.0.0  42.316 ms  42.240 ms  42.145 ms
 5  100.0.0.2  52.705 ms  52.622 ms  52.521 ms

Сподіваюся ми розібралися в основних принципах роботи даних утиліт. Якщо треба зробити трасування по якому те порту в Windows системах, можна використовувати сторонні утиліти, наприклад tcptrace.

Від |2019-01-20T18:23:23+02:007 Вересня, 2018|Unix \ Linux, Windows OS, Усі|

Залишити коментар