Multivan и маршрутизиране на Mikrotik RouterOS

въведение

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

Сурови данни

Като обект на тест беше избран петпортов рутер Mikrotik с ROS версия 6.45.3. Той ще насочва трафика между две локални мрежи (LAN1 и LAN2) и три доставчика (ISP1, ISP2, ISP3). Каналът към ISP1 е със статичен "сив" адрес, ISP2 - "бял", получен през DHCP, ISP3 - "бял" с PPPoE авторизация. Схемата на свързване е показана на фигурата:

Multivan и маршрутизиране на Mikrotik RouterOS

Задачата е да конфигурирате MTK рутера въз основа на схемата, така че:

  1. Осигурете автоматично превключване към резервен доставчик. Основният доставчик е ISP2, първият резерв е ISP1, вторият резерв е ISP3.
  2. Организирайте LAN1 мрежов достъп до Интернет само чрез ISP1.
  3. Осигурете възможност за маршрутизиране на трафик от локални мрежи към интернет през избрания доставчик въз основа на списъка с адреси.
  4. Осигурете възможност за публикуване на услуги от локалната мрежа в Интернет (DSTNAT)
  5. Настройте филтър за защитна стена, за да осигурите минималната достатъчна сигурност от Интернет.
  6. Рутерът може да издава собствен трафик през всеки от трите доставчика, в зависимост от избрания адрес на източника.
  7. Уверете се, че пакетите с отговори са насочени към канала, от който са дошли (включително LAN).

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

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

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

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

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

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

/ip защитна стена nat add action=masquerade chain=srcnat out-interface-list=WAN

В резултат на това потребителите на местни сайтове се забавляват, като изтеглят котки през основния доставчик на ISP2 и има резервация на канал с помощта на механизма проверете шлюза Вижте бележка 1

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

По-нататък. Трябва да освободите конкретни клиенти от LAN чрез ISP1:

/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=да route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
преминаване=без маршрут-dst=100.66.66.1 src-адрес=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 защитна стена nat add action=dst-nat chain=dstnat dst-port=1194
in-interface-list=WAN протокол=udp to-addresses=172.17.17.17

Позиция 4 е готова.

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

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

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

Не е нужно да четете статията по-нататък, защото какво може да има освен парад на съмнителна приложимост?

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

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

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

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

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

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

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

Съгласен с "опасно! Нулиране въпреки това? [да/не]:” и след рестартиране се свързваме с 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. Създаваме минимално достатъчен набор от правила за филтриране на защитната стена, за да защитим рутера:

/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

(ping и не само ping. Всички 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 адреси на LAN интерфейси:

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

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

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

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

Multivan и маршрутизиране на Mikrotik RouterOS

Следвайки стрелките, виждаме, че пакетът пристига на „въвеждане на интерфейс“, преминава през веригата „Предварително маршрутизиране” и чак тогава се разделя на транзитно и локално в блок “Решение за маршрутизиране". Следователно, за да убием две птици с един камък, ние използваме Маркировка за връзка в таблицата Предварително насочване на Mangle вериги Предварително маршрутизиране.

забележка. В ROS етикетите „Routing mark“ са изброени като „Table“ в секцията Ip/Routes/Rules и като „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, защото смятам, че това е по-правилно, както и отхвърлянето на отпадане на невалидни връзки във входния филтър.


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.

Освен това можете да използвате инструмент с маркировки, за да решите параграф 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

В резултат на това изглежда нещо подобно:

Multivan и маршрутизиране на Mikrotik RouterOS

3. Настройте връзка с доставчика на интернет услуги и активирайте брандираното маршрутизиране

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

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

Като разширение на инструмента проверете шлюза За по-задълбочен анализ на състоянието на канала предлагам да използвате метода на рекурсивния маршрут. Същността на метода е, че казваме на рутера да търси път към своя шлюз не директно, а през междинен шлюз. 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

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

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

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

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

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

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

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


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

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 се изпълняват отгоре надолу, до първото съвпадение на условията, тогава това правило трябва да е след правилата от клауза 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

Забележка. NATim всичко, което излиза, с изключение на това, което влиза в политиките на 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:

Multivan и маршрутизиране на Mikrotik RouterOS
Забележка. Първата част от скрипта се задейства при успешно получаване на лизинга, втората - след освобождаване на лизинга.Вижте бележка 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:

Multivan и маршрутизиране на Mikrotik RouterOS
Забележка. ред
/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 инструментариумът е обширен и гъвкав, което от една страна затруднява начинаещите, а от друга е причината за неговата популярност. Учете, опитвайте, откривайте нови инструменти и решения. Например, като приложение на придобитите знания е възможно да се замени инструмента в това изпълнение на мултиван check-gateway с рекурсивни маршрути до netwatch.

Бележки

  1. check-gateway - механизъм, който ви позволява да деактивирате маршрута след две последователни неуспешни проверки на шлюза за наличност. Проверката се извършва веднъж на всеки 10 секунди, плюс времето за изчакване на отговора. Като цяло действителното време за превключване е в диапазона от 20-30 секунди. Ако такова време за превключване не е достатъчно, има опция за използване на инструмента netwatch, където таймерът за проверка може да се настрои ръчно. check-gateway не задейства при периодична загуба на пакети във връзката.

    важно! Деактивирането на основен маршрут ще деактивира всички други маршрути, които се отнасят до него. Следователно, за тях да се уточни check-gateway=ping не е задължително.

  2. Случва се да възникне повреда в DHCP механизма, което изглежда като клиент, заседнал в състояние на подновяване. В този случай втората част на скрипта няма да работи, но няма да попречи на трафика да върви правилно, тъй като състоянието проследява съответния рекурсивен маршрут.
  3. ECMP (Equal Cost Multi-Path) - в ROS е възможно да се зададе маршрут с няколко шлюза и еднакво разстояние. В този случай връзките ще бъдат разпределени между каналите с помощта на кръговия алгоритъм, пропорционално на броя на посочените шлюзове.

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

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