nkusnetsov

В 90% случаев, проблема микротика находится с метре от экрана и пялится в winbox. Часто вижу конфиги админов, вешающих IP и DHCP на slave-интерфейс со словами "работает же". При том, что микротик в логах честно пишет, что-то типа "temporary moving client ether1 from slave to master port bridge". А если микротик не смог исправить ошибку админа за него, начинаются вопли "ай, бага-бага! я всё правильно делаю, а не работает!"

Вы посмотрите в столбец "name" и подумайте откуда берутся запросы о таких именах. На корпоративных RB1100AHx4, RB1100AHx2, RB3011 нет такой массовой проблемы. Единичные криво набранные запросы в адресной строке дают единичные записи. На роутере рулящем гостевой сетью появляется при подключении зараженных девайсов.

@Chexov , дело не в количестве запросов вообще, а в количестве неразрешимых запросов к нечитаемым именам (см.скриншот).

@LostSoul , покажите вывод: 1) /ip ad exp 2) /ip arp pr 3) /int vlan exp 4) /int br exp 5) /ip dhcp-s exp либо supout.rif в личку Ну и на всякий случай проверьте, не возник ли где-то на свитче dhcp-relay

С компа за асусом сделайте трассировку до компа за микротиком.

Вероятно у вас vlan не изолированы. Как минимум, на самом микротике. При правильной настройке vlan и dhcp клиент никак не сможет пролонгировать адрес из другой подсети. Исключение иногда составляет Win-10. Она сразу быстро не получив ответа от dhcp-сервера пытается самовольно использовать прежний ip-адрес. Но тогда на сервере продления не происходит.

Кто-то обращается к микротику как к dns-серверу с запросами странных имён. Вероятно, это зараженный вирусом комп. Включите логирование dns-запросов - увидите кто именно.

Вероятно на асусе нет маршрута до сети 192.168.1.1/24.

По документации RB4011 series - SFP+1 interface can be used in 1G mode if required. https://wiki.mikrotik.com/wiki/MikroTik_SFP_module_compatibility_table#SFP.2B_interface_compatibility_settings_with_SFP_optical_transceivers

Убрал, заработало. Почему надо было убрать? Потому, что это настройка на работу с релеем. У Вас же клиенты сами запросы формируют.

Значит, всё же Вы что-то не так сделали. Для того, чтобы работал DHCP ему нужно два условия: работающий интерфейс (бридж, в случае объединения нескольких интерфейсов в группу коммутации), и статический IP на этом интерфейсе. Далее, в оснастке winbox /IP-> DHCP-Server есть волшебна кнопка "DHCP Setup" которая с помощью визарда создаст DHCP-Server на интерфейсе. Если до этого некий dhcp-сервер был сконфигурирован ранее - сначала его там же удалить. И еще бывает, что упорно раздаются IP из старого пула. Это потому, что создались ранее "lease" для отдельных mac-адресов. Обновить/очистить соответствия можно в соответствующей вкладке оснастки "dhcp-server".

Продам лицензии MikroTok RouterOS Level 5. Оплата через сбер/я.д./банковский перевод. Безнал для юрлиц (+6%) Трансфер через сайт вендора. Цена 3000р./шт. При покупке 3 шт. и более - Цена 2600р./шт. WhatsApp, Telegramm 92З-4O14-пять-пять-пять

Продам лицензии. Возможен безнал. При покупке 3 шт. и более - Цена 2600р./шт.

Изучайте фаервол. Умея им пользоваться легко определить доходят ли пакеты до роутера извне.

По умолчанию в микротике все новые подключения со стороны WAN запрещены фаерволом. Настройте фаервол для начала.

Существует пакет user-manager. Но он ставится не на все микротики. Надо смотреть по архитектуре в разделе download. База рулится через веб-морду. Подключение стандартное, как к любому радиусу в вики описано.

Надо искать на линке .5.1 - .5.128. Nat там действительно ни к чему, если прописаны маршруты на основном роутере.   Возможно , всё же хост с vmware тупо режет пакеты адресованые nat-сети. см.п.3 "3) на 192.168.1.100 убиваются пакеты адресованые сети 192.168.5.0/24"

Печально. В нормальных системах роутер отвечает пакетом icmp-redirect (типа, "чувак, это не ко мне, путь в 192.168.5.0/24 есть через 192.168.1.100!"), зост-отправитель теряет первый icmp-echo пакет, но остальные перенаправляет на 192.168.1.100 и пинг идёт со второго пакета. Искать тут надо wireshark-ом. Проблем возможно несколько: 1) основной шлюз не шлет icmp-redirect 2) отправитель убивает или игнорит полученный icmp-redirect 3) на 192.168.1.100 убиваются пакеты адресованые сети 192.168.5.0/24 П.3 можно проверить принудительно прописав на клиенте 192.168.1.101 маршрут в сеть 192.168.5.0/24 через 192.168.1.100. Для винды как-то так "route add 192.168.5.0 mask 255.255.255.0 192.168.1.100"

Вот это вообще, как по-вашему, по-наркомански работать должно?   Можно на микротике прописать /ip route add dst-address=192.168.5.0/24 gateway=192.168.1.100 Тогда клиенты использующие микротик в качестве шлюза получат сообщение icmp-redirect. Если в фаерволах запретов нет, и всякие "[name] internet security" не режут icmp-редиректы, подсеть 192.168.5.0/24 станет доступна из 192.168.1.0/24

Запись в address-list может добавляться не только правилами фаервола, но и из любого скрипта. А также внешним вызовом команды через API/SSH/etc

Используйте параметр tls-host /ip firewall filter add action=drop chain=forward comment=YouTube disabled=no dst-port=80,443 protocol=tcp tls-host=*.youtube.com

Если кажется, что есть проблема с открытием веб-сайтов через туннель, попробуйте явно уменьшать tcp-mss хотя бы до 1400, и сравнить результаты.

Убирание IPSec внутрь туннелей позволяет на слабых роутерах не поддерживающих аппаратное ускорение криптографии IPSec шифровать не весь трафик, а выборочно. Например шифровать только SIP/UDP и не шифровать SMB. Отсутствие шифрования "не критичных к секретности" потоков данных позволит сэкономить ресурсы процессора. Разделние по протоколам - один туннель IPIP, второй GRE, в случае с двумя провайдерами позволяет легко маркировать в mangle исходящий туннелирующий трафик по признаку протокола и корректно отправлять его в разные таблицы маршрутизации, через двух разных провайдеров. Кроме того, бывает, что провайдеры режут протокол GRE, а до IPIP у них руки не доходят.

@McSea здесь панику поднимают чукчи не читатели, чукчи - писатели.

Почитайте еще раз, что я выше написал. Так и будет.