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

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

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

Давайте подключимся браузером от клиента к веб-серверу и посмотрим на 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) выбрана для примера.

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

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

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

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

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

Source MAC Address = ???
Destination MAC Address = ???
Source IP Address = ???
Destination IP Address = ???

Попробуем написать эти адреса во фреймах сами?

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

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

Заполняем первый фрейм данными 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 адрес свитча. Когда свитч получит этот фрейм, то он увидит, что фрейм предназначен именно ему и скорее всего просто убьет его (может зависеть от производителя), ведь фрейм уже дошел и ему непонятно что с ним делать, ведь это коммутатор, а не роутер. И тут мне еще интересно, а откуда вы знаете на компьютере клиента данный MAC адрес коммутатора? Ведь MAC адрес порта коммутатора вам неизвестен - коммутатор никаким образом не сообщает этот адрес подключенным устройствам.

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

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

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

Иногда студенты спрашивают: почему не указан на картинке MAC адрес верхнего интерфейса коммутатора слева. И вы уже знаете ответ: потому что это неважно. В поле Source MAC address будет стоять MAC адрес интерфейса клиентского компьютера, а не интерфейса коммутатора - коммутатор не меняет ни destination, но 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. Пример описан в данной видеолекции.

Выводы

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

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

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

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

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