Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Форум
    RouterOS
    Сделать ответы ICMP с входного интерфейса

    Сделать ответы ICMP с входного интерфейса

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Сделать ответы ICMP с входного интерфейса, RouterOS
     
    shyrwall
    Guest
    #1
    0
    15.03.2018 06:22:00
    Я устал от того, что RouterOS ведёт себя иначе, чем любой другой роутер на рынке. Ответы на ICMP ошибки должны отправляться с того же интерфейса, который получил ICMP-запрос. Без этого трассировка до чего-то, что проходит через оборудование RouterOS и имеет несколько подключений к разным провайдерам, бессмысленна. Я просто прошу RouterOS вести себя как любой другой роутер на рынке. Не может быть, чтобы это было так сложно. Поскольку под капотом у RouterOS Linux, эта функция уже должна быть доступна, если только Mikrotik не удалили этот код из ядра. http://linuxinsight.com/proc_sys_net_ipv4_icmp_errors_use_inbound_ifaddr.html «Такое поведение — то, чего многие сетевые администраторы ожидают от роутера. И это действительно упрощает отладку сложных сетевых схем». Да... Сделайте это стандартным, чтобы роутер вел себя как обычно, или хотя бы добавьте галочку в /ip settings. Пожалуйста...
     
     
     
    shyrwall
    Guest
    #2
    0
    06.07.2019 15:20:00
    Поднимаю этот вопрос снова, потому что до сих пор не понимаю, почему это не реализовано. При использовании логина “devel” и настройке echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr видно, что всё работает, и никаких проблем с ядром из-за кастомного кода MT или чего-то подобного нет. Пожалуйста, дайте ответ, почему это, например, не реализовано в ip->settings.
     
     
     
    Sob
    Guest
    #3
    0
    06.07.2019 19:16:00
    Официальное оправдание: это всего лишь пользовательский форум, и сотрудники MikroTik не обязательно читают каждую тему здесь. Если хотите быть уверены, что они это увидят, нужно писать в службу поддержки.
     
     
     
    muetzekoeln
    Guest
    #4
    0
    08.07.2019 14:04:00
    +1 за то, чтобы сделать это настраиваемой опцией!
     
     
     
    pe1chl
    Guest
    #5
    0
    10.08.2023 20:49:00
    Это хороший пример того, почему аргумент «Сотрудники MikroTik не обязательно читают все темы здесь. Если хотите, чтобы они это заметили, нужно писать в поддержку» — полный бред. Я указал на эту тему в январе 2023 как SUP-103754, в марте 2023 получил ответ: «Большое спасибо за указание. Мы посмотрим, что можно сделать», а в мае 2023 её закрыли с отметкой «Выполнено». Но НИЧЕГО НЕ ИЗМЕНИЛОСЬ. Всё ещё нет нужной настройки, поведение осталось прежним.
     
     
     
    DarkNate
    Guest
    #6
    0
    12.08.2023 14:11:00
    Странно, когда я запускаю трассировку, в ответах вижу ожидаемый маршрут. Я что-то упускаю? Если только вы неправильно не изменили pref-src через фильтры маршрутов (для полных таблиц BGP) или вручную для статических маршрутов/двойного/тройного WAN. Я всегда проверяю, чтобы маршруты, полученные через интерфейс A, имели pref-src, совпадающий с IP этого интерфейса A. То же самое для интерфейса B. Такую проблему никогда не встречал.
     
     
     
    pe1chl
    Guest
    #7
    0
    12.08.2023 14:21:00
    Он игнорирует pref-src. Pref-src настроен правильно, но используется неправильный адрес. Это в некотором роде объясняет, почему маркировка пакетов с помощью mangle и route-marking тоже не работает. Пакеты, по-видимому, генерируются другим механизмом, а не через «output». Конфигурация с несколькими маршрутными таблицами. Трафик приходит через туннель, который прописан в правилах маршрутизации, и маршрут обратно содержит pref-src, но ответ ICMP всё равно отправляется с публичного IP, а не с адреса туннеля или другого локального адреса оверлейной сети. И это ожидаемо без этой настройки. Как объяснено выше, это можно исправить, добавив в sysctl.conf строку: net.ipv4.icmp_errors_use_inbound_ifaddr = 1
     
     
     
    anav
    Guest
    #8
    0
    12.08.2023 14:39:00
    Pelchi, ты хочешь сказать, что внешний входящий ICMP-трафик может уйти обратно через неправильный роутер, даже если мы помечаем входящий трафик?
     
     
     
    pe1chl
    Guest
    #9
    0
    12.08.2023 16:13:00
    Нет.
     
     
     
    DarkNate
    Guest
    #10
    0
    12.08.2023 20:40:00
    Если мы используем статические маршруты, а не BGP, то НАДО помечать входящий трафик, чтобы убедиться, что он выходит через тот же интерфейс. Так что здесь я вообще не вижу никаких проблем.
     
     
     
    pe1chl
    Guest
    #11
    0
    13.08.2023 17:39:00
    Речь идёт не о входящем и маршрутизируемом ICMP-трафике, а о ICMP-трафике, который генерируется самим маршрутизатором в ответ на него! Трафик входит в маршрутизатор, TTL уменьшается до нуля или адрес назначения недоступен, либо фаервол отклоняет трафик — в таком случае назад отправляется ICMP, но этот трафик создаёт сам маршрутизатор, и он не проходит через цепочку «output» (по крайней мере, любые пометки маршрута, сделанные там, на него не влияют), а также он не подчиняется обычным правилам выбора исходного адреса. Это можно изменить, установив соответствующий параметр.
     
     
     
    Amm0
    Guest
    #12
    0
    13.08.2023 18:12:00
    Никогда не думал об этом, но я никогда не видел PMTUD в межсетевом экране… Наверное, это происходит в ядре? Я заметил, что pref-src= ведёт себя по-разному на V6 и V7, по крайней мере с VRRP… так что не уверен, что оно всегда применяется во всех случаях. Mangle может исправить VRRP, но только если трафик проходит через firewall… Кажется, net.ipv4.icmp_errors_use_inbound_ifaddr должна быть настройкой, как rp-filter и другие параметры ядра в /ip/settings… При этом по умолчанию она могла бы быть 0, чтобы не сломать что-то, что рассчитывает на прежнее поведение. Но да, что значит «основной интерфейс» в RouterOS — похоже, это неопределённо (что и отражает icmp_errors_use_inbound_ifaddr=0)…
     
     
     
    pe1chl
    Guest
    #13
    0
    13.08.2023 20:34:00
    Действительно. Я думаю, что маловероятно, что какая-то реальная ситуация сломается, если этот параметр жестко зашит в значение «1» (особенно учитывая, что «основной интерфейс» не очень четко определён), но можно сделать его дополнительным параметром в /ip/settings, чтобы исключить любые риски. Один из факторов, мешающих решению через маркировку, — это то, что пакет может иметь только одну метку, а я уже использую её для приоритета. Судя по всему, в версии 7 планируют разрешить несколько меток пакета (например, 4 «группы меток пакетов»), как это возможно в ядре Linux, но реализация ещё не завершена. Также в моём случае проблему решило бы разрешение использовать «приоритет пакета» в качестве селектора очереди в queue trees вместо «метки пакета». Это, скорее всего, было бы эффективнее. В данный момент я делаю так: сначала устанавливаю приоритет пакета из старших бит DSCP, затем ставлю 8 меток пакетов в mangle в зависимости от приоритета, а потом в queue tree выбираю из 8 очередей на основе метки пакета. Но выбрать очередь по приоритету пакета было бы намного проще, к тому же метка пакета была бы свободна для разных ухищрений с несколькими шлюзами (сейчас для этого использую routing mark).
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры