Асновы статычнай маршрутызацыі ў Mikrotik RouterOS

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

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

Камутацыя і маршрутызацыя

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

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

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

Калі вам усё зразумела ці вы і так гэта ведалі, то чытайце далей. Астатнім настойліва рэкамендую азнаёміцца ​​з маленькай, але вельмі ёмістай. артыкулам.

Маршрутызацыя ў RouterOS і PacketFlow

Практычна ўвесь функцыянал які адносіцца да статычнай маршрутызацыі знаходзіцца ў пакеце сістэма. Пакет маршрутызацыя дадае падтрымку алгарытмаў дынамічнай маршрутызацыі (RIP, OSPF, BGP, MME), Routing Filters і BFD.

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

На PacketFlow можна вылучыць тры месцы, дзе прымаюцца рашэнні аб маршрутызацыі IP пакетаў:

1. Маршрутызацыя пакетаў, якія паступілі на роўтар. На дадзеным этапе вырашаецца сыдзе пакет лакальнаму працэсу ці будзе адпраўлены далей у сетку. Транзітныя пакеты атрымліваюць Выхадны інтэрфейс
2. Маршрутызацыя лакальных выходных пакетаў. Выходныя пакеты атрымліваюць Выхадны інтэрфейс
3. Дадатковы этап маршрутызацыі для выходных пакетаў, дазваляе змяніць рашэнне аб маршрутызацыі ў [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 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]->[+]

1. Падсетку для якой неабходна стварыць маршрут (па змаўчанні: 0.0.0.0/0)
2. IP шлюза або інтэрфейс на які будзе адпраўлены пакет (можа быць некалькі, гл. ніжэй ECMP)
3. Праверка даступнасці шлюза
4. Тып запісу
5. Дыстанцыя (метрыка) для маршруту
6. Табліца маршрутызацыі
7. IP для лакальных выходных пакетаў праз дадзены маршрут
8. Пра прызначэнне Scope і Target Scope напісана ў канцы артыкула

Флагі маршрутаў

• X - Маршрут адключаны адміністратарам (disabled=yes)
• A - Маршрут выкарыстоўваецца для перадачы пакетаў
• D - Маршрут дададзены дынамічна (BGP, OSPF, RIP, MME, PPP, DHCP, Connected)
• C — Падсетка падключана непасрэдна да маршрутызатара
• S - Статычны маршрут
• r,b,o,m — Маршрут дададзены адным з пратаколаў дынамічнай маршрутызацыі.
• B,U,P - Фільтруючы маршрут (адкідае пакеты замест перадачы)

Што паказваць у gateway: ip-адрас ці інтэрфейс?

Сістэма дазваляе ўказваць і тое, і іншае, пры гэтым не лаецца і не дае падказак, калі вы нешта зрабілі няправільна.

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

Інтэрфейс
Усё складаней і паводзіны маршрутызатара залежыць ад тыпу інтэрфейсу:

• PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*) злучэнне мяркуе наяўнасць толькі двух удзельнікаў і пакет заўсёды будзе накіраваны шлюзу для перадачы, калі шлюз выявіць, што атрымальнікам з'яўляецца ён сам, то перадасць пакет свайму лакальнаму працэсу.
  
• Ethernet мяркуе наяўнасць мноства ўдзельнікаў і будзе адпраўляць на інтэрфейс arp запыты з адрасам атрымальніка пакета, гэтыя чаканыя і цалкам нармальныя паводзіны для connected маршрутаў.
  Але пры спробе выкарыстоўваць інтэрфейс у якасці маршруту для выдаленай падсеткі вы атрымаеце наступную сітуацыю: маршрут актыўны, ping да шлюза праходзіць, але не даходзяць да атрымальніка з указанай падсеткі. Калі паглядзіце на інтэрфейс праз сніфер, то ўбачыце arp запыты з адрасамі з выдаленай падсеткі.
  

Старайцеся ўказваць ip адрас у якасці gateway заўседы калі гэта магчыма. Выключэнне - connected маршруты (ствараюцца аўтаматычна) і PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) інтэрфейсы.

OpenVPN не змяшчае PPP загалоўка, але можна выкарыстоўваць імя OpenVPN інтэрфейсу для стварэння маршруту.

More Specific Route

Асноўнае правіла маршрутызацыі. Маршрут які апісвае больш маленькую падсетку (з найбольшай маскай падсеткі) мае большы прыярытэт пры прыняцці рашэння аб маршрутызацыі пакета. Палажэнне запісаў у табліцы маршрутызацыі не мае дачынення да выбару - асноўнае правіла More Specific.

Усе маршруты з указанай схемы актыўныя (знаходзяцца ў FIB), т.я. паказваюць на розныя падсеткі і не канфліктуюць паміж сабой.

Калі адзін са шлюзаў стане недаступным, звязаны маршрут будзе лічыцца неактыўным (выдалены з FIB) і для пакетаў будзе ажыццяўляцца пошук з астатніх маршрутаў.

Маршруту з падсеткай 0.0.0.0/0 часам надаюць адмысловае значэнне і завуць "Маршрут па змаўчанні" (Default Route) або "Шлюз апошняй надзеі" (gateway of last resort). Насамрэч у ім няма нічога магічнага і ён проста ўключае ўсе магчымыя адрасы IPv4, але дадзеныя назовы добра апісваюць яго задачу - ён паказвае на шлюз, куды перасылаць пакеты для якіх няма іншых, больш дакладных, маршрутаў.

Максімальна магчымая маска падсеткі для IPv4 - /32, такі маршрут паказвае на пэўны хост і можа выкарыстоўвацца ў табліцы маршрутызацыі.

Разуменне More Specific Route з'яўляецца фундаментальным для любых прылад якія працуюць з TCP/IP.

Адлегласць

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

Калі прысутнічае некалькі маршрутаў да адной падсеткі з аднолькавай метрыкай, маршрутызатар дадаць у табліцу FIB толькі адзін з іх, кіруючыся сваёй унутранай логікай.

Метрыка можа прымаць значэнне ад 0 да 255:

• 0 — Метрыка для падключаных маршрутаў. Дыстанцыя 0 не можа быць выстаўлена адміністратарам
• 1-254 - Метрыкі даступныя адміністратару для ўстаноўкі маршрутам. Метрыкі з меншым значэннем маюць большы прыярытэт
• 255 — Метрыка даступная адміністратару для ўстаноўкі маршрутаў. У адрозненні ад 1-254, маршрут з метрыкай 255 заўсёды застаецца неактыўным і не пападае ў FIB
• Адмысловыя метрыкі. У маршрутаў атрыманых ад пратаколаў дынамічнай маршрутызацыі, ёсць стандартныя значэнні метрык

Check gateway

Check gateway – пашырэнне MikroTik RoutesOS для праверкі даступнасці шлюза па icmp ці arp. Раз у 10 секунд (змяніць нельга) на шлюз адпраўляецца запыт, калі двойчы не прыходзіць адказ маршрут лічыцца недаступным і выдаляецца з FIB. Калі check gateway адключыў маршрут праверкі, працягваецца і маршрут зноў стане актыўным пасля адной паспяховай праверкі.

Check gateway адключае запіс, у якім ён наладжаны і ўсе астатнія запісы (ва ўсіх табліцах маршрутызацыі і ecmp маршрутах) з паказаным шлюзам.

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

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

ECMP маршруты

Equal-Cost Multi-Path – адпраўка пакетаў да атрымальніка выкарыстоўваючы адначасова некалькі шлюзам з пераборам па алгарытме Round Robin.

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

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

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

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

Фільтраванне сродкамі Routing

Опцыя Type вызначае, што зрабіць з пакетам:

• unicast - адправіць на ўказаны шлюз (інтэрфейс)
• blackhole - адкінуць пакет
• prohibit, unreachable - адкінуць пакет і адправіць icmp паведамленне адпраўніку

Фільтраванне звычайна выкарыстоўваюць, калі трэба засцерагчы адпраўку пакетаў не па тым шляху, вядома можна фільтраваць падобнае праз firewall.

Пара прыкладаў

Для замацавання базавых рэчаў аб маршрутызацыі.

Тыповы хатні роўтэр

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1

1. Статычны маршрут да 0.0.0.0/0 (default route)
2. Connected маршрут на інтэрфейсе з правайдэрам
3. Connected маршрут на інтэрфейсе з лакальнай сеткай

Тыповы хатні роўтэр з PPPoE

1. Статычны маршрут да default route, дададзены аўтаматычна т.я. гэта пазначана ва ўласцівасцях падключэння
2. Connected маршрут для PPP злучэння
3. Connected маршрут на інтэрфейсе з лакальнай сеткай

Тыповы хатні роўтэр з двума правайдэрамі і рэзерваваннем

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

1. Статычны маршрут да default route праз першага правайдэра з метрыкай 1 і праверкай даступнасці шлюза
2. Статычны маршрут да default route праз другога правайдэра з метрыкай 2
3. Connected маршруты

Трафік да 0.0.0.0/0 ідзе праз 10.10.10.1, пакуль дадзены шлюз даступны, інакш перамыкаецца на 10.20.20.1

Такую схему можна лічыць рэзерваваннем канала, але яна не пазбаўлена недахопаў. Калі адбудзецца абрыў за межамі шлюза правайдэра (напрыклад усярэдзіне аператарскай сеткі), ваш роўтар аб гэтым не пазнае і працягне лічыць маршрут актыўным.

Тыповы хатні роўтэр з двума правайдэрамі, рэзерваваннем і ECMP

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.10.10.1,10.20.20.1 distance=1

1. Статычныя маршруты для праверкі chack gateway
2. Маршрут ECMP
3. Connected маршруты

Маршруты для праверкі сіняга колеру (колер неактыўных маршрутаў), але гэта не мяшае працы check gateway. У бягучай версіі (6.44) RoS аўтаматычны прыярытэт аддаецца ECMP маршруту, але лепш дадаць праверачныя маршруты ў іншыя табліцы маршрутызацыі (опцыя routing-mark)

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

Фільтраванне праз Routing

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1
add dst-address=192.168.200.0/24 gateway=10.30.30.1 distance=1
add dst-address=192.168.200.0/24 gateway=10.10.10.1 distance=2 type=blackhole

1. Статычны маршрут да default route
2. Статычны маршрут да 192.168.200.0/24 праз ipip тунэль
3. Забараняльны статычны маршрут да 192.168.200.0/24 праз маршрутызатар правайдэра

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

Routing Loop
Завеса маршрутызацыі - сітуацыя калі пакет бегае паміж маршрутызатарамі да заканчэння ttl. Звычайна з'яўляецца следствам памылкі канфігурацыі, у буйных сетках лечыцца выкарыстаннем пратаколаў дынамічнай маршрутызацыі, у невялікіх – уважлівасцю.

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

Прыклад (найпросты) як атрымаць падобны вынік:

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

Policy Base Routing і дадатковыя табліцы маршрутызацыі

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

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

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

Прыклад з размеркаваннем праз Firewall:

• 192.168.100.10 -> 8.8.8.8
  1. Трафік ад 192.168.100.10 атрымлівае пазнаку via-isp1 в [Prerouting|Mangle]
  2. На этапе Routing у табліцы via-isp1 праводзіцца пошук маршруту да 8.8.8.8
  3. Маршрут знойдзены, трафік адпраўляецца на шлюз 10.10.10.1
• 192.168.200.20 -> 8.8.8.8
  1. Трафік ад 192.168.200.20 атрымлівае пазнаку via-isp2 в [Prerouting|Mangle]
  2. На этапе Routing у табліцы via-isp2 праводзіцца пошук маршруту да 8.8.8.8
  3. Маршрут знойдзены, трафік адпраўляецца на шлюз 10.20.20.1
• Калі адзін са шлюзаў (10.10.10.1 ці 10.20.20.1) стане недаступным, то пакет сыдзе ў табліцу асноўнай і будзе шукаць прыдатны маршрут там

Праблемы тэрміналогіі

У RouterOS ёсць пэўныя праблемы з тэрміналогіяй.
Пры рабоце з правіламі ў [IP]->[Routes] указваецца табліца маршрутызацыі, хоць і напісана што метка:

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

Як адправіць пакет у пэўную табліцу маршрутызацыі

RouterOS дае некалькі інструментаў:

• Правілы ў [IP]->[Routes]->[Rules]
• Маршрутныя пазнакі (action=mark-routing) у [IP]->[Firewall]->[Mangle]
• VRF

Правілы [IP]->[Route]->[Rules]
Правілы апрацоўваюцца паслядоўна, калі пакет супаў з умовамі правіла ён не праходзіць далей.

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

Правілы складаюцца з умоў і дзеянні:

• Умовы. Практычна паўтараюць спіс прыкмет па якіх пакет правяраецца ў FIB, адсутнічае толькі ToS.
• Дзеянні
  • lookup - адправіць пакет у табліцу
  • lookup only in table - замкнуць пакет у табліцы, калі маршрут не будзе знойдзены пакет не сыдзе ў табліцу main
  • drop - адкінуць пакет
  • unreacheable — адкінуць пакет з апавяшчэннем адпраўніка

У FIB трафік да лакальных працэсаў апрацоўваецца ў абыход правіл [IP]->[Route]->[Rules]:

маркіроўка [IP]->[Firewall]->[Mangle]
Маршрутныя пазнакі дазваляюць усталёўваць шлюз для пакета выкарыстоўваючы практычна любыя ўмовы Firewall:

Практычна, таму што не ўсе з іх маюць сэнс, а некаторыя могуць працаваць нестабільна.

Маркіраваць пакет можна двума спосабамі:

• Адразу ставіць routing-mark
• Спачатку ставіць connection-mark, потым на аснове connection-mark ставіць routing-mark

У артыкуле пра firewall я пісаў, што другі варыянт пераважней т.я. зніжае нагрузку на CPU, у выпадку з маркіроўкай маршрутаў - гэта не зусім так. Паказаныя спосабы маркіроўкі не заўсёды з'яўляюцца раўнацэннымі і звычайна выкарыстоўваюцца для рашэння розных задач.

прыклады выкарыстання

Пераходзім да прыкладаў выкарыстання Policy Base Routing, на іх значна прасцей паказаць навошта ўсё гэта трэба.

MultiWAN і зваротны выходны (Output) трафік
Распаўсюджаная праблема, пры MultiWAN канфігурацыі: Mikrotik даступны з сеткі інтэрнэт толькі па "актыўным" правайдэру.

Роўтару не важна на які ip прыйшоў запыт, пры генерацыі адказу ён будзе шукаць маршрут у табліцы маршрутызацыі, дзе актыўны маршрут праз isp1. Далей такі пакет хутчэй за ўсё будзе адфільтраваны па шляху да атрымальніка.

Яшчэ адзін цікавы момант. Калі на інтэрфейсе ether1 настроены "просты" source nat: /ip fi nat add out-interface=ether1 action=masquerade пакет сыдзе ў сетку з src. address=10.10.10.100, што яшчэ больш пагоршыць сытуацыю.

Выправіць праблему можна некалькімі спосабамі, але для любога з іх запатрабуюцца дадатковыя табліцы маршрутызацыі:

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping distance=2
add dst-address=0.0.0.0/0 gateway=10.10.10.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 routing-mark=over-isp2

Выкарыстанне [IP]->[Route]->[Rules]
Указваем табліцу маршрутызацыі якая будзе выкарыстана для пакетаў з указанымі Source IP.

/ip route rule
add src-address=10.10.10.100/32 action=lookup-only-in-table table=over-isp1
add src-address=10.20.20.200/32 action=lookup-only-in-table table=over-isp2

можна выкарыстоўваць action=lookup, але для лакальнага выходнага трафіку ўказаны варыянт цалкам выключае злучэнні з няправільнага інтэрфейсу.

• Сістэма генеруе зваротны пакет з Src. Address: 10.20.20.200
• На этапе Routing Decision(2) адбываецца праверка. [IP]->[Routes]->[Rules] і пакет адпраўляецца ў табліцу маршрутызацыі over-isp2
• У адпаведнасці з табліцай маршрутызацыі пакет павінен быць адпраўлены на шлюз 10.20.20.1 праз інтэрфейс ether2

Дадзены спосаб не патрабуе працоўны Connection Tracker, у адрозненні ад выкарыстання табліцы Mangle.

Выкарыстанне [IP]->[Firewall]->[Mangle]
Злучэнне пачынаецца са ўваходнага пакета, таму маркіруем яго (action=mark-connection), для выходных пакетаў ад маркіраванага злучэння ўсталёўваем маршрутную пазнаку (action=mark-routing).

/ip firewall mangle
#Маркировка входящих соединений
add chain=input in-interface=ether1 connection-state=new action=mark-connection new-connection-mark=from-isp1
add chain=input in-interface=ether2 connection-state=new action=mark-connection new-connection-mark=from-isp2
#Маркировка исходящих пакетов на основе соединений
add chain=output connection-mark=from-isp1 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=output connection-mark=from-isp2 action=mark-routing new-routing-mark=over-isp2 passthrough=no

Калі на адным інтэрфейсе наладжана некалькі ip, можна дадаць ва ўмову dst-address для ўдакладнення.

• На інтэрфейс ether2 паступае пакет адчыняльны злучэнне. Пакет трапляе ў [INPUT|Mangle] дзе гаворыцца маркіраваць усе пакеты з злучэння як from-isp2
• Сістэма генеруе зваротны пакет з Src. Address: 10.20.20.200
• На этапе Routing Decision(2) пакет у адпаведнасці з табліцай маршрутызацыі адпраўляецца на шлюз 10.20.20.1 праз інтэрфейс ether1. Можаце пераканацца ў гэтым залагіраваўшы пакеты ў [OUTPUT|Filter]
• На этапе [OUTPUT|Mangle] адбываецца праверка на наяўнасць пазнакі злучэння from-isp2 і пакет атрымлівае маршрутскую пазнаку over-isp2
• На этапе Routing Adjusment(3) адбываецца праверка на наяўнасць маршрутнай пазнакі і адпраўка ў адпаведную табліцу маршрутызацыі
• У адпаведнасці з табліцай маршрутызацыі пакет павінен быць адпраўлены на шлюз 10.20.20.1 праз інтэрфейс ether2

MultiWAN і зваротны dst-nat трафік

Прыклад складаней, што рабіць, калі за роўтэрам знаходзіцца сервер (напрыклад web) у прыватнай падсетцы і неабходна забяспечыць доступ да яго па любому з правайдэраў.

/ip firewall nat
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether1 action=dst-nat to-address=192.168.100.100
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether2 action=dst-nat to-address=192.168.100.100

Сутнасць праблемы будзе тая ж, рашэнне падобна на варыянт з Firewall Mangle, толькі будуць выкарыстоўвацца іншыя ланцужкі:

/ip firewall mangle
add chain=prerouting connection-state=new in-interface=ether1 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp1
add chain=prerouting connection-state=new in-interface=ether2 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp2
add chain=prerouting connection-mark=web-input-isp1 in-interface=ether3 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting connection-mark=web-input-isp2 in-interface=ether3 action=mark-routing new-routing-mark=over-isp2 passthrough=no

На схеме не адлюстраваны NAT, але думаю і так усё зразумела.

MultiWAN і выходныя злучэнні

Можна выкарыстоўваць магчымасці PBR для стварэння некалькіх vpn (у прыкладзе SSTP) злучэнняў з розных інтэрфейсаў роўтара.

Дадатковыя табліцы маршрутызацыі:

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.100.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 routing-mark=over-isp3

add dst-address=0.0.0.0/0 gateway=192.168.100.1 distance=1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 distance=2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 distance=3

Маркіроўка пакетаў:

/ip firewall mangle
add chain=output dst-address=10.10.10.100 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp1 passtrough=no
add chain=output dst-address=10.10.10.101 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp2 passtrough=no
add chain=output dst-address=10.10.10.102 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp3 passtrough=no

Простыя правілы NAT, інакш пакет сыдзе з інтэрфейсу з няправільным Src. Address:

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade
add chain=srcnat out-interface=ether2 action=masquerade
add chain=srcnat out-interface=ether3 action=masquerade

Аналіз:

• Роўтар стварае тры працэсы SSTP
• На этапе Routing Decision (2) для гэтых працэсаў выбіраецца маршрут, зыходзячы з табліцы маршрутызацыі main. Ад гэтага ж маршруту пакет атрымлівае Src. Address прывязаны да інтэрфейсу ether1
• В [Output|Mangle] пакеты ад розных злучэнняў атрымліваюць розныя пазнакі
• Пакеты трапляюць у адпаведныя пазнакам табліцы на этапе Routing Adjusment і атрымлівае новы маршрут для адпраўкі пакетаў
• Але ў пакетаў усё яшчэ застаецца Src. Address ад ether1, на этапе [Nat|Srcnat] адрас падмяняецца ў адпаведнасці з інтэрфейсам

Цікава, што на роўтары вы ўбачыце наступную табліцу злучэнняў:

Connection Tracker адпрацоўвае раней [Mangle] и [Srcnat], таму ўсе злучэнні ідуць ад аднаго адраса, калі паглядзець падрабязней то ў Replay Dst. Address будуць адрасы пасля NAT:

На VPN серверы (на тэставым стэндзе ён у мяне адзін) можна ўбачыць што ўсе злучэнні адбываюцца з правільных адрасоў:

Пастой спосаб
Ёсць спосаб прасцей, можна проста пазначыць пэўны шлюз для кожнага з адрасоў:

/ip route
add dst-address=10.10.10.100 gateway=192.168.100.1
add dst-address=10.10.10.101 gateway=192.168.200.1
add dst-address=10.10.10.102 gateway=192.168.0.1

Але такія маршруты будуць уплываць не толькі на выходны, але і на транзітны трафік. Плюс, калі вам не трэба каб трафік на vpn сервера сыходзіў праз непрыдатныя каналы сувязі, то прыйдзецца дадаць яшчэ 6 правіл у [IP]->[Routes]с type=blackhole. У папярэднім варыянце - 3 правілы ў [IP]->[Route]->[Rules].

Размеркаванне злучэнняў карыстальнікаў па каналах сувязі

Простыя, паўсядзённыя задачы. Ізноў жа спатрэбяцца дадатковыя табліцы маршрутызацыі:

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2

Выкарыстоўваючы [IP]->[Route]->[Rules]

/ip route rules
add src-address=192.168.100.0/25 action=lookup-only-in-table table=over-isp1
add src-address=192.168.100.128/25 action=lookup-only-in-table table=over-isp2

Калі выкарыстоўваць action=lookup, то пры адключэнні аднаго з каналаў трафік сыдзе ў табліцу main і пайдзе па працоўным канале. Трэба гэта ці не - залежыць ад задачы.

Выкарыстоўваючы маркіроўкі ў [IP]->[Firewall]->[Mangle]
Просты прыклад са спісамі IP адрасоў. У прынцыпе можна выкарыстоўваць практычна любыя ўмовы. Адзіная перасцярога layer7, нават у пары з пазнакамі злучэнняў, можа здацца што ўсё працуе правільна, але частка трафіку ўсё роўна сыдзе не туды.

/ip firewall mangle
add chain=prerouting src-address-list=users-over-isp1 dst-address-type=!local action=mark-routing new-routing-mark=over-isp1
add chain=prerouting src-address-list=users-over-isp2 dst-address-type=!local action=mark-routing new-routing-mark=over-isp2

"Замкнуць" карыстачоў у адной табліцы маршрутызацыі можна праз [IP]->[Route]->[Rules]:

/ip route rules
add routing-mark=over-isp1 action=lookup-only-in-table table=over-isp1
add routing-mark=over-isp2 action=lookup-only-in-table table=over-isp2

Або праз [IP]->[Firewall]->[Filter]:

/ip firewall filter
add chain=forward routing-mark=over-isp1 out-interface=!ether1 action=reject
add chain=forward routing-mark=over-isp2 out-interface=!ether2 action=reject

Адступленне пра dst-address-type=!local
Дадатковая ўмова dst-address-type=!local неабходна, каб трафік ад карыстальнікаў даходзіў да лакальных працэсаў роўтара (dns, winbox, ssh, …). Калі да роўтара падключана некалькі лакальных падсетак, неабходна прадугледзець каб трафік паміж імі не сыходзіў у інтэрнэт, напрыклад выкарыстоўваючы dst-address-table.

У прыкладзе з выкарыстаннем [IP]->[Route]->[Rules] падобных выключэнняў няма, але трафік да лакальных працэсаў даходзіць. Справа ў тым, што трапляючы ў FIB пакет прамаркіраваны ў [PREROUTING|Mangle] мае маршрутную пазнаку і сыходзіць у табліцу маршрутызацыі адрозную ад main, дзе няма лакальнага інтэрфейсу. У выпадку з Routing Rules, спачатку правяраецца ці прызначаны пакет лакальнаму працэсу і толькі на этапе User PBR ён сыходзіць у зададзеную табліцу маршрутызацыі.

Выкарыстоўваючы [IP]->[Firewall]->[Mangle action=route]
Дадзенае дзеянне працуе толькі ў [Prerouting|Mangle] і дазваляе накіроўваць трафік на ўказаны шлюз без выкарыстання дадатковых табліц маршрутызацыі, паказваючы адрас шлюза напрамую:

/ip firewall mangle
add chain=prerouting src-address=192.168.100.0/25 action=route gateway=10.10.10.1
add chain=prerouting src-address=192.168.128.0/25 action=route gateway=10.20.20.1

дзеянне route мае ніжэйшы прыярытэт чым правілы маршрутызацыі ([IP]->[Route]->[Rules]). У выпадку з маршрутнымі пазнакамі ўсё залежыць ад становішча правіл, калі правіла з action=route стаіць вышэй чым action=mark-route, то будзе выкарыстана яно (незалежна ад сцяга. passtrough), інакш маркіроўка маршруту.
На wiki вельмі мала інфармацыі пра дадзенае дзеянне і ўсе высновы атрыманы эксперыментальным шляхам, у любым выпадку я не знайшоў варыянты, калі ўжыванне дадзенага варыянту дае перавагі перад іншымі.

Дынамічная балансіроўка на аснове PPC

Per Connection Classificator - з'яўляецца больш гнуткім аналагам ECMP. У адрозненні ад ECMP дзеліць трафік па злучэннях стражэйшага (ECMP нічога пра злучэнні не ведае, але ў пары з Routing Cache атрымліваецца нешта падобнае).

PCC бярэ названыя палі з ip загалоўка, пераўтворыць іх у 32-бітнае значэнне і дзеліць на назоўнік. Рэшту ад дзялення параўноўваецца з паказаным рэшткай і калі яны супадаюць, то прымяняецца названае дзеянне. Больш падрабязна. Гучыць дзіка, але працуе.

Прыклад з трыма адрасамі:

192.168.100.10: 192+168+100+10 = 470 % 3 = 2
192.168.100.11: 192+168+100+11 = 471 % 3 = 0
192.168.100.12: 192+168+100+12 = 472 % 3 = 1

Прыклад дынамічнага размеркавання трафіку па src.address паміж трыма каналамі:

#Таблица маршрутизации
/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=3 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=1 routing-mark=over-isp3

#Маркировка соединений и маршрутов
/ip firewall mangle
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/0 action=mark-connection new-connection-mark=conn-over-isp1
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/1 action=mark-connection new-connection-mark=conn-over-isp2
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/2 action=mark-connection new-connection-mark=conn-over-isp3

add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp1 action=mark-routing new-routing-mark=over-isp1
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp2 action=mark-routing new-routing-mark=over-isp2
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp3 action=mark-routing new-routing-mark=over-isp3

Пры маркіроўцы маршрутаў ёсць дадатковая ўмова: in-interface=br-lan, без яго пад action=mark-routing трапіць трафік у адказ з інтэрнэту і ў адпаведнасці з табліцамі маршрутызацыі сыдзе назад да правайдэра.

Пераключэнне каналаў сувязі

Check ping — добрая прылада, але ён правярае сувязь толькі з найблізкім IP балем, сеткі правайдэраў звычайна складаюцца з вялікай колькасці маршрутызатараў і абрыў сувязі можа адбыцца за межамі найблізкага балю, а далей ідуць магістральныя аператары сувязі ў якіх таксама могуць здарацца праблемы, увогуле check ping не заўсёды паказвае актуальную інфармацыю аб доступе ў глабальную сетку.
Калі ў правайдэраў і буйных карпарацый ёсць пратакол дынамічнай маршрутызацыі BGP, то хатнім і офісным карыстальнікам даводзіцца самастойна прыдумляць як правяраць доступ у інтэрнэт праз пэўны канал сувязі.

Звычайна выкарыстоўваюцца скрыпты, якія праз пэўны канал сувязі правяраюць даступнасць ip адраса ў сетцы інтэрнэт, пры гэтым выбіраецца нешта надзейнае, напрыклад google dns: 8.8.8.8. 8.8.4.4. Але ў супольнасці Mikrotik для гэтага прыстасавалі цікавейшая прылада.

Пары слоў пра рэкурсіўную маршрутызацыю
Рэкурсіўная маршрутызацыя неабходная пры пабудове Multihop BGP пірынгу і ў артыкул пра асновы статычнай маршрутызацыі патрапіла толькі за кошт ушлых карыстачоў MikroTik, якія прыдумалі як выкарыстоўваць рэкурсіўныя маршруты ў пары з check gateway для пераключэння каналаў сувязі без дадатковых скрыптоў.

Нетутэйша час у агульных рысах разабрацца з опцыямі scope/target scope і якім чынам маршрут прывязваецца да інтэрфейсу:

1. Маршрут шукае інтэрфейс для адпраўкі пакета зыходзячы са свайго значэння scope і ўсіх запісаў у табліцы main з меншымі ці роўнымі значэннямі target scope
2. Са знойдзеных інтэрфейсаў выбіраецца той, праз які можна адправіць пакет паказанаму шлюзу
3. Інтэрфейс знойдзенага connected запісы выбіраецца для адпраўкі пакета на шлюз

Пры наяўнасці рэкурсіўнага маршруту адбываецца ўсё тое ж самае, але ў два этапы:

• 1-3 Да connected маршрутам дадаецца яшчэ адзін, праз які можна дасягнуць паказанага шлюза
• 4-6 Пошук маршруту connected маршруту для "прамежкавага" шлюза

Усе маніпуляцыі з рэкурсіўным пошукам адбываюцца ў RIB, а ў FIB перадаецца толькі выніковы вынік: 0.0.0.0/0 via 10.10.10.1 on ether1.

Прыклад выкарыстання рэкурсіўнай маршрутызацыі для пераключэння маршрутаў

Канфігурацыя:

/ip route
add dst-address=0.0.0.0/0 gateway=8.8.8.8 check-gateway=ping distance=1 target-scope=10
add dst-address=8.8.8.8 gateway=10.10.10.1 scope=10
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

Можна праверыць, што пакеты будуць адпраўляцца на 10.10.10.1.

Check gateway нічога не ведае пра рэкурсіўную маршрутызацыю і проста адпраўляе ping'і на адрас 8.8.8.8, які (зыходзячы з табліцы main) даступны праз шлюз 10.10.10.1.

Калі адбываецца страта сувязі паміж 10.10.10.1 і 8.8.8.8, тое адбываецца адключэнне маршруту, але пакеты (уключаючы праверачныя ping) да 8.8.8.8 працягваюць ісці праз 10.10.10.1:

Калі адбываецца страта лінка на ether1, тое атрымліваецца непрыемная сітуацыя, калі пакеты да 8.8.8.8 пайдуць праз другога правайдэра:

Гэта праблема, калі вы карыстаецеся NetWatch для запуску скрыптоў пры недаступнасці 8.8.8.8. Пры абрыве лінка NetWatch проста адпрацуе па рэзервовым канале сувязі і будзе лічыць што ўсё нармальна. Вырашаецца даданнем дадатковага фільтруючага маршруту:

/ip route
add dst-address=8.8.8.8 gateway=10.20.20.1 distance=100 type=blackhole

На хабры ёсць артыкул, дзе сітуацыя з NetWatch разгледжана больш дэталёва.

І так, пры выкарыстанні падобнага рэзервавання адрас 8.8.8.8 будзе цвёрда прывязаны да аднаго з правайдэраў, адпаведна выбіраць яго ў якасці крыніцы dns не самая добрая ідэя.

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

Тэхналогія VRF прызначана для стварэння некалькіх віртуальных маршрутызатараў усярэдзіне аднаго фізічнага, дадзеная тэхналогія шырока ўжываецца ў аператараў сувязі (звычайна ў звязку з MPLS) для падавання паслугі L3VPN кліентам з перасякальнымі адрасамі падсетак:

Але VRF у Mikrotik арганізаваны на базе табліц маршрутызацыі і мае шэраг недахопаў, напрыклад лакальныя ip адрасы роўтара даступныя з усіх VRF, падрабязней можна пачытаць па спасылцы.

Прыклад канфігурацыі vrf:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.200.1/24 interface=ether2 network=192.168.200.0

З прылады падлучанага да ether2 бачым, што праходзіць ping да адрасу роўтара з іншага vrf (і гэта праблема), пры гэтым ping у інтэрнэт не сыходзіць:

Для доступу ў інтэрнэт неабходна прапісаць дадатковы маршрут, які звяртаецца да табліцы main (у тэрміналогіі vrf гэта называецца route leaking):

/ip route
add distance=1 gateway=172.17.0.1@main routing-mark=vrf1
add distance=1 gateway=172.17.0.1%wlan1 routing-mark=vrf2

Тут паказаны два спосабу route leaking: выкарыстоўваючы табліцу маршрутызацыі: 172.17.0.1@main і выкарыстоўваючы імя інтэрфейсу: 172.17.0.1%wlan1.

І наладзіць маркіроўку для трафіку ў адказ у [PREROUTING|Mangle]:

/ip firewall mangle
add chain=prerouting in-interface=ether1 action=mark-connection new-connection-mark=from-vrf1 passthrough=no
add chain=prerouting connection-mark=from-vrf1 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf1 passthrough=no 
add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=from-vrf2 passthrough=no
add chain=prerouting connection-mark=from-vrf2 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf2 passthrough=no 

Падсеткі з аднолькавым адрасаваннем
Арганізацыя доступу да падсетак з аднолькавым адрасаваннем на адным роўтары выкарыстоўваючы VRF і netmap:

Базавая канфігурацыя:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.100.1/24 interface=ether2 network=192.168.100.0
add address=192.168.0.1/24 interface=ether3 network=192.168.0.0

Правілы 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]

Фільтраванне маршрутаў (уваходны і выходных) - гэта прылада які звычайна выкарыстоўваецца разам з пратаколамі дынамічнай маршрутызацыі (таму даступны толькі пасля ўсталёўкі пакета маршрутызацыя), але ва ўваходных фільтрах ёсць два цікавыя ланцужкі:

• 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