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

Рис. 2.3.1. Посылаемые и принимаемые кадры при выполнении ping –l 4000 195.208.113.67

Как видно, утилита опять посылает несколько раз эхо-запросы и принимает эхо-ответы. Главная особенность посылаемых запросов заключена в том, что теперь посылаемые и принимаемые пакеты фрагментируются, т.к. предельный размер данных кадра в 1500 байт превышен. Замечание: получаемые фрагментированные пакеты, на самом деле, идут в обратной последовательности. Т.е. сначала идёт пакет с ICMPзаголовком, и только после этого идут остальные пакеты без ICMPзаголовка. Это отличие результатов объясняется настройкой программного анализатора WireShark.

   Проанализируем фрагментированные пакеты эхо запросов.

Третий пакет запроса.

Рис. 2.3.2. Фрагментированный пакет №3 эхо-запроса

Из данного рисунка можем сделать следующие выводы:

1)  Длина кадра составляет 1514 байт.

2)  Отправитель и адресат (их ip и mac адреса) остались прежними.

3)  Длина ip-пакета 1500, что и ожидали, т.к. длина пакета равна: длина (Ethernet Frame) – длина (MAC-handler) = 1514-14=1500.

4)  Теперь добавилась информация в флагах о том, что принимаемый пакет не последний, за ним будут ещё (на самом деле этот пакет должен быть последним, т.е. флаг Morefragments должен быть равен 0). Смещение этого пакета равно 0, т.к. этот пакет посылается первым (на самом деле смещение должно быть, т.к. это последний пакет).

5)  Разрешённое время жизни – 128.

6)  Длина передаваемых данных («чистая длина») равна 1480 байт. Т.е. это длина ip-пакета минус длина заголовка этого пакета в 20 байт.

Второй пакет запроса.

Рис. 2.3.3. Фрагментированный пакет №2 эхо-запроса

Здесь информация аналогична предыдущему пункту за исключением того, что смещение фрагмента данных на этот раз равно 1480 (здесь информация вполне соответствует действительности, т.к. это промежуточный пакет, поэтому флаг Morefragments выставлен верно).

Первый пакет запроса.

Рис. 2.3.4. Фрагментированный пакет №1 эхо-запроса

Отличие от предыдущих пакетов состоит в следующем:

1)  Смещение фрагмента данных равно 2960 (на самом деле оно должно быть равно 0, т.к. это самый первый пакет).

2)  Этот пакет является последним, что видно из флагов (как было сказано, этот пакет первый, поэтому флаг Morefragments должен быть равен 1).

3)  Появляется инкапсуляция ICMP-пакета, показывающая, что это пакет типа эхо-запрос. В связи с чем, длина «чистых данных» равна: длина (Ethernet Frame) – длина (MAC-handler) – длина (ICMP-handler) = 1082-14-20-8= 1040. Тогда, если просуммировать длины всех «чистых данных»: 1480+1480+1040, то получим длину в 4000 байт, что и указано в последнем пакете (как раз, с учётом открывшейся информации о не совсем верной работе программного анализатора, теперь становиться ясно, что размер передаваемых «чистых» данных здесь должен быть не 4000 байт, а 1472 байта).

Формат эхо-ответов при фрагментировании аналогичен, поэтому в целях экономии места не приводится.

Выполнение утилиты pingcзаписью маршрута пакета

Запустим утилиту ping с ключом –r, в результате получим:

Рис. 2.4.1. Результата работы утилиты ping с ключом –r

Как видим, начинает выводиться маршрут отправляемых пакетов.

Теперь проанализируем пакеты эхо-запросов и эхо-ответов при таком запуске утилиты.