+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

:( ICMP Destination Unreachable - это меня убивает!

:( ICMP Destination Unreachable - это меня убивает!, RouterOS

IntraLink

Guest

21.03.2006 23:40:00

У меня куча пользователей с отвратительными роутерами, которые разбрасывают ICMP Destination Unreachable по всей сети. Есть ли возможность в MT просто отключить все эти пакеты разом? Пока единственное, что помогает держать это под контролем, — настройки для борьбы с broadcast storm на моем управляемом коммутаторе. Но у них слишком высокий минимальный порог, и они не останавливают повторяющиеся атаки.

dot-bot

Guest

22.03.2006 13:17:00

Что бы я рассмотрел: Помочь этим пользователям настроить их роутеры и хосты. Попробовать увидеть закономерность в большинстве пакетов и отбрасывать пакеты, соответствующие этой закономерности. Отключать пользователей, которые повреждают сеть, и сообщать им: «Почините то, что сломали, и вы снова онлайн». Замечание: Я бы рассмотрел это, но не стал бы сразу выполнять.

IntraLink

Guest

22.03.2006 14:00:00

Вот пример того, как выглядят пакеты:
0000 ff ff ff ff ff ff 00 0f b5 a4 cb 23 08 00 45 00 ........ ...#..E.
0010 00 3c 3e c3 00 00 06 01 b4 58 c0 a8 00 fe 00 00 .<>..... .X......
0020 00 00 03 02 a9 d1 00 00 00 00 46 00 00 28 3e c3 ........ ..F..(>.
0030 00 00 01 02 05 f7 00 00 00 00 e0 00 00 16 94 04 ........ ........
0040 00 00 22 00 eb 03 46 00 00 28 .."...F. .(

Ethereal расшифровывает это как элемент строки: источник: 192.168.0.254 Назначение: 0.0.0.0 Протокол: ICMP Информация: Недостижимый пункт назначения (Протокол недостижим)

Если углубиться в информацию IGMP, там говорится, что контрольная сумма заголовка: 0xeb03 [неправильно, должно быть 0x97d7]

Несколько моментов: У нас нет 192.168.0.0/24 в нашей сети или на каком-либо из наших маршрутизаторов.

IntraLink

Guest

22.03.2006 14:05:00

Что не так с роутерами этих клиентов, что вызывает это? Думаю, я уловил закономерность, но не могу понять, что добавить в мой MT, чтобы заблокировать это. Я не могу просто отключить их, потому что, как и большинство пользователей, они понятия не имеют и не догадаются, как это исправить, не говоря уже о том, чтобы хотя бы попытались понять, в чем проблема. Если бы я знал реальную причину или корень этой проблемы, и был бы способ исправить это на стороне домашнего роутера, я бы мог зайти на каждый сайт и исправить это по отдельности. Но рано или поздно это снова появится, и, похоже, это влияет не только на пару устройств. Так что было бы неплохо иметь возможность остановить это на уровне радио или роутера (у нас MT и Canopy).

UniKyrn

Guest

22.03.2006 16:18:00

Поставь правило брандмауэра на роутере, к которому подключаются клиенты, чтобы отбрасывать весь трафик из сети 192.168.0.0/16 (fakenet). Это одна из первых вещей, которые я делаю при подключении нового AP, чтобы дурацкие клиентские роутеры не заваливали нашу сеть всяким хламом. Если у меня плохое настроение, я ещё добавляю фейковый DHCP-сервер на соединении с клиентом, который выдаёт IP-адреса 127.0.0.X в ответ на DHCP-запросы, просачивающиеся из их сети в нашу.

airtech

Guest

22.03.2006 16:41:00

У нас та же проблема на нашей сети, и чтобы её решить, мы переводим каждого клиента на отдельную VLAN с собственным DHCP-сервером. Мы заметили несколько вещей, которые могут вызывать эти штормы. Одна из них — довольно много "гениальных" клиентов подключают наше соединение к LAN-порту своих роутеров. Также мы заметили, в основном с роутерами Linksys, что когда они удерживают кнопку сброса при подключенном нашем соединении, это вызывает эти штормы. Поэтому нашим решением было перевести клиентов на отдельные VLAN, чтобы если один клиент вызывает ICMP-шторм, это затрагивает только его соединение.

IntraLink

Guest

22.03.2006 16:43:00

Мне нравится твой фейковый DHCP для 127.0.0.0! LOL. Думал, добавлю правило для сети 192.168.0.0/24, но даже несмотря на то, что он отображается как источник, это широковещательные ICMP-пакеты. Так что не думаю, что IP-правило поможет.

UniKyrn Guest	#8 0 22.03.2006 17:33:00 Можно добавить правило, специфичное для ICMP, в таблицу пересылки брандмауэра, чтобы блокировать эти пакеты. Выбери подходящий исходящий интерфейс.

jp1 Guest	#9 0 22.03.2006 21:05:00 У нас были проблемы с широковещанием/многовещанием из-за неисправных роутеров клиентов. Два года назад роутеры Linksys bfsr41 и подобные создавали проблемы. Мы работали с Cisco, и они сделали исправление, которое включили в следующую версию прошивки. Недавно у нас была проблема с роутерами Gigafast. Gigafast сказали, что я могу вернуть их на замену (чего я не хотел), взяли мои данные и ничего не сделали. Мы просто отключили все Gigafast, которые участвуют в шторме трафика. Я заменил их роутерами wrt54g и Airnet. Мы графически отображаем каждую клиентскую радиосвязь с помощью mrtg, поэтому знаем, кто транслирует. Сам трафик полон поддельных MAC-адресов и поддельных IP-адресов, так что он не представляет большой ценности. Как видите, все три клиента на этой картинке транслируют, но второй и третий – худшие нарушители. Роутеры Gigafast, кажется, не ведут себя плохо, когда находятся в небольших сетях, поэтому мы иногда используем их в небольших маршрутизируемых сетях. Мы также постепенно переходим от нескольких отдельно маршрутизируемых многосайтовых мостовых сетей к множеству небольших маршрутизируемых ячеек с небольшими netblocks.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры