#005 Time to Live или как IP защищается от петель маршрутизации
Господа, дамы, здравствуйте!
В прошлом видео мы разобрались со структурой IP-пакета в целом, но о некоторых полях стоит поговорить отдельно и посмотреть на них более пристально, одним из таких полей на мой взгляд является TTL, о котором далее.
Зачем нужно поле TTL?
Назначение поля TTL довольно простое: не допустить бесконечного хождения пакета по сети в том случае, если произошла петля маршрутизации. Особенность этого поля используется такими утилитами как tracert, mtr, winmtr. Рассматривать назначение этого поля будем на вот такой схеме:
Схема для изучения работы TTL
Но для начала коротко поясню как узлы работают с TTL. Представим, что пакет пришел на узел, он его получает и смотрит на значение поля TTL:
если значение равно единице, это значит, что пакет уже не будет передан следующему узлу: если пакет со значением 1 пришел на узел получатель, то он будет обработан и передан вышестоящему процессу, если же узел не конечный, то такой пакет будет уничтожен;
если значение поля TTL больше единицы, то пакет можно передать следующему узлу, если это требуется, либо если узел конечный, то он вскроет IP-заголовок и передаст содержимое пакета своему вышестоящему процессу;
если пакет нужно передать следующему узлу, то из значения TTL будет вычтена единица, произойдет пересчет контрольной суммы и пакет будет отправлен дальше.
Ничего сложного.
Топология сети и некоторые пояснения
Немного поясню по топологии сети: роутеры это образы Cisco 3725, хосты это образы Debian 10. На схеме показаны сети, которые настроены на линках между роутерами, для удобства нумерация была организована по следующему принципу:
1. Первый октет всегда равен десяти.
2. Второй октет это всегда меньший номер роутера.
3. Третий октет номер всегда номер большего роутера.
4. Четвертый октет равен номеру роутера.
5. Маска всегда /24.
Если бы у нас был линк R1 <-> R5. То на интерфейсе R1 был бы назначен адрес 10.1.5.1/24, на R5 такой: 10.1.5.5/24. Сети хостов назначил случайно и никакой системы в нумерации там нет.
Как работает Time to Live
Работает TTL на самом деле очень просто. Обратимся к нашей схеме. Узел Host_1 отправляет пакеты узлу Host_2, если значение TTL будет равно 4, то пакет будет уничтожен роутером R5, но если значение будет равно 5 или больше, то Host_2 получит пакет.
В этом легко убедиться, сделаем ping с Host_1. Для начала зададим TTL=4.
user@debian:~$ ping -t 4 192.168.2.12
PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data.
From 10.4.5.5 icmp_seq=1 Time to live exceeded
From 10.4.5.5 icmp_seq=2 Time to live exceeded
From 10.4.5.5 icmp_seq=3 Time to live exceeded
From 10.4.5.5 icmp_seq=4 Time to live exceeded
From 10.4.5.5 icmp_seq=5 Time to live exceeded
From 10.4.5.5 icmp_seq=6 Time to live exceeded
^C
--- 192.168.2.12 ping statistics ---
6 packets transmitted, 0 received, +6 errors, 100% packet loss, time 13ms
Параметр t команды ping задает значение TTL. Трассировка подтверждает результаты пинга:
user@debian:~$ traceroute -m 4 192.168.2.12
traceroute to 192.168.2.12 (192.168.2.12), 4 hops max, 60 byte packets
1 192.168.1.155 (192.168.1.155) 1.836 ms 12.191 ms 22.688 ms
2 10.1.3.3 (10.1.3.3) 33.218 ms 43.708 ms 54.255 ms
3 10.3.4.4 (10.3.4.4) 64.698 ms 75.194 ms 85.180 ms
4 10.4.5.5 (10.4.5.5) 95.679 ms 106.314 ms 116.695 ms
Параметр m команде traceroute задает значение TTL, видим, что было пройдено четыре транзитных узла и пакет был уничтожен на четвертом (пятым узлом должен был быть Host_2). А теперь сделаем то же самое для TTL=5.
user@debian:~$ traceroute -m 5 192.168.2.12
traceroute to 192.168.2.12 (192.168.2.12), 5 hops max, 60 byte packets
1 192.168.1.155 (192.168.1.155) 4.686 ms 15.048 ms 25.488 ms
2 10.1.3.3 (10.1.3.3) 35.552 ms 46.068 ms 56.597 ms
3 10.3.4.4 (10.3.4.4) 67.063 ms 77.378 ms 87.591 ms
4 10.4.5.5 (10.4.5.5) 98.109 ms 108.930 ms 119.038 ms
5 192.168.2.12 (192.168.2.12) 129.545 ms 140.033 ms 150.561 ms
user@debian:~$
Успешный успех. Если мы попытаемся пропинговать адрес 192.168.2.17 с TTL=4, пинг у нас пройдет, т.к. этот адрес настроен на R5.
user@debian:~$ traceroute -t 4 192.168.2.17
traceroute to 192.168.2.17 (192.168.2.17), 30 hops max, 60 byte packets
1 192.168.1.155 (192.168.1.155) 3.694 ms 14.099 ms 24.630 ms
2 10.1.3.3 (10.1.3.3) 35.064 ms 45.116 ms 55.612 ms
3 10.3.4.4 (10.3.4.4) 66.078 ms 76.583 ms 87.074 ms
4 10.4.5.5 (10.4.5.5) 97.065 ms * *
user@debian:~$ ping -t 4 192.168.2.17
PING 192.168.2.17 (192.168.2.17) 56(84) bytes of data.
64 bytes from 192.168.2.17: icmp_seq=1 ttl=252 time=33.3 ms
64 bytes from 192.168.2.17: icmp_seq=2 ttl=252 time=34.0 ms
64 bytes from 192.168.2.17: icmp_seq=3 ttl=252 time=36.6 ms
64 bytes from 192.168.2.17: icmp_seq=4 ttl=252 time=49.1 ms
64 bytes from 192.168.2.17: icmp_seq=5 ttl=252 time=40.0 ms
^C
--- 192.168.2.17 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 10ms
rtt min/avg/max/mdev = 33.285/38.610/49.147/5.771 ms
user@debian:~$
Вопрос: почему четвертым хопом мы видим 10.4.5.5, а не 192.168.2.17? Ведь трассировку мы делаем до 192 адреса.
Создадим на сети петлю маршрутизации
Во всех этих примерах на сети не было петли маршрутизации, давайте ее создадим и посмотрим что будет. Петля маршрутизации была создана на линке R3 <-> R4, для этого со стороны R4 был добавлен вот такой статический маршрут в сторону R3:
ip route 192.168.2.12 255.255.255.255 10.3.4.3
Теперь пинг с первого хоста до второго не проходит:
user@debian:~$ ping 192.168.2.12
PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data.
From 10.3.4.3 icmp_seq=1 Time to live exceeded
From 10.3.4.3 icmp_seq=2 Time to live exceeded
From 10.3.4.3 icmp_seq=3 Time to live exceeded
From 10.3.4.3 icmp_seq=4 Time to live exceeded
From 10.3.4.3 icmp_seq=5 Time to live exceeded
From 10.3.4.3 icmp_seq=6 Time to live exceeded
^C
--- 192.168.2.12 ping statistics ---
6 packets transmitted, 0 received, +6 errors, 100% packet loss, time 12ms
user@debian:~$
Вот трассировка, значение TTL по умолчанию для команды traceroute равно 30, так говорит man, петля подтверждает сведения, полученные из man:
user@debian:~$ traceroute 192.168.2.12
traceroute to 192.168.2.12 (192.168.2.12), 30 hops max, 60 byte packets
1 192.168.1.155 (192.168.1.155) 7.676 ms 17.985 ms 28.523 ms
2 10.1.3.3 (10.1.3.3) 38.995 ms 49.491 ms 59.979 ms
3 10.3.4.4 (10.3.4.4) 70.815 ms 80.969 ms 91.496 ms
4 10.3.4.3 (10.3.4.3) 101.949 ms 112.461 ms 122.974 ms
5 10.3.4.4 (10.3.4.4) 143.964 ms 154.418 ms 164.945 ms
6 10.3.4.3 (10.3.4.3) 175.578 ms 185.533 ms 142.816 ms
7 10.3.4.4 (10.3.4.4) 247.771 ms 258.300 ms 268.446 ms
8 10.3.4.3 (10.3.4.3) 278.805 ms 312.816 ms 323.311 ms
9 10.3.4.4 (10.3.4.4) 479.835 ms 626.355 ms 636.819 ms
10 10.3.4.3 (10.3.4.3) 556.593 ms 588.117 ms 598.524 ms
11 10.3.4.4 (10.3.4.4) 755.650 ms 797.647 ms 839.148 ms
12 10.3.4.3 (10.3.4.3) 849.913 ms 804.939 ms 805.743 ms
13 10.3.4.4 (10.3.4.4) 973.320 ms 1015.224 ms 962.095 ms
14 10.3.4.3 (10.3.4.3) 993.059 ms 952.398 ms 971.923 ms
15 10.3.4.4 (10.3.4.4) 1170.728 ms 1109.510 ms 1151.391 ms
16 10.3.4.3 (10.3.4.3) 1161.844 ms 1097.333 ms 1170.133 ms
17 10.3.4.4 (10.3.4.4) 1304.082 ms 1313.947 ms 1334.797 ms
18 10.3.4.3 (10.3.4.3) 1346.658 ms 1300.740 ms 1321.627 ms
19 10.3.4.4 (10.3.4.4) 1530.698 ms 1544.993 ms 1515.161 ms
20 10.3.4.3 (10.3.4.3) 1536.287 ms 1471.464 ms 1502.896 ms
21 10.3.4.4 (10.3.4.4) 1711.457 ms 1689.732 ms 1724.093 ms
22 10.3.4.3 (10.3.4.3) 1661.657 ms 1682.391 ms 1672.738 ms
23 10.3.4.4 (10.3.4.4) 1829.791 ms 1820.323 ms 1810.250 ms
24 10.3.4.3 (10.3.4.3) 1831.317 ms 1841.253 ms 1841.213 ms
25 10.3.4.4 (10.3.4.4) 1976.711 ms 1996.839 ms 2007.309 ms
26 10.3.4.3 (10.3.4.3) 1986.232 ms 1947.299 ms 1957.688 ms
27 10.3.4.4 (10.3.4.4) 2090.287 ms 2083.092 ms 2006.741 ms
28 10.3.4.3 (10.3.4.3) 2006.771 ms 1904.826 ms 1890.734 ms
29 10.3.4.4 (10.3.4.4) 1889.694 ms 1813.301 ms 1670.634 ms
30 10.3.4.3 (10.3.4.3) 1628.703 ms 1389.763 ms 1252.525 ms
user@debian:~$
В данном случае петля маршрутизации видна в трассировке, и по адресам мы можем сказать, что проблема на линке R3<->R4. Но при помощи трассировки не всегда можно локализовать проблему.
В дампе Wireshark петля будет выглядеть так:
Петля маршрутизации в дампе Wireshark
Для того, чтобы получить этот дамп, выполнялся вот такой пинг:
user@debian:~$ ping 192.168.2.12 -c 4 -t 12
PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data.
From 10.3.4.3 icmp_seq=1 Time to live exceeded
From 10.3.4.3 icmp_seq=2 Time to live exceeded
From 10.3.4.3 icmp_seq=3 Time to live exceeded
From 10.3.4.3 icmp_seq=4 Time to live exceeded
--- 192.168.2.12 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 9ms
user@debian:~$
В сторону Host_2 было направлено четыре пакета с TTL = 12. В дампе нас интересуют поля Source, Destination и TTL, дамп снимался с интерфейса R4 в сторону R3, по нему видно что на R4 пакет приходит с TTL равным 10, далее R4 этот пакет отправляет в сторону R3, а тот в свою очередь шлет пакет в R4 и так происходит до тех пор, пока TTL не станет равным 1. Если бы не было TTL, пакет на этом линке мог бы ходить до бесконечности.
Напоследок еще один вопрос, если я изменяю статический маршрут на R4, с помощью которого организуется петля, на такой (next-hop меняется на имя интерфейса в сторону R3):
ip route 192.168.2.12 255.255.255.255 fa0/0
Трассировка с первого хоста до второго становится такой:
user@debian:~$ traceroute 192.168.2.12
traceroute to 192.168.2.12 (192.168.2.12), 30 hops max, 60 byte packets
1 192.168.1.155 (192.168.1.155) 15.593 ms 26.071 ms 36.524 ms
2 10.1.3.3 (10.1.3.3) 47.051 ms 57.558 ms 78.591 ms
3 10.3.4.4 (10.3.4.4) 68.039 ms 89.026 ms 99.513 ms
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
user@debian:~$
По трассировке мы сейчас не можем сделать однозначный вывод о том, что произошла петля. Вопрос: почему трассировка стала такой?
Следующий пост будет без видео, в нем будет краткая инструкция о том, как подготовить данную лабу, делать краткую инструкцию how to в виде длинного видео не вижу особого смысла.
Видео версия
Для тех, кому проще смотреть, чем читать, есть видео версия.