Серия «IP протокол (IPv4)»

Задачи узла отправителя

Начнем с хостов и с их возможности генерировать пакеты и направить их в сеть, вот что делает устройство для отправки пакета:

1. Пакет нужно сформировать, следует сказать, что IP-пакет состоит из двух частей: заголовка, в котором находится вся необходимая информация для обработки пакета узлами компьютерной сети и поля данных. Сам IP никаких данных не генерируют, процесс IP получает данные от вышестоящего процесса, если вышестоящим процессом является транспортный уровень, то обычно это такие протоколы как UDP, TCP, SCTP, но вышестоящим процессом может быть и протокол сетевого уровня, например, протокол ICMP, который используется когда мы хотим чего-нибудь попинговать. Кто бы ни был вышестоящим процессом его данные помещаются в соответствующее поле данных в пакете, а затем накрываются заголовком.

2. Вторым шагом отправитель должен решить какому соседу по канальной среде нужно передать пакет, чтобы он дошел до получателя. Если получатель в одной канальной среде с отправителем, то пакет будет передан непосредственно ему. Если же получатель находится в другой подсети, то пакет будут передан транзитному узлу, который дальше будет принимать решение о том что делать с пакетом.

3. Отправитель может иметь один или несколько интерфейсов, которыми он подключен к сети, поэтому ему нужно выбрать интерфейс, в который пакет будет направлен, выбор будет зависеть от результатов второго шага, а затем нужно определить канальный адрес соседа, которому пакет будет отправлен. Если получатель в одной канальной среде с отправителем, то определяется канальный адрес получателя, если получатель и отправитель в разных подсетях, то отправитель определяет канальный адрес транзитного узла, которому пакет будет передан. Если на канальном уровне Ethernet, то определяется мак-адрес, за узнавание мак-адресов соседей отвечает протокол ARP.

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

Вроде бы никаких хитрых действий отправитель не совершает.

Задачи узла получателя

Задачи получателя несколько более простые:

1. Пакет нужно получить и убедиться в двух вещах:

   1. Получатель должен убедиться, что именно он является получателем.

   2. А также проверить корректность полученных данных.

2. Далее данные передаются вышестоящему процессу, который уже решит что с ними делать.

Если получатель сочтет нужным, то он в дальнейшем может послать ответ отправителю.

Задачи маршрутизатора (транзитного узла)

Роутеры самые сложные устройства с точки зрения IP, выполняющее самый большой объем работы. В их задачи входит:

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

2. Далее требуется определить какому из соседей по канальной среде следует передавать пакет. Если роутер в одной канальной среде с получателем, то пакет будет передан непосредственно ему, если же нет, то следующему транзитному узлу.

3. Как и в случае с узлом отправителем, роутер определяет свой интерфейс, в который будет послан пакет, а также канальный адрес соседа.

4. Если требуется модификация пакета, то пакет модифицируется, а затем отправляется в выбранный интерфейс.

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

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

Топология и подготовка лабы

С теорией всё, давайте соберем простенькую лабу и посмотрим на IP устройства в эмуляторе. Для практики по данной теме буду использовать CPT. Пока мы ничего не будем настраивать, просто посмотрим, что эмулятор будет нам рассказывать о действиях узлов.

Схема, на которой будем тренироваться выглядит так:

Пояснения к схеме:

1. Оранжевым обведены хосты.

2. Зеленым роутеры.

3. Синим коммутатор, в данном случае мы его не рассматриваем как IP-устройство, сейчас можно представить, что это не коммутатор, а связка проводов, которая соединяет PC2, PC3 и RO2 вместе.

На топологии, обведенной фиолетовым, мы посмотрим как два хоста взаимодействуют напрямую, а на участке, обведенном серым, мы посмотрим на взаимодействие хостов через транзитные узлы. Начнем с прямого взаимодействия.

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

Кнопка Edit Filters отвечает за появление окна на скрине выше, на вкладках IPv6 и Misc тоже нужно отключить отображение всех прочих пакетов.

Взаимодействие отправителя и получателя

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

Выполним пинг с PC2 на PC3, нужно открыть командную строку PC2 сделать это можно так:

1. В топологии кликаем на иконку PC2.

2. Появится окно, в котором нужно будет выбрать вкладку Desktop.

3. На вкладке Desktop выбираем иконку Command Prompt.

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

После того, как мы ввели команду и нажали Enter, PC2 сформировал два пакета:

1. Синий, это как раз тот пакет, который нас интересует, то есть ICMP.

2. Зеленый, это кадр с ARP запросом, он нам не интересен, сейчас нам лишь важно понимать, что протокол ARP поможет PC2 узнать канальный адрес узла PC3, в данном случае это мак-адрес.

Посмотрим содержимое синего пакета, клацнув в него.

Появившееся окно имеет две вкладки: OSI Model и Outbound PDU Details. Нам интересна первая, вторую даже смотреть не будем, на ней представлена детальная информация о структуре кадров и пакетов, она нам сейчас не интересна.

На вкладке OSI можно по шагам посмотреть что делает тот или иной узел при приеме или отправке пакета. За прием отвечает In Layers, за передачу отвечает Out Layers. Как видите, каждая половина разбита на семь уровней, это семь уровней модели OSI, если шрифт уровня тускло серого цвета, значит на нем ничего не происходит, если шрифт черный, значит на этом уровне что-то происходит и он кликабельный, переключаться между уровнями можно еще и кнопками Previous Layer/Next Layer.

На рисунке выше CPT нам показывает, что делает узел отправитель(PC2) на сетевом уровне :

1. PC2 запустил процесс Ping сразу после того, как мы выполнили команду ping.

2. Процесс Ping создает сообщение ICMP Echo Request и отправляет его нижележащему процессу. Здесь следует пояснить, что ICMP и IP это протоколы сетевого уровня, но для ICMP процесс IP это нижележащий процесс.

3. Отправитель должен подставлять в пакет свой IP-адрес, чтобы обратная сторона могла ответить, если она сочтет это нужным. При выполнении команды ping не был задан IP-адрес, поэтому устройство выбрало адрес само (оптимальный на взгляд устройства, хотя по факту он там настроен один).

4. PC2 установил, что IP-адрес узла получателя находится с ним в одной подсети, а также в пакет был добавлен IP-адрес узла получателя.

А вот что CPT нам может рассказать о канальном уровне.

На канальном уровне:

1. Узел PC2 определил, что IP адрес получателя юникастовый, а это значит, что узел должен знать или определить мак-адрес получателя. Чтобы определить канальный адрес соседа узел запустил процесс ARP.

2. Первым делом ARP проверил свою таблицу, чтобы найти: какой мак-адрес соответствует IP-адресу, который мы пингуем (192.168.0.1), но такого соответствия он не обнаружил, поэтому PC2 сформировал ARP-запрос и сохранил ICMP пакет в свой буфер(то есть на текущем шаге синий пакет отправлен никуда не будет).

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

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

1. ARP-запрос PC2 использует, чтобы изучить канальный адрес соседа, в сторону которого должен быть отправлен пакет с ICMP.

2. ARP-запрос получат все соседи PC2 по канальной среде, но ответ даст только тот сосед, чей IP-адрес будет указан в ARP-запросе, все остальные проигнорируют этот ARP-запрос. И тут два момента: если соседей с таким IP нет, то никто и не ответит; если сосед с таким адресом есть, то он ответит, в ответе будет содержаться его мак-адрес.

Вот что по этому поводу нам показывает CPT:

Узел RO2 получил запрос и проигнорировал его, это видно по красному крестику, а вот узел PC3 готов ответить на запрос. Что делает PC3 для отправки ARP мы пропустим, но в итоге мы приходим к той ситуации, что узел PC2 получил ARP ответ и изучил мак-адрес соседа, в сторону которого надо отправить пакет.

Зеленый пакет ниже это и есть ARP-ответ PC3, а синий пакет, это тот ICMP, который ранее был спрятан в буфер.

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

Напомню, что остановились на том, что у канального уровня не было мак-адреса соседа, в сторону которого надо было посылать пакет, теперь мы этот адрес знаем, поэтому:

1. ICMP пакет был извлечен из буфера для дальнейшей обработки.

2. PC2 инкапсулирует(помещает/запаковывает) IP пакет, внутри которого ICMP, внутрь Ethernet кадра.

И тут мы видим что физический уровень стал кликабельным.

А на L1 мы видим, что отправитель выбрал свой интерфейс, через который он будет готов послать сообщение в сеть, на физическом уровне Ethernet кадр превращается в последовательность бит.

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

Здесь мы видим изменения:

1. На вкладке OSI появилось описание того, что происходит на приеме, т.е. теперь у нас информация по In Layers и Out Layers.

2. Вкладок PDU Details тоже стало две.

Сейчас мы не будем заходить на вкладку из пункта два. Что касается первого пункта: PC3 должен сперва принять пакет, т.е. выполнить действия получателя, они описаны под заголовком In Layers, а затем он должен будет дать ответ, т.е. PC3 становится отправителем, что он делает для ответа описано под заголовком Out Layers.

Также вы могли заметить что прием выполняется снизу вверх, а передача наоборот, сверху вниз. PC3 на физическом уровне получает битовую последовательность по порту FastEthernet0 и превращает ее в кадр Ethernet. Переходим на канальный уровень.

Здесь узел PC3 убеждается:

1. Что мак-адрес это мак-адрес, который присвоен одному из интерфейсов PC3, либо это широковещательный мак-адрес, любо это мак-адрес многоадресной рассылки, на который должен отвечать PC3. По факту в данном случае мак-адрес юникастовый и он принадлежит PC3.

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

Переходим на сетевой уровень.

Здесь происходит следующее:

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

2. Внутри пакет обнаружилось ICMP вложение, которое надо передать процессу ICMP.

3. ICMP процесс установил что тип полученного сообщения это ICMP Echo Request, на который нужно дать ответ.

И вот мы на границе, когда один и тот же узел превращается из отправителя в получателя. Посмотрим, что делает PC3 для отправки ответа, ответ начинает формироваться на сетевом уровне и спускается вниз к физическому.

Действия узла такие:

1. ICMP процесс решает что на данный Request следует ответить сообщением типа ICMP Echo Reply.

2. Сообщение Echo Reply отправляется процессу IP.

3. Узел видит, что IP-адрес назначения находится в одной подсети с ним, а значит пакет можно отправлять непосредственно получателю.

ICMP вложение накрывается IP заголовком и передается на канальный уровень.

1. PC3 установил что IP-адрес назначения юникастовый, а значит надо запустить ARP процесс для того, чтобы узнать канальный адрес соседа.

2. Мак-адрес соседа находится в ARP-таблице, поэтому в дальнейшем в Ethernet-кадр в поле мак-адрес назначения будет подставлен мак-адрес, соответствующий IP-адресу 192.168.0.2, взятый из ARP-таблицы.

3. IP-пакет накрывается Ethernet-заголовком, тем самым формируется Ethernet кадр.

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

Исходный отправитель превратился в получателя. Получение пакета на канальном и физическом уровнях для PC2 ничем не будут отличаться от действий на PC3, поэтому оставляю этот момент без комментариев. Вот что происходит на сетевом уровне уровне:

1. Первым шагом PC3 видит, что пакет принадлежит ему, а значит, надо снять IP заголовок.

2. Под заголовком обнаруживается ICMP вложение, оно предается ICMP процессу.

3. ICMP процесс видит, что это Reply на Request, посланный ранее.

4. Процесс Ping получает от ICMP сообщение Echo Reply, в этом сообщение содержится диагностическая информация, которая затем отображается на экране командной строки.

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

По итогу:

1. Мы более детально рассмотрели, как взаимодействуют отправители и получатели пакетов без участия транзитных узлов в случае, когда на канальном уровне работает Ethernet.

2. Поверхностно разобрались с тем, как связаны канальный и сетевой уровни.

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

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

Видео версия

Вот здесь теоретическая часть:

Вот здесь про прямое взаимодействие хостов:

p.s. Вопросы на подумать к данной теме смотрите в конце поста со второй частью.

Словосочетание "не гарантирует доставку пакетов" немного раскрою:

• пакеты на сети теряются, потерянный пакет IP не будет пытаться восстановить или повторно переслать, если IP-пакет потерялся, то он потерялся, средств по восстановлению пакетов или повторной их пересылки в IP нет;

• пакеты в ходе передачи могут быть изменены, иногда это делается намеренно, например, изменяется значение поля TTL, а иногда нет, например, пакет искажается из-за того что физический канал не надежный, вообще, IP никак не контролирует пользовательские данные, в заголовке пакета есть контрольная сумма, но она считается только для заголовка;

• пакеты, которые были отправлены позже, могут прийти в пункт своего назначения раньше;

• пакеты дублируются, IP это не контролирует, иногда это бывает полезно, иногда не очень.

Есть еще и третий способ разделить протоколы на группы: бывают протоколы, которым необходимо установить соединение перед началом передачи данных, в ходе установления соединения участники согласовывают параметры передачи. А бывают протоколы, которые не требуют установление соединения и начинают сразу слать пакеты адресатам. IP относится ко вторым.

История протокола IP

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

Ограничусь лишь сегодняшним днем. У нас существует две актуальные версии протокола IP: IPv4 и IPv6. Работают они практически одинаково, на начало 2024 года могу сказать, что IPv4 будет еще долго актуальным, изучение немного проще начать с него, поэтому здесь и далее, если я пишу IP, то имею ввиду именно IPv4.

Ресурсы для изучения IP и вообще сетевых технологий

В завершении давайте обсудим ресурсы, которые помогут в изучении сетевых технологий. Оговорюсь, что конкретных ссылок или наименований давать не буду. Сами источники я бы разделил на два списка. В первый вошли те, которые не следует читать новичку, это различные серьезные книги по компьютерным сетям, например, "Компьютерные сети" от Олиферов или Таненбаума. Книги обозначенных авторов не плохие и не устаревшие, начинающему инженеру они не нужны.

Во второй список вошли:

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

2. Пособия по подготовке к экзаменам вендоров, сам вендор не важен: HP, Cisco, Juniper, Huawei или любой другой.

3. Статьи и публикации в интернете, желательно на открытых для стороннего мнения площадках, например, Хабр.

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

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

Вот некоторые RFC для IP:

• RFC 791 это спецификация протокола IP;

• RFC 5737 содержит в себе перечень блоков IP-адресов, зарезервированных документации;

• RFC 919 это правила распространения широковещательного трафика;

• RFC 1918 описывает блоки IP-адресов, которые можно использовать в частных сетях;

• RFC 1122 описывает требования к программной реализации хостов на сетевом, канальном и транспортном уровнях.

На самом деле RFC огромное множество, есть и шуточные, которое, например, описывает работу протокола IP поверх голубиной почты RFC 2549.

Для тех, кому нравится больше смотреть:

https://www.youtube.com/watch?v=IzPgASpMG0Q&t=

p.s.

в завершении следующих постов буду стараться придумать 2-3 вопроса.

p.p.s.

Следующий пост о видах IP устройств и о том, чего они там такого делают. Готовлю, кнопка принтскрина потихоньку стерается :)