Mikrotik pref source что это

Обнаружена блокировка рекламы: Наш сайт существует благодаря показу онлайн-рекламы нашим посетителям. Пожалуйста, подумайте о поддержке нас, отключив блокировщик рекламы на нашем веб-сайте.

2 статических IP Нужен совет

Раздел для тех, кто начинает знакомиться с MikroTik

Правила форума
Как правильно оформить вопрос.
Прежде чем начать настройку роутера, представьте, как это работает. Попробуйте почитать статьи об устройстве интернет-сетей. Убедитесь, что всё, что Вы задумали выполнимо вообще и на данном оборудовании в частности.
Не нужно изначально строить Наполеоновских планов. Попробуйте настроить простейшую конфигурацию, а усложнения добавлять в случае успеха постепенно.
Пожалуйста, не игнорируйте правила русского языка. Отсутствие знаков препинания и неграмотность автора топика для многих гуру достаточный повод проигнорировать топик вообще.

1. Назовите технологию подключения (динамический DHCP, L2TP, PPTP или что-то иное)
2. Изучите темку «Действия до настройки роутера».
viewtopic.php?f=15&t=2083
3. Настройте согласно выбранного Вами мануала
4. Дочитайте мануал до конца и без пропусков, в 70% случаев люди просто не до конца читают статью и пропускают важные моменты.
5. Если не получается, в Winbox открываем терминал и вбиваем там /export hide-sensitive. Результат в топик под кат, интимные подробности типа личных IP изменить на другие, пароль забить звездочками.
6. Нарисуйте Вашу сеть, рисунок (схему) сюда. На словах может быть одно, в действительности другое.

sergrig Сообщения: 0 Зарегистрирован: 29 июн 2017, 16:07

Добрый день
Нужен совет
У нас есть 1 интернет провайдер, который предоставил нам 2 статических IP (например: 10.10.10.2, 10.10.10.3 gateway 10.10.10.1 )
нам надо чтоб половина пользователей работали под 10.10.10.2 а остольные на 10.10.10.3
как правилно организовать

Vladimir22 Сообщения: 561 Зарегистрирован: 09 дек 2012, 17:12
развести пользователей по разным подсетям , и сделать свои правила для каждой подсети .
sergrig Сообщения: 0 Зарегистрирован: 29 июн 2017, 16:07
Сеть должен быть один
gmx Модератор Сообщения: 3250 Зарегистрирован: 01 окт 2012, 14:48
Путем маркировки по адрес листам. Смотрите в фаерволле вкладку mangle.
podarok66 Модератор Сообщения: 4314 Зарегистрирован: 11 фев 2012, 18:49 Откуда: МО

Если шлюз один, то там требуется вдумчивая маркировка, и аккуратность в прописывании маршрутов. Чтобы не оказалось общего для обоих провайдеров роута. В остальном все как обычно — маркируем, маршрутизируем, наслаждаемся.

Мануалы изучил и нигде не ошибся? Фаервол отключил? Очереди погасил? Витая пара проверена? . Тогда Netinstal’ом железку прошей и настрой ее заново. Что, все равно не фурычит? Тогда к нам. Если не подскажем, хоть посочувствуем.

gmx Модератор Сообщения: 3250 Зарегистрирован: 01 окт 2012, 14:48

Да, правда, с одним шлюзом придется повозиться, я как-то не досмотрел в вопросе. Но все равно маркировками.

podarok66 Модератор Сообщения: 4314 Зарегистрирован: 11 фев 2012, 18:49 Откуда: МО

Ну да, что-то подобное есть у меня в ЖЖ http://podarok66.livejournal.com/6901.html Думаю, что ТС разберется с этим.

kin63camapa Сообщения: 2 Зарегистрирован: 19 июл 2017, 15:22

есть похожая ситуация, провайдер дает 2 адреса и 1 шлюз, без проблем удалось настроить тестовую версию на 2 разных порта, НО мне в продакшне нужно бы сделать это на 1 физическом, пробывал добавлять виртуальные эзернеты и в метароутере делать свитч но имхо это изврат, может есть какой то более элегантный способ?

Сейчас конфиг такой:

конфиг

/ip address
add address=192.168.14.1/24 interface=local network=192.168.14.0
add address=192.168.0.80/24 interface=ether1 network=192.168.0.0
add address=192.168.0.81/24 interface=ether2 network=192.168.0.0
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=!192.168.14.0/24 new-routing-mark=isd2 passthrough=no src-address=192.168.14.3
add action=mark-routing chain=prerouting dst-address=!192.168.14.0/24 new-routing-mark=isd1 passthrough=no src-address=192.168.14.2
add action=mark-connection chain=input dst-address=!192.168.0.0/24 new-connection-mark=isp1 passthrough=yes src-address=192.168.0.80
add action=mark-connection chain=input dst-address=!192.168.0.0/24 new-connection-mark=isp2 passthrough=yes src-address=192.168.0.81
add action=mark-routing chain=prerouting connection-mark=isp1 new-routing-mark=isd1 passthrough=yes
add action=mark-routing chain=prerouting connection-mark=isp2 new-routing-mark=isd2 passthrough=yes
/ip firewall nat
add action=masquerade chain=srcnat src-address=192.168.14.0/24
/ip route
add distance=1 gateway=192.168.0.3%ether1 pref-src=192.168.0.81 routing-mark=isd2
add distance=1 gateway=192.168.0.3%ether2 pref-src=192.168.0.80 routing-mark=isd1

MikroTik.by

For every complex problem, there is a solution that is simple, neat, and wrong.

Список форумовФорум по операционной системе MikroTik RouterOSОбщие вопросы
Поиск

Статическая маршрутизация

Базовая функциональность RouterOS

Musulmanin Сообщения: 434 Зарегистрирован: 06 авг 2019, 15:44 Откуда: Оренбург Контактная информация:

Статическая маршрутизация

Сообщение Musulmanin » 14 сен 2019, 19:08

Добрый день!
В каких случаях применять статическую маршрутизацию, а в каких случаях динамическую?
То есть если 2 узла на пример 2 маршрутизатор то тогда что?

Учиться учиться и еще раз учиться!
https://vk.com/orenburgit
Chupaka Сообщения: 3816 Зарегистрирован: 29 фев 2016, 15:26 Откуда: Минск Контактная информация:

Re: Статическая маршрутизация

Сообщение Chupaka » 14 сен 2019, 23:17

Добрый.
А что именно вы собираетесь маршрутизировать? Какие маршруты необходимо добавить статически или динамически?
Но в целом для двух маршрутизаторов, как правило, проще вручную создать пару необходимых маршрутов.

Musulmanin Сообщения: 434 Зарегистрирован: 06 авг 2019, 15:44 Откуда: Оренбург Контактная информация:

Re: Статическая маршрутизация

Сообщение Musulmanin » 15 сен 2019, 14:07

Спасибо гуру!
Статическая маршрутизация. Смысл её использовать в каких случаях её применяют то есть что бы совместно использовать ресурсы какие то?
То есть 2 маршрутизатора между собой должны быть соедененны кабелем допустим витая пара потом настраивается статическая маршрутизация? Или настраивается маршрутизация в случае если отдельно через интеренет?
Заранее благодарен.

Учиться учиться и еще раз учиться!
https://vk.com/orenburgit
kosyak_kpol Сообщения: 67 Зарегистрирован: 12 сен 2019, 22:50 Откуда: Севастополь

Re: Статическая маршрутизация

Сообщение kosyak_kpol » 15 сен 2019, 18:51

Musulmanin, форма заочного обучения, которую вы пытаетесь организовать себе посредством этого форума, злоупотребляя (на мой взгляд) терпением Chupaka, уж точно не будет эффективной. Не сочтите за дерзость, но осмелюсь дать вам совет больше читать:

— здесь, например, хорошо изложены основы статической маршрутизации (не знаю, нужны они вам или нет):
https://habr.com/ru/post/443788/
Основы статической маршрутизации в Mikrotik RouterOS _ Хабр

— здесь — очень доступно о принципах работы пакетного фильтра:
https://habr.com/ru/post/435070/
Введение в Layer 3 Firewall MikroTik _ Хабр

— в профиле автора найдёте ещё много интересного в аспекте эффективного использования RouterOS. Люди же стараются, делятся своими знаниями и опытом, ещё и на русском языке, ещё и безвозмездно!

— здесь, — «хорошая практика» использования принципов статической маршрутизации:
https://habr.com/ru/post/463813/
Мультиван и маршрутизация на Mikrotik RouterOS _ Хабр

P.S. я сам весьма поверхностно знаком с сетевыми технологиями. Но, Musulmanun, когда читал ваши вопросы, первое, что пришло в голову, — на форуме завёлся опытный тролль.

P.S. от 26.06.2020. Все ссылки в этом посте «канули в Лету». Поэтому, заинтересованным, — доступ к упомянутым статьям Bulroh здесь:
https://kosyak.synology.me:10003/d/s/56 . begg9P1-wg

Последний раз редактировалось kosyak_kpol 29 ноя 2021, 22:05, всего редактировалось 5 раз.

Musulmanin Сообщения: 434 Зарегистрирован: 06 авг 2019, 15:44 Откуда: Оренбург Контактная информация:

Re: Статическая маршрутизация

Сообщение Musulmanin » 15 сен 2019, 19:41

Добрый день! Я не тролль, просто там написано как то не понятно.
Учиться учиться и еще раз учиться!
https://vk.com/orenburgit
kosyak_kpol Сообщения: 67 Зарегистрирован: 12 сен 2019, 22:50 Откуда: Севастополь

Re: Статическая маршрутизация

Сообщение kosyak_kpol » 15 сен 2019, 21:32

Musulmanin писал(а): ↑ 15 сен 2019, 19:41 Добрый день! Я не тролль, просто там написано как то не понятно.

Очень хочется верить людям

Предположим, вы читаете статью по первой моей ссылке и вам что-то не очень понятно. Эта статья — квинтэссенция вопроса статической маршрутизации! Там каждое предложение, каждый абзац, диаграмма или пример — буквально, — на вес золота! Но читать её нужно вдумчиво, анализируя и обдумывая написанное. Это не стёб!
Если что-либо НЕ понятно, то нужно «откатываться» на изучение непонятного вопроса. Вплоть до того, что перечитывать базовые понятия типа принципов IP-адресации или модели OSI (в альтернативных источниках информации). Тогда ваша «картина мира» будет вырисовываться более чётко. Я сам так поступаю.
И ещё, — вам нужна четко сформулированная практическая задача (роутер Mikrotik, я понимаю, у вас есть). Если вы — самоучка, не начинайте со сложных гипотетических задач, имхо, — это неправильно. Сформулируйте сами себе какую-нибудь простую задачу и решайте её, максимально подробно «начитывая» и «ковыряя» каждый этап: создание интерфейсов, DHCP-сервера, DHCP-клиента, файервола и т.п. Затем усложните задачу: добавьте, например, второго провайдера или VPN-сервер. И всё так же «ковыряйте» каждый этап.

Завтра, возможно, накидаю ссылок на полезные ресурсы.

P.S. У модератора прошу прощения за флуд. Больше не буду умничать в чужой теме

Musulmanin Сообщения: 434 Зарегистрирован: 06 авг 2019, 15:44 Откуда: Оренбург Контактная информация:

Re: Статическая маршрутизация

Сообщение Musulmanin » 15 сен 2019, 21:41

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

Re: Статическая маршрутизация

Сообщение kosyak_kpol » 15 сен 2019, 22:22

Я не вижу конкретики в вашем вопросе. Поэтому додумаю за вас пример.

У вас есть два маршрутизатора, смотрящих в Интернет. Между маршрутизаторами VPN-тоннель. Один маршрутизатор является сервером, а другой клиентом. Например, вы хотите объединить локальные сети, расположенные за маршрутизаторами (site-to-site). Тогда вам потребуется на каждом из маршрутизаторов прописать маршрут к шлюзу в удалённую локальную сеть. Этим шлюзом будет адрес маршрутизатора на дальнем конце тоннеля.

Так вот, если у вас простая схема, в которой небольшое количество узлов (в нашем примере — два узла), то статическая маршрутизация вполне подойдёт. А если схема сети сложная (много узлов, многочисленные связи между узлами, требования обеспечения связности сети при отказе каналов), то эффективное решение этой задачи лежит через использование протоколов динамической маршрутизации.

Musulmanin Сообщения: 434 Зарегистрирован: 06 авг 2019, 15:44 Откуда: Оренбург Контактная информация:

Re: Статическая маршрутизация

Сообщение Musulmanin » 15 сен 2019, 22:26

Добрый день! Понял только что при большом количестве необходимо использовать динамическую маршрутизацию.
При статической маршрутизации, что необходимо настраивать VPN?

Re: Статическая маршрутизация

Сообщение kosyak_kpol » 15 сен 2019, 23:06

«Огласите весь список, пожалуйста» (с) — х\ф «Напарник». Какая перед вами стоит задача?

Статическая маршрутизация — это технология передачи пакетов между хостами, расположенными в отдельных сетях уровня L2. Читайте внимательно https://habr.com/ru/post/443788/
Цитирую:
«Маршрутизация — процесс передачи пакетов между Layer2 сегментами. Если устройство хочет отправить пакет, получатель которого находится за пределами Ethernet сегмента, оно смотрит в свою таблицу маршрутизации и передает пакет шлюзу, который знает куда отправить пакет дальше (а может и не знает, изначальный отправитель пакета про это не осведомлен).
Проще всего рассматривать маршрутизатор, как устройство подключенное к двум или более Layer2 сегментам и способное передавать пакеты между ними определяя оптимальный маршрут по таблице маршрутизации.»

Совершенно НЕ обязательно, чтобы между этими сетями существовал VPN-канал.

Musulmanin Сообщения: 434 Зарегистрирован: 06 авг 2019, 15:44 Откуда: Оренбург Контактная информация:

Re: Статическая маршрутизация

Сообщение Musulmanin » 15 сен 2019, 23:12

Доброй ночи!
Хочу понять разницу между статической маршрутизацией и VPN?
Учиться учиться и еще раз учиться!
https://vk.com/orenburgit
kosyak_kpol Сообщения: 67 Зарегистрирован: 12 сен 2019, 22:50 Откуда: Севастополь

Re: Статическая маршрутизация

Сообщение kosyak_kpol » 15 сен 2019, 23:22

Приведу наглядный пример:
Ваш домашний роутер подключен к провайдеру Интернет по технологии IPoE. Т.е. между вами, как клиентом, и провайдером, как сервером доступа НЕТ никакого VPN-а. Тем не менее, когда вы с домашнего компьютера выходите в Интернет (например, — пингуете 8.8.8.8), то делаете это посредством статического маршрута в сеть 0.0.0.0/0 через шлюз вашего провайдера на WAN-интерфейсе роутера (при его типовых настройках). Этот маршрут имеется в main-таблице статической маршрутизации вашего роутера.

Последний раз редактировалось kosyak_kpol 18 сен 2019, 09:57, всего редактировалось 2 раза.

Musulmanin Сообщения: 434 Зарегистрирован: 06 авг 2019, 15:44 Откуда: Оренбург Контактная информация:

Re: Статическая маршрутизация

Сообщение Musulmanin » 15 сен 2019, 23:26

У меня VPN Настроен PPPoE и с помощью его я выхожу в инет, то есть доступа к ресурсам провайдера у меня нету.
Что то я запутался.

Re: Статическая маршрутизация

Сообщение kosyak_kpol » 15 сен 2019, 23:45

Musulmanin писал(а): ↑ 15 сен 2019, 23:12 Доброй ночи!
Хочу понять разницу между статической маршрутизацией и VPN?

VPN никак не влияет на логику маршрутизации. Задача роутера — отправить пакет по выбранному маршруту. Маршрут, в свою очередь, уже может быть связан или с физическим интерфейсом, например, или логическим VPN-интерфейсом, — это не суть важно. Рассматривайте VPN просто как способ организации логического канала связи.

Основная масса типов VPN-каналов работает на L3, поэтому требуют маршрутизации как на стороне сервера, так и на стороне клиента. Возможно, какие-то типы VPN и позволяют связать сети на L2 уровне, но я не знаю.

kosyak_kpol Сообщения: 67 Зарегистрирован: 12 сен 2019, 22:50 Откуда: Севастополь

Re: Статическая маршрутизация

Сообщение kosyak_kpol » 15 сен 2019, 23:55

Musulmanin писал(а): ↑ 15 сен 2019, 23:26 У меня VPN Настроен PPPoE и с помощью его я выхожу в инет, то есть доступа к ресурсам провайдера у меня нету.
Что то я запутался.

Хорошо, у вас вместо IPoE провайдер использует PPPoE. Это не отменяет наличия маршрута в сеть 0.0.0.0/0 через шлюз на интерфейсе PPPoE.
Смотрите таблицу маршрутизации вашего роутера и найдёте там этот маршрут. Вот послушайте меня буквально. Читайте статью по первой ссылке и параллельно смотрите в настройки своего роутера. Станет более понятно! Статья — как дешифровальная машина даст вам понимание «зашифрованных» таблиц вашего Mikrotika.

Последний раз редактировалось kosyak_kpol 18 сен 2019, 09:47, всего редактировалось 2 раза.

Musulmanin Сообщения: 434 Зарегистрирован: 06 авг 2019, 15:44 Откуда: Оренбург Контактная информация:

Re: Статическая маршрутизация

Сообщение Musulmanin » 16 сен 2019, 00:04

Re: Статическая маршрутизация

Сообщение kosyak_kpol » 16 сен 2019, 00:07

Musulmanin, вы понимаете, что означает адрес 0.0.0.0/0 в маршруте из примера? Это, чтобы и мне понимать.

Последний раз редактировалось kosyak_kpol 18 сен 2019, 09:47, всего редактировалось 1 раз.

Musulmanin Сообщения: 434 Зарегистрирован: 06 авг 2019, 15:44 Откуда: Оренбург Контактная информация:

Re: Статическая маршрутизация

Сообщение Musulmanin » 16 сен 2019, 00:09

Да все IP адреса.
Учиться учиться и еще раз учиться!
https://vk.com/orenburgit

Musulmanin Сообщения: 434 Зарегистрирован: 06 авг 2019, 15:44 Откуда: Оренбург Контактная информация:

Re: Статическая маршрутизация

Сообщение Musulmanin » 16 сен 2019, 00:10

Вот то ест ьмаршрут номер один от моего IP адреса на все IP адреса.
Вложения ip.PNG (14.74 КБ) 2260 просмотров
Учиться учиться и еще раз учиться!
https://vk.com/orenburgit
kosyak_kpol Сообщения: 67 Зарегистрирован: 12 сен 2019, 22:50 Откуда: Севастополь

Re: Статическая маршрутизация

Сообщение kosyak_kpol » 16 сен 2019, 08:51

Да.
Два других маршрута — к сетям, доступным непосредственно на интерфейсах маршрутизатора:
Второй — к VPN-сети провайдера. Ваш ip-адрес в этой сети: 188.168.179.
Третий — к вашей локальной сети: 192.168.88.0/24, которая доступна через интерфейс bridge с адресом 192.168.88.1

Последний раз редактировалось kosyak_kpol 16 сен 2019, 12:03, всего редактировалось 1 раз.

Musulmanin Сообщения: 434 Зарегистрирован: 06 авг 2019, 15:44 Откуда: Оренбург Контактная информация:

Re: Статическая маршрутизация

Сообщение Musulmanin » 16 сен 2019, 09:26

Читал вот что написано.
Практически весь функционал относящийся к статической маршрутизации находится в пакете system.
Но у меня это в другой вкладке статическая маршрутизация?
Два других маршрута — к сетям, доступным непосредственно на интерфейсах маршрутизатора:
Вот это не понял?

Re: Статическая маршрутизация

Сообщение kosyak_kpol » 16 сен 2019, 10:05

Musulmanin писал(а): ↑ 16 сен 2019, 09:26 Практически весь функционал относящийся к статической маршрутизации находится в пакете system.
Но у меня это в другой вкладке статическая маршрутизация?

Здесь имеется в виду системный пакет System, который реализует статическую маршрутизацию. Посмотреть состав установленных пакетов в вашем роутере можно в табличке System->Packages->Package List. Собственно, пакеты в этой табличке и являются «прошивкой» вашего роутера. Т.е. базовая маршрутизация доступна в роутере «из коробки». А если нужен функционал расширенной маршрутизации, то требуется дополнительно установить (если не установлен) пакет Routing.

Musulmanin Сообщения: 434 Зарегистрирован: 06 авг 2019, 15:44 Откуда: Оренбург Контактная информация:

Re: Статическая маршрутизация

Сообщение Musulmanin » 16 сен 2019, 10:12

Это пакет установлен, мне до сих пор не понятно в чем будет различие между VPN и настройкой маршртизации? Можно объяснить пожалуйста. Заранее благодарен.

Re: Статическая маршрутизация

Сообщение kosyak_kpol » 16 сен 2019, 10:26

Musulmanin писал(а): ↑ 16 сен 2019, 09:26 Два других маршрута — к сетям, доступным непосредственно на интерфейсах маршрутизатора:
Вот это не понял?

У вас в роутере установлен клиент PPPoE? Установлен. Этот клиент реализует свой логический интерфейс pppoe-out1. Через этот интерфейс ваш роутер, собственно, и подключен к провайдеру Интернет и обеспечивает «выход в Интернет». На этот интерфейс провайдер вам назначил IP-адрес: 188.168.179.(дальше не видно на скриншоте). И этот адрес провайдером включён в сеть, реализующую VPN-PPPoE. Эта сеть обычно состоит всего из двух хостов — вашего роутера и провайдерского сервера PPPoE. Т.е. — имеет маску 30. И эта сеть непосредственно доступна на интерфейсе pppoe-out1. Если вы пропингуете адрес 188.168.180.1, то пакеты пинга пройдут по маршруту №2 в таблице маршрутизации.

То же и с интерфейсом bridge. Бриджу у вас назначен IP-адрес: 192.168.88.1 и через этот интерфейс доступна ваша локальная сеть: 192.168.88.0/24. Т.е., если на роутер поступит пакет с адресом назначения, например, 192.168.88.12, то он отправит его по маршруту №3.

Заметьте, что на этих маршрутах роутер взвёл флаги DAC и установил параметр Distance=0

P.S. от 18.09.2019
Исправлю ошибку. Так как PPPoE-подключение — типа «точка-точка», то хосты в нём меют маску 32, а не 30. То есть, Dst. Address в маршруте #2 — это хост: 188.168.180.1/32

Последний раз редактировалось kosyak_kpol 18 сен 2019, 09:55, всего редактировалось 1 раз.

Musulmanin Сообщения: 434 Зарегистрирован: 06 авг 2019, 15:44 Откуда: Оренбург Контактная информация:

MikroTik, Настройка и установка оборудования , Практика и программирование

Ситуация, когда доступны несколько провайдеров не нова, MikroTik Router OS позволяет настроить доступ сразу по нескольким сетевым интерфейсам, а так же настроить балансировку нагрузки в зависимости от ограничений, которые выставляет провайдер.

Первым шагом настроим дополнительный интерфейс. Инициализируем сам интерфейс.

[mkt@MikroTik] /interface> print Flags: D - dynamic, X - disabled, R - running, S - slave # NAME TYPE MTU 0 R ether1 ether 1500 1 R ether2 ether 1500 2 X ether3 ether 1500 [mkt@MikroTik] /interface> enable 2 [mkt@MikroTik] /interface> print Flags: D - dynamic, X - disabled, R - running, S - slave # NAME TYPE MTU 0 R ether1 ether 1500 1 R ether2 ether 1500 2 R ether3 ether 1500

Для удобства задаем более понятные имена интерфейсам.

[mkt@MikroTik] /interface> set ether1 name="ISP1" [mkt@MikroTik] /interface> set ether2 name="LOCAL" [mkt@MikroTik] /interface> set ether3 name="ISP2" [mkt@MikroTik] /interface> print Flags: D - dynamic, X - disabled, R - running, S - slave # NAME TYPE MTU 0 R ISP1 ether 1500 1 R LOCAL ether 1500 2 R ISP2 ether 1500

Теперь назначим IP адрес новому интерфейсу.

[mkt@MikroTik] > ip address add address=192.168.222.100/24 interface=ISP2 [mkt@MikroTik] > ip address print Flags: X - disabled, I - invalid, D - dynamic # ADDRESS NETWORK BROADCAST INTERFACE 0 192.168.1.116/24 192.168.1.0 192.168.1.255 ISP1 1 192.168.0.1/24 192.168.0.0 192.168.0.255 LOCAL 2 192.168.222.100/24 192.168.222.0 192.168.222.255 ISP2

Настало время изменить маршрутизацию по умолчанию. Для начала, допустим, что оба провайдера предоставляют одинаковую скорость доступа к сети Internet, значит настроим балансировку (это когда для исходящих соединений каналы чередуются), так что бы запросы распеределялись равномерно, т.е. 50/50. Прежде всего удалим старый шлюз по умолчанию.

[mkt@MikroTik] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 A S 0.0.0.0/0 192.168.1.249 r. 1 1 ADC 192.168.0.0/24 192.168.0.1 LOCAL 0 2 ADC 192.168.1.0/24 192.168.1.116 ISP1 0 3 ADC 192.168.222.0/24 192.168.222.100 ISP2 0 [mkt@MikroTik] > ip route remove 0 [mkt@MikroTik] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADC 192.168.0.0/24 192.168.0.1 LOCAL 0 1 ADC 192.168.1.0/24 192.168.1.116 ISP1 0 2 ADC 192.168.222.0/24 192.168.222.100 ISP2 0

И добавим новые.

[mkt@MikroTik] > ip route add dst-address=0.0.0.0/0 gateway=192.168.1.249,192.168.222.1 [mkt@MikroTik] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 A S 0.0.0.0/0 192.168.1.249 r. 1 192.168.222.1 r. 1 ADC 192.168.0.0/24 192.168.0.1 LOCAL 0 2 ADC 192.168.1.0/24 192.168.1.116 ISP1 0 3 ADC 192.168.222.0/24 192.168.222.100 ISP2 0

Допустим,что у первого провайдера скорость доступа в два раза выше чем у второго, тогда 2/3 исходящих запросов надо направить на первого, а оставшиеся 1/3 на второго.

[mkt@MikroTik] > ip route add dst-address=0.0.0.0/0 gateway=192.168.1.249,192.168.1.249,192.168.222.1 [mkt@MikroTik] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 A S 0.0.0.0/0 192.168.222.1 r. 1 192.168.1.249 r. 192.168.1.249 r. 1 ADC 192.168.0.0/24 192.168.0.1 LOCAL 0 2 ADC 192.168.1.0/24 192.168.1.116 ISP1 0 3 ADC 192.168.222.0/24 192.168.222.100 ISP2 0

Это самый простой вариант конфигурации, в котором мы получаем доступ к Интернету с балансировкой нагрузки, но у этого подхода есть ряд недостатков, например, доступ через локальный NAT к локальному серверу (web, smtp, pop services, которые были настроены ранее) не работа, но не такая большая проблема, но об этом в следующий раз. После добавления второго провайдера в нашу тестовую конфигурацию возникла проблема с ответом определенных служб на желаемом канале, если вы обращаетесь к ним извне через NAT. Например, веб-сервер, выведенный через NAT на IP-адрес первого провайдера, получает запрос, но вероятность того, что ответ пройдет по нужному каналу, больше не равна 100%. Что это за веб-сервер после этого? Механизм маркировки пакетов поможет нам решить эту проблему. Таблица MANGLE предназначена для классификации и маркировки пакетов и соединений, а также для изменения заголовков пакетов. В частности, нас интересует цепочка PREROUTING, которая позволяет пометить пакет перед маршрутизацией. Попробуем разобраться с веб-сервером.

Допустим, мы настроили порт NAT 80 с внешнего IP-адреса 192.168.1.116 (ISP1, первый поставщик) на порт 80 веб-сервера в локальной сети, и нам нужно убедиться, что все ответы, которые будут отправляться с веб-сервера, будут проходить до шлюза первого провайдера. Вот правило для таблицы NAT.

[mkt@MikroTik] > ip firewall nat add chain=dstnat dst-address=192.168.1.116 protocol=tcp dst-port=80 action=dst-nat to-addresses=192.168.0.2 to-ports=80 comment="NAT 80 port from ISP1 to local web server" [mkt@MikroTik] > ip firewall nat print Flags: X - disabled, I - invalid, D - dynamic 0 chain=srcnat action=masquerade out-interface=!LOCAL 1 ;;; NAT 80 port from ISP1 to local web server chain=dstnat action=dst-nat to-addresses=192.168.0.2 to-ports=80 protocol=tcp dst-address=192.168.1.116 dst-port=80

Первым делом создадим правило в таблице MANGLE.

[mkt@MikroTik] > ip firewall mangle add chain=prerouting src-address=192.168.0.2 protocol=tcp src-port=80 action=mark-routing new-routing-mark=to-isp1 [mkt@MikroTik] > ip firewall mangle print Flags: X - disabled, I - invalid, D - dynamic 0 chain=prerouting action=add-src-to-address-list protocol=tcp address-list=test_list address-list-timeout=0s dst-port=23 1 chain=prerouting action=mark-routing new-routing-mark=to-isp1 passthrough=yes protocol=tcp src-address=192.168.0.2 src-port=80

Пакеты с локального адреса 192.168.0.2 с 80 порта буду маркироваться как to-isp1. Затем добавим правило в таблицу маршрутизации.

[mkt@MikroTik] > ip route add gateway=192.168.1.249 routing-mark=to-isp1 [mkt@MikroTik] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 A S 0.0.0.0/0 192.168.1.249 r. 1 1 A S 0.0.0.0/0 192.168.1.249 r. 1 192.168.1.249 r. 192.168.222.1 r. 2 ADC 192.168.0.0/24 192.168.0.1 LOCAL 0 3 ADC 192.168.1.0/24 192.168.1.116 ISP1 0 4 ADC 192.168.222.0/24 192.168.222.100 ISP2 0

Все, что идет с токеном to-isp1, отправляется на шлюз первого провайдера. Теперь давайте усложним ситуацию, скажем, второй провайдер предоставит на выгодных условиях большую локальную сеть по всему городу, и через эту сеть все 10 филиалов вашей компании объединятся. Все филиалы и офисы используют один и тот же сайт, но какой смысл обращаться к нему через первого провайдера, когда вы можете настроить доступ к нему почти локально. Прежде всего, мы добавляем правило к таблице NAT, согласно которому все запросы, поступившие на внешний IP-адрес, предоставленный вторым провайдером, будут перенаправлены на порт 80 локального порта веб-сервера.

[mkt@MikroTik] > ip firewall nat add chain=dstnat dst-address=192.168.222.100 protocol=tcp dst-port=80 action=dst-nat to-addresses=192.168.0.2 to-ports=80 comment="NAT 80 port from ISP2 to local web server" [mkt@MikroTik] > ip firewall nat print Flags: X - disabled, I - invalid, D - dynamic 0 chain=srcnat action=masquerade out-interface=!LOCAL 1 ;;; NAT 80 port from ISP1 to local web server chain=dstnat action=dst-nat to-addresses=192.168.0.2 to-ports=80 protocol=tcp dst-address=192.168.1.116 dst-port=80 2 ;;; NAT 80 port from ISP2 to local web server chain=dstnat action=dst-nat to-addresses=192.168.0.2 to-ports=80 protocol=tcp dst-address=192.168.222.100 dst-port=80

Следующим шагом добавим в таблицу MANGLE еще одно правило:

[mkt@MikroTik] > ip firewall mangle add chain=prerouting src-address=192.168.0.2 protocol=tcp src-port=80 dst-address=192.168.222.0/24 action=mark-routing new-routing-mark=to-isp2 [mkt@MikroTik] > ip firewall mangle print Flags: X - disabled, I - invalid, D - dynamic 0 chain=prerouting action=add-src-to-address-list protocol=tcp address-list=test_list address-list-timeout=0s dst-port=23 1 chain=prerouting action=mark-routing new-routing-mark=to-isp2 passthrough=yes protocol=tcp src-address=192.168.0.2 dst-address=192.168.222.0/24 src-port=80 2 chain=prerouting action=mark-routing new-routing-mark=to-isp1 passthrough=yes protocol=tcp src-address=192.168.0.2 src-port=80

Пакеты с локального адреса 192.168.0.2 из порта 80 будут помечены как to-isp2, если они предназначены для подсети второго провайдера. Ну и в заключение, правило в таблице маршрутизации:

[mkt@MikroTik] > ip route add gateway=192.168.222.1 routing-mark=to-isp2 [mkt@MikroTik] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 A S 0.0.0.0/0 192.168.1.249 r. 1 1 A S 0.0.0.0/0 192.168.222.1 r. 1 2 A S 0.0.0.0/0 192.168.1.249 r. 1 192.168.1.249 r. 192.168.222.1 r. 3 ADC 192.168.0.0/24 192.168.0.1 LOCAL 0 4 ADC 192.168.1.0/24 192.168.1.116 ISP1 0 5 ADC 192.168.222.0/24 192.168.222.100 ISP2 0

Теперь на запросы, полученные от первого провайдера, будет отвечать шлюз первого провайдера, а на запросы от второго провайдера и из подсети второго провайдера будет отвечать шлюз второго провайдера.

Основы статической маршрутизации в Mikrotik RouterOS

Маршрутизация — процесс поиска оптимального пути для передачи пакетов в сетях TCP/IP. Любой устройство подключенное к сети IPv4 содержит процесс и таблицы маршрутизации.

Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор – официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.

Данная статья не является HOWTO, она описывает на примерах статическую маршрутизацию в RouterOS, я намеренно опускал остальные настройки (например srcnat для доступа в сеть интернет), поэтому для понимания материала требуется определенный уровень знания по сетям и RouterOS.

Коммутация и маршрутизация

Коммутация — процесс обмена пакетами в пределах одного Layer2 сегмента (Ethernet, ppp, . ). Если устройство видит, что получатель пакета находится с ним в одной Ethernet подсети, оно узнает mac адрес по протоколу arp и передает пакет напрямую, минуя маршрутизатор. У ppp (point-to-point) соединения может быть только два участника и пакет всегда отправляется на один адрес 0xff.

Маршрутизация — процесс передачи пакетов между Layer2 сегментами. Если устройство хочет отправить пакет, получатель которого находится за пределами Ethernet сегмента, оно смотрит в свою таблицу маршрутизации и передает пакет шлюзу, который знает куда отправить пакет дальше (а может и не знает, изначальный отправитель пакета про это не осведомлен).

Проще всего рассматривать маршрутизатор, как устройство подключенное к двум или более Layer2 сегментам и способное передавать пакеты между ними определяя оптимальный маршрут по таблице маршрутизации.

Если вам все понятно или вы и так это знали, то читайте дальше. Остальным настоятельно рекомендую ознакомиться с маленькой, но очень емкой статьей.

Маршрутизация в RouterOS и PacketFlow

Практически весь функционал относящийся к статической маршрутизации находится в пакете system. Пакет routing добавляет поддержку алгоритмов динамической маршрутизации (RIP, OSPF, BGP, MME), Routing Filters и BFD.

Основное меню для настройки маршрутизации: [IP]->[Route] . Сложные схемы могут потребовать предварительную маркировку пакетов маршрутной меткой в: [IP]->[Firewall]->[Mangle] (цепочки PREROUTING и OUTPUT ).

На PacketFlow можно выделить три места, где принимаются решения о маршрутизации IP пакетов:

Маршрутизация пакетов поступивших на роутер. На данном этапе решается уйдет пакет локальному процессу или будет отправлен дальше в сеть. Транзитные пакеты получают Output Interface
Маршрутизация локальных исходящих пакетов. Исходящие пакеты получают Output Interface
Дополнительный этап маршрутизации для исходящих пакетов, позволяет изменить решение о маршрутизации в [Output|Mangle]

Путь пакета в блоках 1, 2 зависит от правил в [IP]->[Route]
Путь пакета в пунктах 1, 2 и 3 зависит от правил в [IP]->[Route]->[Rules]
На путь пакета в блоках 1, 3 можно повлиять используя [IP]->[Firewall]->[Mangle]

RIB, FIB, Routing Cache

Routing Information Base
База в которой собираются маршруты от протоколов динамической маршрутизации, маршруты от ppp и dhcp, статические и подключенные (connected) маршруты. Данная база содержит все маршруты, за исключением отфильтрованных администратором.

Условно, можно считать что [IP]->[Route] отображает RIB.

Forwarding Information Base

База в которой собираются наилучшие маршруты из RIB. Все маршруты в FIB являются активными и используются для пересылки пакетов. Если маршрут становится неактивным (отключен администратором (системой), или интерфейс через который должен отправляться пакет не активен) маршрут удаляется из FIB.

Для принятия решения о маршрутизации в таблице FIB используются следующие данные о IP пакете:

Source Address
Destination Address
Source Interface
Routing mark
ToS (DSCP)

Попадая в FIB пакет проходит следующие стадии:

Пакет предназначен локальному процессу роутера?
Пакет попадает под системные или пользовательские правила PBR?
- Если да, то пакет отправляется в указанную таблицу маршрутизации
Условно, можно считать что [IP]->[Route Active=yes] отображает FIB.

Routing Cache
Механизм кэширования маршрутов. Маршрутизатор запоминает куда были отправлены пакеты и если встречаются похожие (предположительно из одного соединения) пускает их по тому-же маршруту, без проверки в FIB. Кэш маршрутов периодически очищается.

Для администраторов RouterOS не сделали средств просмотра и управления Routing Cache, но при его можно отключить в [IP]->[Settings] .

Данный механизм был удален из ядра linux 3.6, но в RouterOS до сих пор используется kernel 3.3.5, возможно Routing cahce — одна из причин.

Диалог добавления маршрута

[IP]->[Route]->[+]
1. Подсеть для которой необходимо создать маршрут (по умолчанию: 0.0.0.0/0)
2. IP шлюза или интерфейс на который будет отправлен пакет (может быть несколько, см. ниже ECMP)
3. Проверка доступности шлюза
4. Тип записи
5. Дистанция (метрика) для маршрута
6. Таблица маршрутизации
7. IP для локальных исходящих пакетов через данный маршрут
8. Про назначение Scope и Target Scope написано в конце статьи
Флаги маршрутов
- X — Маршрут отключен администратором ( disabled=yes )
- A — Маршрут используется для передачи пакетов
- D — Маршрут добавлен динамически (BGP, OSPF, RIP, MME, PPP, DHCP, Connected)
- C — Подсеть подключена непосредственно к маршрутизатору
- S — Статический маршрут
- r,b,o,m — Маршрут добавлен одним из протоколов динамической маршрутизации
- B,U,P — Фильтрующий маршрут (отбрасывает пакеты вместо передачи)
Что указывать в gateway: ip-адрес или интерфейс?

Система позволяет указывать и то, и другое, при этом не ругается и не дает подсказок, если вы что-то сделали неправильно.

IP адрес
Адрес шлюза должен быть доступен по Layer2. Для Ethernet это означает, что роутер должен иметь на одном из активных интерфейсов ip адрес из той же подсети, для ppp — что адрес gateway указан на одном из активных интерфейсов в качестве адреса подсети.
Если условие доступности по Layer2 не выполняется — маршрут считается неактивным и не попадает в FIB.

Интерфейс
Все сложнее и поведение маршрутизатора зависит от типа интерфейса:
- PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*) соединение предполагает наличие только двух участников и пакет всегда будет направлен шлюзу для передачи, если шлюз обнаружит, что получателем является он сам, то передаст пакет своему локальному процессу.
- Ethernet предполагает наличие множества участников и будет отправлять на интерфейс arp запросы с адресом получателя пакета, это ожидаемое и вполне нормальное поведение для connected маршрутов.
  Но при попытке использовать интерфейс в качестве маршрута для удаленной подсети вы получите следующую ситуацию: маршрут активен, ping до шлюза проходит, но не доходят до получателя из указанной подсети. Если посмотрите на интерфейс через сниффер, то увидите arp запросы с адресами из удаленной подсети.
Старайтесь указывать ip адрес в качестве gateway всегда когда это возможно. Исключение — connected маршруты (создаются автоматически) и PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*) интерфейсы.

OpenVPN не содержит PPP заголовка, но можно использовать имя OpenVPN интерфейса для создания маршрута.

More Specific Route

Основное правило маршрутизации. Маршрут описывающий более маленькую подсеть (с наибольшей маской подсети) имеет больший приоритет при принятии решения о маршрутизации пакета. Положение записей в таблице маршрутизации не имеет отношения к выбору — основное правило More Specific.

Все маршруты из указанной схемы активны (находятся в FIB), т.к. указывают на различные подсети и не конфликтуют между собой.

Если один из шлюзов станет недоступным, связанный маршрут будет считаться неактивным (удален из FIB) и для пакетов будет производиться поиск из оставшихся маршрутов.

Маршруту с подсетью 0.0.0.0/0 иногда придают особое значение и называют «Маршрут по умолчанию» (Default Route) или «Шлюз последней надежды» (gateway of last resort). На самом деле в нем нет ничего магического и он просто включает все возможные адреса IPv4, но данные названия хорошо описывают его задачу — он указывает на шлюз, куда пересылать пакеты для которых нет других, более точных, маршрутов.

Максимально возможная маска подсети для IPv4 — /32, такой маршрут указывает на конкретный хост и может использоваться в таблице маршрутизации.

Понимание More Specific Route является фундаментальным для любых устройств работающих с TCP/IP.

Distance

Дистанции (или Метрики) необходимы для административной фильтрации маршрутов до одной подсети доступной через несколько шлюзов. Маршрут с меньшей метрикой считается приоритетным и попадет в FIB. Если маршрут с меньшей метрикой перестанет быть активным, то в FIB он будет заменен на маршрут с большей метрикой.

Если присутствует несколько маршрутов до одной подсети с одинаковой метрикой, маршрутизатор добавить в таблицу FIB только один из них, руководствуясь своей внутренней логикой.

Метрика может принимать значение от 0 до 255:
- 0 — Метрика для подключенных (connected) маршрутов. Дистанция 0 не может быть выставлена администратором
- 1-254 — Метрики доступные администратору для установки маршрутам. Метрики с меньшим значением имеют больший приоритет
- 255 — Метрика доступная администратору для установки маршрутам. В отличии от 1-254, маршрут с метрикой 255 всегда остается неактивным и не попадает в FIB
- Особые метрики. У маршрутов полученных от протоколов динамической маршрутизации, есть стандартные значения метрик
Check gateway

Check gateway — расширение MikroTik RoutesOS для проверки доступности шлюза по icmp или arp. Раз в 10 секунд (изменить нельзя) на шлюз отправляется запрос, если дважды не приходит ответ маршрут считается недоступным и удаляется из FIB. Если check gateway отключил маршрут проверки продолжается и маршрут снова станет активным после одной успешной проверки.

Check gateway отключает запись, в которой он настроен и все остальные записи (во всех таблицах маршрутизации и ecmp маршрутах) с указанным шлюзом.

В целом check gateway работает нормально, если не возникает проблем с потерей пакетов до шлюза. Check gateway не знает, что происходит со связью за пределами проверяемого шлюза, для этого необходимы дополнительные инструменты: скрипты, рекурсивная маршрутизация, протоколы динамической маршрутизации.

Большинство VPN и туннельных протоколов содержат встроенные средства для проверки активности соединения, включать для них check gateway — это дополнительная (но очень маленькая) нагрузка на сеть и производительность устройства.

ECMP маршруты

Equal-Cost Multi-Path — отправка пакетов до получателя используя одновременно несколько шлюзом с перебором по алгоритму Round Robin.

ECMP маршрут создается администратором, путем указания нескольких gateway для одной подсети (либо автоматический, при наличии двух равноценных маршрутов OSPF).

ECMP используется для балансировки нагрузки между двумя каналами, в теории, если в ecmp маршруте два канала, то для каждого пакета исходящий канал должен отличаться. Но механизм Routing cache отправляет пакеты из соединения по маршруту, которым пошел первый пакет, в итоге получаем подобие балансировки на базе соединений (per-connection loading balancing).

Если отключить Routing Cache, то пакеты в ECMP маршруте будут делиться правильно, но возникает проблема с NAT. Правило NAT обрабатывает только первый пакет из соединения (остальные обрабатываются автоматически) и получается ситуация, что с различных интерфейсов уходят пакеты с одним адресом источника.

В ECMP маршрутах не работает check gateway (баг RouterOS). Но можно обойти это ограничение, если создать дополнительные маршруты для проверки, которые будут отключать записи в ECMP.

Фильтрация средствами Routing

Опция Type определяет, что сделать с пакетом:
- unicast — отправить на указанный шлюз (интерфейс)
- blackhole — отбросить пакет
- prohibit, unreachable — отбросить пакет и отправить icmp сообщение отправителю
Фильтрацию обычно используют, когда нужно обезопасить отправку пакетов не по тому пути, конечно можно фильтровать подобное через firewall.

Пара примеров

Для закрепления базовых вещей о маршрутизации.

Типичный домашний роутер
```
/ip route add dst-address=0.0.0.0/0 gateway=10.10.10.1
```
1. Статический маршрут до 0.0.0.0/0 (default route)
2. Connected маршрут на интерфейсе с провайдером
3. Connected маршрут на интерфейсе с локальной сетью
Типичный домашний роутер с PPPoE
1. Статический маршрут до default route, добавлен автоматически т.к. это указано в свойствах подключения
2. Connected маршрут для PPP соединения
3. Connected маршрут на интерфейсе с локальной сетью
Типичный домашний роутер с двумя провайдерами и резервированием
```
/ip route add dst-address=0.0.0.0/0 gateway=10.10.10.1 distance=1 check-gateway=ping add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2
```
1. Статический маршрут до default route через первого провайдера с метрикой 1 и проверкой доступности шлюза
2. Статический маршрут до default route через второго провайдера с метрикой 2
3. Connected маршруты
Трафик до 0.0.0.0/0 идет через 10.10.10.1, пока данный шлюз доступен, иначе переключается на 10.20.20.1

Такую схему можно считать резервированием канала, но она не лишена недостатков. Если произойдет обрыв за пределами шлюза провайдера (например внутри операторской сети), ваш роутер об этом не узнает и продолжит считать маршрут активным.

Типичный домашний роутер с двумя провайдерами, резервированием и ECMP
```
/ip route add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping add dst-address=0.0.0.0/0 gateway=10.10.10.1,10.20.20.1 distance=1
```
1. Статические маршруты для проверки chack gateway
2. Маршрут ECMP
3. Connected маршруты
Маршруты для проверки синего цвета (цвет неактивных маршрутов), но это не мешает работе check gateway. В текущей версии (6.44) RoS автоматический приоритет отдается ECMP маршруту, но лучше добавить проверочные маршруты в другие таблицы маршрутизации (опция routing-mark )

На Speedtest и прочих подобных сайтах прироста скорости не будет (ECMP делит трафик по соединениям, а не по пакетам), но p2p приложения должны загружать быстрее.

Фильтрация через Routing
```
/ip route add dst-address=0.0.0.0/0 gateway=10.10.10.1 add dst-address=192.168.200.0/24 gateway=10.30.30.1 distance=1 add dst-address=192.168.200.0/24 gateway=10.10.10.1 distance=2 type=blackhole
```
1. Статический маршрут до default route
2. Статический маршрут до 192.168.200.0/24 через ipip туннель
3. Запрещающий статический маршрут до 192.168.200.0/24 через маршрутизатор провайдера
Вариант фильтрации при которой туннельный трафик не уйдет на маршрутизатор провайдера при отключении ipip интерфейса. Подобные схемы требуются редко, т.к. можно реализовать блокировку через firewall.

Routing Loop
Петля маршрутизации — ситуация когда пакет бегает между маршрутизаторами до истечения ttl. Обычно является следствием ошибки конфигурации, в больших сетях лечится внедрением протоколов динамической маршрутизации, в маленьких — внимательностью.

Выглядит это примерно так:

Пример (наипростейший) как получить подобный результат:

Пример с Routing loop не имеет практического применения, но он показывает что маршрутизаторы понятия не имеют о таблице маршрутизации своих соседей.

Policy Base Routing и дополнительные таблицы маршрутизации

При выборе маршрута, роутер использует только одно поле из заголовка пакета (Dst. Address) — это базовая маршрутизация. Маршрутизация на базе других условий, например адреса источника, типа трафика (ToS), балансировка без ECMP, относится к Policy Base Routing (PBR) и использует дополнительные таблицы маршрутизации.

More Specific Route является основным правилом выбора маршрута, в пределах таблицы маршрутизации.

По умолчанию все правила маршрутизации добавляются в таблицу main. Администратор может создать произвольное количество дополнительных таблиц маршрутизации и направлять пакеты в них. Правила в разных таблицах не конфликтуют между собой. Если пакет не нашел подходящего правила в указанной таблице, он уйдет в таблицу main.

Пример с распределением через Firewall:
- 192.168.100.10 -> 8.8.8.8
  1. Трафик от 192.168.100.10 получает метку via-isp1 в [Prerouting|Mangle]
  2. На этапе Routing в таблице via-isp1 производится поиск маршрута до 8.8.8.8
  3. Маршрут найден, трафик отправляется на шлюз 10.10.10.1
- 192.168.200.20 -> 8.8.8.8
  1. Трафик от 192.168.200.20 получает метку via-isp2 в [Prerouting|Mangle]
  2. На этапе Routing в таблице via-isp2 производится поиск маршрута до 8.8.8.8
  3. Маршрут найден, трафик отправляется на шлюз 10.20.20.1
- Если один из шлюзов (10.10.10.1 или 10.20.20.1) станет недоступным, то пакет уйдет в таблицу main и будет искать подходящий маршрут там
Проблемы терминологии

В RouterOS есть определенные проблемы с терминологией.
При работе с правилами в [IP]->[Routes] указывается таблица маршрутизации, хотя и написано что метка:

В [IP]->[Routes]->[Rule] все правильно, в условии метки в действии таблицы:

Как отправить пакет в определенную таблицу маршрутизации

RouterOS дает несколько инструментов:
- Правила в [IP]->[Routes]->[Rules]
- Маршрутные метки ( action=mark-routing ) в [IP]->[Firewall]->[Mangle]
- VRF
Правила [IP]->[Route]->[Rules]
Правила обрабатываются последовательно, если пакет совпал с условиями правила он не проходит дальше.

Routing Rules позволяют расширить возможности маршрутизации, опираясь не только на адрес получателя, но и адрес источника и интерфейс на который был получен пакет.

Правила состоят из условий и действия:
- Условия. Практически повторяют список признаков по которым пакет проверяется в FIB, отсутствует только ToS.
- Действия
  - lookup — отправить пакет в таблицу
  - lookup only in table — запереть пакет в таблице, если маршрут не будет найден пакет не уйдет в таблицу main
  - drop — отбросить пакет
  - unreacheable — отбросить пакет с уведомлением отправителя
  В FIB трафик до локальных процессов обрабатывается в обход правил [IP]->[Route]->[Rules] :
  
  Маркировка [IP]->[Firewall]->[Mangle]
  Маршрутные метки позволяют устанавливать шлюз для пакета используя практически любые условия Firewall:
  
  Практически, потому что не все из них имеет смысл, а некоторые могут работать нестабильно.
  
  Маркировать пакет можно двумя способами:
  - Сразу ставить routing-mark
  - Сначала ставить connection-mark, потом на основе connection-mark ставить routing-mark
  В статье про firewall я писал, что второй вариант предпочтительнее т.к. снижает нагрузку на cpu, в случае с маркировкой маршрутов — это не совсем так. Указанные способы маркировки не всегда являются равноценными и обычно используются для решения различных задач.
  
  Примеры использования
  
  Переходим к примерам использования Policy Base Routing, на них гораздо проще показать зачем все это нужно.
  
  MultiWAN и ответный исходящий (Output) трафик
  Распространенная проблема, при MultiWAN конфигурации: Mikrotik доступен из сети интернет только по «активному» провайдеру.
  
  Роутеру не важно на какой ip пришел запрос, при генерации ответа он будет искать маршрут в таблице маршрутизации, где активен маршрут через isp1. Дальше такой пакет скорее всего будет отфильтрован по пути до получателя.
  
  Еще один интересный момент. Если на интерфейсе ether1 настроен «простой» source nat: /ip fi nat add out-interface=ether1 action=masquerade пакет уйдет в сеть с src. address=10.10.10.100, что еще больше усугубит ситуацию.
  
  Исправить проблему можно нескольким способами, но для любого из них потребуются дополнительные таблицы маршрутизации:
```
/ip route add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping distance=1 add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping distance=2 add dst-address=0.0.0.0/0 gateway=10.10.10.1 routing-mark=over-isp1 add dst-address=0.0.0.0/0 gateway=10.20.20.1 routing-mark=over-isp2
```
  Использование [IP]->[Route]->[Rules]
  Указываем таблицу маршрутизации которая будет использована для пакетов с указанными Source IP.
```
/ip route rule add src-address=10.10.10.100/32 action=lookup-only-in-table table=over-isp1 add src-address=10.20.20.200/32 action=lookup-only-in-table table=over-isp2
```
  Можно использовать action=lookup , но для локального исходящего трафика указанный вариант полностью исключает соединения с неправильного интерфейса.
  - Система генерирует ответный пакет с Src. Address: 10.20.20.200
  - На этапе Routing Decision(2) происходит проверка [IP]->[Routes]->[Rules] и пакет отправляется в таблицу маршрутизации over-isp2
  - В соответствии с таблицей маршрутизации пакет должен быть отправлен на шлюз 10.20.20.1 через интерфейс ether2
  Данный способ не требует рабочий Connection Tracker, в отличии от использования таблицы Mangle.
  
  Использование [IP]->[Firewall]->[Mangle]
  Соединение начинается со входящего пакета, поэтому маркируем его ( action=mark-connection ), для исходящих пакетов от маркированного соединения устанавливаем маршрутную метку ( action=mark-routing ).
```
/ip firewall mangle #Маркировка входящих соединений add chain=input in-interface=ether1 connection-state=new action=mark-connection new-connection-mark=from-isp1 add chain=input in-interface=ether2 connection-state=new action=mark-connection new-connection-mark=from-isp2 #Маркировка исходящих пакетов на основе соединений add chain=output connection-mark=from-isp1 action=mark-routing new-routing-mark=over-isp1 passthrough=no add chain=output connection-mark=from-isp2 action=mark-routing new-routing-mark=over-isp2 passthrough=no
```
  Если на одном интерфейсе настроено несколько ip, можно добавить в условие dst-address для уточнения.
  - На интерфейс ether2 поступает пакет открывающий соединение. Пакет попадает в [INPUT|Mangle] где говорится маркировать все пакеты из соединения как from-isp2
  - Система генерирует ответный пакет с Src. Address: 10.20.20.200
  - На этапе Routing Decision(2) пакет в соответствии с таблицей маршрутизации отправляется на шлюз 10.20.20.1 через интерфейс ether1. Можете убедиться в этом залогировав пакеты в [OUTPUT|Filter]
  - На этапе [OUTPUT|Mangle] происходит проверка на наличие метки соединения from-isp2 и пакет получает маршруткую метку over-isp2
  - На этапе Routing Adjusment(3) происходит проверка на наличие маршрутной метки и отправка в соответствующую таблицу маршрутизации
  - В соответствии с таблицей маршрутизации пакет должен быть отправлен на шлюз 10.20.20.1 через интерфейс ether2
  MultiWAN и ответный dst-nat трафик
  
  Пример посложнее, что делать если за роутером находится сервер (например web) в частной подсети и необходимо обеспечить доступ к нему по любому из провайдеров.
```
/ip firewall nat add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether1 action=dst-nat to-address=192.168.100.100 add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether2 action=dst-nat to-address=192.168.100.100
```
  Суть проблемы будет та же, решение похоже на вариант с Firewall Mangle, только будут использоваться другие цепочки:
```
/ip firewall mangle add chain=prerouting connection-state=new in-interface=ether1 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp1 add chain=prerouting connection-state=new in-interface=ether2 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp2 add chain=prerouting connection-mark=web-input-isp1 in-interface=ether3 action=mark-routing new-routing-mark=over-isp1 passthrough=no add chain=prerouting connection-mark=web-input-isp2 in-interface=ether3 action=mark-routing new-routing-mark=over-isp2 passthrough=no
```
  На схеме не отображен NAT, но думаю и так все понятно.
  
  MultiWAN и исходящие соединения
  
  Можно использовать возможности PBR для создания нескольких vpn (в примере SSTP) соединений с разных интерфейсов роутера.
  
  Дополнительные таблицы маршрутизации:
```
/ip route add dst-address=0.0.0.0/0 gateway=192.168.100.1 routing-mark=over-isp1 add dst-address=0.0.0.0/0 gateway=192.168.200.1 routing-mark=over-isp2 add dst-address=0.0.0.0/0 gateway=192.168.0.1 routing-mark=over-isp3 add dst-address=0.0.0.0/0 gateway=192.168.100.1 distance=1 add dst-address=0.0.0.0/0 gateway=192.168.200.1 distance=2 add dst-address=0.0.0.0/0 gateway=192.168.0.1 distance=3
```
```
/ip firewall mangle add chain=output dst-address=10.10.10.100 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp1 passtrough=no add chain=output dst-address=10.10.10.101 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp2 passtrough=no add chain=output dst-address=10.10.10.102 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp3 passtrough=no
```
  Простые правила NAT, иначе пакет уйдет с интерфейса с неправильным Src. Address:
```
/ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade add chain=srcnat out-interface=ether2 action=masquerade add chain=srcnat out-interface=ether3 action=masquerade
```
  - Роутер создает три процесса SSTP
  - На этапе Routing Decision (2) для данных процессов выбирается маршрут, исходя из таблицы маршрутизации main. От этого же маршрута пакет получает Src. Address привязанный к интерфейсу ether1
  - В [Output|Mangle] пакеты от разных соединений получают разные метки
  - Пакеты попадают в соответствующие меткам таблицы на этапе Routing Adjusment и получает новый маршрут для отправки пакетов
  - Но у пакетов все еще остается Src. Address от ether1, на этапе [Nat|Srcnat] адрес подменяется в соответствии с интерфейсом
  Интересно, что на роутере вы увидите следующую таблицу соединений:
  
  Connection Tracker отрабатывает раньше [Mangle] и [Srcnat] , поэтому все соединения идут от одного адреса, если посмотреть подробнее то в Replay Dst. Address будут адреса после NAT:
  
  На VPN сервере (на тестовом стенде он у меня один) можно увидеть что все соединения происходят с правильных адресов:
  
  Постой способ
  Есть способ проще, можно просто указать определенный шлюз для каждого из адресов:
```
/ip route add dst-address=10.10.10.100 gateway=192.168.100.1 add dst-address=10.10.10.101 gateway=192.168.200.1 add dst-address=10.10.10.102 gateway=192.168.0.1
```
  Но такие маршруты будут влиять не только на исходящий но и на транзитный трафик. Плюс, если вам не нужно чтобы трафик на vpn сервера уходил через неподходящие каналы связи, то придется добавить еще 6 правил в [IP]->[Routes] с type=blackhole . В предыдущем варианте — 3 правила в [IP]->[Route]->[Rules] .
  
  Распределение соединений пользователей по каналам связи
  
  Простые, повседневные задачи. Опять же понадобятся дополнительные таблицы маршрутизации:
```
/ip route add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1 add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2
```
  Используя [IP]->[Route]->[Rules]
```
/ip route rules add src-address=192.168.100.0/25 action=lookup-only-in-table table=over-isp1 add src-address=192.168.100.128/25 action=lookup-only-in-table table=over-isp2
```
  Если использовать action=lookup , то при отключении одного из каналов трафик уйдет в таблицу main и пойдет по рабочему каналу. Нужно это или нет — зависит от задачи.
  
  Используя маркировки в [IP]->[Firewall]->[Mangle]
  Простой пример со списками ip адресов. В принципе можно использовать практически любые условия. Единственное предостережение layer7, даже в паре с метками соединений, может показаться что всё работает правильно, но часть трафика всеравно уйдет не туда.
```
/ip firewall mangle add chain=prerouting src-address-list=users-over-isp1 dst-address-type=!local action=mark-routing new-routing-mark=over-isp1 add chain=prerouting src-address-list=users-over-isp2 dst-address-type=!local action=mark-routing new-routing-mark=over-isp2
```
  «Запереть» пользователей в одной таблице маршрутизации можно через [IP]->[Route]->[Rules] :
```
/ip route rules add routing-mark=over-isp1 action=lookup-only-in-table table=over-isp1 add routing-mark=over-isp2 action=lookup-only-in-table table=over-isp2
```
  Либо через [IP]->[Firewall]->[Filter] :
```
/ip firewall filter add chain=forward routing-mark=over-isp1 out-interface=!ether1 action=reject add chain=forward routing-mark=over-isp2 out-interface=!ether2 action=reject
```
  Отступление про dst-address-type=!local
  Дополнительное условие dst-address-type=!local необходимо чтобы трафик от пользователей доходил до локальных процессов роутера (dns, winbox, ssh, . ). Если к роутеру подключено несколько локальных подсетей, необходимо предусмотреть чтобы трафик между ними не уходил в интернет, например используя dst-address-table .
  
  В примере с использованием [IP]->[Route]->[Rules] подобных исключений нет, но трафик до локальных процессов доходит. Дело в том, что попадая в FIB пакет промаркированный в [PREROUTING|Mangle] имеет маршрутную метку и уходит в таблицу маршрутизации отличную от main, где нет локального интерфейса. В случае с Routing Rules, сначала проверяется предназначен ли пакет локальному процессу и только на этапе User PBR он уходит в заданную таблицу маршрутизации.
  
  Используя [IP]->[Firewall]->[Mangle action=route]
  Данное действие работает только в [Prerouting|Mangle] и позволяет направлять трафик на указанный шлюз без использования дополнительных таблиц маршрутизации, указывая адрес шлюза напрямую:
```
/ip firewall mangle add chain=prerouting src-address=192.168.100.0/25 action=route gateway=10.10.10.1 add chain=prerouting src-address=192.168.128.0/25 action=route gateway=10.20.20.1
```
  Действие route имеет более низкий приоритет чем правила маршрутизации ( [IP]->[Route]->[Rules] ). В случае с маршрутными метками все зависит от положения правил, если правило с action=route стоит выше чем action=mark-route , то будет использовано оно (вне зависимости от флага passtrough ), иначе маркировка маршрута.
  На wiki очень мало информации про данное действие и все выводы получены эксперементальным путем, в любом случае я не нашел варианты когда применение данного варианта дает приимущества перед другими.
  
  Динамическая балансировка на основе PPC
  
  Per Connection Classificator — является более гибким аналогом ECMP. В отличии от ECMP делит трафик по соединениям более строго (ECMP ничего про соединения не знает, но в паре с Routing Cache получается нечто похожее).
  
  PCC берет указанные поля из ip заголовка, преобразует их в 32-битное значение и делит на знаменатель. Остаток от деления сравнивается с указанным остатком и если они совпадают, то применяется указанное действие. Подробнее. Звучит дико, но работает.
  
  Пример с тремя адресами:
```
192.168.100.10: 192+168+100+10 = 470 % 3 = 2 192.168.100.11: 192+168+100+11 = 471 % 3 = 0 192.168.100.12: 192+168+100+12 = 472 % 3 = 1
```
  Пример динамического распределения трафика по src.address между тремя каналами:
```
#Таблица маршрутизации /ip route add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=3 check-gateway=ping add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1 add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2 add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=1 routing-mark=over-isp3 #Маркировка соединений и маршрутов /ip firewall mangle add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/0 action=mark-connection new-connection-mark=conn-over-isp1 add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/1 action=mark-connection new-connection-mark=conn-over-isp2 add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/2 action=mark-connection new-connection-mark=conn-over-isp3 add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp1 action=mark-routing new-routing-mark=over-isp1 add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp2 action=mark-routing new-routing-mark=over-isp2 add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp3 action=mark-routing new-routing-mark=over-isp3
```
  При маркировке маршрутов есть дополнительное условие: in-interface=br-lan , без него под action=mark-routing попадет ответный трафик из интернета и в соответствии с таблицами маршрутизации уйдет обратно к провайдеру.
  
  Переключение каналов связи
  
  Check ping — хороший инструмент, но он проверяет связь только с ближайшим IP пиром, сети провайдеров обычно состоят из большого числа маршрутизаторов и обрыв связи может произойти за пределами ближайшего пира, а дальше идут магистральные операторы связи у которых тоже могут случаться проблемы, в общем check ping не всегда показывает актуальную информацию о доступе в глобальную сеть.
  Если у провайдеров и крупных корпораций есть протокол динамической маршрутизации BGP, то домашним и офисным пользователем приходится самостоятельно придумывать как проверять доступ в интернет через определенный канал связи.
  
  Обычно используются скрипты, которые через определенный канал связи проверяют доступность ip адреса в сети интернет, при этом выбирается что то надежное, например google dns: 8.8.8.8. 8.8.4.4. Но в сообществе Mikrotik для этого приспособили более интересный инструмент.
  
  Пара слов про рекурсивную маршрутизацию
  Рекурсивная маршрутизация необходима при построении Multihop BGP пиринга и в статью про основы статической маршрутизации попала только за счет ушлых пользователей MikroTik, которые придумали как использовать рекурсивный маршруты в паре с check gateway для переключение каналов связи без дополнительных скриптов.
  
  Пришло время в общих чертах разобраться с опциями scope/target scope и каким образом маршрут привязывается к интерфейсу:
  1. Маршрут ищет интерфейс для отправки пакета исходя из своего значения scope и всех записей в таблице main с меньшими или равными значениями target scope
  2. Из найденных интерфейсов выбирается тот, через который можно отправить пакет указанному шлюзу
  3. Интерфейс найденной connected записи выбирается для отправки пакета на шлюз
  При наличии рекурсивного маршрута происходит все тоже самое, но в два этапа:
  - 1-3 К connected маршрутам добавляется еще один, через который можно достичь указанного шлюза
  - 4-6 Поиск маршрута connected маршрута для «промежуточного» шлюза
  Все манипуляции с рекурсивным поиском происходят в RIB, а в FIB передается только итоговый результат: 0.0.0.0/0 via 10.10.10.1 on ether1 .
  
  Пример использования рекурсивной маршрутизации для переключения маршрутов
  
  Конфигурация:
```
/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 check-gateway=ping distance=1 target-scope=10 add dst-address=8.8.8.8 gateway=10.10.10.1 scope=10 add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2
```
  Можно проверить, что пакеты будут отправляться на 10.10.10.1:
  
  Check gateway ничего не знает про рекурсивную маршрутизацию и просто отправляет ping’и на адрес 8.8.8.8, который (исходя из таблицы main) доступен через шлюз 10.10.10.1.
  
  Если происходит потеря связи между 10.10.10.1 и 8.8.8.8, то происходит отключение маршрута, но пакеты (включая проверочные ping) до 8.8.8.8 продолжают идти через 10.10.10.1:
  
  Если происходит потеря линка на ether1, то получается неприятная ситуация, когда пакеты до 8.8.8.8 пойдут через второго провайдера:
  
  Это проблема, если вы используете NetWatch для запуска скриптов при недоступности 8.8.8.8. При обрыве линка NetWatch просто отработает по резервному каналу связи и будет считать что все нормально. Решается добавлением дополнительного фильтрующего маршрута:
```
/ip route add dst-address=8.8.8.8 gateway=10.20.20.1 distance=100 type=blackhole
```
  На хабре есть статья, где ситуация с NetWatch рассмотрена более детально.
  
  И да, при использовании подобного резервирования адрес 8.8.8.8 будет жестко привязан к одному из провайдеров, соответственно выбирать его в качестве источника dns не самая хорошая идея.
  
  Пара слов про Virtual Routing and Forwarding (VRF)
  
  Технология VRF предназначена для создания нескольких виртуальных маршрутизаторов внутри одного физического, данная технология широко применяется у операторов связи (обычно в связке с MPLS) для предоставления услуги L3VPN клиентам с пересекающимися адресами подсетей:
  
  Но VRF в Mikrotik организован на базе таблиц маршрутизации и имеет ряд недостатков, например локальные ip адреса роутера доступны из всех VRF, подробнее можно почитать по ссылке.
  
  Пример конфигурации vrf:
```
/ip route vrf add interfaces=ether1 routing-mark=vrf1 add interfaces=ether2 routing-mark=vrf2 /ip address add address=192.168.100.1/24 interface=ether1 network=192.168.100.0 add address=192.168.200.1/24 interface=ether2 network=192.168.200.0
```
  С устройства подключенного к ether2 видим, что проходит ping до адреса роутера из другого vrf (и это проблема), при этом ping в интернет не уходит:
  
  Для доступа в интернет необходимо прописать дополнительный маршрут обращающийся к таблице main (в терминологии vrf это называется route leaking):
```
/ip route add distance=1 gateway=172.17.0.1@main routing-mark=vrf1 add distance=1 gateway=172.17.0.1%wlan1 routing-mark=vrf2
```
  Тут показано два способа route leaking: используюя таблицу маршрутизации: 172.17.0.1@main и используя имя интерфейса: 172.17.0.1%wlan1 .
  
  И настроить маркировку для ответного трафика в [PREROUTING|Mangle] :
```
/ip firewall mangle add chain=prerouting in-interface=ether1 action=mark-connection new-connection-mark=from-vrf1 passthrough=no add chain=prerouting connection-mark=from-vrf1 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf1 passthrough=no add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=from-vrf2 passthrough=no add chain=prerouting connection-mark=from-vrf2 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf2 passthrough=no 
```
  Подсети с одинаковой адресацией
  Организация доступа до подсетей с одинаковой адресацией на одном роутере используя VRF и netmap:
```
/ip route vrf add interfaces=ether1 routing-mark=vrf1 add interfaces=ether2 routing-mark=vrf2 /ip address add address=192.168.100.1/24 interface=ether1 network=192.168.100.0 add address=192.168.100.1/24 interface=ether2 network=192.168.100.0 add address=192.168.0.1/24 interface=ether3 network=192.168.0.0
```
```
#Маркируем пакеты для отправки в правильную таблицу маршрутизации /ip firewall mangle add chain=prerouting dst-address=192.168.101.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf1 passthrough=no add chain=prerouting dst-address=192.168.102.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf2 passthrough=no #Средствами netmap заменяем адреса "эфимерных" подсетей на реальные подсети /ip firewall nat add chain=dstnat dst-address=192.168.101.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24 add chain=dstnat dst-address=192.168.102.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24
```
  Правила маршрутизации для возвратного трафика:
```
#Указание имени интерфейса тоже может считаться route leaking, но по сути тут создается аналог connected маршрута /ip route add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf1 add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf2
```
  Добавление маршрутов полученных по dhcp в заданную таблицу маршрутизации
  VRF может быть интересен, если необходимо автоматически добавить динамический маршрут (например от dhcp client) в определенную таблицу маршрутизации.
  
  Добавление интерфейса в vrf:
```
/ip route vrf add interface=ether1 routing-mark=over-isp1
```
  Правила для отправки трафика (исходящего и транзитного) через таблицу over-isp1:
```
/ip firewall mangle add chain=output out-interface=!br-lan action=mark-routing new-routing-mark=over-isp1 passthrough=no add chain=prerouting in-interface=br-lan dst-address-type=!local action=mark-routing new-routing-mark=over-isp1 passthrough=no
```
  Дополнительный, фейковый маршрут для работы исходящей маршрутизции:
```
/interface bridge add name=bare /ip route add dst-address=0.0.0.0/0 gateway=bare
```
  Этот маршрут необходим только чтобы локальные исходящие пакеты могли пройти через Routing decision (2) до [OUTPUT|Mangle] и получить маршрутную метку, если на маршрутизаторе есть другие активные маршруты до 0.0.0.0/0 в таблице main оно не требуется.
  
  Цепочки connected-in и dynamic-in в [Routing] -> [Filters]
  
  Фильтрация маршрутов (входящий и исходящих) — это инструмент который обычно используется вместе с протоколами динамической маршрутизации (поэтому доступен только после установки пакета routing), но во входящих фильтрах есть две интересные цепочки:
  - connected-in — фильтрация connected маршрутов
  - dynamic-in — фильтрация динамических маршрутов полученных PPP и DCHP
  Фильтрация позволяет не только отбрасывать маршруты, но и изменять ряд опций: distance, routing-mark, comment, scope, target scope, .
  
  Это очень точечный инструмент и если можете сделать что-то без Routing Filters (но не скриптами), то не используйте Routing Filters, не путайте себя и тех кто будет конфигурировать роутер после вас. В контексте динамической маршрутизации Routing Filters будут использоваться значительно чаще и продуктивнее.
  
  Установка Routing Mark для динамических маршрутов
  Пример с домашнего маршрутизатора. У меня настроено два VPN соединения и трафик в них должен заворачиваться в соответствием с таблицами маршрутизации. При этом я хочу что-бы маршруты создавались автоматически при активации интерфейса:
```
#При создании vpn подключений указываем создание default route и задаем дистанцию /interface pptp-client add connect-to=X.X.X.X add-default-route=yes default-route-distance=101 . add connect-to=Y.Y.Y.Y add-default-route=yes default-route-distance=100 . #Фильтрами отправляем маршруты в определенные таблицы маршрутизации на основе подсети назначения и дистанции /routing filter add chain=dynamic-in distance=100 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn1 add chain=dynamic-in distance=101 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn2
```
  Не знаю почему, наверное баг, но если создать vrf для ppp интерфейса, то маршрут до 0.0.0.0/0 всеравно попадет в таблицу main. Иначе всё было бы еще проще.
  
  Отключение Connected маршрутов
  Иногда требуется и такое:
```
/route filter add chain=connected-in prefix=192.168.100.0/24 action=reject
```
  Инструменты отладки
  
  RouterOS предоставляет ряд средств для отладки маршрутизации:
  - [Tool]->[Tourch] — позволяет посмотреть пакеты на интерфейсах
  - /ip route check — позволяет посмотреть на какой шлюз будет отправлен пакет, не работает с таблицами маршрутизации
  - /ping routing-table= и /tool traceroute routing-table= — ping и трассировка используя указанную таблицу маршрутизации
  - action=log в [IP]->[Firewall] — отличный инструмент, который позволяет проследить путь пакета по packet flow, данное действие доступно во всех цепочках и таблицах
  Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор – официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.
  Похожие публикации: