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

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

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

1. Введение. А как вообще выглядят фреймы Ethernet

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

На каждом этапе перемещения данных по стеку TCP/IP каждый протокол добавляет свой заголовок и передает на следующий уровень абстракции (см. Рисунок 1). Заголовок TСP, потом заголовок IP, потом еще сам заголовок Ethernet и затем считается контрольная сумма всего фрейма (FCS).

При этом программа, реализующая стек TCP/IP в операционной системе делит данные полученные от вышестоящего приложения на сегменты и добавляет заголовок минимум 20 байт. И какой же максимальный размер данных мы можем отправить в одном фрейме? Этот параметр называется TCP Maximum Segment Size (MSS) – максимальная длина сегмента данных TCP, и он, в свою очередь, зависит от максимально возможной длины фрейма. Maximum Transmission Unit (MTU) – максимальная длина фрейма, которая может быть передана без фрагментации. Она 1500 у фреймов Ethernet, и 9000 в случае с jumbo фрейм. Значение MSS – это длина фрейма минус длина заголовков. Если внутри фрейма сегменты TCP, то MSS = MTU — 40 = 1460 (ориентируйтесь на длины заголовков из Рисунка 2).

Обычно конкретное значение MSS определяется во время «TCP-рукопожатия» с целевым хостом исходя из значений MTU. Однако промежуточный маршрутизатор (например, имея канал с меньшим MTU) может подслушивать TCP SYN пакеты и подменять значения MSS, анонсируемые конечными устройствами. Такое может быть, если где-то посередине есть VPN канал. В результате конечные узлы «договорятся» о меньших MSS и пакеты не придётся фрагментировать.

В итоге все эти заголовки и данные объединяются в единый фрейм для передачи и в сумме длина фрейма 1518 байт.

Также для визуализации схемы передачи фреймов (кадров) по сети возьму картинку и рекомендую статью Артема Санникова

Пример 1. Если мы хотим скачать картинку PNG с web-сервера, сколько нам нужно фреймов?

Рекомендую запустить wireshark и посмотреть как это будет выглядеть на вашем компьютере. Например, на скриншоте ниже видно, что картинка PNG размером 22Кб уместилась в 16 сегментах TCP:

Посмотрите в Wireshark как расположены заголовки друг за другом, какой в вашей TCP сессии MSS и какие еще поля есть, например, номер последовательности и TTL.

Пример 2. А сколько фреймов займет SSL транзакция?

Я знаю, что дотошные люди хотят знать про VLAN, QinQ, MPLS

Иногда люди задаются вопросом: а как меняется MTU между свитчами и роутерами при наличии тегов VLAN. А никак ) Остается 1500. Стандарт 802.3AC разрешает максимальный размер фрейма 1522, чтобы добавить информацию о VLAN тегах 802.1q и битах COS 802.1p. А вот при QinQ нужно уже увеличивать MTU до 1504. Приобщу для понимания картинку из более подробной статьи.

Вообще есть огромное количество IEEE 802.3 стандартов для Ethernet. Например, стандарт 802.3AS, где максимальный размер фрейма уже 2000 (но не MTU).

Самое важное, знать, что как только размер MTU превышает возможности среды передачи, то фреймы фрагментируются. И это плохо влияет на скорость передачи. Лучше так не делать. Если вы не знаете какой MTU вам нужно использовать, то вы можете протестировать ваше соединение и найти MTU при котором начинается фрагментация:

ping 10.20.1.11 -M do -s "$((1500-20-8))" -c 1 > MTU_validation.txt

• -M do: (возвращает ошибку, если пакет ping фрагментирован. Здесь написан вариант ping для linux, где используются ICMP пакеты. В Windows используйте ключи -f -l)

• -s packetsize: размер данных:

  • 1500 = тот MTU, который хотите использовать

  • 20 = размер IP заголовка

  • 8 = размер ICMP заголовка

Протокол TCP регулирует значение MSS, чтобы исключить фрагментацию.

2. Основная часть. Как меняются заголовки фреймов при передаче данных по IP сети

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

Попробуем написать эти адреса во фреймах сами? Предлагаю внимательно посмотреть на схему подключения сетевого оборудования ниже:

Клиент с 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) выбрана для примера.

Изучим первый фрейм, между клиентом и свитчом.

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

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

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

Заполняем первый фрейм данными IP и MAC адресов

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

Автор встречал студентов, которые пишут IP адресом получателя IP адрес следующего маршрутизатора (в данном примере — это 10.1.1.1). Это ошибка. У нас всегда во всех фреймах на всем протяжении движения по сетям в поле IP заголовка будут только IP адреса источника и получателя.

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

• Если вы напишете другой IP адрес источника, то маршрутизатор не будет знать куда возвращать ошибки их доставки в случае чего

При этом, IP адреса во фреймах могут меняться в случае появления по пути движения фреймов устройства с включенным source или destination NAT. Но в данной задаче такое устройство выполняющее трансляцию адресов нигде не указано.

Также легко понять какой у нас будет MAC адрес отправителя: это MAC адрес нашего клиента: 0000.0001.1111.

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

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

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

• Иногда люди думают, что MAC адресом получателя будет MAC адрес свитча. Когда свитч получит этот фрейм, то он увидит, что фрейм предназначен именно ему и скорее всего просто убьет его (может зависеть от прозводителя), ведь фрейм уже дошел и непонятно что с ним делать. И тут мне еще интересно, а откуда вы узнаете на компьютере Client данный MAC адрес коммутатора, ведь этот адрес вам неизвестен — коммутатор никаким образом не сообщает этот адрес подключенным клиентам.

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

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

Я специально нарисовал на данной схеме коммутатор, потому что хотел показать читателям важную информацию: ни MAC адреса ни IP адреса в заголовках фреймов на свитчах не меняются. Также важно заметить, что коммутатор не надо указывать в поле destination MAC adddress.

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

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

В итоге конечная картинка будет выглядеть так. Вы видите, что IP адреса в заголовке IP внутри фрейма всегда одинаковые, а вот MAC адреса меняются на MAC адреса всех интерфейсов имеющих IP адрес. Именно так работает сеть на основе Ethernet. По пути между маршрутизаторами могут быть и другие порты: серийные, frame relay, ATM. Нужно понимать, что MAC адрес применим только к протоколу Ethernet. Разные протоколы канального уровня используют разные схемы адресации, например, протокол Frame relay использует номер DLCI, а протокол ATM использует VPI/VCI. Сегодня говорим только про Ethernet. В настоящей сети все эти фреймы вы можете посмотреть сниффером, подключившись на SPAN порт любого из этих устройств, или воспользоваться TAP устройствами или даже сетевыми брокерами. Если это виртуализация, то используйте vTAP или vBroker.

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

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

Автора иногда озадачивают запросы проверять на NGFW MAC адреса. Посмотрите внимательно на картинку. На 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. Пример описан в данной видеолекции.

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

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

• При перемещения IP пакетов по сети, коммутаторы не подставляют свои MAC адреса в фреймы (кадры) Ethernet.

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

• Нет смысла в фильтрации по MAC адресам, кроме работы внутри одной локальной сети или одного широковещательного домена.

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