Сервер роутер и его маршрутизация

В этой статье посмотрим, как с помощью встроенных средств на базе сервера с Windows Server 2012 R2 организовать простой межсетевой маршрутизатор. И хотя на практике маршрутизаторы на базе компьютеров используются довольно редко (аппаратные маршрутизаторы, как правило, имеют более высокую производительность, надежность и несколько дешевле выделенного компьютера), в тестовых или виртуальных средах, когда нужно срочно настроить маршрутизацию между несколькими подсетями, маршрутизатор на базе Windows Server вполне себе приемлемое решение.

Итак, в роли маршрутизатора будет выступать сервер с ОС Windows Server 2012 R2. Сервер имеет 2 сетевых интерфейса: физических или виртуальных, если сервер запущен на гипервизоре. Каждому интерфейсу сервера назначен выделенный IP адрес из различных подсетей. Для удобства, мы переименовали названия сетевых интерфейсов в Панели управления сетями и общим доступом:

Сетевая карта 1 (сетевая карта подключена во внутреннюю LAN сеть):

Имя: LAN

IP: 10.0.1.1

Сетевая карта 2 (сетевая карта во внешней сети ):

Имя: Internet

IP: 192.168.1.20

Наша задача – организовать маршрутизацию пакетов из локальной подсети 10.0.1.0 во внешнюю подсеть 192.168.1.0 (как правило, такая сеть имеет выход в интернет) через NAT. Такую схему можно реализовать в случае необходимости организации доступа клиентов из внутренней сети в интернет.

Маршрутизация в Windows Server 2012 R2 реализуется на базе роли Remote Access (RRAS). Данная служба появилась еще в Windows Server 2003 и до текущей в версии Windows Server ее интерфейс и процесс настройки практически не изменился.

В первую очередь нужно установить роль Remote Access. Для этого откроем консоль Server Manager, выбираем Manage -> Add Roles and Features, находим и отмечаем роль Remote Access, в ее составе выбираем службу Routing, и, соглашаясь со всеми предложенными по умолчанию компонентами, запускаем ее установку (Install).

После окончания установки открываем консоль Routing and Remote Access (rrasmgmt.msc), щелкаем по имени сервера (с красной стрелкой) и выбираем Configure and Enable Routing and Remote Access.

В открывшемся окне выбираем пункт Network Address Translation (NAT).

На следующей шаге (NAT Internet Connection) нужно выбрать сетевой интерфейс, подключённый ко внешней сети / Интернету (в нашем примере это интерфейс Internet с ip 192.168.1.20). Этот интерфейс будет «публичным интерфейсом» нашего NAT роутера.

Далее будет предложено указать должен ли NAT роутер обеспечить клиентов внутренней сети сервисами DHCP и DNS. Как правило, этот функционал во внутренней сети уже имеется, поэтому в нем мы не нуждаемся.

На этом базовая настройка маршрутизации на Windows Server 2012 R2 завершена. Сервер уже должен выполнять маршрутизацию пакетов между двумя подключенными сетями и выполнять трансляцию сетевых адресов (NAT).

Чтобы в этом убедиться, в консоли RRAS откройте свойства сервера. На вкладке General показано, что IPv4 маршрутизация включена (т.е. пакеты IPv4 будут пересылаться с одной сетевой карты на другую).

Проверить работу маршрутизации можно, указав на клиентском компьютере во внутренней сети (к которой подключен интерфейс сервера LAN) в качестве шлюза IP-адрес сервера (10.0.1.1), и выполнить ping или трассировку маршрута к ресурсу, расположенному во внешней сети или интернете. Эти попытки должны быть успешными.

Примечание. Windows Server 2012 R2 поддерживает статическую маршрутизацию, протокол динамической маршрутизации RIPv2 и BGPv4. Поддержка OSPF была прекращена еще в Windows Server 2008.

В нашем случае на сервере осуществялется статическая маршрутизация. Если нужно добавить новый маршрут, щелкните ПКМ по Static Routes, выберите пункт меню New static route и создайте новое статическое правило маршрутизации.

Примечание. Статический маршрут также можно добавить из командной строки с помощью команд Route или netsh.

Источник

Время на прочтение
10 мин

Количество просмотров 7.3K

Сегодня мы приступим к изучению роутеров. Если вы прошли мой видеокурс с первого по 17-й урок, то уже изучили основы свитчей. Сейчас мы переходим к следующему устройству – роутеру. Как вы знаете из предыдущего видеурока, одна из тем курса CCNA так и называется – Cisco Switching & Routing.

В этой серии мы не станем изучать роутеры Cisco, а рассмотрим концепцию маршрутизации в целом. У нас будет три темы. Первая – это обзор того, что вы уже знаете о роутерах и разговор о том, как это можно применить совместно со знаниями, полученными вами в процессе изучения свитчей. Мы должны понять, в чем состоит совместная работа свитчей и роутеров.

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

Мы рассматривали, как данные перемещаются по сети и как производится трехэтапное рукопожатие TCP. Первое сообщение, отправляемое по сети, представляет собой SYN-пакет. Давайте рассмотрим, как происходит трехэтапное рукопожатие, когда компьютер с IP-адресом 10.1.1.10 хочет связаться с сервером 30.1.1.10, то есть пытается установить FTP-соединение.
Для того, чтобы начать соединение, компьютер создает порт источника со случайным номером 25113. Если вы забыли, как это происходит, советую пересмотреть предыдущие видеоуроки, в которых рассматривался этот вопрос.

Далее он помещает во фрейм номер порта назначения, поскольку знает, что должен соединиться с портом 21, затем добавляет информацию третьего уровня OSI, то есть собственный IP-адрес и IP-адрес пункта назначения. Данные, обведенные пунктиром, не меняются, пока не достигнут конечной точки. Достигнув сервера, они также не меняются, но сервер добавляет к фрейму информацию второго уровня, то есть MAC-адрес. Это связано с тем, что свитчи воспринимают только информацию второго уровня OSI. В этом сценарии роутер представляет собой единственное сетевое устройство, которое рассматривает информацию 3-го уровня, естественно, компьютер тоже работает с этой информацией. Итак, свитч работает только с информацией 2-го уровня, а роутер – 3-го.

Свитч знает исходный MAC-адрес XXXX:XXXX:1111 и хочет узнать MAC-адрес сервера, к которому обращается компьютер. Он сравнивает исходный IP-адрес с адресом назначения, понимает, что эти устройства расположены в разных подсетях и принимает решение использовать шлюз для выхода в другую подсеть.

Мне часто задают вопрос, кто решает, каким должен быть IP-адрес шлюза. Во-первых, это решает сетевой администратор, который создает сеть и предоставляет IP-адрес каждому устройству. Как администратор, вы можете назначить роутеру любой адрес, находящийся в диапазоне разрешенных адресов вашей подсети Обычно это первый или последний допустимый адрес, но нет никаких строгих правил по поводу его назначения. В нашем случае администратор назначил адрес шлюза, или роутера, 10.1.1.1 и присвоил его порту F0/0.

Когда вы настраиваете сеть на компьютере со статическим IP-адресом 10.1.1.10, вы назначаете маску подсети 255.255.255.0 и шлюз по умолчанию 10.1.1.1. Если вы не используете статический адрес, значит, компьютер использует DHCP, который назначает динамический адрес. Независимо от того, какой IP-адрес использует компьютер, статический или динамический, для выхода в другую сеть должен иметься адрес шлюза.

Таким образом, компьютер 10.1.1.10 знает, что должен отослать фрейм роутеру 10.1.1.1. Эта передача происходит внутри локальной сети, где IP-адрес не имеет никакого значения, здесь важен только MAC-адрес. Предположим, что ранее компьютер никогда не связывался с роутером и не знает его MAC-адрес, поэтому он должен сначала послать ARP-запрос, которым спрашивает все устройства подсети: «эй, кто из вас имеет адрес 10.1.1.1? Пожалуйста, сообщите мне свой MAC-адрес!». Поскольку ARP – это широковещательное сообщение, оно поступает на все порты всех устройств, включая роутер.

Компьютер 10.1.1.12, получив ARP, думает: «нет, мой адрес не 10.1.1.1», и отбрасывает запрос, аналогично поступает компьютер 10.1.1.13. Роутер, получив запрос, понимает, что спрашивают именно его, и отсылает MAC-адрес порта F0/0 – а все порты имеют разный MAC-адрес — компьютеру 10.1.1.10. Теперь, зная адрес шлюза XXXX:AAAA, который в данном случае является адресом назначения, компьютер добавляет его в конец фрейма, адресованного серверу. Вместе с этим он устанавливает заголовок фрейма FCS/CRC, представляющий собой механизм проверки ошибок передачи.

После этого фрейм компьютера 10.1.1.10 отправляется по проводам к роутеру 10.1.1.1. После получения фрейма роутер удаляет FCS/CRC, используя для проверки тот же алгоритм, что и компьютер. Данные представляют собой не что иное, как набор из нулей и единиц. Если данные повреждены, то есть 1 становится 0 или 0 становится единицей, или имеется утечка данных, которая часто возникает при использовании хаба, то устройство должно переслать фрейм еще раз.

Если проверка FCS/CRC прошла успешно, роутер смотрит на MAC-адреса источника и назначения и удаляет их, поскольку это информация 2-го уровня, и переходит к телу фрейма, в котором содержится информацию 3-го уровня. Из неё он узнает, что информация, которую содержит фрейм, предназначена для устройства с IP-адресом 30.1.1.10.

Роутер каким-то образом знает, где находится это устройство. Мы не обсуждали этот вопрос, когда рассматривали работу свитчей, поэтому рассмотрим его сейчас. Роутер имеет 4 порта, поэтому я добавил к нему еще несколько соединений. Итак, откуда роутер знает, что данные для устройства с IP-адресом 30.1.1.10 нужно отсылать через порт F0/1? Почему он не отсылает их через порт F0/3 или F0/2?

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

В данном случае порт F0/0 настроен на IP-адрес 10.1.1.1 и это означает, что он подсоединен к сети 10.1.1.10/24. Аналогично порт F0/1 настроен на адрес 20.1.1.1, то есть подсоединен к сети 20.1.1.0/24. Роутер знает обе эти сети, потому что они напрямую подсоединены к его портам. Таким образом, информация о том, что трафик для сети 10.1.10/24 должен проходить через порт F0/0, а для сети 20.1.1.0/24 – через порт F0/1, известна по умолчанию. Откуда же роутер знает, через какие порты работать с остальными сетями?

Мы видим, что сеть 40.1.1.0/24 подсоединена к порту F0/2, сеть 50.1.1.0/24 – к порту F0/3, а сеть 30.1.1.0/24 связывает второй роутер с сервером. Второй роутер так же имеет таблицу маршрутизации, в которой сказано, что сеть 30. подсоединена к его порту, обозначим его 0/1, а с первым роутером он соединен через порт 0/0. Этот роутер знает, что его порт 0/0 соединен с сетью 20., а порт 0/1 соединен с сетью 30., и больше не знает ничего.

Аналогично первый роутер знает про сети 40. и 50., подсоединенные к портам 0/2 и 0/3, но ничего не знает о сети 30. Протокол маршрутизации предоставляет роутерам ту информацию, которой они не владеют по умолчанию. Механизм, по которому эти роутеры взаимодействуют друг с другом, является основой маршрутизации, при этом существует динамическая и статическая маршрутизация.

Статическая маршрутизация заключается в том, что первому роутеру дается информация: если нужно связаться с сетью 30.1.1.0/24, то нужно использовать порт F0/1. Однако когда второму роутеру поступает трафик с сервера, который предназначен для компьютера 10.1.1.10, он не знает, что с ним делать, потому что в его таблице маршрутизации имеются только сведения о сети 30. и 20. Поэтому данному роутеру тоже нужно прописать статическую маршрутизацию: если он получает трафик для сети 10., то должен отправить его через порт 0/0.

Проблема статической маршрутизации состоит в том, что я должен вручную настроить первый роутер на работу с сетью 30., а второй роутер – на работу с сетью 10. Это просто, если у меня всего 2 роутера, но когда у меня 10 маршрутизаторов, настройка статической маршрутизации отнимает кучу времени. В этом случае имеет смысл использовать динамическую маршрутизацию.
Итак, получив фрейм от компьютера, первый роутер смотрит в свою таблицу маршрутизации и принимает решение отправить его через порт F0/1. При этом он добавляет к фрейму MAC-адрес источника XXXX.BBBB и MAC-адрес назначения XXXX.СССС.

Получив этот фрейм, второй роутер «обрезает» MAC-адреса, относящиеся ко второму уровню OSI, и переходит к информации 3-го уровня. Он видит, что IP-адрес назначения 30.1.1.10 относится к той же сети, что порт 0/1 роутера, добавляет к фрейму MAC-адрес источника и MAC-адрес устройства назначения и отправляет фрейм серверу.

Как я уже говорил, далее аналогичный процесс повторяется в обратном направлении, то есть осуществляется второй этап рукопожатия, при котором сервер отправляет обратно SYN ACK-сообщение. Перед этим он отбрасывает всю лишнюю информацию и оставляет только SYN-пакет.

Получив этот пакет, второй роутер рассматривает полученную информацию, дополняет её и отправляет дальше.

Итак, на предыдущих уроках мы изучили, как работает свитч, а теперь узнали, как работают роутеры. Давайте ответим на вопрос, что представляет собой маршрутизация в глобальном смысле. Предположим, что вам встретился такой дорожный указатель, установленный на перекрестке с круговым движением. Вы видите, что первое ответвление ведет к базе Королевских воздушных сил Фейрфакс, второе к аэропорту, третье на юг. Если вы выберете четвертый выезд, то попадете в тупик, а через пятый можете проехать через центр города к замку Брэксби.

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

Как я сказал, существует статическая и динамическая маршрутизация. Рассмотрим статическую маршрутизацию, для чего я нарисую 3 устройства, связанные друг с другом, причем первое и третье устройство связаны с сетями. Предположим, что одна сеть 10.1.1.0 хочет связаться с сетью 40.1.1.0, а между роутерами расположены сети 20.1.1.0 и 30.1.1.0.

В этом случае порты роутеров должны принадлежать к разным подсетям. Роутер 1 по умолчанию знает только о сети 10. и 20. и ничего не знает об остальных сетях. Роутер 2 знает только о сетях 20. и 30., потому что они к нему подсоединены, а роутер 3 знает только о сетях 30. и 40. Если сеть 10. хочет связаться с сетью 40., я должен рассказать роутеру 1 о сети 30. и о том, что если он хочет передать фрейм сети 40., то должен использовать интерфейс для сети 20. и отправить фрейм по этой же сети 20.

Второму роутеру я должен назначить 2 маршрута: если он хочет передать пакет из сети 40. в сеть 10., то должен использовать порт сети 20., а для передачи пакета из сети 10. сети 40. – порт сети 30. Аналогично я должен снабдить роутер 3 информацией о сетях 10. и 20.

Если у вас небольшие сети, то статическую маршрутизацию настроить очень легко. Однако чем больше разрастается сеть, тем больше возникает проблем со статической маршрутизацией. Представим, что вы создали новое соединение, которое напрямую связывает первый и третий роутеры. При этом протокол динамической маршрутизации автоматически обновит таблицу маршрутизации роутера 1, указывая следующее: «если вам нужно связаться с роутером 3, используйте прямой маршрут»!

Существует два типа протоколов маршрутизации: протокол внутреннего шлюза IGP и протокол внешнего шлюза EGP. Первый протокол работает с отдельной, автономной системой, известной как домен маршрутизации. Представьте, что у вас небольшая организация, в которой всего 5 роутеров. Если мы говорим только о связи между этими роутерами, то подразумеваем IGP, если же вы используете свою сеть для связи с интернетом, как это делают ISP-провайдеры, то используете EGP.

IGP использует 3 популярных протокола: RIP, OSPF и EIGRP. Учебная программа CCNA упоминает только о двух последних протоколах, потому что RIP устарел. Это самый простой из протоколов маршрутизации, который до сих пор используется в некоторых случаях, однако не обеспечивает необходимую сетевую безопасность. Это одна из причин, по которой Сisco исключила RIP из учебного курса. Однако я все равно расскажу вам о нем, потому что его изучение способствует пониманию основ маршрутизации.

Классификация протоколов EGP использует два протокола: BGP и собственно протокол EGP. При изучении курса CCNA мы будем рассматривать только BGP, OSPF и EIGRP. Рассказ о RIP можете считать бонусной информацией, которая будет отражена в одном из видеоуроков.
Существует еще 2 типа протоколов маршрутизации: дистанционно-векторные протоколы Distance Vector и протоколы маршрутизации состояния канала Link State.

Первый прокол рассматривает векторы расстояния и направления. Например, я могу установить соединение напрямую между роутером R1 и R4, а могу осуществить соединение по пути R1-R2-R3-R4. Если мы говорим о протоколах маршрутизации, использующих дистанционно-векторный метод, то в данном случае соединение всегда будет осуществляться по кратчайшему пути. При этом не имеет значения, что данное соединение будет иметь минимальную скорость. В нашем случае это 128 кбит/с, что намного медленнее, чем соединение по маршруту R1-R2-R3-R4, где скорость составляет 100 мбит/с.

Рассмотрим дистанционно-векторный протокол RIP. Я дорисую перед роутером R1 сеть 10., а за роутером R4 – сеть 40. Предположим, что в этих сетях находится много компьютеров. Если я хочу осуществить связь между сетью 10. R1 и сетью 40. R4, то назначу R1 статическую маршрутизацию типа: «если нужно соединиться с сетью 40., используйте прямую связь с роутером R4». При этом на всех 4-х роутерах я должен вручную настроить RIP. Тогда таблица маршрутизации R1 автоматически будет сообщать, что если сеть 10. хочет связаться с сетью 40., нужно использовать прямое соединение R1-R4. Даже если в обход получится быстрее, протокол Distance Vector все равно выберет кратчайший путь с наименьшим расстоянием передачи.

OSPF – это протокол маршрутизации состояния канала, который всегда смотрит на состояние участков сети. В данном случае он оценивает скорость каналов, и если видит, что скорость передачи трафика по каналу R1-R4 очень низкая, то выбирает путь с большей скоростью R1-R2-R3-R4, даже если его длина превышает самый короткий путь. Таким образом, если я настрою на всех роутерах протокол OSPF, при попытке соединения сети 40. с сетью 10., трафик будет оправлен по маршруту R1-R2-R3-R4. Итак, RIP это дистанционно-векторный протокол, а OSPF — протокол маршрутизации состояния канала.

Существует ещё один протокол – EIGRP, проприетарный протокол маршрутизации Cisco. Если говорить о сетевых устройствах других производителей, например, Juniper, то они не поддерживают EIGRP. Это отличный протокол маршрутизации, который намного эффективнее RIP и OSPF, но его можно использовать только в сетях, основанных на устройствах производства Cisco. Позже я расскажу подробнее, чем так хорош этот протокол. Пока что замечу, что EIGRP сочетает в себе черты дистанционно-векторных протоколов и протоколов маршрутизации состояния канала, представляя собой гибридный протокол.

На следующем видеоуроке мы вплотную подойдём к рассмотрению роутеров Cisco, я немного расскажу вам об операционной системе Cisco IOS, которая предназначена и для свитчей, и для роутеров. Надеюсь, на уроках 19 или 20-го дня мы приступим к подробному изучению протоколов маршрутизации, и я на примере небольших сетей я покажу, как настраивать роутеры Cisco.

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

Источник

Настройка маршрутизатора на основе Windows Server 2012R2

В статье показано как настроить ОС Windows Server 2012 R2 в качестве маршрутизатора. Настраиваемый сервер имеет 2 физических сетевых интерфейса. Каждому сетевому интерфейсу будет назначен статический IP адрес из разных подсетей. Для удобства, сетевые интерфейсы можно переименовать.

Сетевая карта 1 (сетевая карта подключена во внутреннюю сеть):
Имя: in
IP: 10.0.100.1
Сетевая карта 2 (сетевая карта во внешней сети):
Имя: out
IP: 172.16.0.1

Цель: организовать маршрутизацию пакетов из локальной сети 10.0.100.1 во внешнюю сеть 172.16.0.1.

Для начала необходимо добавить новую роль «Удаленный доступ» (Remote Access) на сервере, для этого откроем консоль «Диспетчер серверов» (Server Manager):

Выбираем Manage -> «Добавить роли и компоненты»(Add Roles and Features), выбираем галкой роль «Удаленный доступ» (Remote Access):

В составе роли выбираем службу «Маршрутизация» (Routing), по умолчанию должны установиться дополнительные компоненты, соглашаемся, и запускаем ее установку (Install):

После окончания установки роли открываем консоль «Маршрутизация и удаленный доступ»(Routing and Remote Access) (Ctr + R, rrasmgmt.msc), щелкаем по имени сервера (с красной стрелкой) и выбираем «Настроить и включить маршрутизацию и удаленный доступ» (Configure and Enable Routing and Remote Access).

В окне мастера выбираем пункт «Подключение на основе NAT» (Network Address Translation, NAT)

Далее выбираем сетевой интерфейс, подключённый ко внешней сети (или Интернету) (в примере это сетевой интерфейс out с ip 172.16.0.1). Данный сетевой интерфейс будет «публичным интерфейсом» нашего NAT.

Далее будет предложено указать должен ли NAT, обеспечить клиентов внутренней сети службами DHCP\DNS. Обычно, данный функционал во внутренней сети уже присутствует, поэтому выбираем пункт «Установить службы сопоставления имен и адресов позднее».

Завершение мастера сервера маршрутизации и удаленного означает, что базовые настройки маршрутизации на Windows Server 2012 R2 завершены. В данной конфигурации сервер должен выполнять маршрутизацию пакетов между двух подсетей, при этом выполнять трансляцию сетевых адресов (NAT).

Чтобы убедиться что функционал работает:

В консоли «RRAS» откройте свойства сервера, вкладку «Общие» (General) и убедитесь, что IPv4 маршрутизация включена и счетчики входящих и выходящих байтов увеличиваются.
Проверить работу маршрутизации можно, указав на клиентском ПК во внутренней сети (к которой подключен сетевой интерфейс «in») в качестве шлюза IP-адрес сервера (10.0.100.1), и выполнить ping или трассировку маршрута к ресурсу, расположенному во внешней сети или в интернете. Команда ping должна быть успешна.

Примечание. Если нужно добавить новый маршрут, щелкните в меню «Статические маршруты», выберите пункт меню «новый статический маршрут» (New static route) и создайте новое статическое правило маршрутизации. Статический маршрут также можно добавить из командной строки с помощью команд Route или netsh.

Источник

Всем привет! Статическая маршрутизация – это по сути специальный выделенный путь, по которому должен пройти пакет информации из пункта А в пункт Б. Напомню, что у нас в сети чаще всего встречаются два устройства: маршрутизаторы и коммутаторы. Напомню, что коммутаторы работают на канальном уровне, а маршрутизаторе на сетевом. Далее я коротко расскажу, про Static Route и как это настроить на домашнем устройстве.

Содержание

Коротко про маршрутизацию
ШАГ 1: Заходим в настройки роутера
ШАГ 2: Настройка
TP-Link
D-Link
ASUS
ZyXEL Keenetic
Netis
Tenda
Задать вопрос автору статьи

Коротко про маршрутизацию

Маршрутизатор, исходя из названия, имеет у себя таблицу маршрутизации, а коммутатор коммутации. Все логично, не правда ли. Но есть небольшая проблема коммутации. Представим, что у нас есть две сети по 250 машин и между ними стоят 2 свича.

Если вы помните в таблице коммутации содержатся MAC-адреса. Да они уникальны, поэтому для работы сети нужно, чтобы каждый свич знал, как минимум 500 таких адресов, что не так мало. И тут встает проблема масштабируемости сети, при добавлении новых машин.

А что если установить вместо коммутаторов маршрутизаторы. В итоге у нас есть две сети:

192.168.1.0/24
192.168.2.0./24

И чтобы пакету добраться из одной сети в другую, нужна одна запись в таблице маршрутизации, а именно о соседнем роутере, который уже в свою очередь знает компьютеры «из своего района». Это и удобно, и экономично в плане хранения нужной информации, так как не нужно хранить таблицу из MAC-адресов всех участников сети.

СОВЕТ! Для большей картины понимания самой темы, советую почитать дополнительные материалы про то, что такое маршрутизатор, коммутатор и про модель OSI.

И тут у нас появляются два понятия:

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

Далее я расскажу, как вводить эти статические маршруты для использования их в домашних роутерах.

Смотрим на картинку выше. У нас есть второй роутер (router 2), который имеет доступ к интернету (он же является основным шлюзом). У нас есть компьютер (PC), который подключен сначала к коммутатору. Коммутатор подключен к двум роутерам.

Проблема в том, что ПК должен иметь доступ к серверу (172.30.30.1), но при запросе на router 2, у него в таблице маршрутизации нет данных об этих серверах. Теперь давайте попробуем вписать эти настройки в маршрутизатор.

ШАГ 1: Заходим в настройки роутера

Вот мы и перешли непосредственно к настройке статической маршрутизации. Подключаемся к сети интернет-центра через кабель или по Wi-Fi. Далее нужно ввести DNS или IP-адрес роутера в адресную строку любого браузера. Настройку мы будем делать через Web-интерфейс. Подсказка: адрес можно подсмотреть на этикетке под корпусом аппарата. Чаще всего используют адреса:

192.168.1.1
192.168.0.1

Если вы ранее его настраивали, вводим логин и пароль – их также можно подсмотреть на той же самой бумажке. Чаще всего используют комбинации:

admin – admin
admin – *Пустая строка*

Если есть проблемы со входом в роутер, то смотрим инструкцию тут.

ШАГ 2: Настройка

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

IP адрес назначения – у нас это IP нашего конкретного сервера, к которому мы хотим пробиться через наш 1-ый роутер (172.30.30.1).
Маска подсети – указываем 255.255.255.0.
Шлюз – это IP того роутера, который имеет доступ к серверу. В примере это 192.168.0.2 (Второй маршрутизатор).
Интерфейс – в некоторых настройках нужно будет указывать еще и его. Если доступ к шлюзу идет через интернет, то указываем WAN. Если же вы подключены к нему через LAN порт (как в нашем примере), то указываем его.

Надеюсь я примерно объяснил, как именно статический маршрут нужно заполнять. Теперь приступим непосредственно к практике. Смотрите главу по своей модели.

TP-Link

Старая прошивка

Слева находим раздел «Дополнительные настройки маршрутизации», и в открывшемся списке нажимаем по пункту «Список статических маршрутов». Нажимаем по кнопке «Добавить».

Вписываем данные.

Новая прошивка

«Дополнительные настройки» – «Сеть» – «Расширенные настройки маршрутизации». Нажимаем по плюсику и вписываем нужную информацию.

D-Link

В классическом светлом интерфейсе нужно перейти в «Дополнительно» и нажать по «Маршрутизации».

В темной прошивке все делается также, только сначала нужно перейти в «Расширенные настройки».

Добавляем правило.

ASUS

Переходим в раздел «Локальная сеть», открываем вкладку «Маршруты» и вписываем наши данные. В конце не забудьте нажать на плюсик, правее таблички и нажать на кнопку «Применить».

ZyXEL Keenetic

Новая прошивка

Переходим на страницу «Маршрутизации» и нажимаем по кнопке добавления правила.

Теперь вводим данные:

Тип маршрута – тут нужно указывать тот тип, который вам нужен. Если исходить из задачи, которую указал я, то мы указываем «Маршрут узла».
Адрес сети назначения – указываем адрес сервера. В нашем случае это 30.30.1.
Маска подсети – 255.255.255.0.
Адрес шлюза – адрес роутера, который подключен к нашему серверу. 192.168.0.2.
Интерфейс – указываем тот интерфейс, который мы будем использовать для связи. В нашем примере пакеты пойдут локально через LAN порт, поэтому указываем LAN.

Старая прошивка

Нажимаем по значку плакетки в самом низу и переходим на вкладку «Маршруты». Нажимаем по кнопке добавления и вводим нужные вам данные.

Добавление целого списка маршрутов

Кстати тут вы можете загрузить сразу целую таблицу маршрутизации. Для этого выбираем в том же разделе другую кнопку.

Файлик должен иметь расширение типа BAT. И иметь вид как на скрине ниже. Его спокойно можно создать в блокноте.

Вид достаточно простой:

route ADD IP-адрес назначения MASK указываем маску указываем адрес шлюза

Пример:

route ADD 172.30.30.1 MASK 255.255.255.0 192.168.0.2

ПРИМЕЧАНИЕ! Каждый новый адрес должен начинаться с новой строки, а после последнего указанного IP не должен стоять пробел.

Netis

Переходим в раздел «Advanced» (кнопкам в правом верхнем углу) – «Расширенные» – «Статический маршрут.» – вводим каждый пункт и нажимаем по кнопке «Добавить».

Tenda

Нужный нам пункт находится в разделе «Расширенные настройки».

Источник

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

Данная статья не является 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?
- Если да, то пакет отправляется в указанную таблицу маршрутизации
Пакет отправляется в таблицу main

Условно, можно считать что [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]->[+]

Подсеть для которой необходимо создать маршрут (по умолчанию: 0.0.0.0/0)
IP шлюза или интерфейс на который будет отправлен пакет (может быть несколько, см. ниже ECMP)
Проверка доступности шлюза
Тип записи
Дистанция (метрика) для маршрута
Таблица маршрутизации
IP для локальных исходящих пакетов через данный маршрут
Про назначение 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

Статический маршрут до 0.0.0.0/0 (default route)
Connected маршрут на интерфейсе с провайдером
Connected маршрут на интерфейсе с локальной сетью

Типичный домашний роутер с PPPoE

Статический маршрут до default route, добавлен автоматически т.к. это указано в свойствах подключения
Connected маршрут для PPP соединения
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

Статический маршрут до default route через первого провайдера с метрикой 1 и проверкой доступности шлюза
Статический маршрут до default route через второго провайдера с метрикой 2
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

Статические маршруты для проверки chack gateway
Маршрут ECMP
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

Статический маршрут до default route
Статический маршрут до 192.168.200.0/24 через ipip туннель
Запрещающий статический маршрут до 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 и каким образом маршрут привязывается к интерфейсу:

Маршрут ищет интерфейс для отправки пакета исходя из своего значения scope и всех записей в таблице main с меньшими или равными значениями target scope
Из найденных интерфейсов выбирается тот, через который можно отправить пакет указанному шлюзу
Интерфейс найденной 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

Правила firewall:

#Маркируем пакеты для отправки в правильную таблицу маршрутизации
/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=<name> и /tool traceroute routing-table=<name> — ping и трассировка используя указанную таблицу маршрутизации
action=log в [IP]->[Firewall] — отличный инструмент, который позволяет проследить путь пакета по packet flow, данное действие доступно во всех цепочках и таблицах

Источник: habr.com

Источник

Коротко про маршрутизацию

ШАГ 1: Заходим в настройки роутера

ШАГ 2: Настройка

TP-Link

D-Link

ASUS

ZyXEL Keenetic

Netis

Tenda

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

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

RIB, FIB, Routing Cache

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

Что указывать в gateway: ip-адрес или интерфейс?

More Specific Route

Distance

Check gateway

ECMP маршруты

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

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

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

Проблемы терминологии

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

Примеры использования

MultiWAN и ответный dst-nat трафик

MultiWAN и исходящие соединения

Распределение соединений пользователей по каналам связи

Динамическая балансировка на основе PPC

Переключение каналов связи

Пара слов про Virtual Routing and Forwarding (VRF)

Цепочки connected-in и dynamic-in в [Routing] -> [Filters]

Инструменты отладки

Другие наши интересноые статьи:

Цепочки `connected-in` и `dynamic-in` в `[Routing] -> [Filters]`