ThreeDHead Опубликовано 23 сентября, 2010 · Жалоба Есть в ядре L3-коммутатор, который миррорит трафик порта интернет-роутера, на порт нетфлоу-сенсора. На этом же сервере (сенсор), делаем захват TCPDUMP-ом трафик некоего локального хоста, всё складываем в файл. Проблема в том, что трафик от хоста в интернет идет "чистым" (без тега 802.1Q), а трафик из интернета к хосту идёт с тегом 802.1Q. На подсчете трафика это никак не отражается, а вот на реконструкции проблемы. Реконструкцию производим программой NetResident, а эта программа пытается обработать файл, счетчик при обработке показывает, а вот в базе - 0 записей. Я грешу именно на то что в езернет фреймах сидит тег. Как его можно убрать с пакетов? Именно обработать файл и вырезать тег, или добавить в конце-концов, чтобы симметрично было? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 23 сентября, 2010 · Жалоба Если трафик сохраняется на сервере через "tcpdump -w file.dump", то я бы попробовал отфильтровать его через "tcpdump -r file.dump -w file2.dump vlan 123" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 23 сентября, 2010 · Жалоба /usr/src/sys/net/ethernet.h вам в помощь! struct ether_header { u_char ether_dhost[ETHER_ADDR_LEN]; u_char ether_shost[ETHER_ADDR_LEN]; u_short ether_type; } __packed; #define ETHERTYPE_IP 0x0800 /* IP protocol */ #define ETHERTYPE_VLAN 0x8100 и if_vlan_var.h struct ether_vlan_header { u_char evl_dhost[ETHER_ADDR_LEN]; u_char evl_shost[ETHER_ADDR_LEN]; u_int16_t evl_encap_proto; u_int16_t evl_tag; u_int16_t evl_proto; }; evl_encap_proto=ETHERTYPE_VLAN evl_proto=ETHERTYPE_IP короче просто отрезать n байт которые структура занимает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 23 сентября, 2010 · Жалоба Если трафик сохраняется на сервере через "tcpdump -w file.dump", то я бы попробовал отфильтровать его через "tcpdump -r file.dump -w file2.dump vlan 123"Дык дело не в фильтрации, а в том чтобы вырезать сам тег с пакета.Можно обработать сам готовый дамп с пакетами, и повырезать нафиг 802.1Q с пакетов, тогда будет всё в порядке. Но не очень хочется, как предлагает Ivan_83, руками (писать утиль) выдёргивать оттуда теги, там еще контрольную сумму пакета пересчитывать придётся, еще может что выплывет. Не хочется время на это тратить... Может есть какая тулза для схожей цели, модификации пакетов-там или еще чего? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 23 сентября, 2010 · Жалоба предлагаю проверить конфиг L3 коммутатора в разделе мирроринга портов (возможно с перечитыванием главы мануала) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 23 сентября, 2010 · Жалоба Поднимите на сервере еще интерфейс с этим тегом и пишите половину трафика с него. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 24 сентября, 2010 · Жалоба предлагаю проверить конфиг L3 коммутатора в разделе мирроринга портов(возможно с перечитыванием главы мануала) Да нечего там проверять, до того как коммутаторы ввели в стек, было всё пучком.Стек из DGS-3627, пакеты внутри стека _все_ идут с тегом. От абонента пришел пакет без тега на порт, коммутатор ставит ему тег и пускает в странствие по матрице, когда пакет находит порт назначения, коммутатор первым делом его миррорит, а после снимает тег (порт назначения тоже не тегированный). Вот и получаем тегированный default vlan'ом зеркалированный пакет. Почему именно такая очередность, специалисты длинка молчат. Между тем из интернета (с маршрутизатора) пакет идёт к абоненту тоже нетегированный, заходит в порт стека, миррорится, коммутатор ставит ему тег и пускает в странствие по матрице, когда пакет находит порт назначения (там где находится район абонента), тег снимается и полетел к родному. Т.е. к абоненту миррорится пакет нормально. Повторюсь, до того как коммутаторы были в стеке, трафик по всем направлениям миррорился нормально. Поднимите на сервере еще интерфейс с этим тегом и пишите половину трафика с него.Ну да, так и делаем. Отсюда и проблемы с реконструкцией. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 24 сентября, 2010 · Жалоба Или у вас как-то странно, или я чего-то не понимаю. К примеру у себя слушаю интерфейс em0, в котором бегает все с тегами, пакеты захватываются также с тегом: gw# tcpdump -npei em0 | grep 172.27.10.28 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes 17:46:02.930287 00:22:56:c1:c4:61 > 00:30:48:64:84:c0, ethertype 802.1Q (0x8100), length 102: vlan 900, p 0, ethertype IPv4, 172.27.10.28 > 87.250.251.3: ICMP echo request, id 47890, seq 89, length 64 17:46:02.933824 00:30:48:64:84:c0 > 00:22:56:c1:c4:61, ethertype 802.1Q (0x8100), length 102: vlan 900, p 0, ethertype IPv4, 87.250.251.3 > 172.27.10.28: ICMP echo reply, id 47890, seq 89, length 64 слушаю теперь интерфейс vlan900, поднятый на сервере, пакты захватываются уже без всяких тегов: gw# tcpdump -npei vlan900 | grep 172.27.10.28 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan900, link-type EN10MB (Ethernet), capture size 96 bytes 17:50:28.070515 00:22:56:c1:c4:61 > 00:30:48:64:84:c0, ethertype IPv4 (0x0800), length 98: 172.27.10.28 > 87.250.251.3: ICMP echo request, id 47890, seq 354, length 64 17:50:28.073534 00:30:48:64:84:c0 > 00:22:56:c1:c4:61, ethertype IPv4 (0x0800), length 98: 87.250.251.3 > 172.27.10.28: ICMP echo reply, id 47890, seq 354, length 64 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 24 сентября, 2010 · Жалоба Но не очень хочется, как предлагает Ivan_83, руками (писать утиль) выдёргивать оттуда теги, там еще контрольную сумму пакета пересчитывать придётся, еще может что выплывет. Не хочется время на это тратить...Может есть какая тулза для схожей цели, модификации пакетов-там или еще чего? Вы дольше собираетесь, чем там писать.Контрольной суммы скорее всего в файлах нет, но и пересчитать её тоже не проблема, исходники все открыты. Можно ещё с нетграфом поиграться, чтобы он в одну сторону вланы снимал, перед сенсором. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 24 сентября, 2010 · Жалоба слушаю теперь интерфейс vlan900, поднятый на сервере, пакты захватываются уже без всяких тегов...Правда ваша, если слушать сам интерфейс влана, пакеты будут грабиться без тега.Спасибо, теперь разберусь сам. Надо как-то заставить TCPDUMP грабить оба интерфейса, причем с разными выражениями для каждого, и писать в один файл. Ладно, завтра поиграюсь... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 25 сентября, 2010 · Жалоба С TCPDUMP'ом не получается, грабит, но не декодируется, но я уже не стал разбираться. А вот TSHARK нормуль грабит: tshark -q -p -i any -w /capture/10-X-Y-Z.cap -b filesize:102400 "((not src net 10.0.0.0/8) and (dst host 10.X.Y.Z)) or ((src host 10.X.Y.Z) and (not dst net 10.0.0.0/8))" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...