Но для начала коротко поясню как узлы работают с 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.

Параметр t команды ping задает значение TTL. Трассировка подтверждает результаты пинга:

Параметр m команде traceroute задает значение TTL, видим, что было пройдено четыре транзитных узла и пакет был уничтожен на четвертом (пятым узлом должен был быть Host_2). А теперь сделаем то же самое для TTL=5.

Успешный успех. Если мы попытаемся пропинговать адрес 192.168.2.17 с TTL=4, пинг у нас пройдет, т.к. этот адрес настроен на R5.

Вопрос: почему четвертым хопом мы видим 10.4.5.5, а не 192.168.2.17? Ведь трассировку мы делаем до 192 адреса.

Создадим на сети петлю маршрутизации

Во всех этих примерах на сети не было петли маршрутизации, давайте ее создадим и посмотрим что будет. Петля маршрутизации была создана на линке R3 <-> R4, для этого со стороны R4 был добавлен вот такой статический маршрут в сторону R3:

Теперь пинг с первого хоста до второго не проходит:

Вот трассировка, значение TTL по умолчанию для команды traceroute равно 30, так говорит man, петля подтверждает сведения, полученные из man:

В данном случае петля маршрутизации видна в трассировке, и по адресам мы можем сказать, что проблема на линке R3<->R4. Но при помощи трассировки не всегда можно локализовать проблему.

В дампе Wireshark петля будет выглядеть так:

Для того, чтобы получить этот дамп, выполнялся вот такой пинг:

В сторону Host_2 было направлено четыре пакета с TTL = 12. В дампе нас интересуют поля Source, Destination и TTL, дамп снимался с интерфейса R4 в сторону R3, по нему видно что на R4 пакет приходит с TTL равным 10, далее R4 этот пакет отправляет в сторону R3, а тот в свою очередь шлет пакет в R4 и так происходит до тех пор, пока TTL не станет равным 1. Если бы не было TTL, пакет на этом линке мог бы ходить до бесконечности.

Напоследок еще один вопрос, если я изменяю статический маршрут на R4, с помощью которого организуется петля, на такой (next-hop меняется на имя интерфейса в сторону R3):

Трассировка с первого хоста до второго становится такой:

По трассировке мы сейчас не можем сделать однозначный вывод о том, что произошла петля. Вопрос: почему трассировка стала такой?

Следующий пост будет без видео, в нем будет краткая инструкция о том, как подготовить данную лабу, делать краткую инструкцию how to в виде длинного видео не вижу особого смысла.

Видео версия

Для тех, кому проще смотреть, чем читать, есть видео версия.

В поле данных помещаются данные, которые приходят с транспортного уровня, либо любого другого протокола, который хочет воспользоваться услугами IP. Список протоколов, который можно запихнуть внутрь пакета, легко найти (на вики, сайт IANA).

Ниже три структуры IP-пакета: первая устаревшая, вторая устаревшая, но переведена на рус-яз с ин-яза, третья актуальная.

Общего у них то, что пакет делится на ячейки, каждая ячейка имеет свой размер и свое имя, такая ячейка называется полем. Разница между представленными выше структурами в том, что в первых двух случаях есть поля Type of Service, но на самом деле это поле сейчас заменено на DSCP и ECN. Если говорить совсем просто, то поле ToS использовалось для того, чтобы узел мог отличить важный пакет от неважного и в первую очередь обрабатывать важные пакеты, а неважные уже по возможности. О DSCP и ECN поговорим ниже.

Важно понимать, что узлы ничего не знают ни о каких пакетах, пакет это лишь удобная абстракция для людей. Для компьютеров и роутеров это последовательность нулей и единиц. IP заголовок можно разбить на пять строк(если не считать опции, которые не обязательны) и длина каждой строки получится 32 бита или 4 байта, такая строка в RFC называется 32 битным словом. Поле заголовка не может начинаться на одном слове, а заканчиваться на другом.

Такой строгий подход к структуре заголовка не случаен, для себя я выделил две основные причины этого, которые в общем-то взаимосвязаны:

1. Сам IP размер пакетов считает не в битах или байтах, а в словах.

2. Процессоры сетевых узлов обрабатывают не байты или биты, а слова, если длина слова IP будет равна или кратна машинному слову процессора, то его будет проще обработать.

Кстати говоря, мы уже знаем размер типичного заголовка, он составляет 20 байт, т.к. у нас пять слов (если не считать поля с опциями) и каждое слово 4 байта.

Поля IP заголовка

Теперь разберемся с каждым полем в отдельности. Начнем с версии и размера заголовка.

Версия (Version)

Это версия протокола IP, под него выделено четыре бита, для протокола IPv4 здесь всегда неизменное значение – 4. Хочу заметить, что в IPv4 четверка не связана с количество октетов в IP-адресе, просто такое совпадение.

Размер заголовка (Internet Header Length)

Поле нужно, чтобы узел мог понять: где заканчивается заголовок и начинаются данные, т.к. поле опций не обязательное и их может быть больше чем одна. Под размер заголовка выделено четыре бита, значение данного поля это число, которое равно числу слов в заголовке. Понятно, что максимальное количество слов в заголовке равно пятнадцати.

DSCP и ECN

Под поле DSCP (Differentiated Services Code Point), выделено 6 бит, используется для разделения трафика на классы обслуживания.

Поле ECN (Explicit Congestion Notification) или указатель перегрузки имеет размер два бита. При помощи этого поля узлы могут сигнализировать о перегрузке. Не каждое устройство с этим полем умеет работать, сигнализация через ECN будет работать только в том случае, если узлы сети умеют его обрабатывать.

Размер пакета (Total Length)

Далее обсудим четыре поля, которые имеют отношение к размеру IP-пакета и его фрагментации, начнем с размера.

Это поле позволяет обрабатывающему устройству понять полный размер пакета, то есть заголовок + данные. Под поле выделено два байта, мы уже понимаем, что минимальный размер IP-пакета равен 20 байт, то есть это заголовок без опций и данных, а максимальный размер равен 65535 байт, это максимальное число, которое можно записать при помощи двух байт.

Идентификатор (Identification)

Чаще всего это поле используется в тех ситуация, когда пакет фрагментируется, чтобы принимающая сторона понимала, как из полученных кусочков правильно собрать пакет. У фрагментированных пакетов, которые являются частью одного целого, значение в этом поле должны быть одинаковыми.

Флаги (Flags)

Под флаги выделено три бита, используются для контроля над фрагментацией пакетов. Нумерация бит в поле начинается с нуля, крайний левый бит старший, а крайний правый – младший:

• нулевой бит зарезервирован и должен быть всегда равен нулю;

• если значение первого бита ноль, то допускается фрагментация пакетов, если единица (бит DF или Do not Fragment), то фрагментация запрещена и, если размер пакета при запрещенной фрагментации будет больше, чем разрешенный на канале, то такой пакет в канал отправлен не будет;

• второй бит служит для того, чтобы конечные узлы понимали, где начинается последовательность фрагментированных пакетов, а где она заканчивается, если значение этого бита равно единице (MF More Fragments), то узел понимает, что этот пакет не последний и нужно ждать еще фрагментированные пакеты, чтобы собрать изначально разделенный пакет.

Поскольку тема фрагментации важная, то про нее будет отдельный пост и видео.

Смещение фрагмента (Fragment Offset)

Это поле используется в тех случаях, когда выполняется фрагментация пакетов, размер этого поля равен 13 бит. Об этом поле мы поговорим отдельно и детально, когда будем разбираться с фрагментацией пакетов.

Время жизни (Time to Live, TTL)

TTL имеет размер один байт или восемь бит, поле выполняет функцию защиты от петель маршрутизации. Благодаря TTL пакет не блуждает по сети до бесконечности в ситуациях, когда из-за неверной конфигурации роутеров произошла петля маршрутизации. TTL это число от 0 до 255, это число определяет максимально допустимое число узлов, через которое может пройти пакет, перед тем, как он будет уничтожен.

Время жизни для пакета задается узлом источником и изначально оно измерялось в секундах (то есть максимально возможное время жизни IP пакета раньше было 255 секунд), современные маршрутизаторы обрабатывают пакеты гораздо быстрее, чем за секунду, поэтому сейчас TTL – это значение, которое определяет число транзитных узлов, которые может пройти пакет, прежде чем он будет уничтожен.

Протокол (Protocol)

Под поле выделено 8 бит, поле использует узел получатель, чтобы понять какому процессу передать данные, когда IP-заголовок будет снят. В данное поле записывается код протокола, который был помещен отправителем в IP-пакет, коды регламентированы и их можно найти на сайте IANA.

Контрольная сумма заголовка (Header Checksum)

Под поле выделено два байта и как понятно из названия: протокол IP не имеет механизма проверки целостности данных, поскольку поле «контрольная сумма заголовка» не учитывает поле данных при проверке. Не забываем, что TTL меняется от узла к узлу, а это значит, что и контрольная сумма будет меняться от узла к узлу, то есть каждый транзитный маршрутизатор сперва принимает IP-пакет, вычисляет его контрольную сумму, сравнивает со значением, записанным в поле «контрольная сумма заголовка», затем изменяет поле TTL, вычисляет новую контрольную сумму и отправляет пакет следующему соседу.

Стоит отметить, что если значение контрольной суммы, которую посчитал узел, отличается от контрольной суммы, которая записана в пакете, то он просто уничтожается.

IP-адрес источника

Поле IP-адрес источника имеет размер 32 бита и не изменяется при передаче пакета по сети (если не рассматриваем ситуации с NAT), это поле важно для узла получателя, чтобы знать кому отвечать.

IP-адрес назначения

Данное поле имеет размер четыре байта, в него записывается IP-адрес узла, которому данный пакет предназначен, роутеры смотрят на этот поле при принятии решения о том куда направлять пакет.

Поле данных в IP-пакете

Поле данных в IP-пакете служит контейнером для других протоколов, которым IP оказывает услуги транспорта. Если учитывать, что максимально возможный размер IP-пакета 65535 байт, то максимально возможный размер поля данных 65515 байт.

Поле опций

С большой долей вероятности вы либо не будете использовать опции, либо будете пользоваться ими очень редко, поскольку для штатной передачи трафика опции обычно не используются, поэтому и останавливаться на них сейчас не буду, для самых любознательных дам ссылку.

Если кому интересно, то выше показана структура пакета с опциями Record Route.

Вопросы для ваших ответов

В конце каждого поста обычно стараюсь придумать несколько вопросов, но к данной теме как-то не очень получается, здесь в основном была справочная информация на запоминание.

Видео версия

А вот видео версия у нас есть в наличии, кому больше нравится смотреть - смотрите.

Ранее нерабочий день в понедельник объявили в Москве. Это связано с субботними событиями на фоне военного мятежа ЧВК «Вагнер». В столице, напомним, на один день вводился режим КТО.

В Минцифры подчеркнули, что суббота была очень эмоциональным и напряжённым днем.

— Рекомендуем даже непрерывно действующим ИТ-компаниям, операторам связи и СМИ, работающим в регионах, которые были вчера в эпицентре событий, дать завтра выходной тем сотрудникам, которые не задействованы в выполнении критически важных функций, — подчеркнули в министерстве.

Там же заявили, что дали выходной всем своим сотрудникам, задействованным в минувшую субботу.