Въведение
Забележката да се напише статия, освен от тщеславие, беше предизвикана от тревожната честота на въпросите по темата в профилни групи на рускоговорящото телеграм общество. Статията е насочена към начинаещи администратори на Mikrotik RouterOS (по-нататък ROS). В нея се разглежда само мултиван с акцент на маршрутизацията. В допълнение, в нея се предоставят минимално необходими настройки за осигуряване на безопасна и удобна работа. Тези, които търсят разяснения на теми като опашки, баланс на натоварването, VLAN, мостове, многостепенен задълбочен анализ на състоянието на канала и подобни, могат да не губят време и сили за четене.
Изходни данни
За експериментален обект е избран петпортов маршрутизатор Mikrotik с ROS версия 6.45.3. Той ще маршрутизира трафика между две локални мрежи (LAN1 и LAN2) и три интернет доставчици (ISP1, ISP2, ISP3). Каналът към ISP1 има статичен „сив“ адрес, ISP2 – „бял“, получавен чрез DHCP, а ISP3 – „бял“ с PPPoE авторизация. Схемата на свързване е показана на рисунката:
Задачата е да се конфигурира рутера „МТК“ на основата на схемата така, че:
- Да осигури автоматично превключване към резервния интернет доставчик. Основният интернет доставчик е ISP2, първият резервен – ISP1, а вторият резервен – ISP3.
- Да организира изход на мрежата LAN1 в Интернет единствено през ISP1.
- Да предвиди възможността да маршрутизира трафика от локалните мрежи в Интернет през избраният интернет доставчик на база на address-list.
- Да предвиди възможността за публично предоставяне на услуги от локалната мрежа в Интернет (DSTNAT).
- Да настрои филтъра на защитната стена с цел осигуряване на минимално необходимата безопасност от страна на Интернет.
- Рутерът трябва да може да изпуска собствен трафик през всеки от трите интернет доставчици в зависимост от избрания източников адрес.
- Да осигури маршрутизация на отговорните пакети обратно в канала, от който са дошли (включително LAN).
Забележка. Ще конфигурираме рутера „от нулата“, за да гарантираме отсъствието на изненади в променящите се с версиите стартови конфигурации „из коробка“. За настройка е избран Winbox, в който ще бъдат визуализирани промените. Самите настройки ще бъдат зададени чрез команди в терминалния Winbox. Физическото свързване за настройка се осъществява чрез директно свързване с интерфейса Ether5.
Няколко разсъждения за това какво е мултиван, дали е проблем или хитри умници тъкат мрежи от конспирации.
Любопитният и внимателен администратор, самостоятелно настройващ такава или подобна схема, изведнъж осъзнава, че тя и без това работи нормално. Да-да, без тези ваши потребителски таблици за маршрутизиране и други правила за маршрути, с които изобилстват повечето статии по темата. Да проверим?
Можем ли да настроим адресацията на интерфейсите и шлюзовете по подразбиране? Да:
На ISP1 е записан адрес и шлюз с distance=2 и check-gateway=ping.
На ISP2 настройката на DHCP клиента по подразбиране — следователно distance ще бъде равен на единица.
На 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 е готов.
Настройваме защитната стена и другата сигурност за пункт 5, паралелно се радваме, че при потребителите вече всичко работи и се протягаме към съда с любимата напитка...
А! Забравихме и тунелите.
l2tp-клиент, настроен по нагуглената статия, свърза ли се с любимия холандски VDS? Да.
l2tp-сървър с IPsec стартира и клиентите по DNS-името от IP Cloud (вж. по-горе) се свързват? Да.
Отпуснали се на стола, отпивайки от напитката, мързеливо разглеждаме пунктове 6 и 7 от задачата. Мислим — а има ли нужда? Все пак всичко работи (с)... Ако наистина не е необходимо, то на това приключваме. Мултиванът е реализиран.
Какво е мултиван? Това е свързване на няколко интернет канала към един рутер.
Нататък статията може да не се чете, тъй като какво друго, освен изтъкване на съмнителна приложимост, може да има?
Съ хората, които останаха, заинтересовани от точки 6 и 7 на задачата и чувстват сърбежа на перфекционизма, се потапяме по-дълбоко.
Най-важната задача при реализацията на мултиван е правилната маршрутизация на трафика. И именно: независимо от това в коя (или в кои) канали на доставчика е насочен маршрутът по подразбиране на нашия рутер, той трябва да върне отговор именно в този канал, от който е дошъл пакетът. Задачата е ясна. А къде е проблемът? Все пак в простата локална мрежа задачата е същата, но никой не се занимава с допълнителни настройки и не усеща проблеми. Разликата е, че всеки маршрутизируем възел в Интернет е достъпен през всеки от нашите канали, а не през строго определен, както в простата локалка. А
проблемът
- Решението ще разделим на три етапа: На този етап ще бъдат определени основните настройки на рутера: локална мрежа, защитна стена, списъци с адреси, 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=LAN1.5. Създаваме минимално необходимия набор от правила за филтър на фаервола за защита на рутера:
/ip firewall filter add action=accept chain=input comment="Related Established Untracked Allow"
connection-state=established,related,untracked(правилото осигурява разрешение за установени и родствени връзки, които са инициирани както от свързаните мрежи, така и от самия рутер)
/ip firewall filter add action=accept chain=input comment="ICMP from ALL" protocol=icmp(пинг и не само пинг. Разрешен е целият icmp на вход. Много полезно за откриване на проблеми с MTU)
/ip firewall filter add action=drop chain=input comment="All other WAN Drop" in-interface-list=WAN(закриващото веригата input правило забранява всичко останало, което идва от Интернет)
/ip firewall filter add action=accept chain=forward
comment="Established, Related, Untracked allow"
connection-state=established,related,untracked(правилото позволява установени и родствени връзки, които преминават през рутера)
/ip firewall filter add action=drop chain=forward comment="Invalid drop" connection-state=invalid(правилото нулира връзките с connection-state=invalid, преминаващи през рутера. То е настоятелно препоръчано от Mikrotik, но в определени редки ситуации може да блокира полезен трафик)
/ip firewall filter add action=drop chain=forward comment="Drop all from WAN not DSTNATed"
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN(правилото забранява преминаването през рутера на пакети, които идват от Интернет и не са преминали процедурата dstnat. Това ще защити локалните мрежи от злоумишленици, които, находящи се в един широковещателен домен с нашите външни мрежи, ще напишат нашите външни IP адреси като шлюз и по този начин ще се опитат да “изследват” нашите локални мрежи.)
Забележка. Приемаме за условие, че мрежите LAN1 и LAN2 са доверени и трафикът между тях и от тях не се филтрира.
1.6. Създаваме списък с изброяване на не маршрутизируемите мрежи:
/ip firewall address-list
add address=0.0.0.0/8 comment=""This" Network" list=BOGONS
add address=10.0.0.0/8 comment="Private-Use Networks" list=BOGONS
add address=100.64.0.0/10 comment="Shared Address Space. RFC 6598" list=BOGONS
add address=127.0.0.0/8 comment=Loopback list=BOGONS
add address=169.254.0.0/16 comment="Link Local" list=BOGONS
add address=172.16.0.0/12 comment="Private-Use Networks" list=BOGONS
add address=192.0.0.0/24 comment="IETF Protocol Assignments" list=BOGONS
add address=192.0.2.0/24 comment=TEST-NET-1 list=BOGONS
add address=192.168.0.0/16 comment="Private-Use Networks" list=BOGONS
add address=198.18.0.0/15 comment="Network Interconnect Device Benchmark Testing"
list=BOGONS
add address=198.51.100.0/24 comment=TEST-NET-2 list=BOGONS
add address=203.0.113.0/24 comment=TEST-NET-3 list=BOGONS
add address=224.0.0.0/4 comment=Multicast list=BOGONS
add address=192.88.99.0/24 comment="6to4 Relay Anycast" list=BOGONS
add address=240.0.0.0/4 comment="Reserved for Future Use" list=BOGONS
add address=255.255.255.255 comment="Limited Broadcast" list=BOGONS(Това е списък с адреси и мрежи, които не се маршрутизират в Интернет и, следователно, ние също ще следваме това.)
Забележка. Списъкът може да се променя, затова препоръчвам периодично да проверявате актуалността.
1.7. Настройваме DNS за самия рутер:
/ip dns set servers=1.1.1.1,8.8.8.8Забележка. В текущата версия ROS динамични сървъри имат предимство пред статично зададените. Запитът за разрешаване на име се изпраща на първия сървър в реда на списъка. Преминаването към следващия сървър става при недостъпност на текущия. Тайм-аутът е дълъг — над 5 сек. Връщането обратно, при възстановяване на работата на "падналия сървър", не се извършва автоматично. С оглед на този алгоритъм и наличието на мултиван, авторът препоръчва да не се използват сървъри, предоставени от доставчиците.
1.8. Настройваме локалната мрежа.
1.8.1. Конфигурираме статични IP адреси на интерфейсите на локалните мрежи:
/ip address add interface=ether4 address=192.168.88.254/24 comment="LAN1 IP"
/ip address add interface=ether5 address=172.16.1.0/23 comment="LAN2 IP"1.8.2. Задаваме правила за маршрути към нашите локални мрежи чрез основната таблица за маршрутизация:
/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Забележка. Това позволява да получавате достъп чрез външния IP до своите ресурси (dstnat), докато сте вътре в мрежата.
2. Всъщност, реализацията на коректния мултиван
За да решим задачата "да отговорим оттам, откъдето ни запитали" ще използваме два инструмента ROS: connection mark и routing mark. Connection mark позволява да маркираме нужната връзка и след това да работим с тази марка като условие за прилагане routing mark. А с routing mark възможно е да работим в ip route и route rules. С инструментите се разбрахме, сега трябва да решим кои връзки да маркираме — първо, къде точно да маркираме — второ.
С първото е просто — трябва да маркираме всички връзки, които идват на рутера от интернет през съответния канал. В нашия случай това ще са три марки (в зависимост от броя на каналите): "conn_isp1", "conn_isp2" и "conn_isp3".
Тънкостта с второто е, че входящите връзки ще бъдат от два вида: транзитни и такива, предназначени за самия рутер. Механизмът connection mark работи в таблицата mangle. Нека разгледаме движението на пакета на опростена диаграма, любезно съставена от специалистите на ресурса mikrotik-trainings.com (не реклама):
Следвайки стрелките, виждаме, че пакетът, идващ в "input interface", преминава по веригата "Prerouting" и само след това се разделя на транзитен и локален в блока "Routing Decision". Затова, за да убие два заека с един куршум, задействаме Connection Mark в таблицата Mangle Prerouting вериги Prerouting.
Бележка. В ROS етикетите "Routing mark" са посочени в раздел Ip/Routes/Rules като "Table", а в останалите раздели като "Routing Mark". Това може да въведе известна объркване в разбирането, но по същество е едно и също и е аналог на rt_tables в iproute2 на Linux.
2.1. Маркираме входящите съединения от всеки от доставчиците:
/ip firewall mangle add action=mark-connection chain=prerouting
comment="Connmark in from ISP1" connection-mark=no-mark in-interface=ether1 new-connection-mark=conn_isp1 passthrough=no
/ip firewall mangle add action=mark-connection chain=prerouting
comment="Connmark in from ISP2" connection-mark=no-mark in-interface=ether2 new-connection-mark=conn_isp2 passthrough=no
/ip firewall mangle add action=mark-connection chain=prerouting
comment="Connmark in from ISP3" connection-mark=no-mark in-interface=pppoe-isp3 new-connection-mark=conn_isp3 passthrough=noЗабележка. За да не маркирам вече маркирани съединения, използвам условие 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.
Освен това, може да се използва инструмент с етикети и за решаване на т. 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Забележка. Тези маршрути са необходими, включително за резервиране на трафика от локалните мрежи, представляващи членове на address list “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 е обширен и гъвкав, което от една страна предизвиква трудности за начинаещи, а от друга — причина за популярността му. Изучавайте, пробвайте, откривайте нови инструменти и решения. Например, в тази реализация на мултиван можете да замените инструмента Check-gateway с рекурсивни маршрути на Netwatch.
Бележки
- Check-gateway — механизъм, който позволява деактивирането на маршрут след две последователни неуспешни проверки на наличността на шлюза. Проверка се извършва на всеки 10 секунди, плюс таймаут за отговор. В крайна сметка, фактическият тайминг за превключване е в диапазона от 20 до 30 секунди. Ако този тайминг не е достатъчен, имате опция да използвате инструмента Netwatch, където таймерът за проверка може да бъде задаван ръчно. Механизмът Check-gateway не сработва при периодични загуби на пакети в канала.
Важно! Деактивацията на основния маршрут води до деактивация на всички останали маршрути, които се позовават на него. Затова за тях е необходимо да укажете check-gateway=ping няма необходимост.
- Понякога в механизма на работа на DHCP се получава сбой, който изглежда като клиент, зависнал в състояние renew. В такъв случай втората част на скрипта няма да се изпълни, но коректното преминаване на трафика няма да пречи, тъй като състоянието следи съответстващият рекурсивен маршрут.
- ECMP (Equal Cost Multi-Path) — в ROS има възможност да зададете маршрут с няколко шлюза и еднаква distance. В такъв случай свързванията ще се разпределят по каналите, използвайки алгоритъм round robin, пропорционално на броя на указаните шлюзи.
За тласъка към написването на статията, помощта при формулирането на нейната структура и акценти — лична благодарност на Евгений
Източник: habr.com
