164 подписчика

Магия traceroute

15 февраля 202415 фев 2024

5 мин

Когда вы начинаете изучать, как работает сеть в GNU/Linux, часто сталкиваетесь с такой утилитой как traceroute.

Результат применения обычно выглядит примерно вот так:

me@sk:~$ traceroute yandex.ru
traceroute to yandex.ru (5.255.255.70), 30 hops max, 60 byte packets
1 192.168.2.1 (192.168.2.1) 0.556 ms 0.507 ms 0.490 ms
2 * * *
3 * * *
4 188-234-120-206.ertelecom.ru (188.234.120.206) 53.677 ms 53.943 ms 53.649 ms
5 188-234-120-207.ertelecom.ru (188.234.120.207) 53.915 ms 54.194 ms 53.881 ms
6 vla-32z1-ae4.yndx.net (93.158.160.113) 63.746 ms * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

Откуда столько звездочек? Часто слышу ответ, что на роутерах ICMP заблокирован.

На 26 узлах? Там не будет такого количества узлов даже!

Дело в том, что трассировка в Linux утилитой traceroute выполняется с помощью попытки отправки сообщения на неиспользуемый UDP порт. Это потому, что хотя ICMP тоже может использоваться в качестве запросов, в Linux для этого требуются права суперпользователя.

В качестве ответов и в том и в другом случае приходят ICMP-сообщения, разница только в ответе только на последнем шаге (для ICMP — echo reply, для UDP — «UDP port unreachable»)

При каждом шаге поле TTL в IP пакете (несущем в себе UDP-дейтаграмму или ICMP-пакет) увеличивается на единицу (первый раз он 1).

Соответственно первый раз от первого узла нам приходит ICMP сообщение, что TTL истек, и так еще два раз. На втором шаге отправляется сообщение с TTL=2, и нам отвечает уже второй роутер (если только мы не до него маршрут трассируем). И так далее.

Когда же узел достигает места назначения, то хост видит, что сообщение направлено на порт, который никто не слушает. В ответ идет ответ ICMP что «UDP порт недостижим». Так исходный отправитель понимает, что цель достигнута.

По факту как это не звучало бы не интуитивно, сообщение «UDP порт не достижим» и означает что узла мы как раз достигли.

Вот картинка как это происходит:

Можно обратить внимание, что UDP порт инкриминируется (и этот диапазон портов не используется реальными приложениями, именно для того, чтобы и получить ICMP сообщение «UDP Port Unreachable» в случае достижения узла) происходит это потому, что ответы могут приходить не в том порядке в каком отправлялись, а в отличие от ICMP в UDP нет номера последовательности, поэтому для различения порядка используются разные порты UDP.

Вот я выполнил трассировку в Linux

me@sk:~$ traceroute 1.1.1.1

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets

1 router.lan (192.168.88.1) 4.133 ms 4.049 ms 4.026 ms

2 192.168.1.1 (192.168.1.1) 3.988 ms 3.974 ms 3.961 ms

3 broadband-90-154-70-201.ip.moscow.rt.ru (90.154.70.201) 6.415 ms 6.400 ms 6.386 ms

4 * * *

5 87.226.221.70 (87.226.221.70) 6.245 ms 6.732 ms 6.720 ms

6 188.254.25.75 (188.254.25.75) 10.886 ms 188.254.25.77 (188.254.25.77) 3.597 ms 188.12

8.126.247 (188.128.126.247) 3.893 ms

7 * * *

8 * * *

9 * * *

10 one.one.one.one (1.1.1.1) 4.888 ms * *

А вот захват трафика с помощью tcpdump

sudo tcpdump host 1.1.1.1

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes

11:50:56.307727 IP 192.168.88.245.57674 > one.one.one.one.33434: UDP, length 32

11:50:56.307778 IP 192.168.88.245.38658 > one.one.one.one.33435: UDP, length 32

11:50:56.307796 IP 192.168.88.245.47995 > one.one.one.one.33436: UDP, length 32

11:50:56.307811 IP 192.168.88.245.33649 > one.one.one.one.33437: UDP, length 32

11:50:56.307824 IP 192.168.88.245.35544 > one.one.one.one.33438: UDP, length 32

11:50:56.307836 IP 192.168.88.245.46335 > one.one.one.one.33439: UDP, length 32

11:50:56.307849 IP 192.168.88.245.51707 > one.one.one.one.33440: UDP, length 32

11:50:56.327996 IP 192.168.88.245.55619 > one.one.one.one.33450: UDP, length 32

11:50:56.328076 IP 192.168.88.245.48704 > one.one.one.one.33451: UDP, length 32

11:50:56.328108 IP 192.168.88.245.52801 > one.one.one.one.33452: UDP, length 32

11:50:56.328134 IP 192.168.88.245.37007 > one.one.one.one.33453: UDP, length 32

11:50:56.328166 IP 192.168.88.245.33303 > one.one.one.one.33454: UDP, length 32

11:50:56.328195 IP 192.168.88.245.45515 > one.one.one.one.33455: UDP, length 32

11:50:56.339161 IP 192.168.88.245.56321 > one.one.one.one.33456: UDP, length 32

11:50:56.339203 IP 192.168.88.245.53836 > one.one.one.one.33457: UDP, length 32

11:50:56.339224 IP 192.168.88.245.36947 > one.one.one.one.33458: UDP, length 32

11:50:56.339245 IP 192.168.88.245.47122 > one.one.one.one.33459: UDP, length 32

11:50:56.339266 IP 192.168.88.245.46189 > one.one.one.one.33460: UDP, length 32

11:50:56.339286 IP 192.168.88.245.58584 > one.one.one.one.33461: UDP, length 32

11:50:56.339307 IP 192.168.88.245.59502 > one.one.one.one.33462: UDP, length 32

11:50:56.339348 IP 192.168.88.245.45477 > one.one.one.one.33463: UDP, length 32

11:50:56.339368 IP 192.168.88.245.60462 > one.one.one.one.33464: UDP, length 32

11:50:56.344170 IP one.one.one.one > 192.168.88.245: ICMP one.one.one.one udp port 33461 unreachable, length 68

Остается понять , почему используется UDP. Я встречал разные варианты ответов.

Кто-то думает, что потому что ICMP фильтруется на узлах. Но и UDP может фильтроваться.
Что путь ответного ICMP может пойти другим путем. Но ответ у UDP тоже ICMP, так что тоже такое возможно и точность ответа на самом деле нам не известна.

Правильное объяснение, в том, что для формирования ICMP с нестандартными полями IP (измененный TTL) требуется доступ к сырым сокетам, для чего нужны права суперпользователя, а с UDP обычный сокет и прав не нужно, и это действительно так. То есть в Linux для использования в трассировке ICMP требуются права суперпользователя

Пытаемся выполнить трассировку с помощью ICMP

me@sk:~$ traceroute 1.1.1.1 -I

You do not have enough privileges to use this traceroute method.

socket: Операция не позволена

С sudo работает

me@sk:~$ sudo traceroute 1.1.1.1 -I

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets

1 router.lan (192.168.88.1) 2.224 ms 2.192 ms 2.187 ms

2 192.168.1.1 (192.168.1.1) 2.158 ms 2.153 ms 2.149 ms

3 broadband-90-154-70-201.ip.moscow.rt.ru (90.154.70.201) 4.249 ms 5.810 ms 5.806 ms

4 * * *

5 87.226.221.70 (87.226.221.70) 5.767 ms 5.761 ms 5.754 ms