🥇Multivan ja marsruutimine Mikrotik RouterOS-is

Sissejuhatus

Artiklit üles võtma ajendas lisaks edevusele ka selleteemaliste küsimuste masendav sagedus venekeelse telegrammikogukonna profiiligruppides. Artikkel on suunatud algajatele Mikrotik RouterOS (edaspidi ROS) administraatoritele. See käsitleb ainult multivani, rõhuasetusega marsruudil. Boonusena on minimaalselt piisavad seadistused, et tagada ohutu ja mugav töö. Need, kes otsivad järjekordade, koormuse tasakaalustamise, vlanide, sildade, kanali seisukorra mitmeastmelise süvaanalüüsi jms teemade avalikustamist - ei pruugi lugemisele aega ja vaeva raisata.

Toorandmed

Katsealuseks valiti viie pordiga Mikrotik ruuter ROS versiooniga 6.45.3. See suunab liikluse kahe kohaliku võrgu (LAN1 ja LAN2) ja kolme pakkuja (ISP1, ISP2, ISP3) vahel. Kanalil ISP1-le on staatiline "hall" aadress, ISP2 - "valge", saadud DHCP kaudu, ISP3 - "valge" PPPoE-volitusega. Ühendusskeem on näidatud joonisel:

Ülesanne on konfigureerida MTK ruuter skeemi alusel nii, et:

Tagage automaatne lülitumine varundusteenuse pakkujale. Peamine pakkuja on ISP2, esimene reserv on ISP1, teine reserv on ISP3.
Korraldage LAN1-võrgu juurdepääs Internetile ainult ISP1 kaudu.
Annab võimaluse suunata liiklust kohalikest võrkudest Internetti valitud teenusepakkuja kaudu aadressiloendi alusel.
Pakkuge teenuste avaldamise võimalust kohalikust võrgust Internetti (DSTNAT)
Seadistage tulemüüri filter, et pakkuda Internetist minimaalset piisavat turvalisust.
Ruuter võib sõltuvalt valitud lähteaadressist väljastada oma liiklust ükskõik millise kolme pakkuja kaudu.
Veenduge, et vastusepaketid suunataks kanalile, kust need tulid (sh LAN).

MÄRKUS Seadistame ruuteri "nullist", et tagada üllatuste puudumine "kastist väljas" alustavates konfiguratsioonides, mis muutuvad versioonide kaupa. Konfiguratsioonitööriistaks valiti Winbox, kus muudatusi visuaalselt kuvatakse. Seadistused ise määratakse Winboxi terminali käskudega. Füüsiline ühendus konfigureerimiseks tehakse otseühenduse kaudu Ether5 liidesega.

Natuke arutluskäiku selle üle, mis on multivan, kas see on probleem või on kavalad targad inimesed vandenõuvõrgustike punumisel

Uudishimulik ja tähelepanelik administraator, kes ise sellise või sarnase skeemi paika paneb, mõistab ühtäkki, et see töötab juba normaalselt. Jah, jah, ilma teie kohandatud marsruutimistabelite ja muude marsruudireegliteta, mida enamik selleteemalisi artikleid on täis. Kontrollime?

Kas me saame liidestes ja vaikelüüsides adresseerimist konfigureerida? Jah:

ISP1-s registreeriti aadress ja lüüs kaugus = 2 и check-gateway=ping.
ISP2 puhul on dhcp-kliendi vaikesäte - vastavalt võrdub kaugus ühega.
ISP3 puhul pppoe kliendi seadetes, kui add-default-route=jah pane default-route-distance=3.

Ärge unustage NAT-i registreerida väljumisel:

/ip tulemüür nat add action=masquerade chain=srcnat out-interface-list=WAN

Selle tulemusel on kohalike saitide kasutajatel lõbus peamise ISP2 pakkuja kaudu kasside allalaadimine ja kanali broneerimine toimub mehhanismi abil. kontrolli lüüsi Vaata märkust 1

Ülesande punkt 1 on rakendatud. Kus on multivan oma märkidega? Ei…

Edasi. Peate vabastama LAN-ist teatud kliendid ISP1 kaudu:

/ip tulemüüri mangle add action=marsruudi kett=eelmarsruutimine dst-address-list=!BOGONS
passthrough=jah route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip tulemüüri mangle add action=marsruudi kett=eelmarsruutimine dst-address-list=!BOGONS
passthrough=marsruuti pole-dst=100.66.66.1 src-address=192.168.88.0/24

Ülesande punktid 2 ja 3 on rakendatud. Sildid, templid, marsruudireeglid, kus sa oled?!

Kas soovite Interneti-klientidele juurdepääsu oma lemmik OpenVPN-serverile aadressiga 172.17.17.17? Palun:

/ip pilvekomplekt ddns-enabled=yes

Partnerina anname kliendile väljundtulemuse: “:put [ip cloud saada dns-nimi]"

Registreerime pordi suunamise Internetist:

/ip tulemüür nat add action=dst-nat chain=dstnat dst-port=1194
in-interface-list=WAN-protokoll=udp-aadressid=172.17.17.17

Punkt 4 on valmis.

Seadsime punkti 5 jaoks üles tulemüüri ja muu turvalisuse, samas on hea meel, et kasutajate jaoks kõik juba töötab ja sirutame käe lemmikjoogiga anuma järele...
A! Tunnelid on unustatud.

Google'i artikliga konfigureeritud l2tp-klient on tõusnud teie lemmik Hollandi VDS-i? Jah.
l2tp-server koos IPseciga on tõusnud ja kliendid DNS-nime järgi IP Cloudist (vt ülalt) klammerduvad? Jah.
Toolil tahapoole nõjatudes jooki rüübates kaalume laisalt ülesande 6. ja 7. punkti. Mõtleme – kas meil on seda vaja? Samas, see töötab nii (c) ... Nii et kui seda ikka pole vaja, siis see on kõik. Multivan rakendatud.

Mis on multivan? See on mitme Interneti-kanali ühendamine ühe ruuteriga.

Te ei pea artiklit edasi lugema, sest mis saab seal olla peale kahtlase kohaldatavuse eputamise?

Jääjatele, kes on huvitatud ülesande punktidest 6 ja 7 ning tunnevad ka perfektsionismi kihelust, sukeldume sügavamale.

Multivani rakendamise kõige olulisem ülesanne on liikluse õige suunamine. Nimelt: olenemata sellest, milline (või milline) Vt. märkus 3. Interneti-teenuse pakkuja kanal(id) vaatavad meie ruuteri vaikemarsruuti, see peaks tagastama vastuse täpselt kanalile, kust pakett pärines. Ülesanne on selge. Kus on probleem? Tõepoolest, lihtsas kohalikus võrgus on ülesanne sama, kuid keegi ei vaeva lisaseadeid ega tunne probleeme. Erinevus seisneb selles, et mis tahes Interneti-marsruutitav sõlm on juurdepääsetav iga meie kanali kaudu, mitte rangelt konkreetse kanali kaudu, nagu lihtsas LAN-is. Ja “häda” seisneb selles, et kui meile tuli taotlus ISP3 IP-aadressi kohta, siis meie puhul läheb vastus ISP2 kanali kaudu, kuna vaikelüüs on sinna suunatud. Lahkub ja teenusepakkuja viskab need ära kui vale. Probleem on tuvastatud. Kuidas seda lahendada?

Lahendus on jagatud kolme etappi:

Eelseadistus. Selles etapis määratakse ruuteri põhiseaded: kohalik võrk, tulemüür, aadresside loendid, juuksenõel NAT jne.
Multivan. Selles etapis märgitakse vajalikud ühendused ja sorteeritakse need marsruutimistabelitesse.
Ühenduse loomine Interneti-teenuse pakkujaga. Selles etapis konfigureeritakse Interneti-ühendust pakkuvad liidesed, marsruutimine ja Interneti-kanalite broneerimise mehhanism.

1. Eelseadistus

1.1. Tühjendame ruuteri konfiguratsiooni käsuga:

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

nõus "Ohtlik! Kas lähtestada ikkagi? [ja/n]:” ja pärast taaskäivitamist loome MAC-i kaudu ühenduse Winboxiga. Selles etapis tühjendatakse konfiguratsioon ja kasutajabaas.

1.2. Loo uus kasutaja:

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

logige selle alla sisse ja kustutage vaikimisi:

/user remove admin

MÄRKUS Just vaikekasutaja eemaldamist ja mittekeelamist peab autor turvalisemaks ja soovitab kasutada.

1.3. Koostame tulemüüris, avastusseadetes ja muudes MAC-serverites töötamise mugavuse huvides põhiliideste loendid:

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

Kommentaaridega allkirjastamise liidesed

/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äitke 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 tasub sellele kulutatud aega, lisaks hõlbustab see oluliselt tõrkeotsingut ja konfiguratsioonist arusaamist.

Autor peab turvakaalutlustel vajalikuks lisada ether3 liides "WAN" liideste loendisse vaatamata sellele, et ip-protokoll seda läbi ei lähe.

Ärge unustage, et pärast PPP-liidese tõstmist ether3-s tuleb see lisada ka liideste loendisse "WAN"

1.4. Peidame ruuteri MAC-i kaudu teenusepakkuja võrkude eest naabruskonna tuvastamise ja juhtimise eest:

/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 ruuteri kaitsmiseks minimaalse piisava tulemüüri filtrireeglite komplekti:

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

(reegel annab loa loodud ja seotud ühendustele, 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. Väga kasulik MTU probleemide leidmiseks)

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

(sisestusahela sulgev reegel keelab kõik muu, mis internetist tuleb)

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

(reegel lubab loodud ja seotud ühendusi, mis läbivad ruuterit)

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

(reegel lähtestab ruuterit läbivad ühendused olekuga connection-state=invalid. Mikrotik soovitab seda tungivalt, kuid mõnel harvadel juhtudel võib see kasulikku liiklust blokeerida)

/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 Internetist pärit pakettidel, mis ei ole läbinud dstnat-protseduuri, ruuterit läbida. See kaitseb kohalikke võrke sissetungijate eest, kes meie välisvõrkudega samas levidomeenis olles registreerivad meie välised IP-d lüüsi ja seega proovige "uurida" meie kohalikke võrke.)

MÄRKUS Oletame, et võrgud LAN1 ja LAN2 on usaldusväärsed ning nendevahelist ja nende vahelist liiklust ei filtreerita.

1.6. Looge loend mittemarsruutitavate võrkude loendiga:

/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 loend, mis ei ole Internetti suunatavad ja mida järgitakse vastavalt.)

MÄRKUS Nimekiri võib muutuda, seega soovitan teil perioodiliselt asjakohasust kontrollida.

1.7. Seadistage ruuteri enda DNS:

/ip dns set servers=1.1.1.1,8.8.8.8

MÄRKUS ROS-i praeguses versioonis on dünaamilised serverid staatiliste serverite suhtes ülimuslikud. Nimelahenduse päring saadetakse loendis esimesele serverile. Üleminek järgmisele serverile toimub siis, kui praegune pole saadaval. Aeg on suur - rohkem kui 5 sekundit. Tagasipöördumine, kui "kukkunud server" jätkatakse, ei toimu automaatselt. Arvestades seda algoritmi ja multivani olemasolu, soovitab autor mitte kasutada pakkujate pakutavaid servereid.

1.8. Seadistage kohalik võrk.
1.8.1. Konfigureerime staatilised IP-aadressid LAN-liidestes:

/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. Seadsime oma kohalike võrkude marsruutide reeglid läbi peamise marsruutimistabeli:

/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 kiireid ja lihtsaid viise juurdepääsuks LAN-aadressidele ruuteriliideste väliste IP-aadresside allikatega, mis ei läbi vaikemarsruuti.

1.8.3. Juuksenõela NAT lubamine 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 teil juurdepääsu oma ressurssidele (dstnat) välise IP-aadressi kaudu, olles samal ajal võrgus.

2. Tegelikult väga õige multivani teostus

Probleemi "vastamise kohta, kust nad küsisid" lahendamiseks kasutame kahte ROS-i tööriista: ühendusmärk и marsruudimärk. ühendusmärk võimaldab teil soovitud ühenduse märkida ja seejärel selle märgiga taotlemise tingimusena töötada marsruudimärk. Ja juba koos marsruudimärk võimalik sisse töötada ip marsruut и marsruudi reeglid. Me mõtlesime välja tööriistad, nüüd peate otsustama, millised ühendused märgistada - üks kord, täpselt kuhu märkida - kaks.

Esimesega on kõik lihtne - peame vastava kanali kaudu märkima kõik ühendused, mis Internetist ruuterisse tulevad. Meie puhul on need kolm silti (kanalite arvu järgi): "conn_isp1", "conn_isp2" ja "conn_isp3".

Teise nüanss on see, et sissetulevad ühendused on kahte tüüpi: transiit ja need, mis on mõeldud ruuteri enda jaoks. Ühendusmärgi mehhanism töötab tabelis mangle. Mõelge pakendi liikumisele lihtsustatud diagrammil, mille on lahkesti koostanud mikrotik-trainings.com ressursi spetsialistid (mitte reklaam):

Nooli järgides näeme, et pakett saabub aadressile "sisendi liides", läbib ahela"Eelmarsruutimine” ja alles siis jaguneb see plokis transiidiks ja kohalikuksMarsruutimise otsus". Seetõttu kasutame kahe linnu ühe hoobiga tapmiseks Ühenduse märk tabelis Mangle eelmarsruutimine ketid Eelmarsruutimine.

Märkus:. ROS-is on sildid „Marsruutimismärk” jaotises Ip/Routes/Rules loetletud kui „Tabel” ja muudes jaotistes kui „Marsruutimärk”. See võib mõistmises segadust tekitada, kuid tegelikult on see sama asi ja on linuxis iproute2-s oleva rt_tablesi analoog.

2.1. Märgistame sissetulevad ühendused igalt pakkujalt:

/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ärkida juba märgitud ühendusi, kasutan ühenduse-oleku=uus asemel tingimust connection-mark=no-mark, kuna see on minu arvates õigem, samuti sisendfiltris kehtetute ühenduste tagasilükkamine.

passthrough=no – kuna selle rakendusmeetodi puhul on ümbermärgistamine välistatud ja kiirendamiseks saab reeglite loendamise katkestada pärast esimest vastet.

Tuleb meeles pidada, et me ei sekku veel kuidagi marsruutimisse. Nüüd on ainult ettevalmistusetapid. Rakenduse järgmine etapp on kohaliku võrgu sihtkohast loodud ühenduse kaudu tagasi pöörduva transiitliikluse töötlemine. Need. need paketid, mis (vt diagrammi) läbisid ruuteri teel:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” ja jõudis kohalikus võrgus adressaadini.

Tähtis! ROS-is puudub loogiline jaotus väliseks ja sisemiseks liideseks. Kui jälgime vastuse paketi teed ülaltoodud diagrammi järgi, järgib see sama loogilist teed nagu päring:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” lihtsalt palve pärast"sisendi liides” oli ISP liides ja vastuseks - LAN

2.2. Suuname vastuse transiidiliikluse 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

Kommenteeri. in-interface-list=!WAN - töötame ainult kohaliku võrgu ja dst-address-type=!local liiklusega, millel puudub ruuteri enda liideste aadressi sihtkoha aadress.

Sama kehtib ka kohalike pakettide kohta, mis tulid ruuterisse teel:

“Sisendliides”=>”Eelmarsruutimine”=>”Marsruutimise otsus”=>”Sisend”=>”Kohalik protsess”

Tähtis! Vastus antakse järgmiselt:

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

2.3. Suuname vastuse 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 lugeda lahendatuks ülesande valmistada ette vastuse saatmine sellele Interneti-kanalile, kust päring tuli. Kõik on märgistatud, märgistatud ja marsruutimiseks valmis.
Selle seadistuse suurepärane "kõrvalmõju" on võimalus töötada samaaegselt mõlema (ISP2, ISP3) pakkuja DSNAT-pordi edastamisega. Üldse mitte, kuna meil on ISP1-l mittemarsruutitav aadress. See efekt on oluline näiteks kahe MX-iga meiliserveri puhul, mis vaatavad erinevaid Interneti-kanaleid.

Väliste IP-ruuteritega kohalike võrkude töö nüansside kõrvaldamiseks kasutame lõikudes toodud lahendusi. 1.8.2 ja 3.1.2.6.

Lisaks saate ülesande punkti 3 lahendamiseks kasutada märgistusega tööriista. Rakendame seda järgmiselt:

2.4. Suuname liikluse kohalikelt klientidelt marsruutimisloenditest 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

Selle tulemusena näeb see välja umbes selline:

3. Seadistage ühendus Interneti-teenuse pakkujaga ja lubage kaubamärgiga marsruutimine

3.1. Seadistage ühendus ISP1-ga:
3.1.1. Staatilise IP-aadressi konfigureerimine:

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

3.1.2. Seadistage staatiline marsruutimine:
3.1.2.1. Lisa vaikeabimarsruut:

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

MÄRKUS See marsruut võimaldab kohalike protsesside liiklusel läbida marsruudiotsuse etapi, olenemata mis tahes teenusepakkuja linkide olekust. Väljuva kohaliku liikluse nüanss seisneb selles, et selleks, et pakett vähemalt kuhugi liiguks, peab põhimarsruutimistabelis olema aktiivne marsruut vaikelüüsile. Kui ei, siis pakk lihtsalt hävitatakse.

Tööriista laiendusena kontrolli lüüsi Kanali oleku sügavamaks analüüsiks soovitan kasutada rekursiivse marsruudi meetodit. Meetodi olemus seisneb selles, et me käsime ruuteril otsida teed oma lüüsi juurde mitte otse, vaid läbi vahepealse lüüsi. ISP4.2.2.1, ISP4.2.2.2 ja ISP4.2.2.3 jaoks valitakse sellisteks testlüüsideks 1, 2 ja 3.

3.1.2.2. Marsruut "kinnitus" 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 Alandame ulatuse väärtuse ROS-i sihtulatuse vaikeväärtuseni, et kasutada edaspidi rekursiivse lüüsina 4.2.2.1. Rõhutan: marsruudi ulatus testiaadressile peab olema väiksem või võrdne testitavale viitava marsruudi sihtulatusega.

3.1.2.3. Liikluse rekursiivne vaikemarsruut ilma marsruudimärgita:

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

MÄRKUS Väärtust distance=2 kasutatakse, kuna ISP1 on vastavalt ülesande tingimustele deklareeritud esimeseks varukoopiaks.

3.1.2.4. Liikluse rekursiivne vaikemarsruut marsruudimärgiga "to_isp1":

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

MÄRKUS Tegelikult hakkame siin lõpuks nautima lõikes 2 tehtud ettevalmistustöö vilju.

Sellel marsruudil suunatakse kogu liiklus, millel on marsruut "to_isp1", esimese pakkuja lüüsi, olenemata sellest, milline vaikelüüs on põhitabeli jaoks praegu aktiivne.

3.1.2.5. Esimene varu-rekursiivne vaikemarsruut ISP2 ja ISP3 märgistatud liikluse jaoks:

/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 Neid marsruute on muu hulgas vaja selleks, et reserveerida liiklust kohalikest võrkudest, mis on aadressiloendi „to_isp*” liikmed.

3.1.2.6. Registreerime 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 Koos punktis 1.8.2 toodud reeglitega tagab see juurdepääsu soovitud kanalile antud allikaga. See on kriitilise tähtsusega tunnelite ehitamisel, mis määravad kohaliku külgmise IP-aadressi (EoIP, IP-IP, GRE). Kuna ip marsruudireeglites olevad reeglid täidetakse ülalt alla, kuni tingimuste esimese kokkulangemiseni, siis peaks see reegel olema pärast punkti 1.8.2 reegleid.

3.1.3. Registreerime väljuva liikluse jaoks NAT-reegli:

/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 NATim kõike, mis kustub, välja arvatud see, mis satub IPseci poliitikatesse. Üritan mitte kasutada action=masquerade'i, kui see pole tingimata vajalik. See on aeglasem ja ressursimahukam kui src-nat, kuna see arvutab iga uue ühenduse jaoks NAT-aadressi.

3.1.4. Saadame loendist kliendid, kellel on keelatud juurdepääs teiste pakkujate kaudu, otse ISP1 pakkuja lüüsi.

/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 seda rakendatakse enne teisi marsruutimisreegleid.

place-befor=0 – asetab meie reegli loendis esikohale.

3.2. Seadistage ühendus ISP2-ga.

Kuna ISP2 pakkuja annab meile seaded DHCP kaudu, on mõistlik teha vajalikud muudatused skriptiga, mis käivitub DHCP kliendi käivitamisel:

/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

Skript ise Winboxi aknas:

MÄRKUS Skripti esimene osa käivitatakse siis, kui liising on edukalt sõlmitud, teine - pärast rendilepingu vabastamist.Vaata märkust 2

3.3. Seadistasime ühenduse ISP3 pakkujaga.

Kuna seadete pakkuja annab meile dünaamika, siis on mõistlik teha vajalikud muudatused skriptidega, mis algavad peale ppp liidese tõstmist ja pärast kukkumist.

3.3.1. Kõigepealt 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"

Skript ise Winboxi aknas:

MÄRKUS Rida
/ip tulemüüri mangle set [find comment="Connmark in from ISP3"] in-interface=$"liides";
võimaldab teil liidese ümbernimetamist õigesti käsitleda, kuna see töötab selle koodi, mitte kuvatava nimega.

3.3.2. Nüüd looge profiili kasutades ppp-ühendus:

/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 lihvina paneme kella paika:

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

Neile, kes loevad lõpuni

Kavandatav viis multivani kasutuselevõtuks on autori isiklik eelistus ega ole ainus võimalik. ROS-i tööriistakomplekt on mahukas ja paindlik, mis ühelt poolt tekitab raskusi algajatele ja teisest küljest on selle populaarsuse põhjuseks. Õppige, proovige, avastage uusi tööriistu ja lahendusi. Näiteks omandatud teadmiste rakendusena on multivani antud teostuses võimalik tööriista asendada kontrollvärav rekursiivsete marsruutidega võrgukell.

Märkused

kontrollvärav - mehhanism, mis võimaldab teil marsruudi deaktiveerida pärast kahte järjestikust ebaõnnestunud lüüsi saadavuse kontrolli. Kontroll viiakse läbi iga 10 sekundi järel, millele lisandub vastuse ajalõpp. Kokku jääb tegelik lülitusaeg vahemikku 20-30 sekundit. Kui selline ümberlülitamise ajastus ei ole piisav, on võimalus tööriista kasutada võrgukell, kus kontrolltaimerit saab käsitsi seadistada. kontrollvärav ei käivitu katkendliku paketi kadumise korral lingil.
Tähtis! Peamise marsruudi desaktiveerimine deaktiveerib kõik muud marsruudid, mis sellele viitavad. Seega, et nad täpsustaksid check-gateway=ping pole vaja.
Juhtub, et DHCP mehhanismis ilmneb tõrge, mis näeb välja nagu uuendamisolekusse takerdunud klient. Sel juhul skripti teine osa ei tööta, kuid see ei takista liiklust õigesti kõndimast, kuna olek jälgib vastavat rekursiivset marsruuti.
ECMP (võrdse kuluga mitu teed) - ROS-is on võimalik määrata marsruut mitme lüüsi ja sama vahemaaga. Sel juhul jaotatakse ühendused kanalite vahel ringipõhise algoritmi abil proportsionaalselt määratud lüüside arvuga.

Artikli kirjutamise tõuke saamiseks abi selle ülesehituse ja aktsentide paigutuse kujundamisel - isiklik tänu Jevgenile @jscar

Allikas: www.habr.com