Настройка маршрутизации на роутере mikrotik

Overview

Routing is the process of selecting paths across the networks to move packets from one host to another. 

How Routing Works

Let’s look at a basic configuration example to illustrate how routing is used to forward packets between two local networks and to the Internet.

In this setup, we have several networks:

• two client networks (192.168.2.0/24 and 192.168.1.0/24);
• one network to connect routers (172.16.1.0/30), usually called backbone;
• the last network (10.1.1.0/24) connects our gateway router (Router1) to the internet. 

 Router 2:

/ip address
add address=172.16.1.2/30 interface=ether1
add address=192.168.2.1/24 interface=bridge2

Router1 (gateway) where ether1 connects to the internet:

/ip address
add address=10.1.1.2/24 interface=ether1
add address=172.16.1.1/30 interface=ether2
add address=192.168.1.1/24 interface=bridge1

If we look, for example, at the Router1 routing table, we can see that the router knows only about directly connected networks. At this point, when the Client from LAN1 tries to reach the client from LAN2 (192.168.2.0/24), a packet will be dropped on the router, because the destination is unknown for the particular router:

[admin@MikroTik] > /ip/route> print 
Flags: D - dynamic; X - disabled, I - inactive, A - active; C - connect, S - static, r - ri
p, b - bgp, o - ospf, d - dhcp, v - vpn
Columns: DST-ADDRESS, GATEWAY, Distance
    DST-ADDRESS    GATEWAY D
DAC 10.1.1.0/24    ether1  0
DAC 172.16.1.0/30  ether2  0
DAC 192.168.1.0/24 bridge1 0

To fix this we need to add a route that tells the router what is the next device in the network to reach the destination.  In our example next hop is Router2, so we need to add a route with the gateway that points to the Routers 2 connected address:

[admin@MikroTik] > /ip route add dst-address=192.168.2.0/24 gateway=172.16.1.2
[admin@MikroTik] > /ip/route> print 
Flags: D - dynamic; X - disabled, I - inactive, A - active; C - connect, S - static, r - ri
p, b - bgp, o - ospf, d - dhcp, v - vpn
Columns: DST-ADDRESS, GATEWAY,       Distance
        DST-ADDRESS    GATEWAY       D
    DAC 10.1.1.0/24    ether1        0
    DAC 172.16.1.0/30  ether2        0
    DAC 192.168.1.0/24 bridge1       0
0   AS  192.168.2.0/24 172.16.1.2    

At this point packet from LAN1 will be successfully forwarded to LAN2, but we are not over yet. Router2 does not know how to reach LAN1, so any packet from LAN2 will be dropped on Router2.

If we look again at the network diagram, we can clearly see that Router2 has only one point of exit. It is safe to assume that all other unknown networks should be reached over the link to Router1. The easiest way to do this is by adding a default route: To add a default route set destination 0.0.0.0/0 or leave it blank:

/ip route add gateway=172.16.1.1

As we have seen from the example setup, there are different groups of routes, based on their origin and properties.

Routing Information

RouterOS routing information consists of two main parts:

• FIB (Forwarding Information Base), is used to make packet forwarding decisions. It contains a copy of the necessary routing information.
• RIB (Routing Information Base) contains all learned prefixes from routing protocols (connected, static, BGP, RIP, OSPF).

Routing Information Base

Routing Information Base is a database that lists entries for particular network destinations and their gateways (address of the next device along the path or simply next-hop). One such entry in the routing table is called route.

A hop occurs when a packet is passed from one network segment to another.

By default, all routes are organized in one «main» routing table. It is possible to make more than one routing table which we will discuss further in this article, but for now, for sake of simplicity, we will consider that there is only one «main» routing table.

RIB table contains complete routing information, including static routes and policy routing rules configured by the user, routing information learned from dynamic routing protocols (RIP, OSPF, BGP), and information about connected networks.

Its purpose is not just to store routes, but also to filter routing information to calculate the best route for each destination prefix, to build and update the Forwarding Information Base, and distribute routes between different routing protocols.

Connected Routes

Connected routes represent the network on which hosts can be directly reached (direct attachment to Layer2 broadcast domain). These routes are created automatically for each IP network that has at least one enabled interface attached to it (as specified in the /ip address or /ipv6 address configuration). RIB tracks the status of connected routes but does not modify them. For each connected route there is one IP address item such that:

• address part of the dst-address of the connected route is equal to a network of IP address item.
• netmask part of dst-address of the connected route is equal to the netmask part of the address of the IP address item.
• gateway of the connected route is equal to the actual-interface of the IP address item (same as an interface, except for bridge interface ports) and represents an interface where directly connected hosts from the articular Layer3 network can be reached.

Default Route

A default route is used when the destination cannot be resolved by any other route in the routing table. In RouterOS dst-address of default route is 0.0.0.0/0 (for IPv4) and ::/0 (for IPv6) routes. If the routing table contains an active default route, then the routing table lookup in this table will never fail.

Typically home router routing table contains only connected networks and one default route to forward all outgoing traffic to ISP’s gateway:

[admin@TempTest] /ip/route> print 
Flags: D - dynamic; X - disabled, I - inactive, A - active; C - connect, S - static, r - ri
p, b - bgp, o - ospf, d - dhcp, v - vpn
Columns: DST-ADDRESS, GATEWAY, Distance
#      DST-ADDRESS     GATEWAY      D
   DAd 0.0.0.0/0       10.155.125.1 1
   DAC 10.155.125.0/24 ether12      0
   DAC 192.168.1.0/24  vlan2        0

Multipath (ECMP) routes

To implement some setups, such as load balancing, it might be necessary to use more than one path to a given destination.

ECMP (Equal cost multi-path) routes have multiple gateways (next-hop) values. All reachable next-hops are copied to FIB and are used to forward packets.

These routes can be created manually, as well as dynamically by any of the dynamic routing protocols (OSPF, BGP, RIP). Multiple equally preferred routes to the same destination will have assigned + flag and grouped together automatically by RouterOS (see example below).

[admin@TempTest] /ip/route> print 
Flags: D - DYNAMIC; I - INACTIVE, A - ACTIVE; C - CONNECT, S - STATIC, m - MODEM; + - ECMP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#       DST-ADDRESS      GATEWAY       D
0   AS+ 192.168.2.0/24   10.155.125.1  1
1   AS+ 192.168.2.0/24   172.16.1.2    1

Route Selection

There can be multiple routes with the same destination received from various routing protocols and from static configurations but only one (best) destination can be used for packet forwarding. To determine the best path, RIB runs a Route Selection algorithm which picks the best route from all candidate routes per destination.

Only routes that meet the following criteria can participate in the route selection process:

• Route is not disabled.
• If the type of route is unicast it must have at least one reachable next-hop. ( if a gateway is from connected network and there is connected route active, the gateway is considered as reachable) 
• Route should not be synthetic.

The candidate route with the lowest distance becomes an active route. If there is more than one candidate route with the same distance, the selection of the active route is arbitrary.

Nexthop Lookup

Nexthop lookup is a part of the route selection process. Its main purpose is to find a directly reachable gateway address (next-hop). Only after a valid next-hop is selected router knows which interface to use for packet forwarding.

Nexthop lookup becomes more complicated if routes have a gateway address that is several hops away from this router (e.g. iBGP, multihop eBGP). Such routes are installed in the FIB after the next-hop selection algorithm determines the address of the directly reachable gateway (immediate next-hop).

It is necessary to restrict the set of routes that can be used to look up immediate next-hops. Nexthop values of RIP or OSPF routes, for example, are supposed to be directly reachable and should be looked up only using connected routes. This is achieved using scope and target-scope properties.

Routes with a scope greater than the maximum accepted value are not used for next-hop lookup. Each route specifies the maximum accepted scope value for its nexthop in the target-scope property. The default value of this property allows nexthop lookup only through connected routes, with the exception of iBGP routes that have a larger default value and can lookup nexthop also through IGP and static routes.

There are changes in RouterOS v7 nexthop lookup.

Routes are processed in scope order, and updates to routes with a larger scope cannot affect the state of nexthop lookup for routes with a smaller scope.

Consider an example from v6:

/ip route add dst-address=10.0.1.0/24 gateway=10.0.0.1
    scope=50 target-scope=30 comment=A
/ip route add dst-address=10.0.2.0/24 gateway=10.0.0.1
    scope=30 target-scope=20 comment=B
/ip route add dst-address=10.0.0.0/24 scope=20 gateway=WHATEVER
    comment=C

Gateway 10.0.0.1 is recursively resolved through C using the smallest referring scope (scope 20 from route B), both routes are active. Now we change both A and B at the same time:

/ip route set A target-scope=10

Suddenly, applying an update to route A makes the gateway of route B inactive. This is because in v6 there is only one gateway object per address.

v7 keeps multiple gateway objects per address, one for each combination of scope and gateway check.

When target-scope or gateway check of a route is changed, ROS v7 will not affect other routes, as it does in v6. In v7 target-scope and gateway check are properties that are internally attached to the gateway, not to the route.

Gateway check can be extended by setting check-gateway parameter. Gateway reachability can be checked by sending ARP probes, or ICMP messages or by checking active BFD sessions. The router periodically (every 10 seconds) checks gateway by sending either ICMP echo request (ping) or ARP request (arp). If no response from gateway is received for 10 seconds, request times out. After two timeouts gateway is considered unreachable. After receiving reply from gateway it is considered reachable and timeout counter is reset.

Route Storage

Routing information is stored to take as little memory as possible in a common case. These optimizations have non-obvious worst cases and impact on performance.

All routes and gateways are kept in a single hierarchy by the prefix/address.

    Dst [4]/0 1/0+4                             18  <-- number of prefixes
         ^  ^ ^ ^ ^
         |  | | | |
         |  | | | \- bytes taken by Route distinguisher or Interface Id
         |  | | \--- vrf/routing table
         |  | \----- AFI
         |  \------- netmask length of prefix
         \---------- bytes taken by prefix value

         [stuff subject to change without notice]
    

Each of these ‘Dst’ corresponds to a unique ‘dst-address’ of route or address of the gateway. Each ‘Dst’ requires one or more ‘T2Node’ objects as well.

All routes with the same ‘dst-address’ are kept in Dst in a list sorted by route preference.
Note: WORST CASE: having a lot of routes with the same ‘dst-address’ is really slow! even if they are inactive! because updating a sorted list with tens of thousands of elements is slow!

Route order changes only when route attributes change. If the route becomes active/inactive, the order does not change.

Each Route has three copies of route attributes:

• private — what is received from the peer, before passing in-filters.
• updated — what is the result of applying in-filters.
• current — what are the attributes currently used by the route.

Periodically (when needed), update attributes are calculated from private attributes. This happens when route update is received, or when in-filter is updated.

When the routing table is recalculated, current attributes are set to the value from updated attributes.

This means, that usually if there is no in-filter that changes route attributes, private, updated, and current share the same value.

Route attributes are kept in several groups:

• L1 Data — all flags, list of extra properties, as-path;
• L2 Data — nexthops, RIP,OSPF,BGP metrics, route tags, originators etc.
• L3 Data — distance, scope, kernel type, MPLS stuff
• extra properties — communities, originator, aggregator-id, cluster-list, unknown

Having for example many different combinations of distance and scope route attributes will use more memory!

Matching communities or as-path using regexp will cache the result, to speed up filtering. Each as-path or community value has a cache for all regexp, which is filled on-demand with match results.
Note: WORST CASE: changing attributes in ‘in-filter’ will make the route program use more memory! Because ‘private’ and ‘updated’ attributes will be different! Having a lot of different regexps will make matching slow and use a lot of memory! Because each value will have a cache with thousands of entries!

Detailed info about used memory by routing protocols can be seen in /routing stats memory menu

Forwarding Information Base

FIB (Forwarding Information Base) contains a copy of the information that is necessary for packet forwarding:

• all active routes
• policy routing rules

Each route has dst-address property, that specifies all destination addresses this route can be used for. If there are several routes that apply to a particular IP address, the most specific one (with the largest netmask) is used. This operation (finding the most specific route that matches the given address) is called »routing table lookup».

Only one Best route can be used for packet forwarding. In cases where the routing table contains several routes with the same dst-address, all equally best routes are combined into one ECMP route. The best route is installed into FIB and marked as »active».

When forwarding decision uses additional information, such as the source address of the packet, it is called policy routing. Policy routing is implemented as a list of policy routing rules, that select different routing tables based on destination address, source address, source interface, and routing mark (can be changed by firewall mangle rules) of the packet.

Routing table lookup

FIB uses the following information from the packet to determine its destination:

• source address
• destination address
• source interface
• routing mark

Possible routing decisions are:

• receive packet locally
• discard the packet (either silently or by sending an ICMP message to the sender of the packet)
• send the packet to a specific IP address on a specific interface

Run routing decision:

• check that packet has to be locally delivered (the destination address is the address of the router)
• process implicit policy routing rules
• process policy routing rules added by a user
• process implicit catch-all rule that looks up destination in the »main» routing table
• the returned result is «network unreachable»

The result of the routing decision can be:

• IP address of nexthop + interface
• point-to-point interface
• local delivery
• discard
• ICMP prohibited
• ICMP host unreachable
• ICMP network unreachable

Rules that do not match the current packet are ignored. If a rule has action:

• drop or unreachable, then it is returned as a result of the routing decision process.
• lookup then the destination address of the packet is looked up in the routing table that is specified in the rule. If the lookup fails (there is no route that matches the destination address of the packet), then FIB proceeds to the next rule.
• lookup-only similar to lookup except that lookup fails if none of the routes in the table matches the packet.

Otherwise:

• if the type of the route is blackhole, prohibit, or unreachable, then return this action as the routing decision result;
• if this is a connected route or route with an interface as the gateway value, then return this interface and the destination address of the packet as the routing decision result;
• if this route has an IP address as the value of gateway, then return this address and associated interface as the routing decision result;
• if this route has multiple values of nexthop, then pick one of them in round-robin fashion.

Show Routes

In RouterOS you have three menus to see the current state of routes in the routing table:

• /ip route — list IPv4 routes and basic properties
• /ipv6 route — list IPv6 routes and basic properties
• /routing route — list all routes with extended properties

Example output

[admin@MikroTik] /ip/route> print
Flags: D - dynamic; X - disabled, I - inactive, A - active; C - connect, S - stati
c, r - rip, b - bgp, o - ospf, d - dhcp, v - vpn
Columns: DST-ADDRESS, GATEWAY, DIstance
#       DST-ADDRESS      GATEWAY      DI
0   XS   10.155.101.0/24  1.1.1.10 
1   XS                    11.11.11.10 
   D d   0.0.0.0/0        10.155.101.1 10
2   AS   0.0.0.0/0        10.155.101.1 1
3   AS + 1.1.1.0/24       10.155.101.1 10
4   AS + 1.1.1.0/24       10.155.101.2 10
5   AS   8.8.8.8          2.2.2.2      1
   DAC   10.155.101.0/24  ether12      0


|  ||| |   |                 |         |
|  ||| |   |                 |         \----Distance
|  ||| |   |                 \--Configured gateway
|  ||| |   \-- dst prefix
|  ||| \----- ECMP flag
|  ||\------- protocol flag (bgp, osf,static,connected etc.)
|  |\-------- route status flag (active, inactive, disabled)
|  \--------- shows if route is dynamic
\----------- console order number (shown only for static editable routes)
    

routing route output is very similar to ip route except that it shows routes from all address families in one menu and lists filtered routes as well.

[admin@MikroTik] /routing/route> print
Flags: X - disabled, I - inactive, F - filtered, U - unreachable, A - active; c - connect, s - static, 
r - rip, b - bgp, o - ospf, d - dhcp, v - vpn, a - ldp-address, l - ldp-mapping
Columns: DST-ADDRESS, GATEWAY, DIStance, SCOpe, TARget-scope, IMMEDIATE-GW
     DST-ADDRESS            GATEWAY      DIS SCO TAR IMMEDIATE-GW 
Xs   10.155.101.0/24 
Xs 
d    0.0.0.0/0              10.155.101.1 10  30  10  10.155.101.1%ether12
As   0.0.0.0/0              10.155.101.1 1   30  10  10.155.101.1%ether12
As   1.1.1.0/24             10.155.101.1 10  30  10  10.155.101.1%ether12
As   8.8.8.8                2.2.2.2      1   254 254 10.155.101.1%ether12
Ac   10.155.101.0/24        ether12      0   10      ether12 
Ic   2001:db8:2::/64        ether2       0   10 
Io   2001:db8:3::/64        ether12      110 20  10 
Ic   fe80::%ether2/64       ether2       0   10 
Ac   fe80::%ether12/64      ether12      0   10      ether12 
Ac   fe80::%bridge-main/64  bridge-main  0   10      bridge-main 
A    ether12                             0   250 
A    bridge-main                         0   250 
    

routing route print detail shows more advanced info useful for debugging

[admin@MikroTik] /routing route> print detail
Flags: X - disabled, I - inactive, F - filtered, U - unreachable, A - active;
c - connect, s - static, r - rip, b - bgp, o - ospf, d - dhcp, v - vpn, a - ldp-address, l - ldp-ma>
+ - ecmp
Xs dst-address=10.155.101.0/24
Xs
d afi=ip4 contribution=best-candidate dst-address=0.0.0.0/0 gateway=10.155.101.1
immediate-gw=10.155.101.1%ether12 distance=10 scope=30 target-scope=10
belongs-to="DHCP route" mpls.in-label=0 .out-label=0 debug.fwp-ptr=0x201C2000

As afi=ip4 contribution=active dst-address=0.0.0.0/0 gateway=10.155.101.1
immediate-gw=10.155.101.1%ether12 distance=1 scope=30 target-scope=10
belongs-to="Static route" mpls.in-label=0 .out-label=0 debug.fwp-ptr=0x201C2000

Адаптировано под ROS6 и ROS7. Редакция от 28.12.2021

Введение

Статья ориентирована на начинающих администраторов Mikrotik RouterOS (далее ROS). В ней рассматривается маршрутизация с резервированием для нескольких не связанных multihomed AS каналов интернет, работающих по протоколу IPv4. Так же есть настройки для обеспечения базовой безопасности. «Автоматическая» балансировка исходящего трафика по каналам в данной статье не описана по причине того, что ее реализация на таких исходных данных — это череда компромиссов и ограничений, требующая отдельного рассмотрения. Инструментарий для «ручной» балансировки в статье содержится и приведенные настройки являются хорошей базой для добавления «автоматической» балансировки, как минимум полудюжиной способов.

Исходные данные

В качестве подопытного, выбран пятипортовый маршрутизатор Mikrotik с ROS версии 6.45+. Он будет маршрутизировать трафик между двумя локальными сетями (LAN1 и LAN2) и тремя провайдерами (ISP1, ISP2, ISP3). Канал к ISP1 имеет статический “серый” адрес, ISP2 — “белый”, получаемый по DHCP, ISP3 — “белый” с PPPoE авторизацией. Схема подключения представлена на рисунке:

Задача настроить роутер “МТК” на основе схемы так, чтобы:

1. Обеспечить автоматическое переключение на резервного провайдера.
   Основной провайдер — ISP2, первый резерв — ISP1, второй резерв — ISP3.
2. Организовать выход сети LAN1 в Интернет только через ISP1.
3. Предусмотреть возможность приоритетно маршрутизировать трафик из локальных сетей в Интернет через выбранного провайдера на основе address-list.
4. Предусмотреть возможность публикации сервисов из локальной сети в Интернет (DSTNAT)
5. Настроить фильтр файервола для обеспечения минимально достаточной безопасности со стороны Интернет.
6. Роутер мог выпускать собственный трафик через любого из трех провайдеров в зависимости от выбранного адреса источника.
7. Обеспечить маршрутизацию ответных пакетов в канал, с которого они пришли (включая LAN).

Замечание. Настраивать роутер будем “с чистого листа”, дабы гарантировать отсутствие сюрпризов в меняющихся от версии к версии стартовых конфигурациях “из коробки”. Настройки будут задаваться командами в терминале Winbox. Физическое подключение для настройки осуществляется прямым соединением с интерфейсом ether5.

Важнейшей задачей реализации мультиван является корректная маршрутизация трафика. А именно: независимо от того, в какой (или в какие)^{Примечание 3} канал(ы) провайдера смотрит маршрут по умолчанию на нашем роутере, он должен возвращать ответ именно в тот канал, с которого пакет пришел. Задача понятна. Проблема-то где? Ведь в простой локальной сети задача та же, но никто дополнительными настройками не заморачивается и беды не ощущает. Отличие в том, что любой маршрутизируемый узел в Интернет доступен через каждый из наших каналов, а не через строго конкретный, как в простой локалке. А “беда” заключается в том, что если к нам пришел запрос на IP адрес ISP3, то в нашем случае ответ уйдет через канал ISP2, поскольку туда направлен шлюз по умолчанию. Уйдет и будет отброшен провайдером, как некорректный. С проблемой определились. Как ее решать?

Решение разделим на три этапа:

1. Предварительная настройка. На этом этапе будут заданы базовые настройки маршрутизатора: локальная сеть, фаервол, address lists, hairpin NAT и пр.
2. Мультиван. На этом этапе будут промаркированы и рассортированы по таблицам маршрутизации нужные соединения.
3. Подключение к ISP. На этом этапе будут настроены интерфейсы, обеспечивающие подключение к Интернет, задействована маршрутизация и механизм резервирования каналов Интернет.

Замечание. Три разных типа подключения к ISP выбраны специально для того, чтобы показать — ничего неразрешимого в настройке мультиван с динамическими адресами нет и продемонстрировать один из вариантов решения.

Важно!

Для переключения каналов по алгоритму заданному при помощи стоимости маршрутов distance используется механизм check gateway. Скрипты, приведенные в статье, к резервированию каналов отношения не имеют и призваны автоматизировать решение проблемы динамических IP на каналах ISP2 и ISP3.

1. Предварительная настройка

1.1. Очищаем конфигурацию роутера командой:

/system reset-configuration skip-backup=yes no-defaults=yes

соглашаемся с “Dangerous! Reset anyway? [y/N]:” и, после перезагрузки, подключаемся Winbox-ом по MAC. На данном этапе конфигурация и база пользователей очищены.

1.2. В ROS 6.49+ отказываемся от смены пароля на дефолтном пользователе («Cancel» в Winbox и «Ctrl+C» в терминале) Создаем нового пользователя:

/user add group=full name=knight password=ultrasecret comment="Not horse"

логинимся под ним и удаляем дефолтного:

/user remove admin

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

1.3. Создаем базовые interface lists для удобства оперирования в фаерволе, настройках discovery и прочих MAC серверах:

/interface list add name=WAN comment="For Internet"
/interface list add name=LAN comment="For Local Area"

Подписываем комментариями интерфейсы

/interface ethernet set ether1 comment="to ISP1"
/interface ethernet set ether2 comment="to ISP2"
/interface ethernet set ether3 comment="to ISP3"
/interface ethernet set ether4 comment="to LAN1"
/interface ethernet set ether5 comment="to LAN2"

и заполняем interface lists:

/interface list member add interface=ether1 list=WAN comment=ISP1
/interface list member add interface=ether2 list=WAN comment=ISP2 
/interface list member add interface=ether3 list=WAN comment="to ISP3"
/interface list member add interface=ether4 list=LAN comment=LAN1
/interface list member add interface=ether5 list=LAN comment=LAN2

Замечание. Писать понятные комментарии стоит потраченного на это времени и сильно облегчает понимание конфигурации. Автор считает необходимым, в целях безопасности, добавить в interface list “WAN” интерфейс ether3, не смотря на то, что по нему не будет ходить протокол ip. Не забываем, что после того, как на ether3 будет поднят интерфейс PPP, его тоже нужно будет добавить в interface list “WAN”

1.4. Скрываем роутер от обнаружения соседства и управления из сетей провайдеров по МАС:

/ip neighbor discovery-settings set discover-interface-list=!WAN
/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN

1.5. Создаем минимально достаточный набор правил фильтра файрволла для защиты роутера:

/ip firewall filter add action=accept chain=input \
comment="Related Established Untracked Allow" \
connection-state=established,related,untracked

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

/ip firewall filter add action=accept chain=input \
comment="ICMP from ALL" protocol=icmp

(пинг и не только пинг. Разрешен весь icmp на вход. Весьма полезно для нахождения проблем с MTU)

/ip firewall filter add action=drop chain=input comment="All other WAN Drop" \
in-interface-list=WAN

(закрывающее цепочку input правило запрещает все остальное, что прилетает из Интернет)

/ip firewall filter add action=accept chain=forward \
comment="Established, Related, Untracked allow" \
connection-state=established,related,untracked

(правило разрешает установившиеся и родственные соединения, которые проходят сквозь роутер)

/ip firewall filter add action=drop chain=forward comment="Invalid drop" \
connection-state=invalid

(правило сбрасывает соединения, с connection-state=invalid, проходящие сквозь роутер. Оно настоятельно рекомендовано Mikrotik, но в некоторых ситуациях, например при несимметричной маршрутизации может вызывать блокировку полезного трафика)

/ip firewall filter add action=drop chain=forward \
comment="Drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN

(правило запрещает проходить сквозь роутер пакетам, которые идут из Интернет и не прошли процедуру dstnat. Это убережет локальные сети от злоумышленников, которые, находясь в одном широковещательном домене с нашими внешними сетями, пропишут в качестве шлюза наши внешние IP и, таким образом, попытаются “исследовать” наши локальные сети. )

Замечание. Примем за условие, что сети LAN1 и LAN2 являются доверенными и трафик между ними и с них не фильтруется.

1.6. Создаем список с перечнем не маршрутизируемых сетей:

/ip firewall address-list
add address=0.0.0.0/8 comment="\"This\" Network" list=BOGONS
add address=10.0.0.0/8 comment="Private-Use Networks" list=BOGONS
add address=100.64.0.0/10 comment="Shared Address Space. RFC 6598" list=BOGONS
add address=127.0.0.0/8 comment=Loopback list=BOGONS
add address=169.254.0.0/16 comment="Link Local" list=BOGONS
add address=172.16.0.0/12 comment="Private-Use Networks" list=BOGONS
add address=192.0.0.0/24 comment="IETF Protocol Assignments" list=BOGONS
add address=192.0.2.0/24 comment=TEST-NET-1 list=BOGONS
add address=192.168.0.0/16 comment="Private-Use Networks" list=BOGONS
add address=198.18.0.0/15 comment="Network Interconnect Device Benchmark Testing"\
 list=BOGONS
add address=198.51.100.0/24 comment=TEST-NET-2 list=BOGONS
add address=203.0.113.0/24 comment=TEST-NET-3 list=BOGONS
add address=224.0.0.0/4 comment=Multicast list=BOGONS
add address=192.88.99.0/24 comment="6to4 Relay Anycast" list=BOGONS
add address=240.0.0.0/4 comment="Reserved for Future Use" list=BOGONS
add address=255.255.255.255 comment="Limited Broadcast" list=BOGONS

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

Замечание. Список может изменяться, поэтому советую периодически проверять актуальность.

1.7. Настраиваем DNS для самого роутера:

/ip dns set servers=1.1.1.1,8.8.8.8

Замечание. В текущей версии ROS статически заданные серверы имен имеют приоритет перед динамическими. Запрос на разрешение имени отсылается первому серверу по порядку следования в списке. На следующий сервер переход осуществляется при недоступности текущего. Таймаут большой — более 5 сек. Возврат обратно, при возобновлении работы “упавшего сервера”, автоматически не происходит. С учетом этого алгоритма и наличия мультивана, автор рекомендует не использовать серверы, выдаваемые провайдерами.

1.8. Настраиваем локальную сеть.
1.8.1. Конфигурируем статические IP адреса на интерфейсах локальных сетей:

/ip address add interface=ether4 address=192.168.88.254/24 comment="LAN1 IP"
/ip address add interface=ether5 address=172.16.1.0/23 comment="LAN2 IP"

1.8.2. Задаем правила маршрутов к нашим локальным сетям через главную таблицу маршрутизации.
ROS6:

/ip route rule add dst-address=192.168.88.0/24 table=main comment="to LAN1"
/ip route rule add dst-address=172.16.0.0/23 table=main comment="to LAN2"

ROS7:

/routing/rule/add action=lookup dst-address=192.168.88.0/24 table=main \
comment="to LAN1"
/routing/rule/add action=lookup dst-address=172.16.0.0/23 table=main \
comment="to LAN2"

Замечание. Это один из простых и быстрых способов получить доступ к адресам локальных сетей с соурсами внешних IP адресов интерфейсов роутера, независимо от того, в какой канал ведет маршрут по умолчанию.

1.8.3. Если необходимо включаем Hairpin NAT для LAN1 и LAN2

/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN1" \
out-interface=ether4 src-address=192.168.88.0/24 to-addresses=192.168.88.254
/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN2" \
out-interface=ether5 src-address=172.16.0.0/23 to-addresses=172.16.1.0

Замечание. Это позволяет пользователям из LAN1 и LAN2 получать доступ через внешний IP (dstnat) к серверам, находящимся с пользователями в одном сегменте сети.

1.9. (Применимо для ROS7). Создаем пользовательские таблицы маршрутизации для каждого из провайдеров

/routing/table/add disabled=no fib name=to_isp1
/routing/table/add disabled=no fib name=to_isp2
/routing/table/add disabled=no fib name=to_isp3

Замечание. В ROS7 переосмыслена работа с марками и таблицами маршрутов. В ROS6, к примеру, в правиле mangle action=mark-routing опция new-routing-mark позволяла непосредственно задать имя новой марки под которую в системе автоматически создавалась таблица. В ROS7, по аналогии с iproute2 в линукс, требуется предварительное создание пользовательских таблиц. Только после этого операции с ними становятся доступны в соответствующих правилах.

2. Собственно, реализация того самого корректного мультиван

Для решения задачи “отвечать туда откуда спросили” будем использовать два инструмента ROS: connection mark и routing mark. Connection mark позволяет пометить нужное соединение и в дальнейшем работать с этой меткой, как условием для применения routing mark. А уже с routing mark возможно работать в ip route и route rules. С инструментами разобрались, теперь нужно решить какие соединения метить — раз, где именно метить — два.

С первым все просто — мы должны пометить все соединения, которые приходят в роутер из Интернет по соответствующему каналу. В нашем случае это будут три метки (по количеству каналов): “conn_isp1”, “conn_isp2” и “conn_isp3”.

Нюанс со вторым заключается в том, что входящие соединения будут двух видов: транзитные и те, которые предназначены самому роутеру. Механизм connection mark работает в таблице mangle. Рассмотрим движение пакета на упрощенной диаграмме, любезно собранной специалистами ресурса mikrotik-trainings.com (не реклама):

Следуя по стрелкам, мы видим, что пакет, приходящий в “input interface”, проходит по цепочке “Prerouting” и только потом разделяется на транзитный и локальный в блоке “Routing Decision”. Поэтому, для убиения двух зайцев, задействуем Connection Mark в таблице Mangle Prerouting цепочки Prerouting.

Замечание. В ROS метки “Routing mark” указаны в разделе Ip/Routes/Rules как “Table”, а в остальных разделах, как “Routing Mark”. Сие может внести некую путаницу в понимание, но, по сути, это одно и то же, и является аналогом rt_tables в iproute2 на linux.

2.1. Метим входящие соединения от каждого из провайдеров

/ip firewall mangle add action=mark-connection chain=prerouting \
comment="Connmark in from ISP1" connection-mark=no-mark in-interface=ether1 \
new-connection-mark=conn_isp1 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting \
comment="Connmark in from ISP2" connection-mark=no-mark in-interface=ether2 \
new-connection-mark=conn_isp2 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting \
comment="Connmark in from ISP3" connection-mark=no-mark in-interface=pppoe-isp3 \
new-connection-mark=conn_isp3 passthrough=no

Замечание.Те читатели, кто пробует буквально и в порядке чтения повторить настройку предложенную в статье, при вводе третьей команды столкнутся с ошибкой: «input does not match any value of interface». Это связано с отсутствием в данный момент интерфейса «pppoe-isp3», который будет сконфигурирован в п. 3.3.2. На данном этапе можно вместо «pppoe-isp3» ввести «ether3». После выполнения п. 3.3.2 следует вернуться и поставить актуальное имя интерфейса.

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

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” и попали к своему адресату в локальной сети.

Важно!

В ROS нет логического деления на внешний и внутренний интерфейсы. Если проследить путь движения ответного пакета по приведенной диаграмме, то он пройдет по тому же логическому пути, что и запрос:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” просто для запроса “Input Interface” был интерфейс ISP, а для ответа — LAN

2.2. Направляем ответный транзитный трафик по соответствующим таблицам маршрутизации

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Routemark transit out via ISP1" connection-mark=conn_isp1 \
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Routemark transit out via ISP2" connection-mark=conn_isp2 \
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Routemark transit out via ISP3" connection-mark=conn_isp3 \
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp3 passthrough=no

Замечание. in-interface-list=!WAN — мы работаем только с трафиком из локальной сети и dst-address-type=!local не имеющим адрес назначения адреса интерфейсов самого роутера.

То же самое для локальных пакетов, которые пришли в роутер по пути:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Input”=>”Local Process”

Важно!

Ответ пойдет по следующему пути:

”Local Process”=>”Routing Decision”=>”Output”=>”Post Routing”=>”Output Interface”

2.3. Направляем ответный локальный трафик по соответствующим таблицам маршрутизации

/ip firewall mangle add action=mark-routing chain=output \
comment="Routemark local out via ISP1" connection-mark=conn_isp1 \
dst-address-type=!local new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=output \
comment="Routemark local out via ISP2" connection-mark=conn_isp2 \
dst-address-type=!local new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=output \
comment="Routemark local out via ISP3" connection-mark=conn_isp3 \
dst-address-type=!local new-routing-mark=to_isp3 passthrough=no

На этом этапе задачу подготовки к отправке ответа в тот канал Интернет, с которого пришел запрос, можно считать решенной. Все помечено, промаркировано и готово маршрутизироваться.
Отличным “побочным” эффектом такой настройки является возможность работы проброса портов DstNAT с обоих (ISP2, ISP3) провайдеров одновременно. Не на всех, так как на ISP1 у нас не маршрутизируемый адрес. Этот эффект важен, например, для почтового сервера с двумя MХ, которые смотрят в разные каналы Интернет или для сервиса доступного через DNS имя, разрешающееся в IP адреса обоих провайдеров.

Для устранения нюансов работы локальных сетей с внешними IP роутера используем решения из пп. 1.8.2 и 3.1.2.6.

Кроме того, можно задействовать инструмент с маркировками и для решения пункта 3 задачи. Реализуем так:

2.4. Направляем трафик от локальных клиентов из списков маршрутизации в соответствующие таблицы

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Address List via ISP1" dst-address-list=!BOGONS new-routing-mark=to_isp1 \
passthrough=no src-address-list=Via_ISP1

/ip firewall mangle add action=mark-routing chain=prerouting \
comment="Address List via ISP3" dst-address-list=!BOGONS new-routing-mark=to_isp3 \
passthrough=no src-address-list=Via_ISP3

Замечание. Этот набор правил дан для примера. Считаю нужным обратить внимание на следующее:
— При всего двух каналах интернет разумно задать только одно правило. Для резервного канала.
— При нескольких каналах так же не имеет смысла делать правило для основного провайдера.
— Текущие настройки резервирования, при отказе «целевого» канала интернет предусматривают выход маркированного трафика через резервный канал(ы).
— Нужно помнить, что правила обрабатываются последовательно, в порядке написания. Это важно, если разные address-list содержат пересекающиеся адреса/сети. Без passthrough сработает первое встреченное правило, с passthrough – последнее. Учитывайте это при указании перекрывающихся диапазонов сетей в разных address-list.

По итогу, это выглядит приблизительно так (картинка кликабельна):

3. Настраиваем подключение к ISP и задействуем маршрутизацию по маркам

3.1. Настраиваем подключение к ISP1:
3.1.1. Конфигурируем статический IP адрес

/ip address add interface=ether1 address=100.66.66.2/30 comment="ISP1 IP"

3.1.2. Настраиваем статическую маршрутизацию:
3.1.2.1. Добавляем “аварийный” маршрут по умолчанию

/interface bridge add name=br-lo comment="Loopback interface"
/ip route add distance=254 gateway=br-lo comment="Emergency route"

Замечание. Этот маршрут позволяет трафику от локальных процессов проходить этап Route Decision независимо от состояния каналов любого из провайдеров. Нюанс исходящего локального трафика заключается в том, что чтобы пакет хоть куда-то двинулся, в основной таблице маршрутизации должен присутствовать активный маршрут до шлюза по умолчанию. Если его нет, то пакет просто будет уничтожен.

В качестве расширения инструмента check gateway для более глубокого анализа состояния канала предлагаю использовать метод рекурсивных маршрутов. Суть метода заключается в том, что мы указываем маршрут через промежуточный шлюз. Соответственно check gateway будет проверять доступность именно его, а не шлюза провайдера. В качестве таких “проверочных” шлюзов будут выбраны 4.2.2.1, 4.2.2.2 и 4.2.2.3 (это публичные адреса Level3DNS) соответственно для ISP1, ISP2 и ISP3. Можете выбрать любые другие доступные адреса, исходя из собственных предпочтений.

3.1.2.2. Задаем маршрут до “проверочного” адреса

/ip route add check-gateway=ping comment="For recursion via ISP1" \
distance=1 dst-address=4.2.2.1 gateway=100.66.66.1 scope=11

Замечание. В ROS7, относительно ROS6, несколько изменились условия построения рекурсивных маршрутов. Поэтому будем использовать универсальное решение, которое годится для обеих версий ROS. Суть его в том, что значение scope “базового маршрута” должно быть большим значения target-scope и равным target-scope рекурсивного маршрута.

3.1.2.3. Рекурсивный маршрут по умолчанию для трафика без routing mark

/ip route add check-gateway=ping comment="Unmarked via ISP1" \
distance=2 gateway=4.2.2.1 target-scope=11

Замечание. Значение distance=2 используется потому, что ISP1 по условиям задачи заявлен как первый резервный.

3.1.2.4. Рекурсивный маршрут по умолчанию для трафика c routing mark “to_isp1”
ROS6:

/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1 \
routing-mark=to_isp1 target-scope=11

ROS7 (в данном случае routing-mark заменяем на routing-table):

/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1 \
routing-table=to_isp1 target-scope=11

Замечание. Собственно, здесь мы наконец-то начинаем пользоваться плодами той подготовительной работы, что была проведена в пункте 2. По этому маршруту весь трафик, который имеет марку(таблицу) “to_isp1”, будет направлен на шлюз первого провайдера не зависимо от того, какой в данный момент активен шлюз по умолчанию для таблицы main.

3.1.2.5. Первый резервный рекурсивный маршрут по умолчанию для маркированного трафика провайдеров ISP2 и ISP3
ROS6:

/ip route add comment="Marked via ISP2 Backup1" distance=2 gateway=4.2.2.1 \
routing-mark=to_isp2 target-scope=11
/ip route add comment="Marked via ISP3 Backup1" distance=2 gateway=4.2.2.1 \
routing-mark=to_isp3 target-scope=11

ROS7 (в данном случае routing-mark заменяем на routing-table):

/ip route add comment="Marked via ISP2 Backup1" distance=2 gateway=4.2.2.1 \
routing-table=to_isp2 target-scope=11
/ip route add comment="Marked via ISP3 Backup1" distance=2 gateway=4.2.2.1 \
routing-table=to_isp3 target-scope=11

Замечание. Эти маршруты нужны, в том числе, для резервирования трафика с локальных сетей, которые состоят членами address list “to_isp*”’

3.1.2.6. Прописываем маршрут для локального трафика роутера в интернет через ISP1
ROS6:

/ip route rule add comment="From ISP1 IP to Inet" src-address=100.66.66.2 table=to_isp1

ROS7:

/routing/rule/add action=lookup comment="From ISP1 IP to Inet" \
src-address=100.66.66.2 table=to_isp1

Замечание. В сочетании с правилами из пункта 1.8.2, обеспечивается выход в нужный канал с заданным соурсом. Это является критичным для построения туннелей, в которых задается IP адрес локальной стороны(EoIP, IP-IP, GRE, L2TP etc.). Поскольку правила в ip route rules выполняются сверху вниз, до первого совпадения условий, то данное правило должно быть после правил из пункта 1.8.2.

3.1.3. Прописываем правило NAT для исходящего трафика

/ip firewall nat add action=src-nat chain=srcnat comment="NAT via ISP1" \
ipsec-policy=out,none out-interface=ether1 to-addresses=100.66.66.2

Замечание. NATим все выходящее, кроме того, что попадает в политики IPsec. Я стараюсь не использовать action=masquerade без крайней необходимости. Оно работает медленнее и более ресурсоемко, чем src-nat, поскольку для каждого нового соединения вычисляет адрес для NAT. Однако стоит помнить о таких свойствах masquerade как очистка соединений при падении канала и нюансы выбора адреса, если их на интерфейсе несколько и они из разных сетей.

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

/ip firewall mangle add action=route chain=prerouting \
comment="Address List via ISP1 only" dst-address-list=!BOGONS passthrough=no \
route-dst=100.66.66.1 src-address-list=Via_only_ISP1 place-before=0

Замечание. action=route имеет более высокий приоритет и применяется раньше остальных правил маршрутизации. place-before=0 — помещает наше правило первым в списке.

3.2. Настраиваем подключение к ISP2.

Поскольку провайдер ISP2 настройки нам выдает по DHCP, разумно настройку и вероятные изменения делать скриптом, который стартует при срабатывании DHCP клиента
ROS6:

/ip dhcp-client
add add-default-route=no disabled=no interface=ether2 script=":if (\$bound=1) do={\r\
    \n   /ip route remove [ find gateway=\"4.2.2.2\" ]; /ip route remove [ find where \
dst-address ~\"4.2.2.2\" ]\r\
    \n   /ip route add check-gateway=ping comment=\"For recursion via ISP2\" distance=1 \
dst-address=4.2.2.2/32 gateway=\$\"gateway-address\" scope=11\r\
    \n   /ip route add check-gateway=ping comment=\"Unmarked via ISP2\" \
distance=1 gateway=4.2.2.2 target-scope=11\r\
    \n   /ip route add comment=\"Marked via ISP2 Main\" distance=1 gateway=4.2.2.2 \
routing-mark=to_isp2 target-scope=11\r\
    \n   /ip route add comment=\"Marked via ISP1 Backup1\" distance=2 gateway=4.2.2.2 \
routing-mark=to_isp1 target-scope=11\r\
    \n   /ip route add comment=\"Marked via ISP3 Backup2\" distance=3 gateway=4.2.2.2 \
routing-mark=to_isp3 target-scope=11\r\
    \n   :if [:tobool ([/ip firewall nat find comment=\"NAT via ISP2\"])] do={\r\
    \n   /ip firewall nat set [find comment=\"NAT via ISP2\"] action=src-nat \
chain=srcnat ipsec-policy=out,none out-interface=\$\"interface\" \
to-addresses=\$\"lease-address\" \r\
    \n    } else={/ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=\$\"interface\" to-addresses=\$\"lease-address\" \
    comment=\"NAT via ISP2\"}\r\
    \n   :if [:tobool ([/ip route rule find comment=\"From ISP2 IP to Inet\"])] do={\r\
    \n      /ip route rule set [find comment=\"From ISP2 IP to Inet\"] \
src-address=\$\"lease-address\" table=to_isp2\r\
    \n    } else={/ip route rule add comment=\"From ISP2 IP to Inet\" \
src-address=\$\"lease-address\" table=to_isp2}\r\
    \n} else={\r\
    \n   /ip route remove [find gateway=\"4.2.2.2\"]; /ip route remove [find where \
dst-address ~\"4.2.2.2\"]\r\
    \n   /ip firewall nat remove  [find comment=\"NAT via ISP2\"]\r\
    \n   /ip route rule remove [find comment=\"From ISP2 IP to Inet\"]\r\
    \n}\r\
    \n" use-peer-dns=no use-peer-ntp=no

ROS7:

/ip dhcp-client
add add-default-route=no dhcp-options=clientid,clientid interface=ether2 \
script=":if (\$bound=1) do={\r\
    \n   /ip route remove [ find gateway=\"4.2.2.2\" ]; /ip route remove \
[ find where dst-address ~\"4.2.2.2\" ]\r\
    \n   /ip route add check-gateway=ping comment=\"For recursion via ISP2\" distance=1 \
dst-address=4.2.2.2/32 gateway=\$\"gateway-address\" scope=11\r\
    \n   /ip route add check-gateway=ping comment=\"Unmarked via ISP2\" \
distance=1 gateway=4.2.2.2 target-scope=11\r\
    \n   /ip route add comment=\"Marked via ISP2 Main\" distance=1 gateway=4.2.2.2 \
routing-table=to_isp2 target-scope=11\r\
    \n   /ip route add comment=\"Marked via ISP1 Backup1\" distance=2 gateway=4.2.2.2 \
routing-table=to_isp1 target-scope=11\r\
    \n   /ip route add comment=\"Marked via ISP3 Backup2\" distance=3 gateway=4.2.2.2 \
routing-table=to_isp3 target-scope=11\r\
    \n   :if [:tobool ([/ip firewall/nat/ find comment=\"NAT via ISP2\"])] do={\r\
    \n   /ip firewall nat set [find comment=\"NAT via ISP2\"] action=src-nat \
chain=srcnat ipsec-policy=out,none out-interface=\$\"interface\" \
to-addresses=\$\"lease-address\" \r\
    \n    } else={/ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=\$\"interface\" to-addresses=\$\"lease-address\" \
comment=\"NAT via ISP2\"}\r\
    \n    :if [:tobool ([/routing/rule find comment=\"From ISP2 IP to Inet\"])] do={\r\
    \n      /routing/rule/set [find comment=\"From ISP2 IP to Inet\"] \
action=lookup src-address=\$\"lease-address\" table=to_isp2\r\
    \n    } else={/routing/rule/add action=lookup comment=\"From ISP2 IP to Inet\" \
src-address=\$\"lease-address\" table=to_isp2 }\r\
    \n} else={\r\
    \n   /ip route remove [find gateway=\"4.2.2.2\"]; /ip route remove [find where \
dst-address ~\"4.2.2.2\"]\r\
    \n   /ip firewall nat remove  [find comment=\"NAT via ISP2\"]\r\
    \n   /routing/rule/remove [find comment=\"From ISP2 IP to Inet\"]\r\
    \n}\r\
    \n" use-peer-dns=no use-peer-ntp=no

:if ($bound=1) do={
   /ip route remove [ find gateway="4.2.2.2" ]; /ip route remove [ find where \
dst-address ~"4.2.2.2" ]
   /ip route add check-gateway=ping comment="For recursion via ISP2" distance=1 \
dst-address=4.2.2.2/32 gateway=$"gateway-address" scope=11
   /ip route add check-gateway=ping comment="Unmarked via ISP2" distance=1 \
gateway=4.2.2.2 target-scope=11
   /ip route add comment="Marked via ISP2 Main" distance=1 gateway=4.2.2.2 \
routing-mark=to_isp2 target-scope=11
   /ip route add comment="Marked via ISP1 Backup1" distance=2 gateway=4.2.2.2 \
routing-mark=to_isp1 target-scope=11
   /ip route add comment="Marked via ISP3 Backup2" distance=3 gateway=4.2.2.2 \
routing-mark=to_isp3 target-scope=11
   :if [:tobool ([/ip firewall nat find comment="NAT via ISP2"])] do={
    /ip firewall nat set [find comment="NAT via ISP2"] action=src-nat chain=srcnat \
ipsec-policy=out,none out-interface=$"interface" to-addresses=$"lease-address" 
    } else={ /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=$"interface" to-addresses=$"lease-address" comment="NAT via ISP2"}
   :if [:tobool ([/ip route rule find comment="From ISP2 IP to Inet"])] do={
      /ip route rule set [find comment="From ISP2 IP to Inet"] \
src-address=$"lease-address" table=to_isp2
    } else={ /ip route rule add comment="From ISP2 IP to Inet" \
src-address=$"lease-address" table=to_isp2}
} else={
   /ip route remove [find gateway="4.2.2.2"]; /ip route remove [find where \
dst-address ~"4.2.2.2"]
   /ip firewall nat remove  [find comment="NAT via ISP2"]
   /ip route rule remove [find comment="From ISP2 IP to Inet"]
}

:if ($bound=1) do={
   /ip route remove [ find gateway="4.2.2.2" ]; /ip route remove \
[ find where dst-address ~"4.2.2.2" ]
   /ip route add check-gateway=ping comment="For recursion via ISP2" distance=1 \
dst-address=4.2.2.2/32 gateway=$"gateway-address" scope=11
   /ip route add check-gateway=ping comment="Unmarked via ISP2" distance=1 \
gateway=4.2.2.2 target-scope=11
   /ip route add comment="Marked via ISP2 Main" distance=1 gateway=4.2.2.2 \
routing-table=to_isp2 target-scope=11
   /ip route add comment="Marked via ISP1 Backup1" distance=2 gateway=4.2.2.2 \
routing-table=to_isp1 target-scope=11
   /ip route add comment="Marked via ISP3 Backup2" distance=3 gateway=4.2.2.2 \
routing-table=to_isp3 target-scope=11
   :if [:tobool ([/ip firewall/nat/ find comment="NAT via ISP2"])] do={
    /ip firewall nat set [find comment="NAT via ISP2"] action=src-nat chain=srcnat \
ipsec-policy=out,none out-interface=$"interface" to-addresses=$"lease-address" 
    } else={ /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=$"interface" to-addresses=$"lease-address" comment="NAT via ISP2" }
    :if [:tobool ([/routing/rule find comment="From ISP2 IP to Inet"])] do={
      /routing/rule/set [find comment="From ISP2 IP to Inet"] action=lookup \
src-address=$"lease-address" table=to_isp2
    } else={ /routing/rule/add action=lookup comment="From ISP2 IP to Inet" \
src-address=$"lease-address" table=to_isp2 }
} else={
   /ip route remove [ find gateway="4.2.2.2" ]; /ip route remove [ find where \
dst-address ~"4.2.2.2" ]
   /ip firewall nat remove  [find comment="NAT via ISP2"]
   /routing/rule/remove [find comment="From ISP2 IP to Inet"]
}

Замечание. Первая часть скрипта срабатывает при успешном получении аренды, вторая — после освобождения аренды.^{Примечание 2}

Важно!

В отдельных случаях шлюз может не отвечать на ICMP запросы. C этим можно встретиться на lte подключении в режиме passthrough или если провайдер фильтрует ICMP на шлюз. В такой ситуации для маршрута «For recursion via ISP(x)» вместо check-gateway=ping можно указывать check-gateway=arp.

3.3. Настраиваем подключение к провайдеру ISP3.

Поскольку провайдер настройки нам выдает динамические, то разумно необходимые изменения делать скриптами, которые стартуют после поднятия и после падения интерфейса ppp.

Замечание. Интерфейс ppp может быть указан в качестве шлюза вместо IP адреса. Однако в таком варианте рекурсивный маршрут задействовать не получится. Посему мы получаем в переменную IP адрес стороны провайдера и используем ее дальше точно так же, как и для остальных провайдеров

3.3.1. Сначала конфигурируем профиль
ROS6:

/ppp profile
add comment="for PPPoE to ISP3" interface-list=WAN name=isp3_client \
on-down="/ip route remove [find gateway=\"4.2.2.3\"]\r\
    \n/ip route remove [find where dst-address ~\"4.2.2.3\"]\r\
    \n/ip firewall nat remove  [find comment=\"NAT via ISP3\"]\r\
    \n/ip route rule remove [find comment=\"From ISP3 IP to Inet\"]" \
on-up="/ip route remove [find gateway=\"4.2.2.3\"]; \r\
    \n/ip route remove [find where dst-address ~\"4.2.2.3\"]\r\
    \n/ip route add check-gateway=ping comment=\"For recursion via ISP3\" distance=1 \
dst-address=4.2.2.3/32 gateway=\$\"remote-address\" scope=11\r\
    \n/ip route add check-gateway=ping comment=\"Unmarked via ISP3\" \
distance=3 gateway=4.2.2.3 target-scope=11\r\
    \n/ip route add comment=\"Marked via ISP3 Main\" distance=1 gateway=4.2.2.3 \
routing-mark=to_isp3 target-scope=11\r\
    \n/ip route add comment=\"Marked via ISP1 Backup2\" distance=3 gateway=4.2.2.3 \
routing-mark=to_isp1 target-scope=11\r\
    \n/ip route add comment=\"Marked via ISP2 Backup2\" distance=3 gateway=4.2.2.3 \
routing-mark=to_isp2 target-scope=11\r\
    \n/ip firewall mangle set [find comment=\"Connmark in from ISP3\"] \
in-interface=\$\"interface\"\r\
    \n:if [:tobool ([/ip firewall nat find comment=\"NAT via ISP3\"])] do={\r\
    \n  /ip firewall nat set [find comment=\"NAT via ISP3\"] action=src-nat chain=srcnat \
ipsec-policy=out,none out-interface=\$\"interface\" to-addresses=\$\"local-address\"} \
else={\r\
    \n  /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=\$\"interface\" to-addresses=\$\"local-address\" \
comment=\"NAT via ISP3\"}\r\
    \n:if [:tobool ([/ip route rule find comment=\"From ISP3 IP to Inet\"])] \
do={\r\
    \n  /ip route rule set [find comment=\"From ISP3 IP to Inet\"] \
src-address=\$\"local-address\" table=to_isp3} else={\r\
    \n  /ip route rule add comment=\"From ISP3 IP to Inet\" \
src-address=\$\"local-address\" table=to_isp3 }"

ROS7:

/ppp profile
add interface-list=WAN name=isp3_client on-down=\
    "/ip route remove [find gateway=\"4.2.2.3\"]\r\
    \n/ip route remove [find where dst-address ~\"4.2.2.3\"]\r\
    \n/ip firewall nat remove  [find comment=\"NAT via ISP3\"]\r\
    \n/routing/rule/ remove [find comment=\"From ISP3 IP to Inet\"]" \
on-up="/ip route remove [find gateway=\"4.2.2.3\"]; \r\
    \n/ip route remove [find where dst-address ~\"4.2.2.3\"]\r\
    \n/ip route add check-gateway=ping comment=\"For recursion via ISP3\" distance=1 \
dst-address=4.2.2.3/32 gateway=\$\"remote-address\" scope=11\r\
    \n/ip route add check-gateway=ping comment=\"Unmarked via ISP3\" \
distance=3 gateway=4.2.2.3 target-scope=11\r\
    \n/ip route add comment=\"Marked via ISP3 Main\" distance=1 gateway=4.2.2.3 \
routing-table=to_isp3 target-scope=11\r\
    \nip route add comment=\"Marked via ISP1 Backup2\" distance=3 gateway=4.2.2.3 \
routing-table=to_isp1 target-scope=11\r\
    \nip route add comment=\"Marked via ISP2 Backup2\" distance=3 gateway=4.2.2.3 \
routing-table=to_isp2 target-scope=11\r\
    \nip firewall mangle set [find comment=\"Connmark in from ISP3\"] \
in-interface=\$\"interface\"\r\
    \n:if [:tobool ([/ip firewall/nat/ find comment=\"NAT via ISP3\"])] do={\r\
    \n  /ip firewall nat set [find comment=\"NAT via ISP3\"] action=src-nat chain=srcnat \
ipsec-policy=out,none out-interface=\$\"interface\" to-addresses=\$\"local-address\"} \
else={\r\
    \n  /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=\$\"interface\" to-addresses=\$\"local-address\" \
comment=\"NAT via ISP3\"}\r\
    \n:if [:tobool ([/routing/rule/ find comment=\"From ISP3 IP to Inet\"])] do={\r\
    \n  /routing/rule/ set [find comment=\"From ISP3 IP to Inet\"] action=lookup \
src-address=\$\"local-address\" table=to_isp3} else={\r\
    \n  /routing/rule/ add action=lookup comment=\"From ISP3 IP to Inet\" \
src-address=\$\"local-address\" table=to_isp3 }"

/ip route remove [find gateway="4.2.2.3"]; 
/ip route remove [find where dst-address ~"4.2.2.3"]
/ip route add check-gateway=ping comment="For recursion via ISP3" distance=1 \
dst-address=4.2.2.3/32 gateway=$"remote-address" scope=11
/ip route add check-gateway=ping comment="Unmarked via ISP3" distance=3 \
gateway=4.2.2.3 target-scope=11
/ip route add comment="Marked via ISP3 Main" distance=1 gateway=4.2.2.3 \
routing-mark=to_isp3 target-scope=11
/ip route add comment="Marked via ISP1 Backup2" distance=3 gateway=4.2.2.3 \
routing-mark=to_isp1 target-scope=11
/ip route add comment="Marked via ISP2 Backup2" distance=3 gateway=4.2.2.3 \
routing-mark=to_isp2 target-scope=11
/ip firewall mangle set [find comment="Connmark in from ISP3"] in-interface=$"interface"
:if [:tobool ([/ip firewall nat find comment="NAT via ISP3"])] do={
  /ip firewall nat set [find comment="NAT via ISP3"] action=src-nat chain=srcnat \
ipsec-policy=out,none out-interface=$"interface" to-addresses=$"local-address"} else={
  /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=$"interface" to-addresses=$"local-address" comment="NAT via ISP3"}
:if [:tobool ([/ip route rule find comment="From ISP3 IP to Inet"])] do={
  /ip route rule set [find comment="From ISP3 IP to Inet"] \
src-address=$"local-address" table=to_isp3} else={
  /ip route rule add comment="From ISP3 IP to Inet" src-address=$"local-address" \
table=to_isp3 }

/ip route remove [find gateway="4.2.2.3"]
/ip route remove [find where dst-address ~"4.2.2.3"]
/ip firewall nat remove  [find comment="NAT via ISP3"]
/ip route rule remove [find comment="From ISP3 IP to Inet"]

/ip route remove [find gateway="4.2.2.3"]; 
/ip route remove [find where dst-address ~"4.2.2.3"]
/ip route add check-gateway=ping comment="For recursion via ISP3" distance=1 \
dst-address=4.2.2.3/32 gateway=$"remote-address" scope=11
/ip route add check-gateway=ping comment="Unmarked via ISP3" distance=3 \
gateway=4.2.2.3 target-scope=11
/ip route add comment="Marked via ISP3 Main" distance=1 gateway=4.2.2.3 \
routing-table=to_isp3 target-scope=11
ip route add comment="Marked via ISP1 Backup2" distance=3 gateway=4.2.2.3 \
routing-table=to_isp1 target-scope=11
ip route add comment="Marked via ISP2 Backup2" distance=3 gateway=4.2.2.3 \
routing-table=to_isp2 target-scope=11
ip firewall mangle set [find comment="Connmark in from ISP3"] in-interface=$"interface"
:if [:tobool ([/ip firewall/nat/ find comment="NAT via ISP3"])] do={
  /ip firewall nat set [find comment="NAT via ISP3"] action=src-nat chain=srcnat \
ipsec-policy=out,none out-interface=$"interface" to-addresses=$"local-address"} else={
  /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none \
out-interface=$"interface" to-addresses=$"local-address" comment="NAT via ISP3"}
:if [:tobool ([/routing/rule/ find comment="From ISP3 IP to Inet"])] do={
  /routing/rule/ set [find comment="From ISP3 IP to Inet"] action=lookup \
src-address=$"local-address" table=to_isp3} else={
  /routing/rule/ add action=lookup comment="From ISP3 IP to Inet" \
src-address=$"local-address" table=to_isp3 }

/ip route remove [find gateway="4.2.2.3"]
/ip route remove [find where dst-address ~"4.2.2.3"]
/ip firewall nat remove  [find comment="NAT via ISP3"]
/routing/rule/ remove [find comment="From ISP3 IP to Inet"]

Замечание. Строка
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
позволяет корректно обрабатывать переименование интерфейса, поскольку работает с его ID а не отображаемым именем.

3.3.2. Теперь, используя профиль, создаем подключение ppp

/interface pppoe-client add allow=mschap2 comment="to ISP3" disabled=no \
interface=ether3 name=pppoe-isp3 password=isp3_pass profile=isp3_client \
add-default-route=no user=isp3_client

Замечание. Некоторые провайдеры «забывают» отдавать параметр «remote-address». В таком случае, при подключении скрипт настройки отработает некорректно, а в логе вы увидите такую ошибку:
pppoe,ppp,info pppoe-isp3: could not determine remote address, using xxx.xxx.xxx.xxx
Для решения этой проблемы нужно отключить check-gateway для маршрута с комментарием «For recursion via ISP3» и задать в ppp профиле IP адрес(любой фиктивный):

/ip route unset [find comment="For recursion via ISP3"] check-gateway
/ppp profile set isp3_client remote-address=169.254.69.96

Строка
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
позволяет корректно обрабатывать переименование интерфейса, поскольку работает с его идентификатором в системе а не отображаемым именем.

В качестве последнего штриха настроим часы
ROS6:

/system ntp client set enabled=yes \
server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org

ROS7:

/system ntp client set enabled=yes \
servers=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org

Для тех, кто дочитал до конца

Предложенный способ реализации мультиван — есть личное предпочтение автора и не является единственно возможным. Инструментарий ROS обширен и гибок, что с одной стороны вызывает сложности для начинающих, с другой — причина популярности. Изучайте, пробуйте, открывайте для себя новые инструменты и решения. Например, в качестве применения полученных знаний, можно в данной реализации мультиван заменить инструмент Сheck-gateway с рекурсивными маршрутами на Netwatch. Так же можно для повышения надежности использовать каскад рекурсивных маршрутов, что уменьшит количество ложных переключений при временной недоступности хоста, выбранного в качестве «базового». А такое иногда случается, даже со сверхнадежными anycast адресами.

Примечания

1. Check-gateway — механизм, который позволяет деактивировать маршрут после двух подряд не успешных проверок шлюза на доступность. Проверка осуществляется раз в 10 секунд, плюс таймаут ответа. Итого, фактический тайминг переключения лежит в диапазоне 20-30 секунд. Если такой тайминг переключения не достаточен — есть вариант воспользоваться инструментом Netwatch, где таймер проверки можно задавать вручную и использовать пользовательские скрипты для более тонкого анализа состояния.
   Механизм Check-gateway не срабатывает при периодических потерях пакетов в канале. Важно! Деактивация/активация маршрута механизмом Check-gateway влечет за собой деактивацию/активацию всех остальных маршрутов, которые идут через тот же шлюз. Поэтому включать check-gateway для всех связанных маршрутов нет необходимости.
2. Бывает, что в механизме работы DHСP происходит сбой, который выглядит, как клиент подвисший в состоянии renew. В таком случае вторая часть скрипта не отработает, но корректно ходить трафику не помешает, поскольку состояние отслеживает соответствующий рекурсивный маршрут.
3. ECMP (Equal Cost Multi-Path) — в ROS есть возможность задать маршрут с несколькими шлюзами и одинаковой distance. В таком случае соединения будут распределяться по каналам, используя алгоритм round robin, пропорционально количеству указанных шлюзов.

За толчок к написанию статьи, помощь при формировании ее структуры и расстановке акцентов — личная благодарность Евгению @jscar

Когда нужно применять статическую маршрутизацию в MikroTik

Любая корпоративная сеть, как правило состоит из многоуровневой коммутации как на уровне самого роутера, так и во внешних сервисах. В качестве примера будет сформирован список случаев, когда актуально обратиться к настройке статического маршрута(route) на маршрутизаторе(роутере) MikroTik:

• При добавлении статического адреса на какой-либо интерфейс. Это может быть как интернет соединение(ppoe, dhcp client, static address), так и обычная локальная настройка интерфейса в MikroTik.
• Для обмена данным связки L2TP\PPTP VPN сервера и узлами, которые находятся ЗА VPN клиентом. Эта частая связка, когда в качестве VPN клиента выступает не конечный узел, а установлен маршрутизатор(роутер), за которым может быть множество узлов(при объединении двух офисов).
• При использовании нескольких провайдеров и создании различных правил по балансировки нагрузке или автопереключению(резервированию) интернета.
• Когда нужно разделить узлы локальной сети на группы, каждая их которых будет использовать разные правила для выхода в интернет.
• Индивидуальные случаи, когда нужно задать предопределенное правило движение трафика для узла, которое не создаётся автоматически.

Как настроить “static routing” в MikroTik

Будет рассмотрена запись статического маршрута, с детальным описанием рабочих параметров.

Настройка находится IP→Routes

Dst. Address – конечный адресат, популярные значения

• 0.0.0.0/0 – интернет;
• 192.168.0.0/24 – подсеть;
• 192.168.0.50 – конечный узёл;

Gateway – шлюз, которому будет отправлен пакет.

Check Gateway – проверка доступности шлюза:

• arp – по наличию записи в таблице ARP;
• ping – посредством отправки icmp запросов.

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

Type – маршруты, которые не указывают nexthop для пакетов, но вместо этого выполняют некоторые другие действия с пакетами, имеют тип, отличный от обычного unicast(одноадресного). Маршрут blackhole(черная дыра) молча отбрасывает пакеты, в то время как маршруты, unreachable(недоступные) и prohibit(запрещающие), отправляют сообщение ICMP Destination Unreachable (код 1 и 13 соответственно) на адрес источника пакета.

Distance – определение приоритета заданного маршрута. Чем ниже число, те выше приоритет.

Scope\Target Scope – параметры рекурсивной маршрутизации, состоящей из этапов:

• Маршрут ищет интерфейс для отправки пакета исходя из своего значения scope и всех записей в таблице main с меньшими или равными значениями target scope
• Из найденных интерфейсов выбирается тот, через который можно отправить пакет указанному шлюзу
• Интерфейс найденной connected записи выбирается для отправки пакета на шлюз

Больше информации по использованию параметров ааа можно найти в соответствующем руководстве “Manual:Using scope and target-scope attributes →”

Routing Mark – направлять пакеты из заданной таблицы маршрутизации. Как правило этот параметр или пустой или заполняется промаркерованнымb маршрутами из раздела Mangle.

Pref. Source – задается IP адрес, от которого будет отправлен пакет. Этот параметр актуален, когда на интерфейсе несколько IP адресов.

Примеры статических маршрутов в MikroTik

Настройка статического маршрута с предварительной маркировкой пакета(раздел Mangle)

Применяется для использования разных линий интернета для разных узлов. К примеру в сети расположено два сервера, использующие внешние порты 80 и 443.

Для работы правила нужно промаркировать трафик(раздел Mangle) и указать его в параметре Routing Mark.

Ручное добавление статического маршрута для PPPOE подключения

Применяется, когда нужно изменить некоторые параметры в автоматическом добавлении маршрута(Add default route)

Настройка резервного интернет канала

В качестве параметра переключателя между провайдера используется параметр Distance. Трафик в этом случае направляется в тот маршрут, значение Distance которого МЕНЬШЕ,

Балансировка нагрузки для двух интернет каналов

Осуществляется через почередное указание шлюзов провайдера. Параметром Gateway можно задавать не только последовательность, но и управлять количественной частью. К примеру, если вам нужно чтобы к провайдеру со шлюзом 11.11.11.11 уходило в 2 раза больше трафика(или там канал в 2 раза быстрее) достаточно этот шлюз указать два раза.

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

В качестве шлюза указывается IP адрес VPN клиента. Использование таких маршрутов в MikroTik популярно, когда в качестве L2TP или PPTP VPN клиента выступает роутер, со своей подсетью.

Из статьи Вы узнаете, что такое Policy-based Routing (PBR), как он используется и настраивается на маршрутизаторах MikroTik.

Стандартная маршрутизация основывается на адресе назначения (dst. address). Например, на маршрутизатор прилетает ip-пакет с такими полями в заголовке: src. address = 192.168.0.5, dst. address = 8.8.8.8. Маршрутизатор, в этом случае, ищет маршрут основываясь только на dst. address. Если маршрут для адреса найден, то пакет отправляется по маршруту на другой роутер (в другую подсеть).

При этом, более тонкие маршруты (маршруты с большей маской подсети) являются более приоритетными. Так, например, если маршрутизатор имеет два маршрута: 8.8.8.8/24 -> 10.10.10.1 и 0.0.0.0/0 -> 10.10.11.1, то пакет с dst. address = 8.8.8.8 будет маршрутизирован на 10.10.10.1, а пакет с dst. address = 1.1.1.1 будет отправлен на 10.10.11.1.

В примере выше, 10.10.10.1 или 10.10.11.1 это следующий роутер, его ещё называют next hop. Это может быть — роутер провайдера, или ваш другой роутер. То-есть создавая обычный маршрут, мы указываем:

• направление (dst. address), например 8.8.8.8/24 или 0.0.0.0/0;
• и адрес следующего роутера (next hop), например 10.10.10.1.

А если для пакета маршрут не будет найден то такой пакет будет отброшен.

Policy-based Routing (PBR) — это маршрутизация, при которой маршрут выбирается основываясь не тольно на dst. address, а ещё на каких-нибудь других параметрах. Основанием для выбора маршрута в этом случае может быть: src. address, src. port, dst. port, protocol и другое.

Также, используя PBR на MikroTik, можно создавать несколько таблиц маршрутизации. Это может пригодиться для использования двух провайдеров на одном маршрутизаторе. Таблица маршрутизации содержит список маршрутов. В одной таблице может быть один список маршрутов, а в другой — список маршрутов будет другим. И, с помощью PBR инструментов, мы можем помещать пакеты в другую таблицу маршрутизации.

Ниже я разбираю инструменты доступные в маршрутизаторах MikroTik для настройки PBR и небольшие примеры их использования. Но в статье не будет примера настройки dual wan (двух провайдеров на одном роутере), это тема для другой статьи.

Создание двух маршрутов по умолчанию

И так, на роутере Mikrotik, уже настроена адресация:

/ip address
add address=192.168.0.1/24 comment=lan interface=ether2 network=192.168.0.0
add address=10.10.10.5/24 comment=wan1 interface=ether3 network=10.10.10.0
add address=10.10.11.5/24 comment=wan2 interface=ether4 network=10.10.11.0

То есть, у меня 3 интерфейса и 3 ip-адреса:

• lan — 192.168.0.1/24;
• wan1 — 10.10.10.5/24;
• wan2 — 10.10.11.5/24;

После создания таких ip-адресов, у меня создались следующие connected маршруты:

Connected маршруты — это маршруты связанные с интерфейсом, на который был назначен ip-адресс. То есть, мы назначили на ether2 адрес 192.168.0.1/24, и получили маршрут 192.168.0.0/24 > ether2.

Теперь нам нужно прописать маршрут по умолчанию (dst. address = 0.0.0.0/0) на шлюз нашего провайдера. Но что делать, если у нас 2 провайдера. Если мы просто создадим два маршрута по умолчанию, то один из них станет не активным:

И действительно, в одной таблице маршрутизации не может быть двух маршрутов с одинаковыми направлениями (dts. address). Кстати, в 7 версии RouterOS, в этом случае второй маршрут окажется активным, так как автоматически включается ECMP, но этот протокол в этой статье я не рассматриваю. И все проделываю на 6 версии (6.48.6).

А чтобы создать два маршрута с одинаковым dst. address нужно на втором маршруте указать Routing Mark. Вот так создаются два маршрута по умолчанию, при этом второй будет в своей таблице маршрутизации:

/ip route
add comment=isp2 distance=1 gateway=10.10.11.1 routing-mark=2
add comment=isp1 distance=1 gateway=10.10.10.1

А вот так это выглядит в окне WinBox:

Первый маршрут (0.0.0.0/0 > 10.10.10.1) находится в основной таблице маршрутизации, которая называется main. А второй маршрут (0.0.0.0/0 > 10.10.11.1) находится в новой таблице маршрутизации, которая получила название от Routing Mark — 2. Не обязательно использовать только цифры в названиях, можно было её назвать isp2 или по другому.

И чтобы клиенты выходили через роутер в интернет необходимо настроить nat:

/ip firewall nat
add action=src-nat chain=srcnat comment=wan1 out-interface=ether3 to-addresses=10.10.10.5
add action=src-nat chain=srcnat comment=wan2 out-interface=ether4 to-addresses=10.10.11.5

Получилась вот такая схема сети:

Выбор таблицы маршрутизации (routes / rule)

В предыдущем пункте мы создали два маршрута по умолчанию (0.0.0.0/0) в разных таблицах маршрутизации. Трафик, по умолчанию, всегда выберет маршрут в таблице main (это главная таблица маршрутизации на роутере). Но, мы можем поместить трафик во вторую таблицу маршрутизации используя инструмент ip / routes / rule.

Например, создадим правило, которое помещает пакеты во вторую таблицу маршрутизации, если адрес источника равен 192.168.0.6:

/ip route rule
add src-address=192.168.0.6/32 table=2

Вот так это выглядит в окне WinBox:

То есть пакеты от компьютера с адресом 192.168.0.6 будут помещены во вторую таблицу маршрутизации. А в ней есть маршрут — 0.0.0.0/0 > 10.10.11.1. Получается что трафик с компьютера 192.168.0.6 пойдет через второго провайдера, а все остальные компьютеры будут работать через первого провайдера.

Исходящий трафик от MikroTik через 2-ого провайдера

Исходящим трафиком от самого MikroTik может быть:

• исходящий vpn;
• отправка email;
• ping с самого роутера;
• и другое.

Чтобы выпустить такой трафик через второго провайдера, нужно поместить его во вторую таблицу маршрутизации. Это делается с помощью правила IP / Firewall / Mangle:

/ip firewall mangle
add action=mark-routing chain=output dst-address=0.0.0.0/0 new-routing-mark=2 passthrough=no

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

Что делать, если локальные сети у провайдеров одинаковые

В предыдущем примере у нас локальные сети провайдеров разные:

• 10.10.10.0/24 — у первого провайдера;
• 10.10.11.0/24 — у второго провайдера.

А если бы они были абсолютно одинаковые и вам бы, в добавок, выдали одинаковые ip-адреса для wan:

• Провайдер 1 — ip 10.10.10.5, gw — 10.10.10.1;
• Провайдер 2 — ip 10.10.10.5, gw — 10.10.10.1.

В этом случае применяем VRF:

В консоли это будет выглядеть так:

/ip route vrf
add interfaces=ether4 routing-mark=2

После проделанного, у вас должно получиться примерно следующее:

Я поменял ip-адрес для wan второго провайдера (ether4), он стал таким-же как и у первого провайдера (ether3).

В настройках nat, я изменил адрес (to addresses) для выхода через ether4 — 10.10.10.5.

Ну и после добавления в VRF ether4 во вторую таблицу маршрутизации, у наc connected маршрут от ether4 ушел в свою таблицу маршрутизации.

Получилась следующая схема сети:

Выбор таблицы маршрутизации (ip / firewall / mangle)

Инструмент ip / routes / rule позволяет выбрать таблицу маршрутизации, основываясь на src. address, то есть на ip-адресе или подсети источника.

Но с помощью ip / firewall / mangle мы можем пометить трафик, основываясь на других параметрах. Это может быть исходящий порт, протокол, адрес лист и многое другое.

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

/ip firewall mangle
add action=mark-routing chain=prerouting comment="to isp2" new-routing-mark=2 passthrough=no src-address=192.168.0.9

Но это ещё не все. У меня второй провайдер (ether4) во второй таблице маршрутизации, для этого я использовал VRF. И нужно возвращённый трафик из интернета в локальную сеть возвращать в таблицу main. Для этого создаем в ip / routes / rule следующее правило:

/ip route rule
add dst-address=192.168.0.0/24 table=main

В окне WinBox это выглядит так:

Помещаем принятый трафик в нужную таблицу маршрутизации

Иногда нужно пометить приходящий трафик (из интернета) и поместить его в свою таблицу маршрутизации. PBR на MikroTik позволяет это сделать двумя правилами в ip / firewall / mangle:

/ip firewall mangle
add action=mark-connection chain=prerouting in-interface=ether4 new-connection-mark=from-2 passthrough=yes
add action=mark-routing chain=prerouting connection-mark=from-2 new-routing-mark=2 passthrough=no

То есть, я маркирую соединения пришедшие на ether4 (ISP2) меткой from-2. А уже все соединения с меткой from-2, помещаю в таблицу маршрутизации 2 (new-routing-mark=2).

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

Итог

Мы рассмотрели несколько инструментов MikroTik для настройки PBR:

• /ip route rule — позволяет поместить трафик в нужную таблицу маршрутизации основываясь только на src. address;
• /ip firewall mangle — позволяет пометить трафик и поместить его в нужную таблицу маршрутизации основываясь на большем числе параметров (но сильнее нагружая процессор). Трафик можно метить (new-routing-mark) в двух цепочках:
  • output — для исходящего трафика с самого роутера;
  • prerouting — для проходящего трафика через роутер, например из локальной сети в интернет;
• /ip route vrf — позволяет поместить интерфейс в нужную таблицу маршрутизации. Тогда connected маршруты для этих интерфейсов будут в своих таблицах маршрутизации.

Больше информации по маршрутизации в роутерах MikroTik вы можете получить перейдя по этим ссылкам:

• https://wiki.mikrotik.com/wiki/Manual:IP/Route
• https://help.mikrotik.com/docs/display/ROS/Routing

Спасибо за внимание!