🥇 Мултиван и маршрутизация на Mikrotik RouterOS

Въведение

Статия беше посветена на проблемите, които предизвикват интерес и размисли сред администраторите на Mikrotik RouterOS (по-нататък ROS). В нея се разглеждат само мултиван, със силен акцент върху маршрутизацията. Както бонус, са предоставени минимално необходими настройки за осигуряване на безопасна и удобна работа. Хората, които търсят информация относно опашките, балансирането на натоварването, VLAN-ите, мостовете, многослойния дълбочинен анализ на състоянието на канала и подобни теми – нека не губят време и усилия за прочит.

Изходни данни

За тестовия сценарий избраният маршрутизатор е петпортов Mikrotik с ROS версия 6.45.3. Той ще маршрутизира трафика между две локални мрежи (LAN1 и LAN2) и трима доставчици (ISP1, ISP2, ISP3). Каналът към ISP1 има статичен “сив” адрес, ISP2 – “бял

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

Да се осигури автоматично превключване на резервния доставчик. Основният доставчик е ISP2, първият резерв е ISP1, вторият резерв – ISP3.
Да се организира изходът на LAN1 в Интернет само през ISP1.
Да се предвиди възможността за маршрутизиране на трафика от локалните мрежи в Интернет през избрания доставчик на база address-list.
Да се предвиди възможността за публикуване на услуги от локалната мрежа в Интернет (DSTNAT).
Да се настрои филтър на фаервола за осигуряване на минимална достатъчна безопасност от страна на Интернет.
Роутерът да може да изпраща собствен трафик през който и да е от трите доставчика в зависимост от избрания източников адрес.
Да се осигури маршрутизация на отговорните пакети в канала, от който са дошли (включително LAN).

Забележка. Ще конфигурираме роутера “от нулата”, за да гарантираме отсъствието на изненади в променящите се от версия на версия стартови конфигурации “из коробка”. Като инструмент за настройка е избран Winbox, където промените ще бъдат визуално показани. Самите настройки ще се задават с команди в терминала на Winbox. Физическото свързване за настройка се осъществява чрез директно свързване с интерфейса Ether5.

Някои разсъждения за това какво е мултиван, дали е проблем или хитри умници плетат конспирации около него

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

Можем ли да настроим адресация на интерфейсите и подразбиращите се шлюзове? Да:

На ISP1 зададохме адрес и шлюз с distance=2 и check-gateway=ping.
На ISP2 настройката на dhcp клиента по подразбиране — съответно дистанцията ще бъде равна на единица.
На ISP3 в настройките на pppoe клиента при add-default-route=yes поставяме default-route-distance=3.

Не забравяйте да зададете NAT на изхода:

/ip firewall nat add action=masquerade chain=srcnat out-interface-list=WAN

В резултат на това, потребителите в локалната мрежа зареждат котките си щастливо през основния доставчик ISP2 и имат резервиране на канала чрез механизма check gateway Вижте забележка 1

Точка 1 от задачата е реализирана. Къде е мултиванът с неговите етикети? Не…

Долу. Нужно е да пуснем конкретни клиенти от LAN през ISP1:

/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=yes route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=no route-dst=100.66.66.1 src-address=192.168.88.0/24

Точки 2 и 3 от задачата са реализирани. Етикети, знаци, правила за маршрутизация, къде сте?!

Трябва ли да предоставим достъп до любимия OpenVPN сървър с адрес 172.17.17.17 за клиенти от интернет? Моля:

/ip cloud set ddns-enabled=yes

На клиентите даваме резултата от извода: “:put [ip cloud get dns-name]”

Настройваме пренасочването на портове от интернет:

/ip firewall nat add action=dst-nat chain=dstnat dst-port=1194
in-interface-list=WAN protocol=udp to-addresses=172.17.17.17

Точка 4 е готова.

Настройваме firewall и друга защита за точка 5, паралелно радвайки се, че при потребителите вече всичко работи и се протягаме към контейнера с любимата напитка…
А! Още тунелите забравихме.

l2tp-клиент, настроен по статия от Google, успя ли да достигне до любимия холандски VDS? Да.
l2tp-сървър с IPsec е създаден и клиентите се свързват по DNS името от IP Cloud (виж по-горе)? Да.
Отпуснат на стола, отпивайки от напитката, мързеливо разглеждаме точки 6 и 7 от задачата. Мислим — нужно ли е? Всичко така или иначе работи… Така че, ако не е нужно, тогава това е всичко. Мултиванът е реализиран.

Какво е мултиван? Това е свързването на няколко интернет канала към един рутер.

Статията след това може да не се чете, тъй като какво друго освен изхвърляния с съмнителна приложимост може да има?

С хората, които останаха, които се интересуват от точки 6 и 7 от задачата и също така усещат сърбежа на перфекционизма, навлизаме по-дълбоко.

Най-важната задача при реализацията на мултиван е правилното маршрутизиране на трафика. А именно: независимо от това в който (или в кои) вижда канал(и) на доставчика маршрута по подразбиране на нашия рутер, той трябва да връща отговор точно по канала, от който е дошъл пакета. Задачата е ясна. Къде е проблемът? В простата локална мрежа задачата е същата, но никой не се занимава с допълнителни настройки и не усеща никакви проблеми. Разликата е в това, че всеки маршрутизируем възел в Интернет е достъпен през всеки от нашите канали, а не само през строго конкретен, както в проста локалка. А “беда” е, че ако получим заявка за IP адрес ISP3, то в нашия случай отговорът ще тръгне през канал ISP2, тъй като там е насочен шлюза по подразбиране. Ще тръгне и ще бъде отхвърлен от доставчика, като некоректен. С проблема се разбрахме. Как да го решим?

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

Предварителна настройка. На този етап ще бъдат зададени основните настройки на рутера: локална мрежа, фаервол, адресни списъци, hairpin NAT и т.н.
Мултиван. На този етап ще бъдат маркирани и сортирани по таблиците за маршрутизиране необходимите свързвания.
Свързване с ISP. На този етап ще бъдат настроени интерфейсите, осигуряващи свързването с Интернет, задействана маршрутизацията и резервирането на интернет канали.

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

1.1. Изчистваме конфигурацията на рутера с командата:

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

съгласяваме се с “Опасно! Наистина ли искате да нулирате? [y/N]:” и, след перезареждане, се свързваме с Winbox по MAC. На този етап конфигурацията и базата с потребители са изчистени.

1.2. Създаваме нов потребител:

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

влизаме под него и изтриваме дефолтния:

/user remove admin

Забележка. Точно изтриването, а не отключването на дефолтния потребител, авторът счита за по-безопасно и препоръчва да се прилага.

1.3. Създаваме основни списъци с интерфейси за удобство при работа с фаервола, настройките за откриване и други 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 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"

Забележка. Написването на разбираеми коментари е си струва времето, изразходвано за него, плюс значително облекчава отстраняването на проблеми и разбирането на конфигурацията.

Авторът смята, че е необходимо, за целите на безопасността, да добави интерфейса ether3 в списъка на интерфейси "WAN", въпреки че по него няма да преминава протокол ip.

Не забравяйте, че след като интерфейсът PPP на ether3 е активиран, той също трябва да бъде добавен в списъка на интерфейси "WAN".

1.4. Скриване на рутера от откритие и управление от мрежите на доставчиците по MAC адрес:

/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. Създаване на минимално необходим набор от правила за филтриране на firewall-а за защита на рутера:

/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

(закриващото правило за вход забранява всичко останало, което идва от Интернет)

/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. Задаване на маршрутките правила към нашите локални мрежи чрез основната таблица за маршрутизиране:

/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"

Забележка. Това е един от простите и бързи начини за достъп до адресите на локалните мрежи с ресурси на външни 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

Забележка. Това позволява достъп до собствените ресурси (dstnat) чрез външния IP, оставайки вътре в мрежата.

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

За решаване на задачата "да отговаряме там, откъдето попитаха" ще използваме два инструмента ROS: марка на връзката и марка на маршрута. Марка на връзката позволява да маркираме необходимата връзка и след това да работим с този маркер, като условие за прилагане марка на маршрута. И с марка на маршрута можем да работим в ip route и правила на маршрута. С инструментите се запознахме, сега трябва да решим кои връзки да маркираме — първо, къде точно да маркираме — второ.

С първото е лесно — трябва да маркираме всички връзки, които идват на рутера от Интернет по съответния канал. В нашия случай ще имаме три марки (по броя на каналите): "conn_isp1", "conn_isp2" и "conn_isp3".

Нюансът със второто е, че входящите връзки ще бъдат от два вида: транзитни и такива, които са предназначени за самия рутер. Механизмът на маркиране на връзките работи в таблицата 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

Забележка. За да не маркирам вече маркирани съединения, използвам условието connection-mark=no-mark вместо connection-state=new, тъй като смятам, че това е по-коректно, както и отказът от drop invalid съединения в филтъра input.

passthrough=no — тъй като в този метод на изпълнение повторната маркировка е изключена и за ускорение можем да прекратим прегледа на правилата след първото съвпадение.

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

“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

На този етап задачата по подготовка за изпращане на отговора в онзи канал Интернет, от който е дошла заявката, може да се счита за решена. Всичко е маркирано, промаркирано и готово за маршрутизиране.
Отличен „побочный“ ефект от такова настройване е възможността за работа на портовете DSNAT с двама (ISP2, ISP3) доставчици едновременно. Не при всички, тъй като на ISP1 нямаме маршрутизируем адрес. Този ефект е важен, например, за пощенския сървър с два MX, които гледат в различни интернет канали.

За да отстраним нюансите в работата на локалните мрежи с външни IP на рутера, използваме решения от т. 1.8.2 и 3.1.2.6.

Освен това, можем да използваме инструмент с маркировки и за разрешаване на t. 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 ISP2" dst-address-list=!BOGONS new-routing-mark=to_isp2 
passthrough=no src-address-list=Via_ISP2

/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

В крайна сметка, това изглежда приблизително така:

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. Добавяме „аварийния“ маршрут по подразбиране:

/ip route add comment="Emergency route" distance=254 type=blackhole

Забележка. Този маршрут позволява трафикът от локалните процеси да премине етапа на Route Decision независимо от състоянието на каналите на който и да е от доставчиците. Нюансът на изходящия локален трафик е, че за пакета да тръгне нанякъде, в основната таблица за маршрутиране трябва да има активен маршрут до шлюза по подразбиране. Ако го няма, пакетът просто ще бъде унищожен.

Като разширение на инструмента check gateway предлагам да използваме метода на рекурсивните маршрути за по-дълбок анализ на състоянието на канала. Същността на метода е, че указваме на маршрутизатора да търси пътя към своя шлюз не директно, а през междинен шлюз. Като такива „проверъчни“ шлюзове ще бъдат избрани 4.2.2.1, 4.2.2.2 и 4.2.2.3 съответно за 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=10

Забележка. Стойността на scope понижаваме до дефолтната в ROS target scope, за да използваме в бъдеще 4.2.2.1 като рекурсивен шлюз. Подчертавам: scope на маршрута до „проверения“ адрес трябва да бъде по-малък или равен на target scope на маршрута, който ще се позовава на проверката.

3.1.2.3. Рекурсивен маршрут по подразбиране за трафика без routing mark:

/ip route add comment="Unmarked via ISP1" distance=2 gateway=4.2.2.1

Забележка. Стойността distance=2 се използва, защото ISP1 по условията на задачата е посочен като първи резервен.

3.1.2.4. Рекурсивен маршрут по подразбиране за трафика с routing mark “to_isp1”:

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

Забележка. Сега, тук най-накрая започваме да се възползваме от плодовете на предварителната работа, която беше извършена в точка 2.

По този маршрут целият трафик, който има маркировка route “to_isp1”, ще бъде насочен към шлюза на първия доставчик, независимо от това кой в момента е активният шлюз по подразбиране за таблицата main.

3.1.2.5. Първият резервен рекурсивен маршрут по подразбиране за маркирания трафик на доставчиците ISP2 и ISP3:

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

Забележка. Тези маршрути са необходими, в това число, за резервиране на трафика от локалните мрежи, които се състоят от членовете на списъка с адреси “to_isp*”.

3.1.2.6. Настройваме маршрута за локалния трафик на рутера в интернет през ISP1:

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

Забележка. В комбинация с правилата от точка 1.8.2, се осигурява изход в необходимия канал с зададения източник. Това е критично за изграждането на тунели, в които се задава IP-адреса на локалната страна (EoIP, IP-IP, GRE). Тъй като правилата в 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.

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 клиента:

/ip dhcp-client
add add-default-route=no disabled=no interface=ether2 script=":if ($bound=1) do={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=10r
    n    /ip route add comment="Unmarked via ISP2" distance=1 gateway=4.2.2.2;r
    n    /ip route add comment="Marked via ISP2 Main" distance=1 gateway=4.2.2.2 
           routing-mark=to_isp2;r
    n    /ip route add comment="Marked via ISP1 Backup1" distance=2 gateway=4.2.2.2 
           routing-mark=to_isp1;r
    n    /ip route add comment="Marked via ISP3 Backup2" distance=3 gateway=4.2.2.2 
           routing-mark=to_isp3;r
    n    /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none 
           out-interface=$"interface" to-addresses=$"lease-address" comment="NAT via ISP2" 
           place-before=1;r
    n    if ([/ip route rule find comment="From ISP2 IP to Inet"] ="") do={r
    n        /ip route rule add comment="From ISP2 IP to Inet" 
               src-address=$"lease-address" table=to_isp2 r
    n    } else={r
    n       /ip route rule set [find comment="From ISP2 IP to Inet"] disabled=no 
              src-address=$"lease-address"r
    n    }      r
    n} else={r
    n   /ip firewall nat remove  [find comment="NAT via ISP2"];r
    n   /ip route remove [find comment="For recursion via ISP2"];r
    n   /ip route remove [find comment="Unmarked via ISP2"];r
    n   /ip route remove [find comment="Marked via ISP2 Main"];r
    n   /ip route remove [find comment="Marked via ISP1 Backup1"];r
    n   /ip route remove [find comment="Marked via ISP3 Backup2"];r
    n   /ip route rule set [find comment="From ISP2 IP to Inet"] disabled=yesr
    n}r
    n" use-peer-dns=no use-peer-ntp=no

Самият скрипт в прозореца Winbox:

Забележка. Първата част на скрипта се сработва при успешно получаване на наема, втората — след освобождаване на наема.Вж. бележка 2

3.3. Настройваме връзката с доставчика ISP3.

Тъй като доставчикът настройките ни предоставя динамично, разумно е необходимите промени да се правят с помощта на скриптове, които се стартират след активиране и деактивиране на интерфейса ppp.

3.3.1. Първо конфигурираме профила:

/ppp profile
add comment="for PPPoE to ISP3" interface-list=WAN name=isp3_client 
on-down="/ip firewall nat remove  [find comment="NAT via ISP3"];r
    n/ip route remove [find comment="For recursion via ISP3"];r
    n/ip route remove [find comment="Unmarked via ISP3"];r
    n/ip route remove [find comment="Marked via ISP3 Main"];r
    n/ip route remove [find comment="Marked via ISP1 Backup2"];r
    n/ip route remove [find comment="Marked via ISP2 Backup2"];r
    n/ip route rule set [find comment="From ISP3 IP to Inet"] disabled=yes;" 
on-up="/ip route add check-gateway=ping comment="For recursion via ISP3" distance=1 
    dst-address=4.2.2.3/32 gateway=$"remote-address" scope=10r
    n/ip route add comment="Unmarked via ISP3" distance=3 gateway=4.2.2.3;r
    n/ip route add comment="Marked via ISP3 Main" distance=1 gateway=4.2.2.3 
    routing-mark=to_isp3;r
    n/ip route add comment="Marked via ISP1 Backup2" distance=3 gateway=4.2.2.3 
    routing-mark=to_isp1;r
    n/ip route add comment="Marked via ISP2 Backup2" distance=3 gateway=4.2.2.3 
    routing-mark=to_isp2;r
    n/ip firewall mangle set [find comment="Connmark in from ISP3"] 
    in-interface=$"interface";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" 
    place-before=1;r
    nif ([/ip route rule find comment="From ISP3 IP to Inet"] ="") do={r
    n   /ip route rule add comment="From ISP3 IP to Inet" src-address=$"local-address" 
    table=to_isp3 r
    n} else={r
    n   /ip route rule set [find comment="From ISP3 IP to Inet"] disabled=no 
    src-address=$"local-address"r
    n};r
    n"

Самият скрипт в прозореца Winbox:

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

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 user=isp3_client

Като последен щрих ще настроим часовниците:

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

За тези, които прочетоха до края

Предложеният метод за реализиране на мултиван е личен избор на автора и не е единствено възможния. Инструментариумът на ROS е обширен и гъвкав, което от една страна създава затруднения за начинаещите, а от друга — е причина за популярността. Изучавайте, пробвайте, откривайте нови инструменти и решения. Например, в тази реализация на мултиван, инструментът може да бъде заменен. Сheck-gateway с рекурсивните маршрути на Netwatch.

Забележки

Check-gateway — механизъм, който позволява деактивиране на маршрута след две поредни неуспешни проверки на шлюза за достъпност. Проверка се извършва на всеки 10 секунди, плюс таймаут на отговора. В крайна сметка действителният тайминг за превключване попада в диапазона 20-30 секунди. Ако такъв тайминг не е достатъчен — има вариант да се използва инструментът Netwatch, където времето за проверка може да бъде зададено ръчно. Механизмът Check-gateway не сработва при периодични загуби на пакети в канала.
Важно! Деактивирането на основния маршрут води до деактивиране на всички останали маршрути, които разчитат на него. Затова за тях не е необходимо да се задава check-gateway=ping не е необходимо.
Случва се в механизма на работа на DHCP да възникне авария, която изглежда, като клиент, зациклил в състояние renew. В такъв случай втората част на скрипта няма да сработи, но правилното преминаване на трафика няма да попречи, тъй като състоянието проследява съответния рекурсивен маршрут.
ECMP (Equal Cost Multi-Path) — в ROS има възможност да зададете маршрут с няколко шлюза и еднаква distance. В такъв случай съединенията ще се разпределят по каналите, използвайки алгоритъм round robin, пропорционално на броя на посочените шлюзи.

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

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