Исследование трафика ARP и ICMP, страница 2

Также из того, что при пересылке данных используется технология Ethernet II, можем говорить, что используется следующий формат кадра:

Рис. 2.2.4. Формат кадра Ethernet II

Первые 14 байт используются для передачи MAC адресов источника и приёмника, а также для указания типа Ethernet. Далее, от 46 до 1500 байт отводится под поле данных, последние 4 байта – это контрольная сумма. На рис.2.2.5 показано более подробная структура поля данных.

Рис. 2.2.5. Схема вложения ICMP-пакетов в Ethernet-кадр

Далее изучим более детальную информацию об Интернет протоколе.

Рис. 2.2.6. Информация о версии Интернет протокола

Т.к. используется IPv4, тогда можем судить о структуре ip-пакета.

Рис. 2.2.7. Формат пакета IPv4

Длина нашего заголовка минимальна и составляет 20 байт (указано в IHL), следовательно, отсутствует область с дополнительными параметрами (опциями). В поле «differentiated services field» (тип обслуживания) указано то, как происходит деления трафика на классы обслуживания.   Общий размер пакета с учётом длины заголовка – 60 байт, значит, под данные отводится 40 байт. Замечание:  указано, что длина пакета 60 байт, но на рис. 2.2.1 видно, что длина 74 байта. А дело в том, что ip-пакет – это поле данных Ethernet-кадра, но к этому полю, как видно из рис. 2.2.5, добавляется поле с MAC-заголовком длиной в 14 байт.

Из поля флагов видно, что наш пакет не фрагментирован. Также видим, что разрешенное время жизни составляет 128.  Замечание:  опять же из рис. 2.2.1 видно, что при получении обратного пакета ttl=59. Это не означает, что пакету потребовалось совершить огромное число «прыжков», просто на целевом узле ttl=64, следовательно, нашему пакету потребовалось 5 «прыжков», чтобы дойти до нас.

Также из рис. 2.2.6 видно, что смещение фрагмента равно 0 (что верно, т.к. наш пакет не был фрагментирован), протокол ICMP (номер 1). Помимо этого видим, что контрольная сумма заголовка корректна (значит, хотя бы этот заголовок находится в целостности, при этом за целостность данных сумма ничего не говорит, целостность данных  контролируют протоколы транспортного уровня - TCP иди UDP).

Далее проанализируем информацию на рис. 2.2.8.

Рис. 2.2.8. Информация ICMP

Структура ICMP пакета следующая:

Рис.2.2.9. Формат ICMP пакета

Как видно, что тип пакета – эхо-запрос, код равен 0 (в нашем случае код игнорируется т.к. тип определяет всё однозначно), контрольная сумма верна. Также из рис. 2.2.8 видно, что длина самих «чистых данных» составляет всего 32 байта, всё остальное – результат инкапсуляции протоколов разных уровней.

Аналогично получаем структуру кадра эхо-ответа.

Рис.2.2.10. Содержимое кадра эхо-ответа

Здесь практически всё аналогично, только поменялись местами получатель и отправитель и указано, что это эхо-ответ.

Посылка эхо-запросов и принятие эхо-ответов при помощи утилиты ping на существующий узел с длиной передаваемых данных в 4000 байт

В командной строке напишем ping –l 4000 195.208.113.67.  Тогда получаем результат, представленный на рис. 2.3.1.