Информация
Настройка
Новости
Контакты
Новинка
Распродажа
Оплата
Доставка
Загрузки
  • Прошивки
    • RouterOS
    • WinBox
  • Changelogs
  • Архив
  • RouterOS
Форум
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
    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
    Таблица маршрутизации игнорирует метку маршрутизации.

    Таблица маршрутизации игнорирует метку маршрутизации.

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    Ответить
    RSS
    Таблица маршрутизации игнорирует метку маршрутизации., RouterOS
     
    petterg
    Guest
    #1
    0
    25.08.2012 23:17:00
    Я следовал вики по адресу http://wiki.mikrotik.com/wiki/PCC, чтобы настроить балансировку нагрузки между двумя интернет-соединениями. Из-за ipsec-туннеля я добавил следующее:
    `/ip firewall mangle add chain=prerouting dst-address=172.29.5.0/24 action=accept
    /ip firewall mangle add chain=prerouting dst-address=1.2.3.0/24 action=mark-connection new-connection-mark=ISP1_conn
    /ip firewall mangle add chain=output dst-address=1.2.3.0/24 action=mark-connection new-connection-mark=ISP1_conn` (1.2.3.0/24 — это подсеть, включающая удалённый пир ipsec 1.2.3.4. 172.29.5.0/24 — это удалённая локальная подсеть ipsec). Я подозревал, что это не работает (ipsec был нестабильным), поэтому провёл некоторые тесты. Я удалил два маршрута до 0.0.0.0/0 без routing-mark и добавил следующее:
    `/ip firewall filter add action=log chain=output disabled=no dst-address=1.2.3.0/24 log-prefix="ipsec out:" routing-mark=to_ISP1
    /ip firewall filter add action=log chain=forward disabled=no dst-address=1.2.3.0/24 log-prefix="ipsec fwd:" routing-mark=to_ISP1`. Теперь, когда я пингую 1.2.3.3 или 1.2.3.4 (или пытаюсь установить ipsec с моей локальной стороны до 1.2.3.4), я часто вижу в логах, что пакеты будут использовать ISP2 в качестве исходящего интерфейса, с адресом источника ISP1! Я думаю, это объясняет, почему ipsec так нестабилен. (Дальнейшее логирование показывает, что ipsec-пакеты выходят через интерфейс IPS2, а возвращающиеся пакеты приходят через интерфейс ISP1). И сам факт, что что-то появляется в логах вообще, доказывает, что routing-mark правильный. Затем я запустил следующие команды:
    `/ip route
    add dst-address=0.0.0.0/0 gateway=10.111.0.1 distance=5 check-gateway=ping
    add dst-address=0.0.0.0/0 gateway=10.112.0.1 distance=2 check-gateway=ping`. По моему пониманию работы routing-mark, эти два правила не должны оказывать никакого влияния, поскольку есть другие правила маршрутизации с меньшим расстоянием, которые соответствуют routing-mark. Но они оказывают влияние. После ввода этих двух команд пакеты к ipsec-пиру отправляются через интерфейс ISP2 100% времени, за исключением момента установления туннеля. (По какой-то причине туннель устанавливается. Но все последующие пакеты отправляются через неправильный интерфейс). И пинги всегда отправляются через неправильный интерфейс. Но если добавить маршрут `add dst-address=1.2.3.0/24 gateway=10.111.0.1 distance=1 check-gateway=ping`, всё работает хорошо с ipsec. Но всё же большинство пакетов в интернет используют ISP2. Итак, мой вопрос. Я делаю что-то совершенно не так, или routing-mark часто игнорируется в таблице маршрутизации? Реальная настройка, где я столкнулся с проблемой, была на RB450G с ROS4.11. Проблема воспроизводится на RB751G с ROS 5.11, который я использовал для всех тестов/отладки. Чтобы убедиться, что я не ошибся при переводе адресов в командах из вики, я настроил полную тестовую среду, используя точно те же адреса, что и в вики, используя два других rb751g в качестве ISP* маршрутизаторов, и даже два других, чтобы создать «интернет» с удалённым ipsec-пиром.
     
       Цитировать   Имя
     
    petterg
    Guest
    #2
    0
    26.08.2012 02:06:00
    Небольшая дополнительная информация: эта логика перехватывает IPsec-пакеты с неправильным исходящим интерфейсом: /ip firewall mangle
    add action=log chain=postrouting disabled=no dst-address=192.168.9.123 log-prefix=POST: routing-mark=to_ISP1

    А вот эти правила не перехватывают: /ip firewall nat
    add action=log chain=srcnat disabled=yes dst-address=1.2.3.0/24 log-prefix=SRC:
    add action=log chain=srcnat disabled=yes dst-address=1.2.3.0/24 log-prefix=SRCmark: routing-mark=to_ISP1 (правила перемещены в начало списка)

    Насколько я знаю, SRCNAT — это последнее место в роутере, где можно увидеть пакеты перед их отправкой. Странно, что они там не отображаются.
     
    Цитировать   Имя
     
    petterg
    Guest
    #3
    0
    27.08.2012 23:44:00
    Ни у кого нет опыта работы с routing-mark?
     
    Цитировать   Имя
     
    lelo
    Guest
    #4
    0
    30.10.2014 12:50:00
    Привет, petterg, я не уверен, связана ли моя проблема с той же самой, но у меня тоже были проблемы с маркировкой IPsec-пакетов, и я нашёл причину/решение/баг?? Я не хочу вставлять сюда всю свою конфигурацию, поэтому постараюсь объяснить проблему как можно лучше. У меня двойная конфигурация WAN (без BGP) (с дополнительными скриптами для переключения при отказе WAN, но это не имеет значения). У меня правила mangle, основанные на этом сайте: https://aacable.wordpress.com/2011/07/27/mikrotik-dual-wan-load-balancing-using-pcc-method-complete-script-by-zaib/ только немного усовершенствованы: /ip firewall mangle add chain=input in-interface=WAN1 action=mark-connection new-connection-mark=WAN1_conn add chain=input in-interface=WAN2 action=mark-connection new-connection-mark=WAN2_conn В моём случае у меня chain=prerouting, поэтому все входящие соединения с роутера (как сам роутер, так и предназначенные для моих локальных подсетей) отмечены соединением. У меня есть VPN-соединения с удалёнными локациями (GRE-туннели, работающие поверх IPsec). GRE-туннели работают на локальных IP-адресах (10.255.255.10/32 - центральный офис, 10.255.255.20/32 - удалённый офис). IPsec-политики настроены только для этих IP-адресов, чтобы они были инкапсулированы и зашифрованы с помощью IPsec. У меня есть два GRE-туннеля до каждой удалённой локации (один работает на нашем WAN1, а второй — на WAN2). Что я обнаружил, что исходящие IPsec-пакеты, которые отмечены для WAN2, на самом деле не выходят через правильный интерфейс (они выходили через WAN1 (по умолчанию)). Поскольку оба наших провайдера не фильтруют наши исходящие адреса, мы можем использовать IP-адрес, назначенное ISP1, и пакет успешно выходит через интерфейс ISP2 и наоборот. Поэтому я даже не подозревал, что происходит что-то не так... После двух дней упорной работы, анализа логов, я нашёл причину!! Все расшифрованные пакеты, которые поступают из IPsec-туннеля (эти с 10.255… на которых работают GRE-туннели) в брандмауэре действуют как входящие интерфейс = физический интерфейс, на который был получен IPsec-пакет. Это на самом деле для меня не ново, я знал это раньше и это, вероятно, нормально. Таким образом, согласно правилам mangle выше, соединения GRE (с локальными/приватными IP-адресами) также отмечаются соединением, что приводит к тому, что исходящий пакет GRE правильно отмечается для правильного исходящего WAN-интерфейса. Но это совершенно не имеет значения, так как исходящий пакет GRE перехватывается IPsec-полисикой, шифруется, инкапсулируется, и весь процесс начинается заново. http://wiki.mikrotik.com/images/thumb/2/2a/IP_final.png/700px-IP_final.png и.. вот где начинаются проблемы.. ! Теперь исходящий IPsec-пакет также должен быть отмечен и направлен через правильный wan-интерфейс, но это не работает. Либо правило маршрутизации не работает, либо метка маршрута игнорируется во время маршрутизации. и.. теперь решение/причина! Эта проблема с маркировкой/маршрутизацией IPsec-пакетов вызвана предыдущей маршрутизацией пакета, который был инкапсулирован в IPsec!! (GRE-пакеты в моём случае). Я совершенно не представляю себе... какая связь/причина маршрутизации пакетов, которые поступают в IPsec-туннель, с маркировкой IPsec-пакетов? Решение было очень простым, я обновил вышеуказанные правила подсетями IP-адресов назначения WAN-ссылок, так что теперь соединения, предназначенные для публичных IP-адресов, поступают только через WAN-интерфейсы и маркируются. (GRE-пакеты теперь не отмечаются). Я провёл несколько тестов, не только с GRE, но и с простым ICMP-пингом по этим приватным IP-адресам, используемым GRE. И я могу подтвердить: каждый пакет, который маркируется для маршрутизации, но в конечном итоге инкапсулируется в IPsec-пакет, приводит к тому, что маршрутизация для этого IPsec-пакета не работает. Пожалуйста, ребята из MikroTik, подтвердите, это баг или я чего-то не знаю? (проверено на ROS 6.18 и 6.20)
     
    Цитировать   Имя
     
    611
    Guest
    #5
    0
    22.05.2023 07:19:00
    На дворе 2023 год, ROS v7.9, всё то же самое, по-прежнему без документации. Пришлось прибегнуть к простому сбросу метки маршрутизации как первому правилу в цепочке обработки исходящего трафика: /ip firewall mangle add chain=output action=mark-connection connection-state=new,untracked ipsec-policy=out,ipsec new-connection-mark=no-mark passthrough=yes log-prefix=cm-reset comment="reset connection mark for outgoing packets to be IPsec encrypted as they break IPsec route adjustment (routing marks on encrypted packets stop working)".
     
    Цитировать   Имя
     
    mrz
    Guest
    #6
    0
    22.05.2023 09:40:00
    Посмотри на схему потока пакетов и конкретный пример ispec https://help.mikrotik.com/docs/display/ROS/Packet+Flow+in+RouterOS. Если тебе нужно перенаправить ipsec-пакеты, то нужно использовать routing marks после ipsec-инкапсуляции. Ipsec не заботится ни о каких предыдущих метках или предыдущих решениях о маршрутизации. Он инкапсулирует и отправляет пакеты в соответствии со своими политиками. Если тебе нужно перенаправить входящие дешифрованные пакеты, то то же самое, маркировку нужно делать после процесса дешифрования.
     
    Цитировать   Имя
     
    msatter
    Guest
    #7
    0
    22.05.2023 11:26:00
    В чем разница между режимом туннелирования IPsec и транспортным режимом IPsec? Режим туннелирования IPsec используется между двумя выделенными маршрутизаторами, где каждый маршрутизатор выступает в качестве одного конца виртуального "туннеля" через общедоступную сеть. В режиме туннелирования IPsec зашифровывается исходный IP-заголовок, содержащий окончательный пункт назначения пакета, а также полезная нагрузка пакета. Чтобы промежуточные маршрутизаторы знали, куда пересылать пакеты, IPsec добавляет новый IP-заголовок. На каждом конце туннеля маршрутизаторы расшифровывают IP-заголовки, чтобы доставить пакеты к их пунктам назначения. В транспортном режиме зашифрована только полезная нагрузка каждого пакета, но исходный IP-заголовок не зашифрован. Таким образом, промежуточные маршрутизаторы могут видеть окончательный пункт назначения каждого пакета — если не используется отдельный протокол туннелирования (например, GRE).

    Означает ли вышеописанное, что RouterOS всегда использует туннель? В транспортном режиме зашифрована только полезная нагрузка, поэтому используется обычная маршрутизация.

    Source: https://www.cloudflare.com/learning/network-layer/what-is-ipsec/
     
    Цитировать   Имя
     
    mrz
    Guest
    #8
    0
    22.05.2023 11:38:00
    Это всё ещё ipsec капсулирование/декапсулирование, и после капсулирования/декапсулирования пакет уже не тот.
     
    Цитировать   Имя
     
    Тимофей Листопадов
    User
    Сообщений: 6 Регистрация: 16.07.2025
    #9
    0
    16.07.2025 10:34:13

    У кого IPsec идёт через не тот интерфейс — причина может быть в метках маршрутизации (routing-mark).

    Решение:
    – Не метьте IPsec-трафик в mangle:

    bash
    КопироватьРедактировать


    /ip firewall mangle
    add chain=prerouting ipsec-policy=out,ipsec action=accept
    add chain=output ipsec-policy=out,ipsec action=accept



    – Сделайте отдельный маршрут до IPsec-пира без меток:

    bash
    КопироватьРедактировать


    /ip route
    add dst-address=1.2.3.4 gateway=10.111.0.1



    Вывод: IPsec и routing-mark — плохо совместимы. Лучше не мешать.

     
    Цитировать   Имя
     
    Страницы: 1
    Ответить
    Читают тему
    BBCode   Правила
    Форма ответов
    Текст сообщения*
    Перетащите файлы
    Ничего не найдено
    Файл
    Загрузить картинки
    #name# #size#
     
    #name#
    Файлы:
    Перетащите один или несколько файлов в эту область
    или выберите файл на компьютере
    Файлы:
    Загрузить файлы
     
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры