Tracert vs Traceroute

У чому відмінність маршруту пакету від його шляху?
Стандартний механізм маршрутизації пакетів в інтернеті — 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 ms 15.929
2 20.0.0.0 15.678 ms 15.157 ms ms 15.071
3 30.0.0.1 26.423 ms 26.081 ms ms 26.744
4 40.0.0.0 48.979 ms 48.674 ms ms 48.384
5 100.0.0.2 58.707 ms 58.773 ms ms 58.536

Шлях пакета можна подивитися за допомогою утиліт tracert в OC Windows і traceroute в GNU/Linux і Unix-подібних системах. (інші команди, типу tracepath ми не розглядаємо).
Багато хто вважає, що цих утиліт один і той же принцип роботи, але це не так. Давайте розберемося.

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

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

Висновок:
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 і т д). Може вийде так, що порт призначення буде відкрито. В даному випадку сервер відправить на хост-ініціатор наприклад 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 ms 15.929
2 20.0.0.0 15.678 ms 15.157 ms ms 15.071
3 30.0.0.1 26.423 ms 26.081 ms ms 26.744
4 40.0.0.0 48.979 ms 48.674 ms ms 48.384
5 100.0.0.2 58.707 ms 58.773 ms ms 58.536

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 ms 6.680
2 20.0.0.0 17.021 ms 16.838 ms ms 17.051
3 30.0.0.1 31.035 ms 30.859 ms ms 30.658
4 40.0.0.0 41.124 ms 40.941 ms ms 40.728
5 100.0.0.2 51.291 ms 51.045 ms ms 50.720

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

А тепер повісимо на інтерфейс 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
half duplex
!
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 ms 4.367
2 20.0.0.0 18.431 ms 18.359 ms ms 29.573
3 30.0.0.1 30.579 ms 30.690 ms ms 30.722
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 ms 5.689
2 20.0.0.0 18.364 ms 18.629 ms ms 18.556
3 30.0.0.1 42.289 ms 42.225 ms ms 42.143
4 40.0.0.0 41.984 ms !X 41.898 ms !X 41.815 ms !X

Тепер трасування закінчилася на передостанньому хопі і у виведенні з'явилися знаки! Х. Чому це сталося? Router4 отримавши пакет до Server1 дропает його, так як він потрапляє під забороняє правило на вхідному інтерфейсі і відправляє вузлу-ініціатору повідомлення про те, що пакет був зафильтрован (ICMP Type 3 «Destination Unreachable» Code 13 — Communication Administratively Prohibited»). Це теж повідомлення про недосяжності порту призначення. Тому утиліта traceroute отримавши таке повідомлення, закінчує свою роботу так не діставшись до вузла призначення. В даному випадку у висновку важливо зрозуміти, що пакети були саме зафильрованы, про що нам підказує знак !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 ms 3.890
2 20.0.0.0 19.474 ms 19.389 ms ms 19.294
3 30.0.0.1 30.147 ms 30.276 ms ms 30.826
4 40.0.0.0 42.316 ms 42.240 ms ms 42.145
5 100.0.0.2 52.705 ms 52.622 ms ms 52.521

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

Спасибі за увагу!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.