Ошибки супер фреймов

RX (recive) — принимать пакеты приходящие от клиента
TX (transmit) передавать— пакеты приходящие к клиенту 

Типы ошибок:

CRC Error — ошибки проверки контрольной суммы

Undersize — возникают при получение фрейма размером 61-64 байта.

Фрейм передается дальше, на работу не влияет

Oversize — возникают при получении пакета размером более 1518 байт и правильной контрольной суммой

Jabber — возникает при получении пакета размером более 1518 байт и имеющего ошибки в контрольной сумме

Drop Pkts — пакеты отброшенные в одном из трех случаев:

Какие пакеты входят в Drop Packets при выводе show error ports?

Переполнение входного буфера на порту

Пакеты, отброшенные ACL

Проверка по VLAN на входе

Fragment — количество принятых кадров длиной менее 64 байт (без преамбулы и начального ограничителя кадра, но включая байты FCS — контрольной суммы) и содержащих ошибки FCS или ошибки выравнивания.

Excessive Deferral — количество пакетов, первая попытка отправки которых была отложена по причине занятости среды передачи.

Collision — возникают, когда две станции одновременно пытаются передать кадр данных по общей сред

Late Collision — возникают, если коллизия была обнаружена после передачи первых 64 байт пакета

Excessive Collision — возникают, если после возникновения коллизии последующие 16 попыток передачи пакета окончались неудачей. данный пакет больше не передается

Single Collision — единичная коллизия

Режим: ADSL_G.dmt
Тип трафика: ATM
Состояние: Исх.
Питание в линии: L0

Входящий трафик Исходящий трафик
Кодирование линии (Trellis): On On
Отношение сигнал/шум (0.1 dB): 171 150
Затухание линии (0.1 dB): 245 80
Выходная мощность (0.1 dBm): 198 123
Достигаемая скорость (Кбит/с): 8,384 1,132

Path 0 Path 1
Входящая Исходящая Входящая Исходящая
Rate (Kbps): 7,168 960 0 0

K (количество байт в кадре DMT): 225 31 0 0
R (количество проверенных байт в кодовом слове RS): 0 0 0 0
S (размер кодового слова RS в кадре DMT): 0.50 1.00 0.0 0.0
D (глубина интерливинга): 1 1 0 0
Задержка (мсек): 0.13 0.25 0.0 0.0
INP (символ DMT): 0.00 0.00 0.0 0.0

Супер-кадры: 0 0 0 0
Ошибки супер фреймов: 0 0 0 0
Слова RS: 0 0 0 0
Исправимые ошибки RS : 0 0 0 0
Неисправимые ошибки RS : 0 0 0 0

Ошибки HEC : 0 0 0 0
Ошибки OCD : 0 0 0 0
Ошибки LCD : 0 0 0 0
Итого ячеек: 271,166,205 0 0 0
Ячейки данных: 75,378,420 0 0 0
Битовые ошибки : 0 0 0 0

Общее количество ES: 0 0
Общее количество SES: 0 0
Общее количество UAS: 13 13

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

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

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

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

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

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

Интересно, что в заголовке фрейма первым идет адрес назначения, а в IP заголовке первым идет адрес источника.

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

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

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

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

Сведения: лучше сначала заполнить самому

Если вы преподаватель, то дайте такое задание своим студентам: попросите их заполнить все эти карточки на картинке ниже.

Заполните сами данные поля заголовков фреймов перед тем как продолжить читать ответы

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

Заполняем первый фрейм данными 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 NAT или Destination NAT. Но в нашей задаче такое устройство, выполняющее трансляцию адресов, не указано.

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

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

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

Какой MAC-адрес получателя написать во фрейме, исходящем с интерфейса Client

• Иногда люди думают, что им будет MAC-адрес сервера, а именно 0000.00008.8888. Если вы создадите такой фрейм и отправите его с интерфейса компьютера клиента в сторону свитча, то кадр реально попадет в широковещательный домен, доступный через коммутатор (в левой части картинки). Коммутатор получит этот фрейм, проверит по своей таблице 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. По пути между маршрутизаторами могут быть и другие порты: серийные, frame relay, ATM. Нужно понимать, что MAC-адрес применим только к протоколу Ethernet. Протоколы канального уровня используют разные схемы адресации: например, frame relay использует номер DLCI, а протокол ATM — VPI или VCI. Сегодня мы говорим только про Ethernet.

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

Записал видео по этой же теме:

Автор Денис Батранков, руководитель направления сетевой безопасности Positive Technologies.

15 Дек 2022

7630

0

Далее текст от лица автора

Ошибка 1. Группы вместо фреймов

Я не разрешаю своим студентам* использовать группы. Почему? Фреймы лучше в 99% случаев, потому что в отличие от групп они позволяют применять такие функции Figma как автолейауты, привязки (constraints), компоненты, сетки и другие

*Примечание переводчика. Молли — создатель проекта UI Prep, в рамках которого она обучает UX/UI дизайну

Ошибка 2. Супер-пупер наборы компонентов

Дизайнерам нравится создавать универсальный набор компонентов со множеством вариантов и свойств. Но при работе над проектом разделение компонентов на типы/подтипы облегчает их поиск и использование. Например, вместо одного суперкомпонента для всех типов кнопок разбейте их на подтипы. Вы с лёгкостью найдёте их на панели Assets и быстро настроите.

Ошибка 3. Слишком большое количество цветовых стилей

Десять оттенков и тонов для каждого цвета — это излишество почти для любой дизайн-системы. Такое количество цветов может привести к путанице и их неправильному использованию. Вместо этого присвойте всем десяти оттенкам и тонам числовое обозначение. Затем создайте от одного до пяти стилей для самых важных из них.

Например, присвойте номера десяти оттенкам/тонам вашего основного цвета. Затем создайте стили для разных состояний этого цвета: 50 (фон), 600 (базовый/по умолчанию), 700 (при наведении), 800 (при нажатии).

Ошибка 4. Неправильное использование иконок

У иконок обманчивый вид. Они выглядят как безобидные маленькие компоненты, но при неправильной настройке могут создать проблемы.

Правила для иконок:

• Держите все векторные фигуры иконок в стандартных квадратных фреймах
• Убедитесь, что одна иконка — это один вектор
• Никогда не вращайте иконки для создания новых версий (например, стрелка влево/вправо)
• Объединяйте в варианты только те иконки, которые тесно связаны между собой

Ошибка 5. Видимость всех компонентов на панели Assets

Скройте некоторые компоненты на панели Assets. Для этого нужно добавить «.» или «_» в начало их названия. Это полезно только в случае атомарных компонентов, из которых состоят другие компоненты. Например, присвойте вложенным иконкам статуса для аватара наименование «.status», чтобы они не были видны на панели Assets и не загромождали её. И только полный компонент аватара отобразите на панели.

Ошибка 6. Использование жёлтого цвета в дизайне

Непросто сделать желтый цвет доступным для восприятия. Выберите оранжевый в качестве предупреждающего цвета. В крайнем случае стремитесь сделать его ближе к оранжевому, делая каждый следующий его оттенок темнее.

Ошибка 7. Отсутствие описаний для стилей и компонентов

Используйте описания для стилей и компонентов, чтобы быстрее находить их и применять. Например, добавьте описания, чтобы:

• знать, когда или где элемент должен использоваться (например, для основного цвета/700 напишите пояснение: «при наведении»)
• ключевые слова для поиска помогали быстро находить нужную информацию на панели Assets (например, для иконки сердца добавьте описание: «нравится, избранное, сохранить» («like, love, favorite, save»)).

Ошибка 8. Ориентация на размеры устройств, а не на брейкпоинты*

Figma предлагает размеры фреймов на основе общепринятой ширины устройств. Это нормально… но с точки зрения дизайна гораздо практичнее опираться на брейкпоинты! Используйте следующую ширину фреймов в макетах:

• Маленький: 375px
• Средний: 600px
• Большой: 900px
• Очень большой: 1200px

Подробнее читайте здесь.

*Примечание переводчика. Брейкпоинты — контрольные точки дизайна, которые дают возможность дизайнерам и разработчикам контролировать макет дизайна при его масштабировании из мобильной версии в десктопную. Они помогают адаптировать дизайн к устройствам любого размера без ущерба для UX

Ошибка 9. Использование автоматической высоты строки (интерлиньяжа) для текста

Автоматическая высота строки в Figma хорошо работает для многих текстовых стилей. Но вам не помешает немного её настроить.

Следуйте следующим рекомендациям по настройке интерлиньяжа:

1. Увеличьте расстояние между абзацами — задайте значение высоты строки, равное 150%
2. Уменьшите расстояние между заголовками и текстом — задайте значение высоты строки, равное 120%
3. Округлите все значения интерлиньяжа до ближайшего числа в 8px или в 4px. Это улучшит восприятие текста

Ошибка 10. Хранение стилей и компонентов в одном файле

Вы можете хранить стили и компоненты в одном файле, но это сделает вашу дизайн-систему менее гибкой. Такой подход затруднит работу над дизайном в нескольких направлениях (продукт + маркетинг) или процесс разработки нескольких тем (светлая + темная). Вместо этого храните все стили в одном файле, а все компоненты — в другом. Вы можете пойти ещё дальше и создать третий файл для хранения всех иконок.