Static Routing-ի հիմունքները Mikrotik RouterOS-ում

Ուղղորդումը TCP/IP ցանցերի միջոցով փաթեթներ փոխանցելու լավագույն ուղին գտնելու գործընթաց է: IPv4 ցանցին միացված ցանկացած սարք պարունակում է գործընթաց և երթուղային աղյուսակներ:

Այս հոդվածը HOWTO չէ, այն նկարագրում է RouterOS-ի ստատիկ երթուղին օրինակներով, ես միտումնավոր բաց եմ թողել մնացած կարգավորումները (օրինակ՝ srcnat ինտերնետ մուտք գործելու համար), ուստի նյութը հասկանալը պահանջում է ցանցերի և RouterOS-ի իմացության որոշակի մակարդակ:

Անջատում և երթուղում

Switching-ը փաթեթների փոխանակման գործընթաց է Layer2 հատվածում (Ethernet, ppp, ...): Եթե ​​սարքը տեսնում է, որ փաթեթի ստացողը գտնվում է իր հետ նույն Ethernet ենթացանցում, նա սովորում է mac հասցեն՝ օգտագործելով arp արձանագրությունը և անմիջապես փոխանցում է փաթեթը՝ շրջանցելով երթուղիչը։ Ppp (կետ-կետ) կապը կարող է ունենալ միայն երկու մասնակից, և փաթեթը միշտ ուղարկվում է մեկ հասցեով՝ 0xff:

Routing-ը Layer2 հատվածների միջև փաթեթների փոխանցման գործընթացն է: Եթե ​​սարքը ցանկանում է ուղարկել փաթեթ, որի ստացողը գտնվում է Ethernet սեգմենտից դուրս, այն նայում է իր երթուղղման աղյուսակին և փոխանցում է փաթեթը դեպի դարպաս, որը գիտի, թե որտեղ պետք է ուղարկել փաթեթը հաջորդիվ (կամ կարող է չգիտի, փաթեթի սկզբնական ուղարկողն է՝ չգիտեմ այս մասին):

Երթուղիչի մասին մտածելու ամենահեշտ ձևն այն է, որ սարքը միացված է երկու կամ ավելի Layer2 սեգմենտներին և ունակ է փաթեթներ փոխանցել դրանց միջև՝ որոշելով երթուղային աղյուսակից լավագույն երթուղին:

Եթե ​​ամեն ինչ հասկանում եք, կամ արդեն գիտեիք, ապա կարդացեք։ Մնացածի համար խստորեն խորհուրդ եմ տալիս ծանոթանալ փոքրիկ, բայց շատ տարողունակի հետ հոդվածներ.

Ուղղորդում RouterOS-ում և PacketFlow-ում

Ստատիկ երթուղման հետ կապված գրեթե բոլոր գործառույթները փաթեթում են համակարգ. Պլաստիկ տոպրակ երթուղի ավելացնում է դինամիկ երթուղային ալգորիթմների (RIP, OSPF, BGP, MME), երթուղային ֆիլտրերի և BFD-ի աջակցություն:

Հիմնական ընտրացանկը երթուղիների կարգավորման համար. [IP]->[Route]. Բարդ սխեմաները կարող են պահանջել, որ փաթեթները նախապես պիտակավորվեն երթուղային նշանով հետևյալում. [IP]->[Firewall]->[Mangle] (շղթաներ PREROUTING и OUTPUT).

PacketFlow-ում կա երեք տեղ, որտեղ կայացվում են IP փաթեթների երթուղման որոշումներ.

1. Ուղղորդող փաթեթներ, որոնք ստացվել են երթուղիչի կողմից: Այս փուլում որոշվում է, թե արդյոք փաթեթը գնալու է լոկալ գործընթաց, թե կուղարկվի հետագա ցանց: Ստացվում են տարանցիկ փաթեթներ Արդյունք Interface
2. Տեղական ելքային փաթեթների ուղղում: Ելքային փաթեթները ստանում են Արդյունք Interface
3. Լրացուցիչ երթուղային քայլ ելքային փաթեթների համար, որը թույլ է տալիս փոխել երթուղային որոշումը [Output|Mangle]

• Փաթեթի ուղին 1, 2 բլոկներում կախված է կանոններից [IP]->[Route]
• Փաթեթի ուղին 1, 2 և 3 կետերում կախված է կանոններից [IP]->[Route]->[Rules]
• 1, 3 բլոկների փաթեթի ուղու վրա կարելի է ազդել՝ օգտագործելով [IP]->[Firewall]->[Mangle]

RIB, FIB, Routing Cache

Ուղղորդման տեղեկատվական բազա
Հիմք, որտեղ երթուղիները հավաքվում են դինամիկ երթուղային արձանագրություններից, երթուղիները ppp և dhcp-ից, ստատիկ և միացված երթուղիներից: Այս տվյալների բազան պարունակում է բոլոր երթուղիները, բացառությամբ ադմինիստրատորի կողմից զտված:

Պայմանականորեն, կարելի է ենթադրել, որ [IP]->[Route] ցուցադրում է RIB-ը:

Փոխանցման տեղեկատվական բազա

Այն բազան, որտեղ հավաքվում են RIB-ից լավագույն երթուղիները: FIB-ի բոլոր երթուղիներն ակտիվ են և օգտագործվում են փաթեթներ փոխանցելու համար: Եթե ​​երթուղին դառնում է ոչ ակտիվ (անջատված է ադմինիստրատորի (համակարգի) կողմից, կամ ինտերֆեյսը, որի միջոցով պետք է ուղարկվի փաթեթը, ակտիվ չէ), երթուղին հեռացվում է FIB-ից:

Երթուղային որոշում կայացնելու համար FIB աղյուսակը օգտագործում է IP փաթեթի վերաբերյալ հետևյալ տեղեկատվությունը.

• Աղբյուրի հասցեն
• Նպատակային հասցե
• Աղբյուրի ինտերֆեյս
• Երթուղային նշան
• ToS (DSCP)

FIB փաթեթ մտնելն անցնում է հետևյալ փուլերով.

• Արդյո՞ք փաթեթը նախատեսված է տեղական երթուղիչի գործընթացի համար:
• Արդյո՞ք փաթեթը ենթակա է համակարգի կամ օգտագործողի PBR կանոնների:
  • Եթե ​​այո, ապա փաթեթն ուղարկվում է նշված երթուղային աղյուսակին
• Փաթեթն ուղարկվում է հիմնական աղյուսակ

Պայմանականորեն, կարելի է ենթադրել, որ [IP]->[Route Active=yes] ցուցադրում է FIB:

Քեշի ուղղորդում
Երթուղու քեշավորման մեխանիզմ: Երթուղիչը հիշում է, թե որտեղ են ուղարկվել փաթեթները, և եթե կան նմանատիպ (ենթադրաբար նույն կապից), թույլ է տալիս նրանց գնալ նույն երթուղով, առանց FIB-ում ստուգելու: Երթուղու քեշը պարբերաբար մաքրվում է:

RouterOS-ի ադմինիստրատորների համար նրանք չեն ստեղծել գործիքներ՝ երթուղավորման քեշը դիտելու և կառավարելու համար, այլ երբ այն կարող է անջատվել: [IP]->[Settings].

Այս մեխանիզմը հեռացվել է linux 3.6 միջուկից, բայց RouterOS-ը դեռ օգտագործում է միջուկը 3.3.5, գուցե Routing cahce-ը պատճառներից մեկն է։

Ավելացնել երթուղու երկխոսություն

[IP]->[Route]->[+]

1. Ենթացանց, որի համար ցանկանում եք ստեղծել երթուղի (կանխադրված՝ 0.0.0.0/0)
2. Դարպասի IP կամ միջերես, որին կուղարկվի փաթեթը (կարող են լինել մի քանիսը, տես ստորև ECMP)
3. Դարպասի հասանելիության ստուգում
4. Գրառման տեսակը
5. Հեռավորություն (մետրիկ) երթուղու համար
6. Երթուղային աղյուսակ
7. IP այս երթուղու միջոցով տեղական ելքային փաթեթների համար
8. Scope-ի և Target Scope-ի նպատակը գրված է հոդվածի վերջում:

Երթուղու դրոշներ

• X - Երթուղին անջատված է ադմինիստրատորի կողմից (disabled=yes)
• A - Երթուղին օգտագործվում է փաթեթներ ուղարկելու համար
• D - Դինամիկ կերպով ավելացված երթուղի (BGP, OSPF, RIP, MME, PPP, DHCP, Միացված)
• C - Ենթացանցը ուղղակիորեն միացված է երթուղիչին
• S - Ստատիկ երթուղի
• r,b,o,m - Դինամիկ երթուղային արձանագրություններից մեկի կողմից ավելացված երթուղի
• B,U,P - Զտման երթուղի (փաթեթները թողնում է փոխանցելու փոխարեն)

Ի՞նչ նշել gateway-ում՝ ip-հասցե կամ ինտերֆեյս:

Համակարգը թույլ է տալիս նշել երկուսն էլ, մինչդեռ այն չի հայհոյում և չի հուշում, եթե ինչ-որ բան սխալ եք արել։

IP հասցե
Դարպասի հասցեն պետք է հասանելի լինի Layer2-ի միջոցով: Ethernet-ի համար սա նշանակում է, որ երթուղիչը պետք է ունենա նույն ենթացանցից հասցե ակտիվ ip ինտերֆեյսներից մեկում, իսկ ppp-ի համար, որ gateway հասցեն նշված է ակտիվ ինտերֆեյսներից մեկում որպես ենթացանցային հասցե:
Եթե ​​Layer2-ի համար հասանելիության պայմանը չի կատարվում, երթուղին համարվում է ոչ ակտիվ և չի ընկնում FIB-ի մեջ:

ինտերֆեյս
Ամեն ինչ ավելի բարդ է, և երթուղիչի վարքագիծը կախված է ինտերֆեյսի տեսակից.

• PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) կապը ենթադրում է ընդամենը երկու մասնակից, և փաթեթը միշտ կուղարկվի դարպաս՝ փոխանցման համար, եթե դարպասը հայտնաբերի, որ ստացողը ինքն է, ապա այն կփոխանցի փաթեթը դեպի դրա տեղական գործընթացը:
  
• Ethernet-ը ենթադրում է բազմաթիվ մասնակիցների ներկայություն և հարցումներ կուղարկի arp ինտերֆեյսին փաթեթի ստացողի հասցեով, սա սպասելի և միանգամայն նորմալ վարքագիծ է միացված երթուղիների համար:
  Բայց երբ փորձում եք օգտագործել ինտերֆեյսը որպես հեռավոր ենթացանցի երթուղի, դուք կստանաք հետևյալ իրավիճակը. երթուղին ակտիվ է, ping-ը դեպի դարպասն անցնում է, բայց նշված ենթացանցից չի հասնում ստացողին: Եթե ​​դուք նայեք ինտերֆեյսին sniffer-ի միջոցով, ապա կտեսնեք arp հարցումներ՝ հեռավոր ենթացանցից հասցեներով:
  

Հնարավորության դեպքում փորձեք նշել ip հասցեն որպես դարպաս: Բացառություն են միացված երթուղիները (ստեղծվում են ավտոմատ կերպով) և PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*) միջերեսները:

OpenVPN-ը չի պարունակում PPP վերնագիր, բայց դուք կարող եք օգտագործել OpenVPN ինտերֆեյսի անունը՝ երթուղի ստեղծելու համար:

Ավելի կոնկրետ երթուղի

Հիմնական երթուղային կանոն. Երթուղին, որը նկարագրում է ավելի փոքր ենթացանցը (ամենամեծ ենթացանցով դիմակ) գերակայություն ունի փաթեթի երթուղային որոշման մեջ: Ուղղորդման աղյուսակում գրառումների դիրքը չի համապատասխանում ընտրությանը. հիմնական կանոնն ավելի կոնկրետ է:

Նշված սխեմայից բոլոր երթուղիներն ակտիվ են (գտնվում են FIB-ում): մատնանշեք տարբեր ենթացանցեր և չեն հակասում միմյանց:

Եթե ​​դարպասներից մեկն անհասանելի դառնա, հարակից երթուղին կհամարվի ոչ ակտիվ (հեռացված է FIB-ից), իսկ փաթեթները կփնտրվեն մնացած երթուղիներից:

0.0.0.0/0 ենթացանցով երթուղին երբեմն տրվում է հատուկ նշանակություն և կոչվում է «Լռակյաց երթուղի» կամ «Վերջին միջոցի դարպաս»: Իրականում, դրանում ոչ մի կախարդական բան չկա, և այն պարզապես ներառում է բոլոր հնարավոր IPv4 հասցեները, բայց այս անունները լավ նկարագրում են դրա առաջադրանքը. այն ցույց է տալիս այն դարպասը, որտեղ փոխանցվում են փաթեթներ, որոնց համար այլ, ավելի ճշգրիտ երթուղիներ չկան:

IPv4-ի առավելագույն հնարավոր ենթացանցային դիմակը /32 է, այս երթուղին մատնանշում է կոնկրետ հոսթ և կարող է օգտագործվել երթուղային աղյուսակում:

Ավելի կոնկրետ երթուղի հասկանալը հիմնարար է ցանկացած TCP/IP սարքի համար:

Հեռավորություն

Հեռավորությունները (կամ չափումները) պահանջվում են երթուղիների վարչական զտման համար դեպի մեկ ենթացանց, որոնք հասանելի են բազմաթիվ դարպասների միջոցով: Ավելի ցածր ցուցանիշ ունեցող երթուղին համարվում է առաջնահերթություն և կներառվի FIB-ում: Եթե ​​ավելի ցածր մետրիկով երթուղին դադարում է ակտիվ լինել, ապա այն FIB-ում կփոխարինվի ավելի բարձր մետրիկով երթուղիով:

Եթե ​​կան մի քանի երթուղիներ դեպի նույն ենթացանց՝ նույն մետրով, ապա երթուղիչը կավելացնի դրանցից միայն մեկը FIB աղյուսակում՝ առաջնորդվելով իր ներքին տրամաբանությամբ:

Չափանիշը կարող է ունենալ 0-ից մինչև 255 արժեք.

• 0 - մետրիկ միացված երթուղիների համար: Հեռավորությունը 0 չի կարող սահմանվել ադմինիստրատորի կողմից
• 1-254 - Չափումներ, որոնք հասանելի են ադմինիստրատորին երթուղիներ սահմանելու համար: Ավելի ցածր արժեք ունեցող չափորոշիչներն ավելի բարձր առաջնահերթություն ունեն
• 255 - Չափանիշը հասանելի է ադմինիստրատորին՝ երթուղիներ սահմանելու համար: Ի տարբերություն 1-254-ի, 255 մետրիկ ունեցող երթուղին միշտ մնում է անգործուն և չի ընկնում FIB-ի մեջ:
• կոնկրետ չափումներ. Դինամիկ երթուղային արձանագրություններից ստացված երթուղիներն ունեն ստանդարտ մետրային արժեքներ

ստուգեք դարպասը

Check gateway-ը MikroTik RoutesOS-ի ընդլայնում է՝ icmp-ի կամ arp-ի միջոցով դարպասի հասանելիությունը ստուգելու համար: Յուրաքանչյուր 10 վայրկյանը մեկ անգամ (չի կարող փոխվել), հարցում է ուղարկվում դարպասին, եթե պատասխանը երկու անգամ չի ստացվում, երթուղին համարվում է անհասանելի և հեռացվում է FIB-ից: Եթե ​​ստուգման դարպասն անջատված է, ստուգման ուղին շարունակվում է, և մեկ հաջող ստուգումից հետո երթուղին նորից կակտիվանա:

Check gateway-ն անջատում է մուտքը, որտեղ այն կազմաձևված է, և բոլոր այլ մուտքերը (բոլոր երթուղային աղյուսակներում և ecmp երթուղիներում) նշված դարպասով:

Ընդհանրապես, check gateway-ը լավ է աշխատում, քանի դեռ դարպասի համար փաթեթների կորստի հետ կապված խնդիրներ չկան: Check gateway-ը չգիտի, թե ինչ է կատարվում ստուգված դարպասից դուրս հաղորդակցության հետ, սա պահանջում է լրացուցիչ գործիքներ՝ սկրիպտներ, ռեկուրսիվ երթուղում, դինամիկ երթուղային արձանագրություններ:

VPN-ի և թունելային արձանագրությունների մեծ մասը պարունակում է ներկառուցված գործիքներ կապի ակտիվությունը ստուգելու համար, ինչը հնարավորություն է տալիս ստուգման դարպասը նրանց համար լրացուցիչ (բայց շատ փոքր) բեռ է ցանցի և սարքի աշխատանքի վրա:

ECMP երթուղիներ

Equal-Cost Multi-Path - փաթեթների ուղարկում ստացողին՝ օգտագործելով մի քանի դարպասներ՝ միաժամանակ օգտագործելով Round Robin ալգորիթմը:

ECMP երթուղին ստեղծվում է ադմինիստրատորի կողմից՝ նշելով մի քանի դարպասներ մեկ ենթացանկի համար (կամ ավտոմատ կերպով, եթե կան երկու համարժեք OSPF երթուղիներ):

ECMP-ն օգտագործվում է երկու ալիքների միջև բեռի հավասարակշռման համար, տեսականորեն, եթե ecmp երթուղում երկու ալիք կա, ապա յուրաքանչյուր փաթեթի համար ելքային ալիքը պետք է տարբեր լինի: Բայց Routing cache մեխանիզմը փաթեթներ է ուղարկում կապից այն երթուղու երկայնքով, որը վերցրեց առաջին փաթեթը, արդյունքում մենք ստանում ենք մի տեսակ հավասարակշռում, որը հիմնված է միացումների վրա (մեկ կապի բեռնման հավասարակշռում):

Եթե ​​անջատեք Routing Cache-ը, ապա ECMP երթուղու փաթեթները ճիշտ կկիսվեն, բայց NAT-ի հետ խնդիր կա: NAT կանոնը մշակում է կապից միայն առաջին փաթեթը (մնացածը մշակվում է ավտոմատ կերպով), և ստացվում է, որ նույն աղբյուրի հասցեով փաթեթները թողնում են տարբեր միջերեսներ։

Ստուգման դարպասը չի աշխատում ECMP երթուղիներում (RouterOS-ի սխալ): Բայց դուք կարող եք շրջանցել այս սահմանափակումը՝ ստեղծելով լրացուցիչ վավերացման երթուղիներ, որոնք կանջատեն մուտքերը ECMP-ում:

Զտում երթուղիների միջոցով

Type տարբերակը որոշում է, թե ինչ անել փաթեթի հետ.

• unicast - ուղարկել նշված դարպասին (ինտերֆեյս)
• blackhole - հրաժարվել փաթեթից
• արգելել, անհասանելի - հեռացնել փաթեթը և ուղարկել icmp հաղորդագրություն ուղարկողին

Զտումը սովորաբար օգտագործվում է, երբ անհրաժեշտ է ապահովել փաթեթների ուղարկումը սխալ ճանապարհով, իհարկե, դուք կարող եք դա զտել firewall-ի միջոցով:

Մի երկու օրինակ

Համախմբել երթուղավորման մասին հիմնական բաները:

Տիպիկ տնային երթուղիչ

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1

1. Ստատիկ երթուղի դեպի 0.0.0.0/0 (կանխադրված երթուղի)
2. Միացված երթուղին մատակարարի հետ ինտերֆեյսի վրա
3. Միացված երթուղի LAN ինտերֆեյսի վրա

Տիպիկ տնային երթուղիչ PPPoE-ով

1. Ստատիկ երթուղի դեպի լռելյայն երթուղի, ինքնաբերաբար ավելացված: այն նշված է կապի հատկություններում
2. Միացված երթուղի PPP միացման համար
3. Միացված երթուղի LAN ինտերֆեյսի վրա

Տիպիկ տնային երթուղիչ երկու մատակարարներով և ավելորդությամբ

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

1. Ստատիկ երթուղի դեպի լռելյայն երթուղի առաջին մատակարարի միջով մետրային 1-ով և դարպասի հասանելիության ստուգմամբ
2. Ստատիկ երթուղի դեպի լռելյայն երթուղի երկրորդ մատակարարի միջոցով մետրիկ 2-ով
3. Կապակցված երթուղիներ

0.0.0.0/0 տրաֆիկը անցնում է 10.10.10.1-ով, քանի դեռ այս դարպասը հասանելի է, հակառակ դեպքում այն ​​անցնում է 10.20.20.1-ի:

Նման սխեման կարելի է համարել կապուղու ամրագրում, բայց դա առանց թերությունների չէ։ Եթե ​​մատակարարի դարպասից դուրս (օրինակ՝ օպերատորի ցանցի ներսում) ընդմիջում տեղի ունենա, ձեր երթուղիչը չի իմանա այդ մասին և կշարունակի երթուղին ակտիվ համարել:

Տիպիկ տնային երթուղիչ երկու մատակարարներով՝ ավելորդություն և ECMP

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.10.10.1,10.20.20.1 distance=1

1. Ստատիկ երթուղիներ՝ չեկի դարպասը ստուգելու համար
2. ECMP երթուղի
3. Կապակցված երթուղիներ

Ստուգման երթուղիները կապույտ են (ոչ ակտիվ երթուղիների գույնը), բայց դա չի խանգարում ստուգման դարպասին: RoS-ի ներկայիս տարբերակը (6.44) ավտոմատ առաջնահերթություն է տալիս ECMP երթուղուն, բայց ավելի լավ է փորձնական երթուղիներ ավելացնել այլ երթուղային աղյուսակներում (տարբերակ routing-mark)

Speedtest-ում և այլ նմանատիպ կայքերում արագության բարձրացում չի լինի (ECMP-ը տրաֆիկը բաժանում է կապերի, ոչ թե փաթեթների), սակայն p2p հավելվածները պետք է ավելի արագ ներբեռնվեն։

Զտում երթուղղման միջոցով

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1
add dst-address=192.168.200.0/24 gateway=10.30.30.1 distance=1
add dst-address=192.168.200.0/24 gateway=10.10.10.1 distance=2 type=blackhole

1. Ստատիկ երթուղի դեպի լռելյայն երթուղի
2. Ստատիկ երթուղի դեպի 192.168.200.0/24 ipip թունելի վրայով
3. Արգելում է ստատիկ երթուղին դեպի 192.168.200.0/24, ISP երթուղիչի միջոցով

Զտման տարբերակ, որտեղ թունելի երթևեկությունը չի գնա մատակարարի երթուղիչ, երբ ipip ինտերֆեյսն անջատված է: Նման սխեմաները հազվադեպ են պահանջվում, քանի որ դուք կարող եք արգելափակում իրականացնել firewall-ի միջոցով:

Երթուղային հանգույց
Routing loop - իրավիճակ, երբ փաթեթն անցնում է երթուղիչների միջև մինչև ttl-ի ժամկետի ավարտը: Սովորաբար դա կոնֆիգուրացիայի սխալի արդյունք է, մեծ ցանցերում այն ​​վերաբերվում է դինամիկ երթուղային արձանագրությունների ներդրմամբ, փոքրերում՝ խնամքով։

Դա նման բան է թվում.

Օրինակ (ամենապարզ), թե ինչպես ստանալ նմանատիպ արդյունք.

Routing loop-ի օրինակը գործնական կիրառություն չունի, բայց այն ցույց է տալիս, որ երթուղիչները գաղափար չունեն իրենց հարևանի երթուղային աղյուսակի մասին:

Քաղաքականության բազայի երթուղի և լրացուցիչ երթուղային աղյուսակներ

Երթուղի ընտրելիս երթուղիչը օգտագործում է միայն մեկ դաշտ փաթեթի վերնագրից (Dst. Address) - սա հիմնական երթուղավորում է: Այլ պայմանների վրա հիմնված երթուղիավորումը, ինչպիսիք են աղբյուրի հասցեն, տրաֆիկի տեսակը (ToS), հավասարակշռումը առանց ECMP-ի, պատկանում է Policy Base Routing-ին (PBR) և օգտագործում է լրացուցիչ երթուղային աղյուսակներ:

Ավելի կոնկրետ երթուղի երթուղային աղյուսակում հիմնական երթուղու ընտրության կանոնն է:

Լռելյայնորեն, բոլոր երթուղային կանոնները ավելացվում են հիմնական աղյուսակում: Ադմինիստրատորը կարող է ստեղծել կամայական թվով լրացուցիչ երթուղային աղյուսակներ և երթուղային փաթեթներ դեպի դրանք: Տարբեր աղյուսակների կանոնները չեն հակասում միմյանց: Եթե ​​փաթեթը նշված աղյուսակում չի գտնում համապատասխան կանոն, այն կանցնի հիմնական աղյուսակ:

Firewall-ի միջոցով բաշխման օրինակ.

• 192.168.100.10 -> 8.8.8.8
  1. Երթևեկությունը 192.168.100.10-ից ստանում է պիտակավորում via-isp1-ի միջոցով в [Prerouting|Mangle]
  2. Աղյուսակում գտնվող Routing փուլում via-isp1-ի միջոցով որոնում է դեպի 8.8.8.8 երթուղի
  3. Գտնվել է երթուղի, երթևեկությունն ուղարկվում է 10.10.10.1 դարպաս
• 192.168.200.20 -> 8.8.8.8
  1. Երթևեկությունը 192.168.200.20-ից ստանում է պիտակավորում via-isp2-ի միջոցով в [Prerouting|Mangle]
  2. Աղյուսակում գտնվող Routing փուլում via-isp2-ի միջոցով որոնում է դեպի 8.8.8.8 երթուղի
  3. Գտնվել է երթուղի, երթևեկությունն ուղարկվում է 10.20.20.1 դարպաս
• Եթե ​​դարպասներից մեկը (10.10.10.1 կամ 10.20.20.1) անհասանելի դառնա, ապա փաթեթը կգնա սեղանին: հիմնական և այնտեղ հարմար երթուղի կփնտրի

Տերմինաբանական խնդիրներ

RouterOS-ն ունի որոշակի տերմինաբանական խնդիրներ:
Կանոններով աշխատելիս [IP]->[Routes] երթուղային աղյուսակը նշված է, չնայած գրված է, որ պիտակը.

В [IP]->[Routes]->[Rule] ամեն ինչ ճիշտ է, աղյուսակի գործողության պիտակի վիճակում.

Ինչպես փաթեթ ուղարկել կոնկրետ երթուղային աղյուսակին

RouterOS-ը տրամադրում է մի քանի գործիքներ.

• Կանոններ մեջ [IP]->[Routes]->[Rules]
• Երթուղու նշիչներ (action=mark-routing) մեջ [IP]->[Firewall]->[Mangle]
• VRF

կանոնակարգերը [IP]->[Route]->[Rules]
Կանոնները մշակվում են հաջորդաբար, եթե փաթեթը համապատասխանում է կանոնի պայմաններին, այն չի անցնում հետագա:

Routing Rules-ը թույլ է տալիս ընդլայնել երթուղավորման հնարավորությունները՝ հենվելով ոչ միայն ստացողի հասցեի վրա, այլ նաև սկզբնաղբյուրի հասցեի և միջերեսի վրա, որից ստացվել է փաթեթը:

Կանոնները բաղկացած են պայմաններից և գործողություններից.

• Պայմաններ. Գործնականում կրկնել այն նշանների ցանկը, որոնցով փաթեթը ստուգվում է FIB-ում, բացակայում է միայն ToS-ը:
• Գործունեություն
  • փնտրել - փաթեթ ուղարկել սեղանին
  • որոնել միայն աղյուսակում - փաթեթը փակել աղյուսակում, եթե երթուղին չի գտնվել, փաթեթը չի գնա հիմնական աղյուսակ
  • drop - գցել փաթեթ
  • անհասանելի - հրաժարվել ուղարկողի ծանուցմամբ փաթեթը

FIB-ում երթևեկությունը դեպի տեղական գործընթացներ մշակվում է՝ շրջանցելով կանոնները [IP]->[Route]->[Rules]:

Նշում [IP]->[Firewall]->[Mangle]
Ուղղորդող պիտակները թույլ են տալիս փաթեթի համար մուտք գործել՝ օգտագործելով Firewall-ի գրեթե ցանկացած պայմաններ.

Գործնականում, քանի որ դրանցից ոչ բոլորն են իմաստավորում, և ոմանք կարող են անկայուն աշխատել:

Փաթեթը պիտակավորելու երկու եղանակ կա.

• Անմիջապես դրեք երթուղային նշան
• Դրեք առաջինը կապի նշան, ապա հիման վրա կապի նշան սահմանել երթուղային նշան

Firewall-ների մասին հոդվածում գրել էի, որ նախընտրելի է երկրորդ տարբերակը։ նվազեցնում է պրոցեսորի ծանրաբեռնվածությունը, երթուղիների գծանշման դեպքում, սա ամբողջովին ճիշտ չէ: Նշման այս մեթոդները միշտ չէ, որ համարժեք են և սովորաբար օգտագործվում են տարբեր խնդիրներ լուծելու համար:

Օգտագործման օրինակներ

Անցնենք Policy Base Routing-ի օգտագործման օրինակներին, դրանք շատ ավելի հեշտ է ցույց տալ, թե ինչու է այս ամենը անհրաժեշտ։

MultiWAN և վերադարձ ելքային (Ելք) տրաֆիկ
MultiWAN կոնֆիգուրացիայի հետ կապված ընդհանուր խնդիր. Mikrotik-ը հասանելի է ինտերնետից միայն «ակտիվ» մատակարարի միջոցով:

Ուղղորդողին չի հետաքրքրում, թե ինչ ip-ի է եկել հարցումը, պատասխան ստեղծելիս նա երթուղային աղյուսակում կփնտրի երթուղի, որտեղ ակտիվ է երթուղին isp1-ով: Ավելին, նման փաթեթը, ամենայն հավանականությամբ, կզտվի ստացողի ճանապարհին:

Մեկ այլ հետաքրքիր կետ. Եթե ​​«պարզ» աղբյուրի nat-ը կազմաձևված է ether1 ինտերֆեյսի վրա. /ip fi nat add out-interface=ether1 action=masquerade փաթեթը առցանց կմտնի src-ով: հասցե=10.10.10.100, որն էլ ավելի է վատացնում իրավիճակը:

Խնդիրը շտկելու մի քանի եղանակ կա, բայց դրանցից որևէ մեկը կպահանջի լրացուցիչ երթուղային աղյուսակներ.

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping distance=2
add dst-address=0.0.0.0/0 gateway=10.10.10.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 routing-mark=over-isp2

Օգտագործում [IP]->[Route]->[Rules]
Նշեք երթուղային աղյուսակը, որը կօգտագործվի նշված Source IP-ով փաթեթների համար:

/ip route rule
add src-address=10.10.10.100/32 action=lookup-only-in-table table=over-isp1
add src-address=10.20.20.200/32 action=lookup-only-in-table table=over-isp2

Կարող եք օգտագործել action=lookup, բայց տեղական ելքային տրաֆիկի համար այս տարբերակը լիովին բացառում է սխալ ինտերֆեյսի կապերը:

• Համակարգը ստեղծում է պատասխան փաթեթ Src-ով: Հասցե՝ 10.20.20.200թ
• Երթուղային որոշումը (2) քայլը ստուգում է [IP]->[Routes]->[Rules] և փաթեթն ուղարկվում է երթուղային աղյուսակ over-isp2
• Ըստ երթուղային աղյուսակի, փաթեթը պետք է ուղարկվի gateway 10.20.20.1 ether2 ինտերֆեյսի միջոցով:

Այս մեթոդը չի պահանջում աշխատող Connection Tracker, ի տարբերություն Mangle աղյուսակի օգտագործման:

Օգտագործում [IP]->[Firewall]->[Mangle]
Կապը սկսվում է մուտքային փաթեթից, ուստի մենք նշում ենք այն (action=mark-connection), նշված միացումից ելքային փաթեթների համար սահմանեք երթուղային պիտակը (action=mark-routing).

/ip firewall mangle
#Маркировка входящих соединений
add chain=input in-interface=ether1 connection-state=new action=mark-connection new-connection-mark=from-isp1
add chain=input in-interface=ether2 connection-state=new action=mark-connection new-connection-mark=from-isp2
#Маркировка исходящих пакетов на основе соединений
add chain=output connection-mark=from-isp1 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=output connection-mark=from-isp2 action=mark-routing new-routing-mark=over-isp2 passthrough=no

Եթե ​​մի քանի IP-ներ կազմաձևված են մեկ ինտերֆեյսի վրա, կարող եք ավելացնել պայմանը dst-address վստահ լինել.

• Փաթեթը բացում է կապը ether2 ինտերֆեյսի վրա: Փաթեթը մտնում է [INPUT|Mangle] որն ասում է միացումից բոլոր փաթեթները նշել որպես from-isp2
• Համակարգը ստեղծում է պատասխան փաթեթ Src-ով: Հասցե՝ 10.20.20.200թ
• Routing Decision(2) փուլում փաթեթը, համաձայն երթուղային աղյուսակի, ուղարկվում է gateway 10.20.20.1 ether1 ինտերֆեյսի միջոցով: Դուք կարող եք դա հաստատել՝ մուտք գործելով փաթեթները [OUTPUT|Filter]
• Բեմում [OUTPUT|Mangle] կապի պիտակը ստուգված է from-isp2 և փաթեթը ստանում է երթուղու պիտակ over-isp2
• Routing Adjusment(3) քայլը ստուգում է երթուղային պիտակի առկայությունը և այն ուղարկում համապատասխան երթուղային աղյուսակին:
• Ըստ երթուղային աղյուսակի, փաթեթը պետք է ուղարկվի gateway 10.20.20.1 ether2 ինտերֆեյսի միջոցով:

MultiWAN և վերադարձ dst-nat տրաֆիկ

Օրինակն ավելի բարդ է, ինչ անել, եթե մասնավոր ենթացանցում երթուղիչի հետևում կա սերվեր (օրինակ՝ վեբ), և դուք պետք է մուտք գործեք դրա մուտքը պրովայդերներից որևէ մեկի միջոցով:

/ip firewall nat
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether1 action=dst-nat to-address=192.168.100.100
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether2 action=dst-nat to-address=192.168.100.100

Խնդրի էությունը նույնն է լինելու, լուծումը նման է Firewall Mangle տարբերակին, կօգտագործվեն միայն այլ շղթաներ.

/ip firewall mangle
add chain=prerouting connection-state=new in-interface=ether1 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp1
add chain=prerouting connection-state=new in-interface=ether2 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp2
add chain=prerouting connection-mark=web-input-isp1 in-interface=ether3 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting connection-mark=web-input-isp2 in-interface=ether3 action=mark-routing new-routing-mark=over-isp2 passthrough=no

Դիագրամը ցույց չի տալիս NAT, բայց կարծում եմ, որ ամեն ինչ պարզ է:

MultiWAN և ելքային կապեր

Դուք կարող եք օգտագործել PBR հնարավորությունները՝ տարբեր երթուղիչի միջերեսներից մի քանի vpn (օրինակ՝ SSTP) միացումներ ստեղծելու համար:

Լրացուցիչ երթուղային աղյուսակներ.

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.100.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 routing-mark=over-isp3

add dst-address=0.0.0.0/0 gateway=192.168.100.1 distance=1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 distance=2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 distance=3

Փաթեթի նշումներ.

/ip firewall mangle
add chain=output dst-address=10.10.10.100 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp1 passtrough=no
add chain=output dst-address=10.10.10.101 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp2 passtrough=no
add chain=output dst-address=10.10.10.102 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp3 passtrough=no

Պարզ NAT կանոններ, հակառակ դեպքում փաթեթը կթողնի միջերեսը սխալ Src-ով: հասցե:

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade
add chain=srcnat out-interface=ether2 action=masquerade
add chain=srcnat out-interface=ether3 action=masquerade

Վերլուծում:

• Ուղղորդիչը ստեղծում է երեք SSTP գործընթաց
• Երթուղային որոշման (2) փուլում այս գործընթացների համար երթուղին ընտրվում է հիմնական երթուղային աղյուսակի հիման վրա: Նույն երթուղուց փաթեթը ստանում է Src: Հասցեն կապված է ether1 ինտերֆեյսի հետ
• В [Output|Mangle] Տարբեր կապերից փաթեթները ստանում են տարբեր պիտակներ
• Փաթեթները մտնում են պիտակների համապատասխան աղյուսակներ Routing Adjusment փուլում և ստանում են փաթեթներ ուղարկելու նոր երթուղի:
• Բայց փաթեթները դեռ ունեն Src: Հասցե ether1-ից, բեմում [Nat|Srcnat] հասցեն փոխարինվում է ինտերֆեյսի համաձայն

Հետաքրքիր է, որ երթուղիչի վրա կտեսնեք կապի հետևյալ աղյուսակը.

Connection Tracker-ն աշխատում է ավելի վաղ [Mangle] и [Srcnat], այնպես որ բոլոր կապերը գալիս են նույն հասցեից, եթե ավելի մանրամասն նայեք, ապա ներս Replay Dst. Address NAT-ից հետո կլինեն հասցեներ.

VPN սերվերի վրա (ես ունեմ մեկը փորձարկման նստարանին), կարող եք տեսնել, որ բոլոր կապերը գալիս են ճիշտ հասցեներից.

Սպասեք մի ճանապարհ
Կա ավելի հեշտ ճանապարհ, դուք կարող եք պարզապես նշել հատուկ դարպաս յուրաքանչյուր հասցեի համար.

/ip route
add dst-address=10.10.10.100 gateway=192.168.100.1
add dst-address=10.10.10.101 gateway=192.168.200.1
add dst-address=10.10.10.102 gateway=192.168.0.1

Բայց նման երթուղիները կազդեն ոչ միայն ելքային, այլեւ տարանցիկ երթեւեկության վրա։ Բացի այդ, եթե ձեզ հարկավոր չէ երթևեկություն դեպի vpn սերվեր՝ անհամապատասխան կապի ուղիներով անցնելու համար, ապա ստիպված կլինեք ավելացնել ևս 6 կանոն։ [IP]->[Routes]с type=blackhole. Նախորդ տարբերակում - 3 կանոն [IP]->[Route]->[Rules].

Օգտագործողների կապերի բաշխում ըստ կապի ուղիների

Պարզ, ամենօրյա առաջադրանքներ. Կրկին, լրացուցիչ երթուղային աղյուսակներ կպահանջվեն.

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2

Օգտագործելով [IP]->[Route]->[Rules]

/ip route rules
add src-address=192.168.100.0/25 action=lookup-only-in-table table=over-isp1
add src-address=192.168.100.128/25 action=lookup-only-in-table table=over-isp2

Օգտագործման դեպքում action=lookup, ապա երբ ալիքներից մեկն անջատված է, երթևեկությունը կգնա դեպի հիմնական աղյուսակը և կանցնի աշխատանքային ալիքով։ Դա անհրաժեշտ է, թե ոչ, կախված է առաջադրանքից:

Օգտագործելով նշումները [IP]->[Firewall]->[Mangle]
Պարզ օրինակ ip հասցեների ցուցակներով: Սկզբունքորեն, գրեթե ցանկացած պայմաններ կարող են օգտագործվել: Layer7-ի միակ նախազգուշացումը, նույնիսկ երբ զուգակցվում է կապի պիտակների հետ, կարող է թվալ, որ ամեն ինչ ճիշտ է աշխատում, բայց որոշ երթևեկություն դեռ սխալ ճանապարհով կգնա:

/ip firewall mangle
add chain=prerouting src-address-list=users-over-isp1 dst-address-type=!local action=mark-routing new-routing-mark=over-isp1
add chain=prerouting src-address-list=users-over-isp2 dst-address-type=!local action=mark-routing new-routing-mark=over-isp2

Դուք կարող եք «կողպել» օգտվողներին մեկ երթուղային աղյուսակում [IP]->[Route]->[Rules]:

/ip route rules
add routing-mark=over-isp1 action=lookup-only-in-table table=over-isp1
add routing-mark=over-isp2 action=lookup-only-in-table table=over-isp2

Կամ միջոցով [IP]->[Firewall]->[Filter]:

/ip firewall filter
add chain=forward routing-mark=over-isp1 out-interface=!ether1 action=reject
add chain=forward routing-mark=over-isp2 out-interface=!ether2 action=reject

Retreat pro dst-address-type=!local
Լրացուցիչ պայման dst-address-type=!local անհրաժեշտ է, որ օգտագործողների կողմից տրաֆիկը հասնի երթուղիչի տեղական գործընթացներին (dns, winbox, ssh, ...): Եթե ​​մի քանի տեղական ենթացանցեր միացված են երթուղիչին, ապա անհրաժեշտ է ապահովել, որ դրանց միջև երթևեկությունը չգնա ինտերնետ, օրինակ՝ օգտագործելով dst-address-table.

Օգտագործելով օրինակում [IP]->[Route]->[Rules] Նման բացառություններ չկան, բայց երթևեկությունը հասնում է տեղական գործընթացների: Փաստն այն է, որ մտնելով FIB փաթեթում նշված է [PREROUTING|Mangle] ունի երթուղու պիտակ և մտնում է երթուղային աղյուսակ, բացի հիմնականից, որտեղ չկա տեղական ինտերֆեյս: Routing Rules-ի դեպքում նախ ստուգվում է, թե արդյոք փաթեթը նախատեսված է լոկալ գործընթացի համար և միայն User PBR փուլում է այն անցնում նշված երթուղային աղյուսակին։

Օգտագործելով [IP]->[Firewall]->[Mangle action=route]
Այս գործողությունը գործում է միայն [Prerouting|Mangle] և թույլ է տալիս ուղղորդել երթևեկությունը դեպի նշված դարպաս՝ առանց լրացուցիչ երթուղային աղյուսակների օգտագործման՝ ուղղակիորեն նշելով դարպասի հասցեն.

/ip firewall mangle
add chain=prerouting src-address=192.168.100.0/25 action=route gateway=10.10.10.1
add chain=prerouting src-address=192.168.128.0/25 action=route gateway=10.20.20.1

ազդեցություն route ունի ավելի ցածր առաջնահերթություն, քան երթուղային կանոնները ([IP]->[Route]->[Rules]) Երթուղային նշանների դեպքում ամեն ինչ կախված է կանոնների դիրքից, եթե կանոնը հետ action=route արժե ավելի քան action=mark-route, ապա այն կօգտագործվի (անկախ դրոշից passtrough), հակառակ դեպքում նշելով երթուղին:
Վիքիում շատ քիչ տեղեկություններ կան այս գործողության մասին և բոլոր եզրակացությունները ստացվում են փորձարարական եղանակով, ամեն դեպքում ես տարբերակներ չեմ գտել, երբ այս տարբերակի օգտագործումը առավելություններ է տալիս մյուսների նկատմամբ։

PPC-ի վրա հիմնված դինամիկ հավասարակշռում

Per Connection Classifier-ը ECMP-ի ավելի ճկուն անալոգ է: Ի տարբերություն ECMP-ի, այն ավելի խիստ է բաժանում երթևեկությունն ըստ կապերի (ECMP-ն ոչինչ չգիտի կապերի մասին, բայց երբ զուգակցվում է Routing Cache-ի հետ, ստացվում է նման բան):

PCC-ն վերցնում է նշված դաշտերը ip-ի վերնագրից, դրանք փոխակերպում է 32-բիթանոց արժեքի և բաժանում հայտարար. Բաժանման մնացած մասը համեմատվում է նշվածի հետ մնացորդը իսկ եթե դրանք համընկնում են, ապա կիրառվում է նշված գործողությունը։ ավելի շատ. Խենթ է հնչում, բայց այն աշխատում է:

Օրինակ երեք հասցեներով.

192.168.100.10: 192+168+100+10 = 470 % 3 = 2
192.168.100.11: 192+168+100+11 = 471 % 3 = 0
192.168.100.12: 192+168+100+12 = 472 % 3 = 1

Երեք ալիքների միջև src.address-ով տրաֆիկի դինամիկ բաշխման օրինակ.

#Таблица маршрутизации
/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=3 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=1 routing-mark=over-isp3

#Маркировка соединений и маршрутов
/ip firewall mangle
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/0 action=mark-connection new-connection-mark=conn-over-isp1
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/1 action=mark-connection new-connection-mark=conn-over-isp2
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/2 action=mark-connection new-connection-mark=conn-over-isp3

add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp1 action=mark-routing new-routing-mark=over-isp1
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp2 action=mark-routing new-routing-mark=over-isp2
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp3 action=mark-routing new-routing-mark=over-isp3

Երթուղիներ նշելիս կա լրացուցիչ պայման. in-interface=br-lan, առանց դրա տակ action=mark-routing Ինտերնետից պատասխան տրաֆիկը կստանա և, համաձայն երթուղային աղյուսակների, կվերադառնա մատակարարին:

Կապի ալիքների փոխարկում

Check ping-ը լավ գործիք է, բայց այն ստուգում է կապը միայն մոտակա IP գործընկերոջ հետ, պրովայդերների ցանցերը սովորաբար բաղկացած են մեծ թվով երթուղիչներից, և կապի ընդհատումը կարող է տեղի ունենալ մոտակա գործընկերից դուրս, և այդ ժամանակ կան հիմնական հեռահաղորդակցության օպերատորներ, որոնք կարող են նաև խնդիրներ ունեն, ընդհանուր առմամբ ստուգման ping-ը միշտ չէ, որ ցույց է տալիս արդի տեղեկատվություն համաշխարհային ցանց մուտք գործելու մասին:
Եթե ​​պրովայդերները և խոշոր կորպորացիաներն ունեն BGP դինամիկ երթուղային արձանագրություն, ապա տնային և գրասենյակային օգտվողները պետք է ինքնուրույն պարզեն, թե ինչպես ստուգել ինտերնետ հասանելիությունը հատուկ հաղորդակցման ալիքով:

Սովորաբար օգտագործվում են սկրիպտներ, որոնք որոշակի հաղորդակցման ալիքի միջոցով ստուգում են ինտերնետում ip հասցեի առկայությունը՝ միաժամանակ ընտրելով ինչ-որ հուսալի բան, օրինակ՝ google dns՝ 8.8.8.8: 8.8.4.4. Բայց Միկրոտիկ համայնքում սրա համար հարմարեցվել է ավելի հետաքրքիր գործիք.

Մի քանի խոսք ռեկուրսիվ երթուղավորման մասին
Ռեկուրսիվ երթուղավորումն անհրաժեշտ է Multihop BGP peering-ի ստեղծման ժամանակ և մտավ ստատիկ երթուղման հիմունքների մասին հոդվածում միայն MikroTik-ի խորամանկ օգտատերերի շնորհիվ, ովքեր հասկացան, թե ինչպես օգտագործել ռեկուրսիվ երթուղիները՝ զուգակցված check gateway-ի հետ՝ առանց հավելյալ սկրիպտների կապի ալիքները փոխելու համար:

Ժամանակն է հասկանալու շրջանակի / թիրախային շրջանակի ընտրանքները ընդհանուր գծերով և թե ինչպես է երթուղին կապված միջերեսի հետ.

1. Երթուղին փնտրում է ինտերֆեյս՝ փաթեթն ուղարկելու համար՝ հիմնվելով դրա շրջանակի արժեքի և հիմնական աղյուսակի բոլոր գրառումների վրա՝ նպատակային շրջանակի շրջանակի փոքր կամ հավասար արժեքներով:
2. Գտնված միջերեսներից ընտրվում է այն մեկը, որի միջոցով կարող եք փաթեթ ուղարկել նշված դարպասին
3. Գտնված միացված մուտքի ինտերֆեյսը ընտրված է փաթեթը դարպաս ուղարկելու համար

Ռեկուրսիվ երթուղու առկայության դեպքում ամեն ինչ տեղի է ունենում նույնը, բայց երկու փուլով.

• 1-3 Միացված երթուղիներին ավելացվում է ևս մեկ երթուղի, որով կարելի է հասնել նշված դարպաս
• 4-6 «միջանկյալ» դարպասի համար միացված երթուղու հայտնաբերում

Ռեկուրսիվ որոնման հետ կապված բոլոր մանիպուլյացիաները տեղի են ունենում RIB-ում, և միայն վերջնական արդյունքը փոխանցվում է FIB. 0.0.0.0/0 via 10.10.10.1 on ether1.

Երթուղիները փոխելու համար ռեկուրսիվ երթուղավորման օգտագործման օրինակ

Կոնֆիգուրացիա:

/ip route
add dst-address=0.0.0.0/0 gateway=8.8.8.8 check-gateway=ping distance=1 target-scope=10
add dst-address=8.8.8.8 gateway=10.10.10.1 scope=10
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

Կարող եք ստուգել, ​​որ փաթեթները կուղարկվեն 10.10.10.1.

Check gateway-ը ոչինչ չգիտի ռեկուրսիվ երթուղավորման մասին և պարզապես պինգեր է ուղարկում 8.8.8.8, որը (հիմնական աղյուսակի հիման վրա) հասանելի է 10.10.10.1 դարպասի միջոցով:

Եթե ​​10.10.10.1-ի և 8.8.8.8-ի միջև կապի կորուստ կա, ապա երթուղին անջատված է, բայց փաթեթները (ներառյալ փորձնական պինգերը) մինչև 8.8.8.8 շարունակում են անցնել 10.10.10.1.

Եթե ​​ether1-ի կապը կորչում է, ապա տհաճ իրավիճակ է առաջանում, երբ 8.8.8.8-ից առաջ փաթեթները անցնում են երկրորդ մատակարարի միջով.

Սա խնդիր է, եթե դուք օգտագործում եք NetWatch սկրիպտներ գործարկելու համար, երբ 8.8.8.8-ը հասանելի չէ: Եթե ​​հղումը խզված է, NetWatch-ը պարզապես կաշխատի կապի պահուստային ալիքով և կենթադրի, որ ամեն ինչ կարգին է: Լուծվում է՝ ավելացնելով լրացուցիչ զտիչ երթուղի.

/ip route
add dst-address=8.8.8.8 gateway=10.20.20.1 distance=100 type=blackhole

Կա on habré հոդված, որտեղ ավելի մանրամասն դիտարկվում է NetWatch-ի հետ կապված իրավիճակը։

Եվ այո, նման ամրագրում օգտագործելիս 8.8.8.8 հասցեն կապակցված կլինի պրովայդերներից մեկին, ուստի այն որպես dns աղբյուր ընտրելը լավ գաղափար չէ:

Մի քանի խոսք Վիրտուալ երթուղավորման և վերահասցեավորման (VRF) մասին

VRF տեխնոլոգիան նախագծված է մի քանի վիրտուալ երթուղիչի ստեղծման համար մեկ ֆիզիկականի մեջ, այս տեխնոլոգիան լայնորեն օգտագործվում է հեռահաղորդակցության օպերատորների կողմից (սովորաբար MPLS-ի հետ միասին)՝ հաճախորդներին L3VPN ծառայություններ մատուցելու ենթացանցային հասցեներով.

Բայց VRF-ը Mikrotik-ում կազմակերպված է երթուղային աղյուսակների հիման վրա և ունի մի շարք թերություններ, օրինակ՝ երթուղիչի տեղական ip հասցեները հասանելի են բոլոր VRF-ներից, կարող եք կարդալ ավելին։ по ссылке.

vrf կոնֆիգուրացիայի օրինակ.

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.200.1/24 interface=ether2 network=192.168.200.0

Ether2-ին միացված սարքից մենք տեսնում ենք, որ ping-ը գնում է դեպի երթուղիչի հասցե մեկ այլ vrf-ից (և սա խնդիր է), մինչդեռ ping-ը չի գնում ինտերնետ.

Ինտերնետ մուտք գործելու համար դուք պետք է գրանցեք լրացուցիչ երթուղի, որը մուտք է գործում հիմնական աղյուսակը (vrf տերմինաբանությամբ սա կոչվում է երթուղու արտահոսք).

/ip route
add distance=1 gateway=172.17.0.1@main routing-mark=vrf1
add distance=1 gateway=172.17.0.1%wlan1 routing-mark=vrf2

Ահա երթուղու արտահոսքի երկու եղանակ՝ օգտագործելով երթուղային աղյուսակը. 172.17.0.1@main և օգտագործելով ինտերֆեյսի անունը. 172.17.0.1%wlan1.

Եվ սահմանեք գծանշում հետադարձ երթևեկության համար [PREROUTING|Mangle]:

/ip firewall mangle
add chain=prerouting in-interface=ether1 action=mark-connection new-connection-mark=from-vrf1 passthrough=no
add chain=prerouting connection-mark=from-vrf1 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf1 passthrough=no 
add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=from-vrf2 passthrough=no
add chain=prerouting connection-mark=from-vrf2 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf2 passthrough=no 

Նույն հասցեով ենթացանցեր
Միևնույն երթուղիչի վրա նույն հասցեով ենթացանցերի մուտքի կազմակերպում, օգտագործելով VRF և netmap.

Հիմնական կոնֆիգուրացիա.

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.100.1/24 interface=ether2 network=192.168.100.0
add address=192.168.0.1/24 interface=ether3 network=192.168.0.0

firewall կանոններ.

#Маркируем пакеты для отправки в правильную таблицу маршрутизации
/ip firewall mangle
add chain=prerouting dst-address=192.168.101.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf1 passthrough=no
add chain=prerouting dst-address=192.168.102.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf2 passthrough=no

#Средствами netmap заменяем адреса "эфимерных" подсетей на реальные подсети
/ip firewall nat
add chain=dstnat dst-address=192.168.101.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24
add chain=dstnat dst-address=192.168.102.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24

Վերադարձի երթևեկության կանոններ.

#Указание имени интерфейса тоже может считаться route leaking, но по сути тут создается аналог connected маршрута
/ip route
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf1
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf2

dhcp-ի միջոցով ստացված երթուղիների ավելացում տվյալ երթուղային աղյուսակին
VRF-ը կարող է հետաքրքիր լինել, եթե Ձեզ անհրաժեշտ է ավտոմատ կերպով դինամիկ երթուղի ավելացնել (օրինակ՝ dhcp հաճախորդից) կոնկրետ երթուղային աղյուսակում:

Ինտերֆեյսի ավելացում vrf-ին.

/ip route vrf
add interface=ether1 routing-mark=over-isp1

Աղյուսակով տրաֆիկ (ելքային և տարանցիկ) ուղարկելու կանոններ over-isp1:

/ip firewall mangle
add chain=output out-interface=!br-lan action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting in-interface=br-lan dst-address-type=!local action=mark-routing new-routing-mark=over-isp1 passthrough=no

Լրացուցիչ, կեղծ երթուղի դեպի աշխատանքի ելքային երթուղի.

/interface bridge
add name=bare

/ip route
add dst-address=0.0.0.0/0 gateway=bare

Այս երթուղին անհրաժեշտ է միայն, որպեսզի տեղական ելքային փաթեթները կարողանան նախկինում անցնել երթուղային որոշմամբ (2): [OUTPUT|Mangle] և ստացիր երթուղային պիտակը, եթե հիմնական աղյուսակում մինչև 0.0.0.0/0 երթուղիչի վրա այլ ակտիվ երթուղիներ կան, դա պարտադիր չէ:

Ցանցեր connected-in и dynamic-in в [Routing] -> [Filters]

Երթուղու զտումը (ներգնա և ելքային) գործիք է, որը սովորաբար օգտագործվում է դինամիկ երթուղային արձանագրությունների հետ համատեղ (և, հետևաբար, հասանելի է միայն փաթեթը տեղադրելուց հետո): երթուղի), բայց մուտքային ֆիլտրերում երկու հետաքրքիր շղթա կա.

• միացված - միացված երթուղիների զտում
• dynamic-in - PPP-ի և DCHP-ի կողմից ստացված դինամիկ երթուղիների զտում

Զտումը թույլ է տալիս ոչ միայն հրաժարվել երթուղիներից, այլև փոխել մի շարք տարբերակներ՝ հեռավորություն, երթուղային նշան, մեկնաբանություն, շրջանակ, թիրախային շրջանակ, ...

Սա շատ ճշգրիտ գործիք է, և եթե դուք կարող եք ինչ-որ բան անել առանց Routing Filters-ի (բայց ոչ սկրիպտների), ապա մի օգտագործեք Routing Filters, մի շփոթեք ինքներդ ձեզ և նրանց, ովքեր կկարգավորեն երթուղիչը ձեզանից հետո: Դինամիկ երթուղավորման համատեքստում Routing Filters-ը կօգտագործվի շատ ավելի հաճախ և ավելի արդյունավետ:

Դինամիկ երթուղիների համար երթուղային նշանի սահմանում
Օրինակ տնային երթուղիչից: Ես կազմաձևված եմ երկու VPN կապ, և դրանցում երթևեկությունը պետք է փաթաթված լինի երթուղային աղյուսակների համաձայն: Միևնույն ժամանակ, ես ցանկանում եմ, որ երթուղիները ավտոմատ կերպով ստեղծվեն, երբ ինտերֆեյսը միացված է.

#При создании vpn подключений указываем создание default route и задаем дистанцию
/interface pptp-client
add connect-to=X.X.X.X add-default-route=yes default-route-distance=101 ...
add connect-to=Y.Y.Y.Y  add-default-route=yes default-route-distance=100 ...

#Фильтрами отправляем маршруты в определенные таблицы маршрутизации на основе подсети назначения и дистанции
/routing filter
add chain=dynamic-in distance=100 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn1
add chain=dynamic-in distance=101 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn2

Չգիտեմ ինչու, հավանաբար սխալ է, բայց եթե դուք ստեղծեք vrf ppp ինտերֆեյսի համար, ապա դեպի 0.0.0.0/0 երթուղին դեռ կմտնի հիմնական աղյուսակ: Հակառակ դեպքում ամեն ինչ ավելի հեշտ կլիներ։

Կապակցված երթուղիների անջատում
Երբեմն սա պահանջվում է.

/route filter
add chain=connected-in prefix=192.168.100.0/24 action=reject

Վրիպազերծման գործիքներ

RouterOS-ը տրամադրում է մի շարք գործիքներ երթուղավորումը վրիպազերծելու համար.

• [Tool]->[Tourch] - թույլ է տալիս դիտել փաթեթները միջերեսների վրա
• /ip route check - թույլ է տալիս տեսնել, թե որ դարպասին կուղարկվի փաթեթը, չի աշխատում երթուղային աղյուսակների հետ
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - ping և հետագծել՝ օգտագործելով նշված երթուղային աղյուսակը
• action=log в [IP]->[Firewall] - հիանալի գործիք, որը թույլ է տալիս հետևել փաթեթի ուղին փաթեթի հոսքի երկայնքով, այս գործողությունը հասանելի է բոլոր շղթաներում և աղյուսակներում

Source: www.habr.com