Не рассматривается.
Речь вроде шла о свитче с PoE, т.е. о заведомо правильном решении. Так что не смущайте человека упоминанием китайского хлама, который ему все равно не потребуется.
Осталось сверить хеши нескольких бинарников (включая dropbox и explorer.exe) и на этом успокоиться.
И найдите в логах файрвола адрес, на который якобы ломился Dropbox. Наверняка он совпадет с забитым в Bat.
Почему нет?
Ну хорошо. Забудьте на время о файрволе, и:
1) Сначала найдите адрес, по которому идет подключение, и узнайте, что это такое с помощью любого сервиса ip lookup.
2) Проанализируйте трафик с помощью сниффера.
3) Определите, какой точно процесс создал соединение (netstat -b).
Любые показания файрвола на данный момент считайте ненадежными и подлежащими проверке вышеуказанными средствами.
Мне кажется, ложная тревога. Ну допустим, шлют железки IGMP join на локальные мультикастовые группы. И? Вот если бы они джойнились на саму 224.0.0.2, или цеплялись бы к непонятным внешним адресам — это было бы прикольно. А так — вполне нормальное поведение, винда любит мусорить в сеть. С большой долей вероятности данные пакеты создаются самой ОС, а файрвол непонятно почему относит их к обычным программам.
Georg, всё сказанное FilimoniC можно кратко суммаризовать в следующие слова: «не парься».
Нет оборудования, которое даст false positive на наличие PoE.
В упор не вижу никакого криминала. Все группы — вполне легитимные для системы.
Как вы обнаружили все Join запросы? Может, файрвол обновился, и его расколбасило?
Наличие или отсутствие PoE абсолютно никак не связано с согласованием скорости. Если устройства с обеих сторон поддерживают гигабит — согласует на него. Воткнете сетевую на 100М — будет 100М.
Исходите из того, что PoE свитч ничем не отличается от обычного — кроме возможности по требованию запитать подключенное устройство.
Что до дебага, сначала:
debug crypto condition peer ipv4 2.2.2.2
(это отфильтрует лишнее)
Затем уже debug crypto isakmp и debug crypto ipsec. Но скорее всего один только show crypto ipsec sa peer 2.2.2.2 позволит понять, в чем проблема.
Цискина инфраструктура. Контроллер линейки WLC, разнообразные точки доступа (часть под передачу данных, часть сенсоры, способные анализировать и триангулировать эфир, а также и давить чужие SSID до полной неработоспособности), WCS (та штука, которая в том числе и отображает клиентов и вражеские AP на карте).
В общем, обычный Cisco Wireless.
Ну и само собой, чтобы пеленговать телефон, нужно, чтобы он либо подключился к сети, либо поднял soft-ap.
Только ключевое слово — «многопоточной». Один поток не сможет выжать более 1гб/с. Если нужно, чтобы именно один поток был шире 1G — смотрите в сторону 10G, но там уже другие расценки.
Для юриков всегда можно расширить каналы. Вы ведь их не поверх E1 поднимаете?
Единственное более-менее приличное решение, пришедшее мне в голову для этой кошмарной топологии и исключительно странной задачи — GLBP. Этот протокол поддерживается на цисках и он проприетарный, но все равно можете попробовать поискать его реализацию в любом виде на микротиках.
Можно сделать как написано в wiki.mikrotik.com/wiki/VRRP-examples, но тогда придется вручную (или скриптами?) рандомизировать DGW у всех устройств.
Сейчас все сидят на IOU (либо L2IOU, который на самом деле виртуальный L3 свитч с близким к cat6500 функционалом, в отличие от строго роутерного IOU). Не эмулятор, не симулятор, скорее скомпилированный под линукс IOS, сворованный у циски. ЦП не жрет, памяти жрет по минимуму, реализовать топологию машин на 30 на среднем железе — не проблема. Глючит совсем умеренно, даже скорее почти совсем не глючит. Есть правильные оболочки вроде iou-web, с которыми не приходится мучиться при создании схемы патчевания.
Можно в поддержку написать.