🥇Multicast ja marsruutimine Mikrotik RouterOS

Sissejuhatus

Artikli loomiseks, mis läheb kaugemale isekusest, viis mind murettekitav küsimuste esinemissagedus selle teema ümber vene keelt kõnelevates Telegrami kogukondades. Artikkel on suunatud Mikrotik RouterOS (edaspidi ROS) algajatele administraatoritele. Siin käsitletakse ainult multivan'i, keskendudes suunamisele. Boonusena on olemas minimaalsed seadistused, mis tagavad turvalise ja mugava töö. Need, kes otsivad teemasid nagu järjekorrad, koormuse tasakaalustamine, VLAN-id, sildamine, mitmeastmeline kanalite seisundi süvaanalüüs jne — võivad mitte raisata aega ja energiat lugemisele.

Algandmed

Katseseadmeks on valitud viiepordiline Mikrotik ruuter, mille ROS versioon on 6.45.3. See suunab liiklust kahe kohaliku võrgu (LAN1 ja LAN2) ning kolme teenusepakkuja vahel (ISP1, ISP2, ISP3). Kanali ISP1 juurde on staatiline 'hall' aadress, ISP2 — 'valge', saadakse DHCP kaudu, ISP3 — 'valge', millel on PPPoE autentimine. Ühendusskeem on esitatud joonisel:

Ülesanne on seadistada ruuter 'MTK' vastavalt skeemile nii, et:

Tagada automaatne üleminek varu pakkujale. Peamine pakkuja — ISP2, esimene varu — ISP1, teine varu — ISP3.
Korraldada LAN1 võrgu ühendus internetti ainult läbi ISP1.
Tagada võimalus suunata liiklust kohalikest võrkudest internetti valitud pakkuja kaudu address-listi põhjal.
Tagada võimalus teenuste avalikustamiseks kohalikust võrgust internetti (DSTNAT).
Seada tulemüüris filter, et tagada minimaalne vajalik turvalisus interneti poolt.
Ruuter peaks suutma edastada oma liiklust läbi mistahes kolmest pakkujast sõltuvalt valitud allika aadressist.
Tagada vastuspakettide suunamine sama kanali kaudu, kust nad tulid (sh LAN).

Märkus. Konfigureerime ruuteri "puhtalt lehelt", et tagada üllatuste puudumine versioonide lõikes muutuvates algsetes konfigureerimites "karbist välja". Konfigureerimise tööriigiks on valitud Winbox, kus muudatused kuvatakse visuaalselt. Seaded ise sisestatakse Winboxi terminali käskudega. Füüsiline ühendamine seadistamiseks toimub otsese ühenduse kaudu Ether5 liidesega.

Veidi mõtteid selle kohta, mis on multilaan, kas see on probleem või on osavad geeniused kokku tõmmanud järgmiste vandenõudevõrkude.

Uudishimulik ja tähelepanelik admin, kes seadistab sellist või sarnast skeemi iseseisvalt, mõistab ühel hetkel, et see töötab tegelikult normaalselt. Jah, ilma nende teie kasutajate marsruudistustabelite ja teiste marsruudireeglitega, millega enamik artikleid selle teema kohta kihab. Kontrollime?

Kas saame seada aadressid liidesetel ja vaikeväravad? Jah:

ISP1-le määrasime aadressi ja värava koos distance=2 ja check-gateway=ping.
ISP2-l on vaikimisi DHCP kliendi seadistus — seega on distance üks.
ISP3 puhul PPPOE kliendi seadetes on add-default-route=yes installime default-route-distance=3.

Ärge unustage määrata NAT väljundit:

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

Kokkuvõttes laadivad kohalikud kasutajad kahtlemata ISPI2 kaudu ja on olemas kanalivarude mehhanism. kontrolli väravat Vaata märkust 1

Ülesande 1 punkt on täidetud. Kus on multivan oma siltidega? Ei ole…

Edasi. Tuleb lasta konkreetsed kliendid LAN-ist välja kaudu 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

Ülesande punktid 2 ja 3 on täidetud. Silte, märke, marsruudi reeglid, kus te olete?!

Kas tuleb anda juurdepääs armastatud OpenVPN serverile, mille aadress on 172.17.17.17, Interneti klientidele? Palun:

/ip cloud set ddns-enabled=yes

Kliendile anname tulemuse: “:put [ip cloud get dns-name]”

Määrame porti edastamise Internetist:

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

Punkt 4 on valmis.

Seame sisemise tulemüüri ja muu turvalisuse punktiks 5, samal ajal rõõmustades, et kasutajad saavad juba kõik töötada ja sirutume armastatud joogi poole…
Ah! Tunnelsid oleme unustanud.

Kas l2tp klient, seadistatud leitud artikli järgi, tõusis armastatud Hollandi VDS-ini? Jah.
Kas l2tp server IPseciga on üles seatud ja kliendid ühinevad DNS-nime kaudu IP Cloud'ist (vt eelnevat)? Jah.
Toetudes tooli seljatoele ja nautides jooki, uurime laiskuse ja rahu juures ülesande punktide 6 ja 7. Mõtleme — kas see on meile vajalik? Kõik töötab ju (jah)... Kui see tõesti ei ole vajalik, siis sellega ongi kõik. Multivan on realiseeritud.

Mis on multivan? See on mitme internetiühenduse ühendamine ühe ruuteri kaudu.

Edasi ei ole artiklit mõtet lugeda, sest mis seal peale kahtlaste rakenduste näitamise veel olla võib?

Nendega, kes on veel kohal, kes on huvitatud ülesande punktidest 6 ja 7 ning tunnevad perfektsionismi kratsimist, süveneme rohkem.

Muliwan'i elluviimise kõige tähtsam ülesanne on liikluse korrektne marsruutimine. See tähendab, et sõltumata sellest, millisesse (või millistesse) kanalitesse teenusepakkuja vaikimisi marsruutimist vaatab, peab see tagastama vastuse just sinna kanalisse, kust pakett tuli. Ülesanne on arusaadav. Kus on probleem? Lihtsas kohalikes võrkudes on ülesanne sama, kuid keegi ei muretse lisaseadistuste pärast ning probleeme ei tunta. Erinevus seisneb selles, et iga marsruutitav sõlm Internetis on kergesti ligipääsetav läbi iga meie kanali, mitte läbi rangelt konkreetse, nagu lihtsas kohalikus võrgus. Ja probleem seisneb selles, et kui me saime päringu IP-aadressile ISP3, siis meie puhul läheks vastus läbi kanali ISP2, kuna sinna on suunatud vaikimisi lüüs. See läheb kaduma ja teenusepakkuja loobub sellest, kuna see on vale. Probleem on tuvastatud. Kuidas seda lahendada?

Lahenduse jagame kolmeks etapiks:

Eelnevad seadistused. Selles etapis määratakse marsruuteri põhiseaded: vähemalt kohaliku võrgu, tulemüür, aadressi loendid, hairpin NAT jne.
Muliwan. Selles etapis märgitakse ja sorteeritakse marsruutimistabelite jaoks vajalikud ühendused.
Ühendamine ISP-ga. Selles etapis seadistatakse liidesed, mis tagavad ühenduse Internetiga, aktiivsustatakse marsruutimine ja interneti kanali varundamise mehhanism.

1. Esialgne seadistamine

1.1. Nullime ruuteri konfiguratsiooni käsuga:

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

nõustume „Dangerous! Reset anyway? [y/N]:” ja pärast taaskäivitamist ühendame Winboxiga MAC-aadressi kaudu. Selles etapis on konfiguratsioon ja kasutajabaas kustutatud.

1.2. Loome uue kasutaja:

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

logime sisse ja eemaldame vaikeseaded:

/user remove admin

Märkus. Just vaikeseade eemaldamine, mitte väljalülitamine, loetakse autori poolt turvalisemaks ja soovitatakse rakendada.

1.3. Loome põhiliideste loetelud, et hõlbustada tulekahju seinal, avastamise seadistuste ja teiste MAC-serverite haldamist:

/interface list add name=WAN comment="For Internet"
/interface list add name=LAN comment="For Local Area"

Märgistame liidesed kommentaaridega

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

ja täidame liideste loetelud:

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

Märkus. Mugavate kommentaaride kirjutamine on ajakulu väärt, see lihtsustab tõrkeotsingut ja konfiguratsiooni mõistmist.

Autor peab vajalikuks lisada turvalisuse huvides interface list “WAN” liidesse ether3, hoolimata sellest, et selle kaudu ei edastata IP-protokolli.

Ärge unustage, et pärast ether3 liidese PPP aktiveerimist tuleb see samuti lisada interface list “WAN”.

1.4. Peidame ruuteri varjatud avastamise ja juhtimise eest teenusepakkujate võrkudes MAC-aadresside kaudu:

/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. Loome minimaalsete piisavate tulemuste komplekti tulemüürireegleid ruuteri kaitsmiseks:

/ip firewall filter add action=accept chain=input comment="Related Established Untracked Allow" 
connection-state=established,related,untracked

(reegliga lubatakse kehtestatud ja seotud ühendusi, mis on algatatud nii ühendatud võrkudest kui ka ruuterist endast)

/ip firewall filter add action=accept chain=input comment="ICMP from ALL" protocol=icmp

(ping ja mitte ainult ping. Kõik ICMP on lubatud sissesõidul. See on väga kasulik MTU probleemide leidmiseks)

/ip firewall filter add action=drop chain=input comment="All other WAN Drop" in-interface-list=WAN

(sisendreegel, mis sulgeb ahela, keelab kõik muu, mis tuleb Internetist)

/ip firewall filter add action=accept chain=forward 
comment="Established, Related, Untracked allow" 
connection-state=established,related,untracked

(reegel lubab kehtestatud ja seotud ühendusi, mis läbivad ruuteri)

/ip firewall filter add action=drop chain=forward comment="Invalid drop" connection-state=invalid

(reegel lähtestab ühendusi, mille connection-state=invalid, mis läbivad ruuteri. See on Mikrotiki poolt tungivalt soovitatav, kuid harvadel juhtudel võib see blokeerida kasulikku liiklust)

/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

(reegel keelab pakettide läbimist ruuterist, mis tulevad Internetist ja ei ole läbinud dstnat protseduuri. See kaitseb kohalikke võrgustikke pahatahtlike isikute eest, kes, olles meie väliste võrkude sama leviala sees, määravad meie välised IP aadressid oma väravaks ja püüavad seeläbi "uurida" meie kohalikke võrgustikke.)

Märkus. Eeldame, et LAN1 ja LAN2 võrgud on usaldusväärsed ning nende vahel ja nendelt tulevat liiklust ei filtreerita.

1.6. Loome nimekirja mitte marsruutitavatest võrkudest:

/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

(See on aadresside ja võrkude nimekiri, mida ei marsruudita Internetti ning seega järgime ka seda.)

Märkus. Nimekirja võib muuta, seega soovitan perioodiliselt kontrollida selle asjakohasust.

1.7. Seadistame DNS-i ruuteri jaoks:

/ip dns set servers=1.1.1.1,8.8.8.8

Märkus. Praeguses ROS-i versioonis dünaamilised serverid имеют приоритет перед статически заданными. Запрос на разрешение имени отсылается первому серверу по порядку следования в списке. На следующий сервер переход осуществляется при недоступности текущего. Таймаут большой — более 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"

Märkus. Это один из простых и быстрых способов получить доступ к адресам локальных сетей с соурсами внешних 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

Märkus. Это позволяет получать доступ через внешний IP на свои ресурсы (dstnat), находясь внутри сети.

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

Для решения задачи “отвечать туда откуда спросили” будем использовать два инструмента ROS: ühenduse märge ja marsruudi märge. Ühenduse märge lubab määrata vajalikud ühendused ja edaspidi töötada selle märgisega nagu tingimusega rakendamiseks marsruudi märge. Ja juba sellega marsruudi märge on võimalik töötada ip route ja marsruuditööpõhimõtted. Oleme tööriistadega tutvunud, nüüd peame otsustama, millised ühendused märgistada — esimene, kus täpselt märgistada — teine.

Esimese puhul on kõik lihtne — peame märkima kõik ühendused, mis tulevad ruuterisse Interneti kaudu vastava kanali kaudu. Meie olukorras on need kolm märki (kanalite arvu järgi): “conn_isp1”, “conn_isp2” ja “conn_isp3”.

Teise ülesande nüanss seisneb selles, et sissetulevad ühendused võivad olla kahte tüüpi: ülekandmised ja need, mis on mõeldud otse ruuterile. Ühenduse märgistamise mehhanism töötab tabelis mangle. Vaatame paketi liikumist lihtsustatud diagrammil, mille on koostanud mikrotik-trainings.com spetsialistid (midagi müügi jaoks):

Järgi nooli, näeme, et pakett, mis jõuab “sisendliidesesse”, läbib ahela “Prerouting” ja alles seejärel jaguneb ülekande ja kohalikuks plokiks “Marsruudiotsus”. Seetõttu, et tabada kahte jänest, kasutame Ühenduse märki tabelis Mangle Prerouting ahelaid Prerouting.

Märkus. ROSis märgid “Routing mark” on loetletud osas Ip/Routes/Rules kui “Table” ning teistes osades kui “Routing Mark”. See võib tekitada teatavat segadust, kuid sisuliselt on need sama asi ja vastavad rt_tables'ile iproute2-s Linuxis.

2.1. Märgime sissetulevaid ühendusi igast teenusepakkujast:

/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

Märkus. Selleks, et mitte märgistada juba märgitud ühendusi, kasutan tingimust connection-mark=no-mark selle asemel, et connection-state=new, kuna pean seda õigustatuks, samuti nagu loobumist drop invalid ühendustest sissetuleku filtris.

passthrough=no — selle tõttu, et antud teostusmeetodi puhul on ümbermärgistamine välistatud ning kiirusel saab reeglite läbivaatamise katkestada pärast esimest vastavust.

Tuleb meeles pidada, et me ei sekkuda seni marsruutimise protsessi. Praegu käivad ettevalmistusetapid. Järgmise teostuse etapiks on kohaliku võrgu adressaadile tagasi suunatud transit liikluse töötlemine. St. need paketid, mis (vaata diagrammi) on läbinud marsruuteri teel:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” ning jõudnud oma adressaadini kohalikus võrgus.

Oluline! ROS-is puudub loogiline jaotus välise ja sisemise liidese vahel. Kui jälgida vastuspaketi teed antud diagrammil, läbib see sama loogilist rada nagu päring:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” lihtsalt päringu jaoks “Sisendliides” oli ISP liides, ja vastuseks — LAN

2.2. Suunake vastusreaktiivne liiklus vastavatesse marsruutimistabelitesse:

/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

Märkus. in-interface-list=!WAN — töötame ainult kohaliku võrgu liiklusega ja dst-address-type=!local, millel ei ole sihtaadressi omaniku ruuteri liidese aadressid.

Sama kehtib kohalike pakettide puhul, mis tulid ruuterisse teed pidi:

“Sisendliides”=>”Eeltöötlus”=>”Marsruudihindamine”=>”Sisend”=>”Kohalik protsess”

Oluline! Vastus liigub järgmise tee pidi:

”Kohalik protsess”=>”Marsruudihindamine”=>”Väljund”=>”Postitöötlus”=>”Väljundi liides”

2.3. Suunake vastus kohaliku liikluse vastavatesse marsruutimistabelitesse:

/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

Selles etapis võib ülesande vastuse saatmiseks sellele Interneti-kanalile, kust päring tuli, pidada lahendatuks. Kõik on märgistatud, sildistatud ja valmis marsruutimiseks.
Selle seadistuse suurepärane "kõrvalefekt" on vajadus kasutada DSNAT sadamate edastamise võimalust mõlema (ISP2, ISP3) teenusepakkuja kaudu samaaegselt. Mitte kõikide, kuna ISP1-l on meil marsruutitav aadress. See efekt on oluline näiteks meiliserversi puhul, millel on kaks MХ, mis vaatavad erinevate Interneti-kanalite poole.

Kohalikest võrkudest väliste IP-de toimivuse probleemide kõrvaldamiseks kasutame lahendusi punktides 1.8.2 ja 3.1.2.6.

Lisaks saame kasutada sildimärgistusega tööriista ka punkti 3 ülesande lahendamiseks. Teostame nii:

2.4. Suuname kohalike klientide liikluse marsruudilistest tabelitest vastavatesse tabelitesse:

/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

Lõppkokkuvõttes näeb see välja umbes nii:

3. Seame ühenduse ISP-ga ja rakendame marsruudimise sildimärgistuse järgi

3.1. Seame ühenduse ISP1-ga:
3.1.1. Konfigureerime staatilise IP-aadressi:

/ip address add interface=ether1 address=100.66.66.2/30 comment="ISP1 IP"

3.1.2. Seame staatilise marsruudingu:
3.1.2.1. Lisame "hädaolukorra" marsruudi vaikimisi:

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

Märkus. See marsruut võimaldab kohalike protsesside liiklusel läbida marsruudiotsuse etapi, sõltumata ühegi teenusepakkuja kanalite seisundist. Väljamineva kohaliku liikluse eripära seisneb selles, et pakk peab liikuma, peab põhijuhitabelis olema aktiivne marsruut vaikimisi väravani. Kui seda pole, hävitatakse pakk lihtsalt.

Tööriista laiendamiseks kontrolli väravat sügavamaks kanaliseisundi analüüsiks soovitan kasutada rekursiivsete marsruutide meetodit. Meetodi olemus seisneb selles, et näitame ruuterile teed oma väravasse mitte otse, vaid läbi vahevärava. Selliste „kontrollväravatena“ valitakse vastavalt 4.2.2.1, 4.2.2.2 ja 4.2.2.3 ISP1, ISP2 ja ISP3 jaoks.

3.1.2.2. Marsruut „kontrollaadressi“ juurde:

/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

Märkus. Alandame scope väärtuse vaikeseadeks ROS-i sihtscope'is, et kasutada hiljem 4.2.2.1 rekursiivse väravana. Rõhutan: marsruudi scope „kontrollaadressi“ juurde peab olema väiksem või võrdne sihtramtu jutustusega, mis osutab kontrollpunktile.

3.1.2.3. Vaikimisi rekursiivne marsruut liiklusele ilma marsruudi markeerimiseta:

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

Märkus. Kaugus=2 kasutatakse, kuna ISP1 on ülesande tingimustes esimesena varuna määratud.

3.1.2.4. Vaikimisi rekursiivne marsruut liiklusele, millel on marsruudzi märge “to_isp1”:

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

Märkus. Siin hakkame lõpuks nautima selle ettevalmistustöö vilju, mis viidi läbi punktis 2.

Selle marsruudi kaudu suunatakse kogu liiklus, millel on marsruudi märge “to_isp1”, esimese pakkuja väravasse, olenemata sellest, milline on hetkel vaikimisi aktiivne värav põhitaabelis.

3.1.2.5. Esimene varu rekursiivne marsruut vaikimisi märgistatud liiklusele pakkujatelt ISP2 ja 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

Märkus. Need marsruudid on vajalikud, sealhulgas, et tagada liiklus kohalike võrkudest, mis koosnevad aadressiloendi liikmetest “to_isp*”.

3.1.2.6. Määrame marsruudi ruuteri kohaliku liikluse jaoks internetti ISP1 kaudu:

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

Märkus. Kombineerituna punktis 1.8.2 sätestatud reeglitega tagatakse juurdepääs soovitud kanalile antud sordiga. See on kriitilise tähtsusega tunnelite loomisel, kus määratakse kohaliku poole IP-aadress (EoIP, IP-IP, GRE). Kuna ip route reeglid töötavad ülevalt alla kuni esimese tingimuse täitmiseni, peab see reegel olema pärast punktis 1.8.2 sätestatud reegleid.

3.1.3. Kirjutame NAT reegli väljamineva liikluse jaoks:

/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

Märkus. NATitakse kogu väljaminev, välja arvatud see, mis kuulub IPseci poliitikate alla. Ma püüan mitte kasutada action=masquerade ilma äärmise vajaduseta. See töötab aeglasemalt ja on rohkem ressursimahukas kui src-nat, sest iga uue ühenduse jaoks arvutab NATi aadressi.

3.1.4. Suuname nimekirjas olevad kliendid, kellel on keelatud läbimine teiste teenusepakkujate kaudu, kohe ISP1 teenusepakkuja väravasse.

/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

Märkus. action=route omab kõrgemat prioriteeti ja rakendatakse enne teisi marsruudireegleid.

place-before=0 — paigutab meie reegli nimekirja esimeseks.

3.2. Seame ühenduse ISP2-ga.

Kuna ISP2 teenusepakkuja annab meile seadistused DHCP kaudu, on mõistlik vajalikud muudatused teha skripti abil, mis käivitub DHCP kliendi aktiveerimisel:

/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

Kood Winboxi aknas:

Märkus. Esimene skripti osa aktiveerub rendi edukal saamisel, teine - pärast rendi vabastamist.Vaata märkust 2

3.3. Kohandame ISP3 pakkuja ühendust.

Kuna seadistuste pakkuja annab meile dünaamilisi, on mõistlik vajalikud muudatused teha skriptidega, mis käivituvad pärast liidese ppp üles tõusmist ja allakäiku.

3.3.1. Esiteks konfigureerime profiili:

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

Kood Winboxi aknas:

Märkus. String
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
see võimaldab õigesti töödelda liidese ümbernimetamist, kuna see töötab oma koodi, mitte kuvatava nimega.

3.3.2. Nüüd, kasutades profiili, loome ppp ühenduse:

/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

Viimase lihvi andmiseks seadistame kella:

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

Neile, kes lugesid lõpuni

Pakutud lahendus multivan'i rakendamiseks on autori isiklik eelistus ja ei ole ainus võimalik. ROS'i tööriistakomplekt on ulatuslik ja paindlik, mis ühelt poolt tekitab raskusi algajatele, kuid teiselt poolt on see populaarsuse põhjus. Uurige, proovige ja avastage uusi tööriistu ja lahendusi. Näiteks, saadud teadmiste rakendamiseks, võib selles multivan'i lahenduses asendada tööriista Check-gateway rekursiivsete marsruutidega Netwatch.

Märkused

Check-gateway — mehhanism, mis võimaldab deaktiveerida marsruudi pärast kahes järjestikuses ebaõnnestunud värava kättesaadavuse kontrolli. Kontrollimine toimub iga 10 sekundi tagant, pluss vastuse timeout. Seega jääb tegelik lülitamise ajavahemik vahemikku 20-30 sekundi. Kui selline lülitamise ajavahemik pole piisav — on võimalus kasutada tööriista Netwatch, kus saab kontrolli taimerit käsitsi määrata. Mehhanism Check-gateway ei aktiveeru kanali perioodiliste paketikaotuste korral.
Oluline! Peamise marsruudi deaktiveerimine toob kaasa kõigi teiste marsruutide deaktiveerimise, mis sellele viitavad. Seega nende puhul on vajalik check-gateway=ping ei ole vajalik.
Juhtub, et DHCP mehhanismi töös esineb rike, mis näib nagu klient, kes on hangunud olekus renew. Sellisel juhul teine osa skriptist ei tööta, kuid korrektne liiklus ei ole takistatud, kuna olek jälgib vastavat rekurssiivset marsruuti.
ECMP (Equal Cost Multi-Path) — ROS-is on võimalik määrata marsruut mitme värava ja sama kaugusega. Sellisel juhul jaotatakse ühendused kanalite vahel ühtlaselt, kasutades ringhäälingu algoritmi, proportsionaalselt määratud väravate arvule.

Isiklik tänu Jevgenile inspiratsiooni eest artikli kirjutamiseks, abistades selle struktuuri loomisel ja rõhuasetuste seadmisel. @jscar

Allikas: habr.com