Найти тему
Кручинин.Linux

Как компьютер понимает, куда отправить пакет?

Оглавление

Рассмотрим простейший пример. Создадим сеть без маршрутизатора из 4х ПК. Чтобы не думать об устройстве коммутатора (свитча), соединим их с помощью концентратора -- были такие древние железки, которые просто отправляли сигнал всем. Сейчас таких не найдешь, но нам сейчас важно понять основы.

Небольшая ремарка, как работает концентратор. Можно пропустить и продлжить читать дальше материал.

[начало ремарки]

Витая пара состоит из пар + и -. В 10 и 100 мегабитных Ethernet из таких 4х пар используется только две. Одна пара используется для передачи информации, вторая для приема. Концентратор -- простая железка, которую можно спаять самостоятельно. Сигнал (красного цвета) отправляется с ввода 1 порта №3 и приходит на ввод 3 портов №2 и №1. Но также этим же сигналом (темно-красный) будет занят и ввод №1 (служащий для передачи) коммутаторов №2 и №1. Поэтому передача при использовании концентратора может быть только полудуплексная (как по рации, по очереди). Более того, мы даже на свой принимающий ввод №3 будем принимать свой же сигнал (фиолетовый).

[конец ремарки]

Самое главное, концентратор (или хаб, hub) отправляет сигнал во все порты, а нам того и надо.

Компьютеры "подпишем" -- вместо их стандартных названий укажем IP-адрес и MAC-адрес.
Айпи-адреса тоже присвоим.
Вот наша схема.

-2

Айпи-адрес мы прописываем в свойствах Config > Interface> FastEthernet0

Например, для 10.0.0.3

-3

В Config>Global прописываем имя

-4

Настройка режима симуляции

Далее мы включим режим Симуляции и выключим все протоколы.

Нажмем кнопку Simulation и далее кнопку Show All/None

-5

Далее нажмем Edit Filters, и выберем ARP и ICMP.

После чего закроем.

-6

Если все правильно сделали, то должно получиться так:

-7

Теперь откроем компьютер 10.0.0.2 и попробуем запинговать 10.0.0.3

Вообще IP-адреса нет

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

Нажимаем Enter и кнопку Play и видим, появился пакет.

-8

Кликаем на IP-пакет и сразу видим, что только уровень 3 и в нем только ICMP.

-9

Если кликнем на Outbound PDU то тоже видим только ICMP

-10

Если пакет сразу удаляется, то нужно посмотреть, а присвоен ли нашему компьютеру адрес? Нашему присвоен.

Пример, когда пакет сразу уничтожается

-11

В консоли тоже не радостно.

-12

Мда.

Проверяем (Desctop > IP Configuration) -- и правда не присвоен.

-13

Что делать? Присваиваем.

-14

Когда IP-адрес присвоили

Повторяем наши действия. Снова симуляция, снова пинг, снова play

Если мы уже ранее что-то отправили, лучше перед этим удалить таблицу сопоставления IP-адресов и MAC-адресов командой arp -d для чистоты эксперимента.

-15

Зачем два пакета?

Итак, в этот раз появилось два пакета.

-16

Кликаем на левый пакет

-17

Видим,что уровень 3 есть, но в нем кроме ICMP есть еще и IP. Понятно, что мы хотим от 10.0.0.2 отправить на 10.0.0.3

Жмем на Outbound PDU.

Видим, что IP-пакет есть, в него вложен ICMP.

-18

Казалось бы, пора отправить? но нет.

Почему? Потому что чтобы отправить IP-пакет, нужно знать, куда его отправить. Да,мы знаем IP-адреса, но мы не знаем какие за этими IP-адресами стоят MAC-адреса.

Поэтому закрываем информацию на левом пакете и кликаем на правый.

-19

Здесь мы видим только уровень 2, в котором мы видим, что от MAC-адреса 0090.215A.29EC мы отправляем на MAC FFFF.FFFF.FFFF. Это широковещательный MAC, то есть буквально "внимание всем".

Посмотрим в Outbound PDU.

-20

Первое что бросается в глаза, кроме всяких не интересных нам заголовков, что сначала идет поле кому (DEST ADDR) и в нем широковещательный адрес, а потом -- поле от кого (SRC ADDR) и там наш MAC -0090.215A.29EC

Вообще MAC адреса похожи на позывные и работают также. Это когда по рации вы говорите ,Первый, я второй ,как слышно. Или внимание всем, я первый, отбой тревоги. Первый, второй это как бы обычные MAC-адреса, а внимание всем -- широковещательный.

-21

Далее мы увидим заголовки ARP-протокола (Address Recolution Prototocol) он нужен буквально чтобы всем задать один и тот же вопрос (какой MAC у 10.0.0.3) и чтобы только один (владелец IP 10.0.0.3) ответил, какой же у него MAC.

Поэтому в полях SOURCE MAC и SOURCE IP мы выставляем наши данные, в поле TARGET IP -- IP для которого мы ищем адрес, а вот TARGET MAC -- все нули. Потому что мы не знаем этот адрес и хотим узнать!

Жмем плей и видим, что IP-пакет был отброшен, а вот ARP-запрос полетел ко всем.

-22

Более того, мы видим, что пакет отвергается теми компьютерами, IP-адрес которых отличается от искомого, и принимается тем, чей совпадает.

А

Он готовит ответ. Он летит обратно и мы можем в него заглянуть

-23

Кликнем на Outbound и увидим подробности

-24

В Ethernet заголовке мы видим, что теперь адресат 0090.2150.29EC -- это 10.0.0.2 и отвечает ему 001.6448.3733. И далее в ARP протоколе видим, что все поля заполнены. Самое главное, что есть SOURCE MAC и содержит искомый MAC-адрес 001.6448.3733

Далее мы увидим, что формируется уже IP-пакет. Нажмем на него.

-25

И нажмем на Outbound PDU

-26

Мы видим что теперь заполнены не только IP и ICMP но и канальный уровен.

Говорится буквально следующее 0001.6448.3733, я 0090.2140.29EC, вот тебе посылка от 10.0.0.2 к 10.0.0.3

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

И здесь мы видим, что интерфейсы, у которых MAC-адрес не совпадает с полем DEST ADDR, будут отбрасывать пакет, а тот интерфейс у кого совпадает -- принимает и отвечает. Это очень похоже на работу нескольких людей по рации.
Третий, я четвертый. Первый, второй, седьмой, десятый, пятый, мятый -- все они проигнорируют мой запрос. Также и сетевые интерфейсы.

-27


Ответы приходят

-28

В другую сеть

А как же, когда сообщение отправляется в другую сеть?

Какой тогда MAC-адрес будет указываться?

Попробуем запинговать 1.1.1.1

-29

Ситуация похожа на тот случай, когда у нас не было IP-адреса на интерфейсе.

Пакет сразу отбрасывается

-30

Чтобы более подробно понять почему, рекомендую мою статью маршрутизация https://dzen.ru/a/Zfx2NbgccxBY1vX7

А пока скажу, что у нас нет адреса шлюза по умолчанию. Все пакеты, которые не принадлежат нашей IP-сети (грубо говоря не имеют вид 10.X.X.X) должны отправиться на адрес шлюза, а у нас его нет.

-31

Потому впишем адрес шлюза

-32

Вписать мало. Нужно его добавить.

-33

И настроить

en

conf t

настроим адрес 10.0.0.1

int fa0/0

ip addr 10.0.0.1 255.0.0.0

no shut

и также настроим адрес, имитирующий Интернет

int lo0

ip addr 1.1.1.1 255.255.255.255

-34

Теперь пробуем отправить пинг на 1.1.1.1

Снова два пакета

-35

Левый

IP есть, ICMP есть, Ethernet с MAC-адресами нет

-36

Правый

-37

Увидели ARP-запрос на IP-адрес роутера

Ротует отвечает

-38

И теперь пакет летит на роутер. Видм что от 10.0.0.2 на 1.1.1.1

-39

Провернем выше окно, и посмотрим на MAC-адреса

-40

Что за 0001.97D8.5702?

-41

А это адрес роутера.

-42

А что будет, если мы не 1.1.1.1 запингуем, а 2.2.2.2

ARP-запрос пока не улетит, так как пока в ARP-таблице есть соответствия IP-адрес MAC-адрес

Легко проверить командой arp -a

-43

Включаем симуляцию и пингуем 2.2.2.2

Пакет сформирован, посмотрим

-44

Все как будто хорошо

-45

Есть и канальный заголовок, и сетевой.

А в Outbound PDU видим -- адресуется на MAC-адрес роутера 0001.97D8.5702 и просит переслать пакет от 10.0.0.2 на 2.2.2.2

-46

Жмем Play и видим, пакет летит до роутера.

А вот роутер не знает, что с этим пакетом делать.

-47

Смотрим внтурь и видим

-48

В поле Ethernet видим что 0090.2151.29EC получает Ethernet-фрейм от 0001.97D8.5702 (т.е. от роутера)

В нем IP-пакет от 10.0.0.1 (от роутера) к 10.0.0.2

В нем ICMP сообщение, тип 0x03 код 0x01 это сообщение означает, что Destination Unreachable.

И внутри ICMP содержится заголовок IP-сообщения, которое не смогли доставить (от 10.0.0.2 до 2.2.2.2)

-49

В консоли мы видим ответы на пинг, что Destination host unreachable.

-50

То есть в данном случае маршрутизатор не знает, куда отправить дальше. Ни на нем этого адреса нет. Ни маршрута далее к этому адресу нет.

Так что далее рекомендую мою статью маршрутизация https://dzen.ru/a/Zfx2NbgccxBY1vX7

Подписывайтесь на мой канал https://dzen.ru/olinux

-51

и читайте заметки о неочевидных моментах в работе GNU/Linux и сетевых протоколов.

Всегда с вами,
Сергей Кручинин,
преподаватель GNU/Linux
и компьютерных сетей

-52