Увядзенне
Узяцца за артыкул, акрамя ганарыстасці, заахвоціла гнятлівая частата ўзнікнення пытанняў па гэтай тэме ў профільных групах рускамоўнай тэлеграм-супольнасці. Артыкул арыентавана на пачаткоўцаў адміністратараў Mikrotik RouterOS (далей ROS). У ёй разглядаецца толькі мульціван, з акцэнтам на маршрутызацыю. Бонусам прысутнічаюць мінімальна дастатковыя наладкі для забеспячэння бяспечнай і зручнай працы. Тыя, хто шукае раскрыцця тэм чэргаў, балансавання нагрузкі, уланаў, брыджаў, шматступеннага глыбокага аналізу стану канала і таму падобнага - могуць не марнаваць часу і сіл на чытанне.
Зыходныя дадзеныя
У якасці паддоследнага, абраны пяціпартовы маршрутызатар 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.
Трохі разваг аб тым, што такое мультыван, праблема гэта ці хітрыя разумнікі вакол плятуць сеткі замоваў
Дапытлівы і ўважлівы адмін, самастойна наладжваючы такую ці падобную схему, раптам нечакана ўсведамляе, што яно і так нармальна працуе. Так-так, без гэтых вашых карыстацкіх табліц маршрутызацыі і іншых route rules, якімі мільгаюць большасць артыкулаў на гэтую тэму. Праверым?
Адрасацыю на інтэрфейсах і шлюзы па змаўчанні наладзіць можам? Так:
На 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=так 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 задачы рэалізаваны. Пазнакі, маркі, route rules, дзе вы?!
Трэба даць доступ да любімага 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 падняўся і кліенты па ДНС-імя з IP Cloud(гл вышэй.) чапляюцца? Так.
Адкінуўшыся на спінку крэсла, сёрбаючы напой, ляніва разглядаем пункты 6 і 7 задачы. Думаем - а яно нам трэба? Усё ж і так працуе (с)… Дык вось калі яно не трэба, то на гэтым усё. Мультыван рэалізаваны.
Што такое мульціван? Гэта падлучэнне некалькіх каналаў Інтэрнэт да аднаго роўтара.
Далей артыкул можна не чытаць, паколькі што там акрамя выпендрэжа сумнеўнай дастасавальнасці можа быць?
З тымі, хто застаўся, хто зацікаўлены пунктамі 6 і 7 задачы, а таксама адчувае сверб перфекцыянізму, апускаемся глыбей.
Найважнейшай задачай рэалізацыі мультыван з'яўляецца карэктная маршрутызацыя трафіку. А менавіта: незалежна ад таго, у якой (ці ў якія)Гл. нататка 3 канал(ы) правайдэра глядзіць маршрут па змаўчанні на нашым роўтары, ён павінен вяртаць адказ менавіта ў той канал, з якога пакет прыйшоў. Задача зразумелая. Праблема дзе? Бо ў простай лакальнай сетцы задача тая ж, але ніхто дадатковымі наладамі не затлумляецца і бяды не адчувае. Адрозненне ў тым, што любы маршрутызуемы вузел у Інтэрнэт даступны праз кожны з нашых каналаў, а не праз строга канкрэтны, як у простай лакалцы. А "бяда" заключаецца ў тым, што калі да нас прыйшоў запыт на IP адрас ISP3, то ў нашым выпадку адказ сыдзе праз канал ISP2, паколькі туды накіраваны шлюз па змаўчанні. Сыдзе і будзе адкінуты правайдэрам, як некарэктны. З праблемай вызначыліся. Як яе рашаць?
Рашэнне падзелім на тры этапы:
- Папярэдняя настройка. На гэтым этапе будуць зададзены базавыя налады маршрутызатара: лакальная сетка, фаервол, address lists, hairpin NAT і інш.
- Мультыван. На гэтым этапе будуць прамаркіраваны і пасартаваны па табліцах маршрутызацыі патрэбныя злучэнні.
- Падключэнне да ISP. На гэтым этапе будуць настроены інтэрфейсы, якія забяспечваюць падключэнне да Інтэрнет, задзейнічана маршрутызацыя і механізм рэзервавання каналаў Інтэрнет.
1. Папярэдняя настройка
1.1. Чысцім канфігурацыю роўтара камандай:
/system reset-configuration skip-backup=yes no-defaults=yesзгаджаемся з “Dangerous! Reset anyway? [y/N]:” і, пасля перазагрузкі, падлучаемся Winbox-ом па MAC. На дадзеным этапе канфігурацыя і база карыстальнікаў ачышчаны.
1.2. Ствараем новага карыстальніка:
/user add group=full name=knight password=ultrasecret comment=”Not horse”лагінімся пад ім і выдаляем дэфолтнага:
/user remove adminЗаўвага. Менавіта выдаленне а не адключэнне дэфолтнага карыстальніка аўтар лічыць больш бяспечным і рэкамендуе да прымянення.
1.3. Ствараем базавыя interface lists для выгоды аперавання ў фаерволле, наладах discovery і іншых MAC серверах:
/interface list add name=WAN comment="For Internet"
/interface list add name=LAN comment="For Local Area"Падпісваем каментарамі інтэрфейсы
/interface ethernet set ether1 comment="to ISP1"
/interface ethernet set ether2 comment="to ISP2"
/interface ethernet set ether3 comment="to ISP3"
/interface ethernet set ether4 comment="to LAN1"
/interface ethernet set ether5 comment="to LAN2"і запаўняем interface lists:
/interface list member add interface=ether1 list=WAN comment=ISP1
/interface list member add interface=ether2 list=WAN comment=ISP2
/interface list member add interface=ether3 list=WAN comment="to ISP3"
/interface list member add interface=ether4 list=LAN comment="LAN1"
/interface list member add interface=ether5 list=LAN comment="LAN2"
Заўвага. Пісаць зразумелыя каментары варта выдаткаванага на гэта часу плюс моцна палягчае траблшутынг і разуменне канфігурацыі.
Аўтар лічыць неабходным, у мэтах бяспекі, дадаць у interface list "WAN" інтэрфейс ether3, не гледзячы на тое, што па ім не будзе хадзіць пратакол ip.
Не забываем, што пасля таго, як на ether3 будзе падняты інтэрфейс PPP, яго таксама трэба будзе дадаць у interface list "WAN"
1.4. Хаваем роўтэр ад выяўлення суседства і кіравання з сетак правайдэраў па МАС:
/ip neighbor discovery-settings set discover-interface-list=!WAN
/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=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 rules. З прыладамі разабраліся, зараз трэба вырашыць якія злучэнні пазначаць - раз, дзе менавіта пазначаць - два.
З першым усё проста - мы павінны пазначыць усе злучэнні, якія прыходзяць на роўтар з Інтэрнэт па адпаведным канале. У нашым выпадку гэта будуць тры пазнакі (па колькасці каналаў): "conn_isp1", "conn_isp2" і "conn_isp3".
Нюанс з другім складаецца ў тым, што ўваходныя злучэнні будуць двух выглядаў: транзітныя і тыя, якія прызначаны самому роўтэру. Механізм connection mark працуе ў табліцы мангравыя зараснікі. Разгледзім рух пакета на спрошчанай дыяграме, ветліва сабранай адмыслоўцамі рэсурсу mikrotik-trainings.com (не рэклама):
Прытрымліваючыся па стрэлках, мы бачым, што пакет, які прыходзіць у “Уваходны інтэрфейс”, праходзіць па ланцужку “Prerouting” і толькі потым падзяляецца на транзітны і лакальны ў блоку “Routing Decision”. Таму, для забіцця двух зайцоў, задзейнічаны Знак злучэння ў табліцы 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" проста для запыту “ўваходных інтэрфейс” быў інтэрфейс 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 у нас не які маршрутызуецца адрас. Гэты эфект важны, напрыклад, для паштовага сервера з двума MХ, якія глядзяць у розныя каналы Інтэрнэт.
Для ўхілення нюансаў працы лакальных сетак з вонкавымі 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.
Па гэтым маршруце ўвесь трафік, які мае mark 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 ў 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 няма неабходнасці.
- Бывае, што ў механізме працы DHСP адбываецца збой, які выглядае, як кліент які падвіс у стане renew. У такім разе другая частка скрыпту не адпрацуе, але карэктна хадзіць трафіку не перашкодзіць, паколькі стан адсочвае адпаведны рэкурсіўны маршрут.
- ECMP (Equal Cost Multi-Path) - у ROS ёсць магчымасць задаць маршрут з некалькімі шлюзамі і аднолькавай distance. У такім разе злучэнні будуць размяркоўвацца па каналах, выкарыстаючы алгарытм round robin, прапарцыйна колькасці паказаных шлюзаў.
За штуршок да напісання артыкула, дапамога пры фарміраванні яго структуры і расстаноўцы акцэнтаў - асабістая падзяка Яўгену.
Крыніца: habr.com