Что меняется внутри фрейма Ethernet при передаче от роутера к роутеру?
Вопрос из заголовка, порой, вводит в тупик, даже коллег, имеющих сертификаты уровня CCNA. Давайте обсудим как выглядят фреймы на каждом этапе передачи от клиента к коммутатору, к роутеру, к межсетевому экрану и к серверу и какие поля при этом там меняются.
Буду исходить из того, что читатель знаком с базовым курсом по TCP/IP, поэтому буду касаться только нужных для статьи моментов.
Давайте подключимся от клиента к серверу и посмотрим на IP и MAC адреса источника и получателя в каждом фрейме в каждом канале на картинке ниже. Самое простое это увидеть самим — подключить в каждый канал сниффер.
Предлагаю внимательно посмотреть на схему подключения сетевого оборудования ниже:
Схема подключения клиента к серверу через промежуточное оборудования с 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 адресов
Фрейм от клиента
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 адреса во фреймах могут меняться в случае появления по пути движения фреймов устройства с включенным source или destination NAT. Но в данной задаче такое устройство выполняющее трансляцию адресов нигде не указано.
Также легко понять какой у нас будет MAC адрес отправителя: это MAC адрес нашего клиента: 0000.0001.1111.
Какой написать MAC адрес получателя?
Поскольку это самая важная часть текста, то выделил в отдельную главу.
Какой MAC адрес получателя написать во фрейме исходящем с интерфейса Client?
Иногда люди думают, что 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 с включенной маршрутизацией
Автора иногда озадачивают запросы проверять на 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. Пример описан в данной видеолекции.
Схема передачи фреймов в сети с межсетевым экраном уровня L2 (прозрачным для L3 уровня)
3. Заключение. Выводы
Мне бы хотелось, чтобы теперь все знали, что
При перемещении IP пакетов по сети, коммутаторы не подставляют свои MAC адреса в фреймы (кадры) Ethernet.
При перемещении IP пакетов по сети, каждый маршрутизатор подставляет свои собственные MAC адреса и наши снифферы или анализаторы трафика (например системы защиты NTA) видят MAC адрес ближайшего маршрутизатора, а не реального хоста.
Нет смысла в фильтрации по MAC адресам, кроме работы внутри одной локальной сети или одного широковещательного домена.
Еще будет меняться поле TTL и контрольные суммы, и это можно обсуждать отдельно.
