#002 Виды устройств в IP (хосты и роутеры). Часть 1⁠⁠

Господа, дамы, здравствуйте!

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

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

Для общего представления о работе IP теории будет достаточно, для того чтобы проникнуться лучше самостоятельно собрать и повторить лабу в Cisco Packet Tracert(далее для краткости CPT), внимательно посмотреть где и какие адреса меняются, подумать(с гуглом или яндексом) почему это происходит. Вопросы, замечания, дополнения и уточнения только приветствуются.

Виды устройств в IP

Устройства в IP делятся на два вида:

1. Конечные или терминальные узлы, для краткости я их буду называть хосты, они могут отправлять и получать пакеты, в некоторых случаях устройство может либо только получать, либо только отправлять пакеты. Хосты описаны в RFC1122.

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

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

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

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. Вопросы на подумать к данной теме смотрите в конце поста со второй частью.