Что меняется во фреймах Ethernet при передаче информации от клиента серверу?

Что меняется во фреймах Ethernet при передаче информации от клиента серверу?

Вопрос из заголовка порой вводит в тупик даже коллег, имеющих сертификаты уровня CCNA. Давайте рассмотрим, как выглядят фреймы (кадры) на каждом этапе передачи от клиента коммутатору, роутеру, межсетевому экрану и серверу и какие поля при этом в них меняются.

Буду исходить из того, что читатель знаком с базовым курсом TCP/IP, и касаться только нужных для статьи моментов.

Проведём эксперимент

Давайте подключимся от клиента к серверу и посмотрим на IP- и MAC-адреса источника и получателя во всех фреймах в каждом канале (рис. 1). Самый простой способ увидеть это самим — подключить в каждый канал сниффер.

Рисунок 1. Схема подключения клиента к серверу через промежуточное оборудование

Клиент с IP-адресом 10.1.1.11/24 и MAC-адресом 0000.0001.1111 подключается к серверу с IP-адресом 10.1.3.33/24 и MAC-адресом 0000.0008.8888. Маска /24 (255.255.255.0) выбрана для примера.

Структура фреймов Ethernet при передаче по сети

Напомню, как выглядит структура фрейма (кадра) Ethernet при передаче в сеть: все заголовки и данные вышестоящих протоколов стека TCP/IP объединяются в единый блок данных для передачи. Ваши файлы, голос и видео в виде нарезанных кусочков перемещаются в поле Payload. Внутри Ethernet-заголовка находятся MAC-адреса источника и получателя, и внутри IP-заголовка находятся IP-адреса источника и получателя. Эта структура данных в наших сетях используется коммутаторами и маршрутизаторами для передачи фреймов друг другу. Например, ниже (рис. 2) внутри фрейма отображены заголовки IP-протокола 4-й версии и TCP-протокола (могут быть помещены и другие протоколы, например ICMP или UDP):

Рисунок 2. Пример фрейма (кадра) Ethernet MTU — максимальный размер фрейма для данной среды передачи. Обычно 1500 байт. TCP MSS — максимальный размер сегмента данных TCP. Обычно MSS = MTU-40 = 1460 В сумме длина фрейма 1518 байт.

Рисунок 3. Демонстрация, как производится пересылка фрейма через коммутатор

Изучим первый фрейм между клиентом и коммутатором (рис. 3)
 
Итак, какими будут Source IP и SourceMAC, Destination IP и DestinationMAC в первом кадре от клиентского компьютера? Попробуйте написать эти адреса во фреймах сами: просмотрите названия полей заголовков на рисунке 4, запишите ваши ответы и только затем читайте дальше. Проверьте себя.

Рисунок 4. Итак, какими будут Source IP и Source MAC, Destination IP и Destination MAC в первом кадре от клиентского компьютера?

Будем исходить из того, что клиент и сервер уже передавали друг другу данные и поэтому все нужные ARP-таблицы и таблицы маршрутизации настроены на всём пути от клиента к серверу. У клиента маршрутизатором по умолчанию является 10.1.1.1/24. Соответственно, MAC-адрес у этого IP-адреса уже был запрошен в одном из ранее отправленных ARP-запросов и в ARP-таблице клиента есть информация о MAC-адресе для IP-адреса 10.1.1.1.

Заполняем первый фрейм данными IP- и MAC-адресов (рис. 5).

Рисунок 5. Фрейм от клиента: Src MAC — MAC-адрес отправителя; Dst MAC — MAC-адрес получателя; Src IP — IP-адрес отправителя; Dst IP — IP-адрес получателя

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

Я встречал студентов, которые вписывали в поле с IP-адресом получателя IP-адрес следующего маршрутизатора (в примере — 10.1.1.1): это ошибка. Всегда во фреймах при движении по сетям в поле IP-заголовка будут только IP-адреса источника и получателя. Если вы отправите другой адрес, то маршрутизатору будет недоступен настоящий адрес получателя ив таблице маршрутизации не будет информации о том, куда направлять пакеты. Если вы напишете другой IP-адрес источника, то маршрутизатор не определит, куда возвращать ошибки доставки пакетов. При этом IP-адреса во фреймах могут меняться, если по пути движения кадров появится устройство с включённым SourceNATили Destination NAT. Но в нашей задаче такое устройство, выполняющее трансляцию адресов, не указано.

Кроме того, легко понять, каким будет MAC-адрес отправителя: это MAC-адрес клиента — 0000.0001.1111.

Какой MAC-адрес получателя написать

Поскольку это самая важная часть текста, я выделил её в отдельную главу.

Рисунок 6. 

Какой MAC-адрес получателя написать во фрейме, исходящем с интерфейса Client? Иногда люди думают, что им будет MAC-адрес сервера, а именно 0000.00008.8888. Если вы создадите такой фрейм и отправите его с интерфейса компьютера клиента в сторону свитча, то кадр реально попадёт в широковещательный домен, доступный через коммутатор (в левой части рис.6). Коммутатор получит этот фрейм, проверит по своей таблице MAC-адресов, что такого адреса в ней нет, и отправит кадр сразу на все свои порты. В итоге он дойдёт до роутера (в левой части картинки сверху), на котором MAC-адрес другой (0000.0003.3333), и роутер просто отбросит этот фрейм, потому что он пришёл не по адресу. Такой кадр просто не достигнет сервера.

MAC-адресом получателя также не может быть MAC-адрес свитча. Когда свитч получит фрейм, то определит, что кадр отправлен именно ему, и, скорее всего, просто «убьёт» его (зависит от производителя устройства), ведь фрейм уже дошёл и непонятно, что с ним делать. И ещё мне интересно: как вы на компьютере Client узнаете MAC-адрес коммутатора? Ведь устройство никаким образом не сообщает его подключённым клиентам.

Правильный ответ 

Нужно указывать MAC-адрес роутера, который является вашим маршрутизатором по умолчанию. IP-адрес маршрутизатора задаётся в таблице маршрутизации при настройке компьютера или может быть получен от DHCP-сервера. С компьютера Client заранее сделан ARP-запрос, благодаря которому мы узнаем MAC-адрес, соответствующий IP-адресу роутера. Именно его и надо подставлять в поле Destination MAC address.

В результате этот фрейм от клиента попадает на свитч. Ключевым здесь является то, что коммутатор не меняет ни MAC-адреса, ни IP-адреса. При этом свитч хранит таблицу с описанием того, на каком интерфейсе какие MAC-адреса подключены, и определяет интерфейс, на котором находится нужный нам следующий маршрутизатор 0000.0003.3333. От коммутатора фрейм отправляется на маршрутизатор (неизменённым), где благополучно принимается, ведь получатель указал правильный MAC-адрес.

Я специально нарисовал на схеме коммутатор, потому что хотел сообщить читателям важную информацию: ни MAC-адреса, ни IP-адреса в заголовках фреймов на свитчах не меняются. Кроме того, важно заметить, что адрес коммутатора не надо указывать в поле Destination MAC address.

Иногда студенты спрашивают: почему на картинке не указан MAC-адрес интерфейса верхнего коммутатора слева? И вы уже знаете ответ: потому что это неважно. В поле Source MAC address будет указан MAC-адрес интерфейса клиентского компьютера, а не интерфейса коммутатора: коммутатор не меняет ни Destination MAC address, ниSource MAC addressв заголовках фреймов. Три раза повторил, да? :)

Решение задачи

Окончательная картинка будет выглядеть следующим образом: IP-адреса в заголовке внутри фрейма всегда одинаковые, а вот MAC-адреса меняются на MAC-адреса всех интерфейсов, имеющих IP-адрес. Именно так работает сеть на основе Ethernet. По пути между маршрутизаторами могут быть и другие порты: серийные, framerelay, ATM. Нужно понимать, что MAC-адрес применим только к протоколу Ethernet. Протоколы канального уровня используют разные схемы адресации: например, framerelay использует номер DLCI, а протокол ATM — VPI или VCI. Сегодня мы говорим только про Ethernet.

В настоящей сети вы можете посмотреть все фреймы сниффером, подключившись к SPAN-порту любого из устройств, или воспользоваться TAP-устройствами или даже сетевыми брокерами (рис. 7). Если это виртуализация, то используйте vTAP или vBroker.

Рисунок 7. Схема передачи фреймов по сети от клиента серверу. Синим помечены адреса клиента, красным — адреса сервера

Что будет, если я добавлю в эту сеть NGFW?

Давайте поместим в схему NGFW, который защищает подключения от клиентов к серверу. Нужно понимать, что NGFW будет являться маршрутизатором для сети. На его интерфейсах есть IP-адреса и MAC-адреса, и тогда схема прохождения фреймов аналогична схеме с роутером (рис. 8).

Рисунок 8. Схема передачи фреймов в сети с NGFW с включённой маршрутизацией

Меня озадачивают запросы на проверку MAC-адресов с помощью NGFW. Внимательно посмотрите на картинку: на NGFW видны только MAC-адреса ближайших роутеров. Вы никогда не сможете получить фрейм с настоящим MAC-адресом клиента или сервера. Проверки по MAC-адресам сделать можно, но в поле будет либоany, либо MAC-адрес вашего роутера или роутера провайдера.

А что, если я хочу фильтрующий мост?

Если изменить картинку выше и подключить NGFW не как роутер (устройство layer 3), а как коммутатор (устройство layer 2) или как виртуальную линию (устройство layer 1), то NGFW на самом деле будет фильтрующим мостом согласно типовой классификации межсетевых экранов. И мы всё равно понимаем, что фильтровать можно будет только устройства, которые подключены к NGFW или напрямую, или через коммутатор. Такое, в принципе, бывает в SCADA-сетях, но в интернете все устройства L3, и по MAC-адресам их фильтровать не получится. В сети SCADA логичнее сделать VLAN insertion, разделить один broadcast domain на несколько разных VLAN и заменить теги VLAN на самом NGFW (рис. 9).

Рисунок 9. Схема передачи фреймов в сети с межсетевым экраном L2 (прозрачным для L3)

Заключение. Выводы

Мне бы хотелось, чтобы теперь все знали, что:

• при перемещении IP-пакетов по сети MAC-адреса коммутаторов не подставляются во фреймы Etherne;
• при перемещении IP-пакетов по сети каждый маршрутизатор подставляет свои MAC-адреса, и наши снифферы или анализаторы трафика (например, системы NTA) определяют MAC-адрес ближайшего маршрутизатора, а не реального узла;
• нет смысла в фильтрации по MAC-адресам. Она нужна только для одной локальной сети или одного широковещательного домена.

Ещё будут меняться поле TTL и контрольные суммы, но это нужно обсуждать отдельно.