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

Точные шаги, чтобы заблокировать нежелательные DHCP-серверы. В этой статье я расскажу, как заблокировать «нежелательные» DHCP-серверы в вашей сети. Это особенно актуально, если у вас есть дети или вы живете в многоквартирном доме, где соседам иногда каж

Точные шаги, чтобы заблокировать нежелательные DHCP-серверы. В этой статье я расскажу, как заблокировать «нежелательные» DHCP-серверы в вашей сети. Это особенно актуально, если у вас есть дети или вы живете в многоквартирном доме, где соседам иногда каж, RouterOS

heinb

Guest

01.05.2008 13:01:00

Привет! Буду очень благодарен за помощь. Я изучил руководство и литературу, но так и не могу понять, что именно нужно сделать. Вот ситуация: наша беспроводная сеть вещает в диапазоне 172.XX.XX.0/24 (распространение DHCP на клиентские ПК осуществляется через DHCP-сервер). У одного (или нескольких) клиентов работает устройство, которое тоже применяет DHCP, но в диапазоне 192.168.1.0/24. Похоже, это мешает клиентам в диапазоне 172.XX.XX.0/24 получать адреса DHCP. Что мне нужно сделать на брандмауэре Mikrotik, чтобы заблокировать DHCP в диапазоне 192.168.1.0/24, но при этом обеспечить подключение в диапазоне 172.XX.XX.0/24. Также я понимаю, что если отключено стандартное перенаправление, клиенты друг друга “не будут видеть”. Тем не менее, я хотел бы, чтобы некоторые ПК могли общаться друг с другом (для LAN-гейминга). Как именно это сделать на брандмауэре? Я пытался что-то сделать раньше (фильтрация IP), но это лишило меня доступа к точке доступа. Помогите, пожалуйста!

fosben Guest	#2 0 30.05.2008 12:29:00 У меня DHCP-сервер RouterOS, настроен как authoritative=yes, но всё равно проблемы с поддельными DHCP-серверами в сети. Сам DHCP-сервер работает на RouterOS 2.9.44, может, обновление поможет решить эту проблему?

schnozberries

Guest

04.04.2011 22:26:00

У меня тоже много проблем с "бегущими" DHCP-серверами в моих сетях. Я работаю в ISP, специализирующемся на студенческих общежитиях. Это настоящий кошмар из-за этой самой проблемы. Я устанавливаю DHCP authoritative в "yes", и это не решает проблему. Единственный способ, который у нас есть, — это отследить порт, к которому подключен "бегущий" DHCP-сервер, и отключить этот порт. Я что-то упускаю здесь? Кажется, многие пользователи RouterOS сталкиваются с этой проблемой, и обратной связи о том, как эффективно справляться с этими ситуациями, очень мало. Кажется, что правило брандмауэра будет неэффективным, потому что DHCP-сообщение широковещательного типа не обязательно должно проходить через брандмауэр, прежде чем дойти до пользователя и получить от него ответ.

fewi

Guest

04.04.2011 22:38:00

Обычно эту проблему на устройстве, которое работает как DHCP-сервер в локальной сети с взаимосвязанными клиентами, решить невозможно по той самой причине, которую вы указали: другой неавторизованный DHCP-сервер может находиться ближе к клиенту и ответить первым. Большинство реализаций DHCP-клиентов просто используют первое полученное предложение, поэтому, если "рогатый" ближе, он отправляет быстрее, и клиент принимает этот лиз. Вы не можете фильтровать этот трафик на DHCP-сервере, потому что он просто не вовлечён в разговор вообще. Единственное правильное решение — фильтровать трафик на портах, подключённых к конечным клиентам, и отбрасывать пакеты от DHCP-сервера к DHCP-клиенту входящие на порт, чтобы ни одно устройство, подключенное к портам конечных клиентов, не могло выступать в качестве DHCP-сервера, поскольку оно не может отправлять трафик обратно к клиентам. Большинство управляемых коммутаторов второго уровня (Cisco, HP, Brocade, Foundry) имеют функциональность специально для этого. Альтернативой могут быть частные VLAN, где каждый клиентский порт не может общаться с другими клиентскими портами вообще. Это также решает другие вопросы безопасности, но может не подойти, если клиентам необходимо общаться друг с другом. Разумеется, если вы используете устройства, работающие под RouterOS для клиентских портов, вы можете реализовать фильтрацию там.

nz_monkey Guest	#5 0 04.04.2011 22:56:00 Согласен с fewi. Фильтры мостов могут помочь в этом.

schnozberries

Guest

05.04.2011 15:19:00

Спасибо за быстрые ответы. Я изучу возможности фильтрации на наших коммутаторах второго уровня. Сейчас используем старые коммутаторы 3COM, но скоро перейдём на коммутаторы AdTran NetVanta. Посмотрим, как всё пойдёт. Ещё раз спасибо.

FIPTech

Guest

05.04.2011 20:43:00

Авторitative = yes не работает, если другой DHCP-сервер быстрее отвечает. Фильтрацию нужно проводить внутри управляемого коммутатора уровня 2 с функцией DHCP snooping, фильтруя оконечные порты от несанкционированного DHCP-трафика. Вы определяете MAC-адреса и порты авторизованных DHCP-серверов для каждого VLAN, и всё в порядке. Другое решение – использовать фильтрацию перенаправления портов, которая все еще присутствует в большинстве настоящих управляемых коммутаторов уровня 2. С помощью этой функции можно запретить связь между клиентскими компьютерами, но разрешить связь с сервером или шлюзом. Лучшее решение – первое, чтобы можно было поддерживать связь между клиентами, если это необходимо. Эти функции не встретишь на недорогих управляемых "умных" коммутаторах. Нужны настоящие коммутаторы уровня 2, 2+ или 3, чтобы получить их.

kubik256

Guest

01.12.2014 08:33:00

Авторитативность = да не работает, если другой DHCP-сервер отвечает быстрее. Это верно, у меня та же проблема, когда кто-то подключает домашний роутер к нашей сети. Но даже если DHCP на Mikrotik выставлен как авторитетный, некоторые ПК, находящиеся ближе к этому «дикому» DHCP, всё равно получают не те IP-адреса. Эта firewall-правило всё исправило: /ip firewall filter add chain=forward action=drop protocol=udp src-address=!192.168.10.1 src-port=67 dst-port=68. Адрес источника !192.168.10.1 не обязателен, он здесь только для уверенности, что это правило не заблокирует основной DHCP в каких-то перехватывающих пакетах. 192.168.10.1, разумеется, IP-адрес самого Mikrotik.

franklinvillalobos Guest	#9 0 14.02.2017 01:16:00 Спасибо!!!

tnrclkr Guest	#10 0 10.08.2017 12:14:00 Авторитетные всякие вещи не работали… Так я решил. Доверяйте файрвол. Это было для устройств TPLINK в моей сети, которые выдавали Rogue DHCP.

pe1chl Guest	#11 0 10.08.2017 13:53:00 Это правило файрвола, конечно, работает только в очень специфических ситуациях с несколькими сетями. На обычном домашнем роутере с локальным мостом между LAN и WIFI, и когда MikroTik выступает в роли DHCP-сервера на этом мосту, оно абсолютно бесполезно. Можно фильтровать DHCP в мосту, но это не так просто, как кажется, и, конечно, не будет работать между портами Ethernet, подключенными к коммутатору, или между WiFi-клиентами, когда включена стандартная пересылка. Может быть, вариант - обнаруживать, а не блокировать, подозрительные DHCP-серверы. Это возможно в RouterOS, загляните в IP->DHCP server на вкладке Alerts и настройте оповещение. Разумеется, сложность в том, как увидеть оповещение и чтобы кто-то предпринял какие-то действия. Но можно использовать это и для отладки: включите и смотрите в лог.

Читают тему

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