🥇Mikrotiki RouterOS-i multiwan ja marsruutimine

Sissejuhatus

Artikli kirjutamisele innustas mind, peale isekuse, küsimuste tüütu sagedus selle teema osas vene keelt kõnelevates Telegrami kogukondades. Artikkel on suunatud Mikrotik RouterOS (edaspidi ROS) algajatele administraatoritele. Selles käsitletakse ainult multipoint'i, keskendudes marsruutimisele. Boonuseks on minimaalset vajalikud seadistused ohutu ja mugava töö tagamiseks. Kes otsib teemasid nagu järjekorrad, koormuse jaotamine, VLAN-id, sildade loomine, mitmeastmeline süvitsi minek kanalite seisundi analüüsimiseks ja sellele sarnased teemad — ärge raisake aega ja vaeva lugemise peale.

Algandmed

Katsetamiseks on valitud viieportiline Mikrotiki marsruuter, mille ROS versioon on 6.45.3. See marsruutima liiklust kahe lokaalvõrgu (LAN1 ja LAN2) ja kolme teenusepakkuja (ISP1, ISP2, ISP3) vahel. Kanal ISP1-ga on staatiline "hall" aadress, ISP2-l on "valge" aadress, mis saadakse DHCP kaudu, ISP3-l on "valge" aadress, millel on PPPoE autoriseerimine. Ühendusskeem on esitatud joonisel:

Küsimus on seadistada marsruuter "MTK" vastavalt skeemile nii, et:

Tagatakse automaatne üleminek varu teenusepakkuja peale. Peamine teenusepakkuja on ISP2, esimene varu on ISP1, teine varu on ISP3.
LAN1 võrgustiku väljund Internetti toimub ainult ISP1 kaudu.
Kätkestatakse liigendada liiklust lokaalsetest võrkudest Internetti valitud teenusepakkuja kaudu address-list'i põhjal.
Kätkestatakse võimalust avaldada teenuseid lokaalses võrgus Internetis (DSTNAT).
Seadistatakse tulemüüri filter minimaalsete turvanõuete tagamiseks Interneti-poolse riski eest.
Marsruuter peaks suutma saata oma liiklust läbi mis tahes kolme teenusepakkuja sõltuvalt valitud allika aadressist.
Tagatakse vastuspakettide marsruutimine kanalisse, kust nad tulid (kaasa arvatud LAN).

Märkus. Marsruuteri seadistamine toimub "puhta lehega", et tagada üllatuste vältimine, mis tulenevad versioonide vahel muutuvatest algkonfiguratsioonidest "karbist välja". Seadistamise tööriistana on valitud Winbox, kus muudatused kuvatakse visuaalselt. Seadistused antakse Winboxi terminalis käskude abil. Füüsiline ühendamine seadistamiseks toimub otsese ühenduse kaudu Ether5 liidesega.

Veidi mõtteid selle kohta, mis on multivann, kas see on probleem või keerulised nutikad inimesed kuduvad ümber vandenõud.

Küsimusi esitatud ja tähelepanelik admin, seadistades sellist või sarnast skeemi, mõistab järsku, et see töötab ju iseenesest normaalselt. Jah, jah, ilma nende teie kasutajate marsruuditabeliteta ja muude marsruutimise reeglitega, millega enamik sellest teemast artiklitest on üle ujutatud. Kas tõestame?

Saame seadistada liideste ja vaikeväravate adresseerimise? Jah:

ISP1-le määrasime aadressi ja värava distance=2 ja check-gateway=ping.
ISP2 puhul on vaikimisi dhcp kliendi seadistamine — seega on kaugus ühtne.
ISP3-l pppoe kliendi seadistustes on add-default-route=yes määra default-route-distance=3.

Ära unusta määrata NAT väljumiseks:

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

Kokkuvõttes laadivad kohalike võrkude kasutajad kassid läbi peamise pakkuja ISP2 ja kanali varundamine toimub mehhanismi check gateway Vaata märkus 1

Ülesande punkt 1 on teostatud. Kus on multivann oma märgistega? Ei...

Edasi. Peame käivitama konkreetsed kliendid LANist läbi 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 teostatud. Märgid, sildid, marsruutimisreeglid, kus te olete?!

Kas tuleb anda juurdepääs lemmik OpenVPN serverile aadressiga 172.17.17.17 interneti klientidele? Palun:

/ip cloud set ddns-enabled=yes

Kliendi jaoks anname välja 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.

Seadistame tulemüür ja muud turvameetmed punktis 5, samal ajal rõõmustades, et kasutajatel töötab juba kõik ja sirutame käe lemmikjoogiga mahuti poole…
Ah! Tunnelid unustasime veel.

l2tp klient, seadistatud Googeldatud artikli järgi, jõudis lemmik Hollandisse VDS? Jah.
l2tp server IPsec-iga on üles tõusnud ja kliendid, kasutades DNS-nime IP Cloudist (vt üle), ühenduvad? Jah.
Toetudes tooli seljatoele, lonksates jooki, vaatan laiskalt ülesande punktid 6 ja 7. Mõtleme - kas me tõesti vajame seda? Kõik töötab ju (koos)... Kui see ei ole vajalik, siis on kõik. Multivann on rakendatud.

Mis on multivann? See on mitu internetiühendust ühe ruuteri kaudu.

Edasi artiklit lugeda ei ole mõtet, kuna mis seal peale kahtlase rakenduse uhkeldamise olla võib?

Nende seas, kes jäid, kes on huvitatud ülesande punktidest 6 ja 7 ning tunnevad perfektsionismi tõmmet, süveneme süg deeper.

Multivan realiseerimise üks olulisemaid ülesandeid on liikluse õige suunamine. Nimelt: sõltumata sellest, millist (või milliseid) kanalit pakkuja vaatab vaikimisi marsruudi meie ruuteris, peab see andma vastuse just sellele kanalile, kust pakk on tulnud. Ülesanne on arusaadav. Kus on probleem? Ehkki lihtsas kohalikus võrgus on ülesanne sama, ei vaevu keegi lisaseadetega ega tunne muret. Erinevus on selles, et iga marsruutitav sõlm Internetis on kergesti ligipääsetav igas meie kanalist, mitte siiski ainult konkreetsest, nagu lihtsas lokaalses võrgus. Ja probleem seisneb selles, et kui me saame päringu ISP3 IP-aadressile, siis meie puhul saadetakse vastus ISP2 kanali kaudu, kuna see on vaikimisi marsruut. See saadetakse ja lükatakse pakkuja poolt tagasi kui vale. Probleem on tuvastatud. Kuidas seda lahendada?

Jagame lahenduse kolme etappi:

Eelnev seadistamine. Sellel etapil määratakse ruuteri põhiseaded: kohaliku võrgu, tulemüür, aadressiloendid, hairpin NAT jne.
Multivan. Sellel etapil märgitakse ja sorteeritakse marsruutimistabeli jaoks vajalikud ühendused.
Ühendus ISP-ga. Sellel etapil seadistatakse liidesed, mis tagavad Interneti-ühenduse, aktiveeritakse marsruutimine ja kanali varundamise mehhanismid.

1. Eelnev seadistamine

1.1. Kustutame ruuteri konfigureerimise käsuga:

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

oleme nõus “Dangerous! Reset anyway? [y/N]:” ja pärast taaskäivitamist ühendame Winboxi kaudu MAC-iga. Sellel etapil on konfigureerimine ja kasutajabaas kustutatud.

1.2. Loome uue kasutaja:

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

logime sisse tema kaudu ja eemaldame vaikimisi kasutaja:

/user remove admin

Märkus. Just vaikimisi kasutaja eemaldamine, mitte keelamine, on autori arvates turvalisem ja soovitatav kasutada.

1.3. Loome põhiliideste loendid, et hõlbustada töötlemist tulemüüris, avastamise seadetes ja muudes MAC-serverites:

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

Märgime 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 loendid:

/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. Arusaadavate kommentaaride kirjutamine väärt kustutatud aega ning tugevdab tõrkeotsingut ja konfigureerimise mõistmist.

Autor peab vajalikuks turvalisuse mõttes lisada interface list'i "WAN" etherneti 3, hoolimata sellest, et sellel ei käi ip-protokoll.

Ärge unustage, et pärast PPP-ühenduse aktiveerimist etherneti 3-l tuleb see samuti lisada interface list'i "WAN".

1.4. Peidame ruuteri naabruse ja haldamise eest teenusepakkujate võrkudest 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 vähemalt vajalikud tulemüüri filtreerimise reeglid ruuteri kaitsmiseks:

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

(reegel lubab kehtestatud ja seotud ühendusi, mis on algatatud nii ühendatud võrkudest kui 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 sissetulemiseks. 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 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 liiguvad ruuteri kaudu)

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

(reegel tagasi lükkab ühendused, mille connection-state on invalid, mis liiguvad ruuteri kaudu. See on soovitatav Mikrotik'i poolt, 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 ruuteri kaudu liikumise pakettidele, mis tulevad Internetist ja ei ole läbinud dstnat protseduuri. See kaitseb kohalikku võrku kurjategijate eest, kes, olles samas laias laastus kohaliku võrgu, proovivad meie väliseid IP-aadresse värvata ja seega "uurida" meie kohalikke võrke.)

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

1.6. Loome nimekirja mitte-marshuutitavatest 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 ja seega järgime ka meid.)

Märkus. Nimekiri võib muutuda, seega soovitan perioodiliselt kontrollida selle актуaalne.

1.7. Seame DNS ruuteri jaoks:

/ip dns set servers=1.1.1.1,8.8.8.8

Märkus. Praeguses ROS versioonis on dünaamiline serverid eelduvad staatiliselt määratud üle. Nime resolutsiooni päring saadetakse esimesele serverile nimekirjas. Järgmisele serverile liikumine toimub, kui praegune ei ole kättesaadav. Aeg on pikk — üle 5 sekundi. Tagasi pöördumine, kui "kukkunud server" taastub, ei toimu automaatselt. Sellega arvestades ja arvestades mitme linki olemasolu, soovitab autor mitte kasutada teenusepakkujate väljastatud servereid.

1.8. Seame üles kohaliku võrgu.
1.8.1. Konfigureerime staatilised IP-aadresse kohalike võrkude liidesetel:

/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. Seame marsruudi reeglid meie kohalike võrkude jaoks peamise marsruuditabeli kaudu:

/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. See on üks lihtsamaid ja kiiremaid viise, kuidas pääseda ligi kohalike võrkude aadressidele väliste IP aadresside all, mille kaudu vaikimisi marsruuti ei tehta.

1.8.3. Lülitame sisse Hairpin NAT LAN1 ja LAN2 jaoks:

/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. See võimaldab juurdepääsu oma ressurssidele (dstnat) välise IP kaudu viibides samas võrgus.

2. Tegelikult, selle korrektseltliku mitme lingi rakendamine

Probleemi lahendamiseks "vastata sealt, kust küsiti" kasutame kaht ROS tööriista: connection mark ja routing mark. Connection mark võimaldab märgistada vajaliku ühenduse ja hiljem töötada selle märgisega tingimusena rakendamisel routing mark. Ja juba saab routing mark töötada ip route ja route rules. Tööriistadega oleme lõpule viinud, nüüd peame otsustama, millised ühendused märgistada — üks, kus täpselt märgistada — kaks.

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

Teise osaga on aga nüanss selles, et sissetulevad ühendused on kahte tüüpi: transiit ja need, mis on suunatud ise ruuterile. Connection mark mehhanism töötab tabelis mangle. Vaatame paketi liikumist lihtsustatud diagrammil, mille on koostanud spetsialistid veebilehelt mikrotik-trainings.com (mitte reklaam):

Järgides nooli, näeme, et "input interface", minnes, läbib pakett "Prerouting" ahelat ja alles seejärel jaguneb transiit- ja kohalikesse "Routing Decision" blokeerimisse. Seetõttu, et kahte jänest ühe hoobiga tappa, kasutame Connection Mark tabelis Mangle Prerouting ahelates Prerouting.

Note. ROS-i märgid "Routing mark" on toodud osas Ip/Routes/Rules kui "Table", aga teistes osades kui "Routing Mark". See võib tekitada teatud segadust mõistmises, kuid tegelikult on need sama ja on analoogilised rt_tables'ile iproute2-l Linuxis.

2.1. Märgistame sissetulevad ühendused igalt pakkujatelt:

/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ärgistatud ühendusi, kasutan tingimust connection-mark=no-mark selle asemel, et connection-state=new, kuna pean seda korrektsemaks, nagu ka loobumist drop invalid ühendustest sisendfilteris.

passthrough=no — kuna selle rakenduse viisiga on uuesti märgistamine välistatud ja kiiruskaotuse vältimiseks saab reeglite otsimist katkestada pärast esimest vastavust.

Peab meeles pidama, et me ei sekku praegu suunamisse. Praegu käivad ainult ettevalmistusetapid. Järgmine etapp on vahetustraffiku töötlemine, mis tagastatakse juba loodud ühenduse kaudu aadressilt kohalikku võrku. St. nendest pakettidest, mis (vt diagrammi) läbisid ruuteri teel:

"Input Interface"=>"Prerouting"=>"Routing Decision"=>"Forward"=>"Post Routing"=>"Output Interface" ja jõudsid oma adressaadini kohalikus võrgus.

Oluline! ROS-is ei ole loogilist jagunemist väliste ja siseste liideste vahel. Kui jälgida tagasipaketi teed antud diagrammil, siis see läbib sama loogilist teed nagu päring:

"Input Interface"=>"Prerouting"=>"Routing Decision"=>"Forward"=>"Post Routing"=>"Output Interface" lihtsalt selle päringu "Input Interface" jaoks oli ISP liides, aga vastuseks — LAN

2.2. Suuname vastavad vahetustraffiku vastavatesse suunamis tabelitesse:

/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 kohalikest võrgust tuleva liiklusega ja dst-address-type=!local, millel ei ole sihtadresse, mis on ruuteri liideste aadressid.

Sama kehtib kohalike pakettide kohta, mis tulid ruuterisse teel:

"Input Interface"=>"Prerouting"=>"Routing Decision"=>"Input"=>"Local Process"

Oluline! Vastus läheb järgmise tee kaudu:

"Local Process"=>"Routing Decision"=>"Output"=>"Post Routing"=>"Output Interface"

2.3. Suuname vastavad kohaliku liikluse vastavatesse suunamis tabelitesse:

/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 küsimuse vastuse saatmise ettevalmistamise kanali suunas, kust päring tuli, lugeda lahendatuks. Kõik on märgistatud, märgitud ja valmis suunamiseks.
Selle konfiguratsiooni “kõrvalmõjuna” on võimalik kasutada DSNAT portide edastamist samaaegselt mõlemalt (ISP2, ISP3) teenusepakkujalt. Mitte kõikides, kuna ISP1-l on meil mitte-suunatav aadress. See efekt on oluline näiteks kahel erineval Interneti kanalil töötavale meiliserverile, millel on kaks MХ-d.

Kohalikest võrkudest väliste IP-dega ruuteri töötamise nüansside kõrvaldamiseks kasutame lahendusi punktidest 1.8.2 ja 3.1.2.6.

Lisaks saab teemas 3 töö lahendamiseks kasutada ka märgistustööriista. Rakendame järgmiselt:

2.4. Suuname kohalike klientide liikluse marsruutimistabelitest 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õpptulemus näeb välja umbes nii:

3. Seadistame ühenduse ISP-ga ja rakendame marsruutimise märgid.

3.1. Seadistame ü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. Seadistame staatilise marsruutimise:
3.1.2.1. Lisame “varu” marsruudi vaikesuunana:

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

Märkus. See marsruut võimaldab kohalike protsesside liiklusel läbida marsruudi otsustamise etapi sõltumata mõne teenusepakkuja kanalite seisundist. Nüanss välise kohaliku liikluse puhul on see, et pakett peab kuhugi liikuma, seega peab põhimasruutimise tabelis olema aktiivne marsruut vaikimisi värava suunas. Kui seda ei ole, hävitatakse pakett lihtsalt.

Tööriista laienduseks check gateway soovitan suurema sügavuse analüüsiks kasutada rekursiivsete marsruutide meetodit. Meetodi olemus seisneb selles, et me ütleme ruuteri, et ta otsiks teed oma väravasse mitte otse, vaid läbi vahepealse värava. Selliste “kontrollimise” väravatena valitakse vastavalt ISP1, ISP2 ja ISP3 jaoks aadressid 4.2.2.1, 4.2.2.2 ja 4.2.2.3.

3.1.2.2. Marsruut “kontrollimise” aadressile:

/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. Märkuse scope väärtust vähendame ROS sihtscope'i vaikeseadete tasemele, et kasutada siinkohal 4.2.2.1 rekursiivse väravana. Tõstan esile: marsruudi scope “kontrollimise” aadressile peab olema väiksem või võrdne selle marsruudi sihtscope'iga, mis viitab kontrollimisele.

3.1.2.3. Rekursiivne marsruut vaikimisi liiklusele, millel ei ole marsruudi märki:

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

Märkus. Distance=2 väärtuse kasutamine tuleneb sellest, et ISP1 on ülesande tingimustes määratud esimeseks varuks.

3.1.2.4. Rekursiivne marsruut vaikimisi liiklusele, kus on marsruudi märk “to_isp1”:

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

Märkus. Siin me lõpuks hakkame kasutama selle ettevalmistava töö vilju, mis viidi läbi punktis 2.

Selle marsruudi kaudu suunatakse kogu liiklus, millel on mark route "to_isp1", esimese teenusepakkuja väravasse, olenemata sellest, milline vaikimisi värav on praegu aktiveeritud põhitaudist.

3.1.2.5. Esimene varu rekursiivne vaikimisi marsruut märgistatud liiklusele teenusepakkujatelt 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 kohalike võrkude liikluse varundamiseks, mis koosnevad aadressiloendist "to_isp*".

3.1.2.6. Määrame marsruudi kohaliku roteri liikluse jaoks interneti kaudu ISP1:

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

Märkus. Koos punktis 1.8.2 esitatud reeglitega tagatakse pääs soovitud kanalisse määratud allikaga. See on kriitiline tunnelite loomisel, kus määratakse kohaliku poole IP-aadress (EoIP, IP-IP, GRE). Kuna reeglid ip route rules täidetakse üksteise järel, esimesest tingimuste vastavusest, peab see reegel olema pärast punktis 1.8.2 esitatud reegleid.

3.1.3. Määrame NAT-i reegli väljaminevale liiklusele:

/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. NAT teostab kogu väljamineva, välja arvatud see, mis kuulub IPsec poliitikatesse. Püüan vältida action=masquerade kasutamist ilma äärmise vajaduseta. See töötab aeglasemalt ja on rohkem ressursinõudlik kui src-nat, kuna arvutab iga uue ühenduse jaoks NAT-i aadressi.

3.1.4. Suuname kliendid loendist, kellele ei ole lubatud läbimine teiste teenusepakkujate kaudu, otse 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 on kõrgema prioriteediga ja rakendatakse enne teisi marsruudireegleid.

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

3.2. Konfigureerime ühenduse ISP2-ga.

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

/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

Skripti aken Winboxis:

Märkus. Skripti esimene osa käivitub pärast rentimise eduka saamise, teine osa — pärast rendi vabastamist.Vaata märkust 2

3.3. Konfigureerime ühenduse teenusepakkujaga ISP3.

Kuna teenusepakkuja annab meile dünaamilised seadistused, on mõistlik vajalikud muudatused teha skriptide abil, mis käivituvad pärast liidese ppp aktiveerimist ja deaktiveerimist.

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"

Skripti aken Winboxis:

Märkus. Rida
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
võimaldab õigesti töödelda liidese ümbernimetamist, kuna see töötab selle koodi, mitte nähtava 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 viimistluse tegemiseks seadistage kellad:

/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 viis multivan'i rakendamiseks on autori isiklik eelistus ja ei ole ainus võimalik lahendus. ROSi tööriistakast on ulatuslik ja paindlik, mis ühelt poolt tekitab algajatele raskusi, teisalt on see populaarsuse põhjus. Uurige, proovige, avastage uusi tööriistu ja lahendusi. Näiteks võib saadud teadmiste rakendamise osana selles multivan'i rakenduses asendada tööriista Check-gateway rekursiivsete marsruutidega Netwatch.

Märkus

Check-gateway — mehhanism, mis võimaldab marsruuti deaktiveerida pärast kahte järjestikust ebaõnnestunud värava kättesaadavuse kontrolli. Kontrollimine toimub iga 10 sekundi järel, pluss vastuse ajalimiit. Kokkuvõttes toimub tegelik vahetusaeg vahemikus 20-30 sekundit. Kui see vahetusaeg ei ole piisav, on võimalus kasutada tööriista Netwatch, kus kontrollimise taimerit saab seadistada käsitsi. Mehhanism Check-gateway ei aktiveeru perioodiliste paketikaotuste korral kanalil.
Oluline! Peamaaruute deaktiveerimine toob kaasa kõigi teiste marsruutide deaktiveerimise, mis sellele viitavad. Seetõttu ei ole nende puhul vaja määrata check-gateway=ping ei ole vajalik.
Aeg-ajalt võib DHCP töömechanismi töö ilmneda rikke tõttu, mis näib nagu klient, kes on uuendamises kinni. Sellisel juhul ei toimi skripti teine osa, kuid õige liiklus ei tee halba, kuna olekut jälgib vastav rekursiivne marsruut.
ECMP (Equal Cost Multi-Path) — ROSis on võimalus seadistada marsruut mitme väravaga ja sama kaugusega. Sellisel juhul jaotatakse ühendused kanalite vahel, kasutades round robin algoritmi, proportsionaalselt määratud väravate arvule.

Aitäh artikli kirjutamise tõukamise, struktuuri koostamise ja rõhuasetuste paigutamise eest - isiklik tänu Evgenile @jscar

Allikas: habr.com