Изучение структуры сетевых протоколов поможет тебе более глубоко понять принцип их работы и функции. В этой статье мы проанализируем небольшой фрагмент сетевого трафика и зарисуем предполагаемую схему сети, исходя из полученных данных.
Я сформировал дамп сетевого трафика на своем лабораторном стенде с помощью фильтра захвата (Capture Filtering) в Wireshark с некоторыми условиями. Вот что из этого вышло.
Мы будем раскрывать по порядку каждый захваченный пакет и искать в инкапсулируемых данных интересующую нас информацию о схеме исходной сети. Затем мы изобразим эту информацию графически (для этого будем использовать ресурс diagrams.net).
Сразу бросается в глаза MAC-адрес клиентского устройства. Сетевой адрес этого девайса нам пока неизвестен, потому что он еще не получил его, а адреса назначения — широковещательные.
Идем дальше. Возможно, ты обратил внимание на IP-адрес 192.168.30.2 в разделе заголовка 50 DHCP. Это означает, что клиент запрашивает именно этот IP-адрес, так как ранее, возможно, он его уже получал. Но пока мы не станем отображать его на схеме и дождемся окончательного ответа от DHCP-сервера.
И последнее, что нам интересно в этом пакете, — опция 12 DHCP. Здесь отображается имя устройства. Теперь перенесем полученные данные на схему.
Следующий пакет DHCP Offer — в ответе на сообщение клиента сервер предлагает возможные сетевые параметры.
Как мы видим, на запрос клиента ответил DHCP-сервер с IP-адресом 192.168.30.1 и MAC-адресом 00:19:56:bb:41:09. Он предложил клиенту IP-адрес 192.168.30.2 (кстати, тот, который клиент и запрашивал, поле Your IP address) и маску сети 255.255.255.128. Отлично, дополним схему новыми данными.
Новые элементы я буду окрашивать в красный цвет для наглядности.
Еще хочу обратить внимание на поле Time to Live заголовка IPv4 данного сообщения.
TTL — значение, которое определяет время жизни пакета. Это значение декрементируется на единицу каждый раз, когда пакет проходит через маршрутизирующее устройство по пути к месту назначения.
Дело в том, что по умолчанию для разных операционных систем типичны свои значения TTL.
Поскольку в клиентском сообщении DHCP Request TTL имеет значение 128, мы можем предположить, что это устройство под управлением ОС Windows.
Последнее сообщение, свидетельствующее об успешном окончании взаимодействия клиента и DHCP-сервера, — DHCP ACK.
В этом сообщении DHCP-сервер присваивает клиенту:
И напоследок глянем на TTL IP-пакета от DHCP-сервера.
Значение 255 указывает на Cisco IOS. Можно даже проверить производителя устройства по MAC-адресу на онлайн‑сервисах, которых полно в интернете.
Получается, что в качестве DHCP-сервера в сети функционирует маршрутизатор Cisco. Исследовав четыре перехваченных пакета, можем предположить следующую схему сети.
Здесь хост 192.168.30.2 с помощью широковещательной рассылки пытается выяснить MAC-адрес у хоста 192.168.30.48. Значение 1 в поле Opcode означает, что это именно запрос, а значение 2 — ответ. И если посмотреть на полный скрин дампа в начале статьи, то мы не увидим там ответа на ARP-запрос. Поэтому существование хоста 192.168.30.48 ставится под вопрос.
Двигаемся дальше и смотрим на пакеты 6 и 7. Они, в принципе, одинаковые.
Хост 192.168.20.27, не получив ответа, пытается повторно установить TCP-сессию с веб‑сервером (о чем свидетельствует порт назначения 443), отправляя SYN-запросы. Отобразим на схеме веб‑сервер и хост под управлением Windows (поскольку TTL = 128).
В первую очередь смотрим на несущий Ethernet-кадр и определяем, что адрес назначения мультикастовый. А если глянуть на адрес источника (00:19:56:bb:41:09), то становится понятно, что это MAC-адрес того самого маршрутизатора на нашей схеме.
Идем дальше и обращаем внимание на поле Device ID, которому присвоено значение gateway. Это не что иное, как имя устройства, которое задается командой hostname в Cisco IOS.
Следующие поля — Software Version и Platform — обозначают версию прошивки и модель самого устройства соответственно. Итак, мы имеем дело с маршрутизатором Cisco 2821 с установленным программным обеспечением C2800NM-ADVIPSERVICESK9-M, Version 12.4(3f), RELEASE SOFTWARE (fc3). Отобразим эту информацию на схеме и пойдем дальше.
Поле Port ID содержит название и номер порта устройства, через который был отправлен данный CDP-пакет. В нашем случае это порт GigabitEthernet0/1. Теперь давай собирать пазл: только что мы выяснили, что пакет CDP отправлялся через порт G0/1, а MAC-адрес отправителя в Ethernet-заголовке 00:19:56:bb:41:09. Делаем вывод, что MAC-адрес 00:19:56:bb:41:09 принадлежит порту G0/1.
Но это еще не все. Смотрим на поле Addresses и видим значение 192.168.20.1. Это свидетельствует о том, что интерфейс, с которого был отправлен CDP-пакет (G0/1), имеет IP-адрес 192.168.20.1. Вроде бы ничего примечательного, но давай вернемся назад и посмотрим на четвертый пакет DHCP ACK: в этом сообщении клиенту отвечал DHCP-сервер с IP-адресом 192.168.30.1 и — внимание — MAC-адресом 00:19:56:bb:41:09! А ведь до этого мы определили, что порт G0/1 имеет IP-адрес 192.168.20.1 и MAC-адрес 00:19:56:bb:41:09. Выходит, на порте G0/1 висит два айпишника: 192.168.20.1 и 192.168.30.1.
Как так получается? А все дело в «роутере на палочке» — router on a stick — способе маршрутизации между VLAN. В таком варианте маршрутизации роутер соединяется с коммутатором единственным проводом, а на физическом интерфейсе роутера создаются логические субинтерфейсы (они еще называются подынтерфейсы), которым назначаются IP-адреса из разных подсетей. Причем MAC-адреса у них идентичные, так как они часть одного физического порта (в нашем случае порта G0/1). Давай максимально незамысловато отобразим это на схеме.
И раз мы уже выяснили, что в данной сети есть как минимум два компьютера, которые имеют связь с одним физическим интерфейсом маршрутизатора, то, скорее всего, между ними стоит какой‑нибудь коммутатор.
Последнее поле, которое мы изучим в CDP-пакете, — это поле IP Prefixes. В нашем случае оно имеет три значения: 192.168.30.0/25, 192.168.20.0/27 и 66.1.66.0/24. Каждое значение представляет один из непосредственно подключенных к роутеру сегментов IP-сети. Про сети 192.168.30.0/25 и 192.168.20.0/27 мы уже знаем, а вот сегмент 66.1.66.0/24 видим впервые. Тем не менее один из интерфейсов маршрутизатора входит в этот сегмент сети.
RIP — устаревший внутренний протокол динамической маршрутизации. Его характеризует 520-й UDP-порт, мультикастовый IP-адрес 224.0.0.9 и мультикастовый MAC-адрес.
MAC-адрес отправителя уже до боли знакомый. Значит, это сообщение было отправлено во внутреннюю пользовательскую сеть, где, скорее всего, нет других роутеров. Таким образом, на этом роутере не сконфигурирован порт G0/1 как пассивный.
Возможно, смотря на TTL, ты ожидал увидеть значение 1, а на деле оно равно 2. Это сделано для того, чтобы протокол RIP мог работать в NBMA-сетях. В общем, здесь ничего интересного. Рассмотрим непосредственно сам заголовок RIP.
Итак, поле Command обозначает тип сообщения: для запроса значение устанавливается в 1, а для отклика или ответа — в 2. Но это не значит, что кто‑то запросил маршрутную информацию от нашего роутера, так как RIP каждые несколько секунд сам ее рассылает.
Поле Version, как ни странно, означает версию протокола RIP. Вторая версия отличается от первой лишь тем, что поддерживает бесклассовую адресацию. Простыми словами, RIPv2, помимо данных о сетях, передает сведения о масках этих сетей и тем самым в современных реалиях имеет хоть какой‑то шанс на существование.
И самое интересное — это поля, отображающие данные о сетях, до которых можно добраться через наш маршрутизатор. IP Address — здесь отображается адрес сети назначения. В нашем примере их два: 192.168.30.0 и 66.1.66.0. Метрика у обоих маршрутов равна единице. Это значит, что, чтобы добраться до этих сетей, другому роутеру нужно сделать один переход до места назначения. Значение поля Netmask, думаю, не нуждается в объяснении.
Router Tag, или метка маршрута, используется для того, чтобы обеспечить разделение внутренних маршрутов (маршруты для сетей в пределах домена маршрутизации RIP) от внешних, которые, возможно, были импортированы из EGP или другого IGP.
Значение Next Hop выставляется как 0.0.0.0 в том случае, если сеть напрямую подсоединена к роутеру, тем самым роутер‑отправитель говорит, что он является хопом по пути к сети назначения.
Возможно, у тебя возник вопрос: почему в анонсе нет сети 192.168.20.0? Если взглянуть на IP-заголовок, то видно, что IP-адрес источника — 192.168.20.1, который как раз таки входит в сеть 192.168.20.0. Поэтому анонсировать информацию об этой же сети ей же просто не нужно.
Итак, анализируя пакет RIP, мы подтвердили, что сеть 66.1.66.0/24 напрямую присоединена к нашему маршрутизатору.
Здесь мы снова видим TCP-протокол, однако IP- и MAC-адреса нам незнакомы. Давай их изучать. Некий 192.168.20.2 с MAC-адресом f0:bf:97:6a:a0:8b хочет установить связь с неким 5.9.243.178, отправляя SYN-запрос на шлюз по умолчанию 00:19:56:bb:41:09 (Cisco Router).
Кроме того, в TCP-заголовке виден всем известный 80-й порт назначения. То есть хост 192.168.20.2 пытается установить TCP-сессию с HTTP-сервером. Также, если посмотреть на TTL (оно равно 64), можно предположить, что инициатором установления сессии выступает Unix-система. Добавим эту информацию на схему.
По 11-му и 12-му пакетам, очевидно, идет продолжение установки TCP-сессии и сервер в сторону клиента отправляет пару флагов SYN/ACK. Опять же смотрим на TTL сервера: значение равно 49, что также предположительно указывает на ОС Unix на стороне веб‑сервера. Ведь пакет от сервера проходит определенное количество маршрутизирующих устройств, которые каждый раз уменьшают величину TTL на единицу.
Ну и только после завершения установки TCP-сессии клиент формирует HTTP-запрос. Поглядим на него.
Тут, кроме того, что клиент запрашивает веб‑страницу http://xgu.ru/wiki/HSRP, нет ничего интересного.
Наконец мы рассмотрели последний перехваченный пакет и получили следующую картину.
Тут мы отобразили все интересующие нас данные, взятые из дампа. Осталось навести марафет, чтобы схема выглядела более понятной.
автор Alexander Mikhailov aka @alexander_99
источник xakep.ru
Я сформировал дамп сетевого трафика на своем лабораторном стенде с помощью фильтра захвата (Capture Filtering) в Wireshark с некоторыми условиями. Вот что из этого вышло.
Мы будем раскрывать по порядку каждый захваченный пакет и искать в инкапсулируемых данных интересующую нас информацию о схеме исходной сети. Затем мы изобразим эту информацию графически (для этого будем использовать ресурс diagrams.net).
УЗНАЕМ КАНАЛЬНЫЕ И СЕТЕВЫЕ АДРЕСА ПЕРВЫХ УСТРОЙСТВ
Из первых четырех пакетов сразу видно, что некое устройство получает IP-адрес и другие сетевые параметры по DHCP. Раскрываем первый пакет.
Сразу бросается в глаза MAC-адрес клиентского устройства. Сетевой адрес этого девайса нам пока неизвестен, потому что он еще не получил его, а адреса назначения — широковещательные.
Идем дальше. Возможно, ты обратил внимание на IP-адрес 192.168.30.2 в разделе заголовка 50 DHCP. Это означает, что клиент запрашивает именно этот IP-адрес, так как ранее, возможно, он его уже получал. Но пока мы не станем отображать его на схеме и дождемся окончательного ответа от DHCP-сервера.
И последнее, что нам интересно в этом пакете, — опция 12 DHCP. Здесь отображается имя устройства. Теперь перенесем полученные данные на схему.
Следующий пакет DHCP Offer — в ответе на сообщение клиента сервер предлагает возможные сетевые параметры.
Как мы видим, на запрос клиента ответил DHCP-сервер с IP-адресом 192.168.30.1 и MAC-адресом 00:19:56:bb:41:09. Он предложил клиенту IP-адрес 192.168.30.2 (кстати, тот, который клиент и запрашивал, поле Your IP address) и маску сети 255.255.255.128. Отлично, дополним схему новыми данными.
Новые элементы я буду окрашивать в красный цвет для наглядности.
MICROSOFT WINDOWS И CISCO IOS, ИЛИ ПРИ ЧЕМ ЗДЕСЬ TTL?
Сообщение DHCP Request не несет в себе новой информации, кроме того, что в опции 55 клиент запрашивает дополнительные параметры у DHCP-сервера: сетевую маску, адрес шлюза, сервер DNS и доменное имя.
Еще хочу обратить внимание на поле Time to Live заголовка IPv4 данного сообщения.
TTL — значение, которое определяет время жизни пакета. Это значение декрементируется на единицу каждый раз, когда пакет проходит через маршрутизирующее устройство по пути к месту назначения.
Дело в том, что по умолчанию для разных операционных систем типичны свои значения TTL.
Поскольку в клиентском сообщении DHCP Request TTL имеет значение 128, мы можем предположить, что это устройство под управлением ОС Windows.
Последнее сообщение, свидетельствующее об успешном окончании взаимодействия клиента и DHCP-сервера, — DHCP ACK.
В этом сообщении DHCP-сервер присваивает клиенту:
- IP-адрес 192.168.30.2;
- маску сети 255.255.255.128 (опция 1);
- шлюз 192.168.30.1 (опция 3);
- DNS 8.8.8.8 (опция 6).
И напоследок глянем на TTL IP-пакета от DHCP-сервера.
Значение 255 указывает на Cisco IOS. Можно даже проверить производителя устройства по MAC-адресу на онлайн‑сервисах, которых полно в интернете.
Получается, что в качестве DHCP-сервера в сети функционирует маршрутизатор Cisco. Исследовав четыре перехваченных пакета, можем предположить следующую схему сети.
РАСКРЫВАЕМ ARP И TCP
Раскроем пятый по очереди пакет (а точнее, кадр) ARP.
Здесь хост 192.168.30.2 с помощью широковещательной рассылки пытается выяснить MAC-адрес у хоста 192.168.30.48. Значение 1 в поле Opcode означает, что это именно запрос, а значение 2 — ответ. И если посмотреть на полный скрин дампа в начале статьи, то мы не увидим там ответа на ARP-запрос. Поэтому существование хоста 192.168.30.48 ставится под вопрос.
Двигаемся дальше и смотрим на пакеты 6 и 7. Они, в принципе, одинаковые.
Хост 192.168.20.27, не получив ответа, пытается повторно установить TCP-сессию с веб‑сервером (о чем свидетельствует порт назначения 443), отправляя SYN-запросы. Отобразим на схеме веб‑сервер и хост под управлением Windows (поскольку TTL = 128).
МНОГО ЛИ МОЖЕТ РАССКАЗАТЬ CDP?
Протокол CDP служит для обнаружения соседних сетевых устройств под управлением Cisco IOS и может предоставить много полезной информации. Рассмотрим подробно его самые интересные поля.
В первую очередь смотрим на несущий Ethernet-кадр и определяем, что адрес назначения мультикастовый. А если глянуть на адрес источника (00:19:56:bb:41:09), то становится понятно, что это MAC-адрес того самого маршрутизатора на нашей схеме.
Идем дальше и обращаем внимание на поле Device ID, которому присвоено значение gateway. Это не что иное, как имя устройства, которое задается командой hostname в Cisco IOS.
Следующие поля — Software Version и Platform — обозначают версию прошивки и модель самого устройства соответственно. Итак, мы имеем дело с маршрутизатором Cisco 2821 с установленным программным обеспечением C2800NM-ADVIPSERVICESK9-M, Version 12.4(3f), RELEASE SOFTWARE (fc3). Отобразим эту информацию на схеме и пойдем дальше.
Поле Port ID содержит название и номер порта устройства, через который был отправлен данный CDP-пакет. В нашем случае это порт GigabitEthernet0/1. Теперь давай собирать пазл: только что мы выяснили, что пакет CDP отправлялся через порт G0/1, а MAC-адрес отправителя в Ethernet-заголовке 00:19:56:bb:41:09. Делаем вывод, что MAC-адрес 00:19:56:bb:41:09 принадлежит порту G0/1.
Но это еще не все. Смотрим на поле Addresses и видим значение 192.168.20.1. Это свидетельствует о том, что интерфейс, с которого был отправлен CDP-пакет (G0/1), имеет IP-адрес 192.168.20.1. Вроде бы ничего примечательного, но давай вернемся назад и посмотрим на четвертый пакет DHCP ACK: в этом сообщении клиенту отвечал DHCP-сервер с IP-адресом 192.168.30.1 и — внимание — MAC-адресом 00:19:56:bb:41:09! А ведь до этого мы определили, что порт G0/1 имеет IP-адрес 192.168.20.1 и MAC-адрес 00:19:56:bb:41:09. Выходит, на порте G0/1 висит два айпишника: 192.168.20.1 и 192.168.30.1.
Как так получается? А все дело в «роутере на палочке» — router on a stick — способе маршрутизации между VLAN. В таком варианте маршрутизации роутер соединяется с коммутатором единственным проводом, а на физическом интерфейсе роутера создаются логические субинтерфейсы (они еще называются подынтерфейсы), которым назначаются IP-адреса из разных подсетей. Причем MAC-адреса у них идентичные, так как они часть одного физического порта (в нашем случае порта G0/1). Давай максимально незамысловато отобразим это на схеме.
И раз мы уже выяснили, что в данной сети есть как минимум два компьютера, которые имеют связь с одним физическим интерфейсом маршрутизатора, то, скорее всего, между ними стоит какой‑нибудь коммутатор.
Последнее поле, которое мы изучим в CDP-пакете, — это поле IP Prefixes. В нашем случае оно имеет три значения: 192.168.30.0/25, 192.168.20.0/27 и 66.1.66.0/24. Каждое значение представляет один из непосредственно подключенных к роутеру сегментов IP-сети. Про сети 192.168.30.0/25 и 192.168.20.0/27 мы уже знаем, а вот сегмент 66.1.66.0/24 видим впервые. Тем не менее один из интерфейсов маршрутизатора входит в этот сегмент сети.
ROUTING INFORMATION PROTOCOL
RIP — устаревший внутренний протокол динамической маршрутизации. Его характеризует 520-й UDP-порт, мультикастовый IP-адрес 224.0.0.9 и мультикастовый MAC-адрес.
MAC-адрес отправителя уже до боли знакомый. Значит, это сообщение было отправлено во внутреннюю пользовательскую сеть, где, скорее всего, нет других роутеров. Таким образом, на этом роутере не сконфигурирован порт G0/1 как пассивный.
Возможно, смотря на TTL, ты ожидал увидеть значение 1, а на деле оно равно 2. Это сделано для того, чтобы протокол RIP мог работать в NBMA-сетях. В общем, здесь ничего интересного. Рассмотрим непосредственно сам заголовок RIP.
Итак, поле Command обозначает тип сообщения: для запроса значение устанавливается в 1, а для отклика или ответа — в 2. Но это не значит, что кто‑то запросил маршрутную информацию от нашего роутера, так как RIP каждые несколько секунд сам ее рассылает.
Поле Version, как ни странно, означает версию протокола RIP. Вторая версия отличается от первой лишь тем, что поддерживает бесклассовую адресацию. Простыми словами, RIPv2, помимо данных о сетях, передает сведения о масках этих сетей и тем самым в современных реалиях имеет хоть какой‑то шанс на существование.
И самое интересное — это поля, отображающие данные о сетях, до которых можно добраться через наш маршрутизатор. IP Address — здесь отображается адрес сети назначения. В нашем примере их два: 192.168.30.0 и 66.1.66.0. Метрика у обоих маршрутов равна единице. Это значит, что, чтобы добраться до этих сетей, другому роутеру нужно сделать один переход до места назначения. Значение поля Netmask, думаю, не нуждается в объяснении.
Router Tag, или метка маршрута, используется для того, чтобы обеспечить разделение внутренних маршрутов (маршруты для сетей в пределах домена маршрутизации RIP) от внешних, которые, возможно, были импортированы из EGP или другого IGP.
Значение Next Hop выставляется как 0.0.0.0 в том случае, если сеть напрямую подсоединена к роутеру, тем самым роутер‑отправитель говорит, что он является хопом по пути к сети назначения.
Возможно, у тебя возник вопрос: почему в анонсе нет сети 192.168.20.0? Если взглянуть на IP-заголовок, то видно, что IP-адрес источника — 192.168.20.1, который как раз таки входит в сеть 192.168.20.0. Поэтому анонсировать информацию об этой же сети ей же просто не нужно.
Итак, анализируя пакет RIP, мы подтвердили, что сеть 66.1.66.0/24 напрямую присоединена к нашему маршрутизатору.
THREE-WAY HANDSHAKE И HTTP-ЗАПРОС
Здесь мы снова видим TCP-протокол, однако IP- и MAC-адреса нам незнакомы. Давай их изучать. Некий 192.168.20.2 с MAC-адресом f0:bf:97:6a:a0:8b хочет установить связь с неким 5.9.243.178, отправляя SYN-запрос на шлюз по умолчанию 00:19:56:bb:41:09 (Cisco Router).
Кроме того, в TCP-заголовке виден всем известный 80-й порт назначения. То есть хост 192.168.20.2 пытается установить TCP-сессию с HTTP-сервером. Также, если посмотреть на TTL (оно равно 64), можно предположить, что инициатором установления сессии выступает Unix-система. Добавим эту информацию на схему.
По 11-му и 12-му пакетам, очевидно, идет продолжение установки TCP-сессии и сервер в сторону клиента отправляет пару флагов SYN/ACK. Опять же смотрим на TTL сервера: значение равно 49, что также предположительно указывает на ОС Unix на стороне веб‑сервера. Ведь пакет от сервера проходит определенное количество маршрутизирующих устройств, которые каждый раз уменьшают величину TTL на единицу.
Ну и только после завершения установки TCP-сессии клиент формирует HTTP-запрос. Поглядим на него.
Тут, кроме того, что клиент запрашивает веб‑страницу http://xgu.ru/wiki/HSRP, нет ничего интересного.
Наконец мы рассмотрели последний перехваченный пакет и получили следующую картину.
Тут мы отобразили все интересующие нас данные, взятые из дампа. Осталось навести марафет, чтобы схема выглядела более понятной.
ВЫВОДЫ
Мы проанализировали всего тринадцать сетевых пакетов и извлекли из них много ценной информации об исходной сети. Этот подход к визуализации будет полезен, к примеру, при поиске инцидентов в сети и траблшутинге. Как минимум подобное «чтение» сетевого трафика повысит твой скилл в сетевых технологиях и прокачает понимание принципов взаимодействия сетевых устройств и протоколов.автор Alexander Mikhailov aka @alexander_99
источник xakep.ru