სტატიკური მარშრუტის საფუძვლები Mikrotik RouterOS-ში

მარშრუტირება არის TCP/IP ქსელების მეშვეობით პაკეტების გადაცემის საუკეთესო გზის პოვნის პროცესი. IPv4 ქსელთან დაკავშირებული ნებისმიერი მოწყობილობა შეიცავს პროცესის და მარშრუტიზაციის ცხრილებს.

ეს სტატია არ არის HOWTO, ის აღწერს სტატიკურ მარშრუტიზაციას RouterOS-ში მაგალითებით, მე განზრახ გამოვტოვე დანარჩენი პარამეტრები (მაგალითად, srcnat ინტერნეტში წვდომისთვის), ამიტომ მასალის გაგება მოითხოვს ქსელების და RouterOS-ის გარკვეულ დონეს.

გადართვა და მარშრუტიზაცია

გადართვა არის პაკეტების გაცვლის პროცესი ერთი Layer2 სეგმენტის ფარგლებში (Ethernet, ppp, ...). თუ მოწყობილობა ხედავს, რომ პაკეტის მიმღები არის მასთან ერთსა და იმავე Ethernet ქვექსელში, ის სწავლობს mac მისამართს arp პროტოკოლის გამოყენებით და პირდაპირ გადასცემს პაკეტს, როუტერის გვერდის ავლით. ppp (point-to-point) კავშირს შეიძლება ჰყავდეს მხოლოდ ორი მონაწილე და პაკეტი ყოველთვის იგზავნება ერთ მისამართზე 0xff.

მარშრუტირება არის 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, მარშრუტიზაციის ქეში

მარშრუტის საინფორმაციო ბაზა
ბაზა, რომელშიც მარშრუტები გროვდება დინამიური მარშრუტიზაციის პროტოკოლებიდან, მარშრუტები 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. Gateway 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 - ფილტრაციის მარშრუტი (გადაგდებს პაკეტებს გადაცემის ნაცვლად)

რა უნდა მიუთითოთ კარიბჭეში: ip-მისამართი თუ ინტერფეისი?

სისტემა საშუალებას გაძლევთ მიუთითოთ ორივე, მაშინ როდესაც ის არ იფიცებს და არ იძლევა მინიშნებებს, თუ რამე არასწორად გააკეთეთ.

IP მისამართი
კარიბჭის მისამართი უნდა იყოს ხელმისაწვდომი Layer2-ზე. Ethernet-ისთვის ეს ნიშნავს, რომ როუტერს უნდა ჰქონდეს მისამართი იმავე ქვექსელიდან ერთ-ერთ აქტიურ ip ინტერფეისზე, ppp-სთვის, რომ კარიბჭის მისამართი მითითებულია ერთ-ერთ აქტიურ ინტერფეისზე, როგორც ქვექსელის მისამართი.
თუ Layer2-ისთვის ხელმისაწვდომობის პირობა არ არის დაკმაყოფილებული, მარშრუტი ჩაითვლება არააქტიურად და არ მოხვდება FIB-ში.

ინტერფეისი
ყველაფერი უფრო რთულია და როუტერის ქცევა დამოკიდებულია ინტერფეისის ტიპზე:

• PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) კავშირი ითვალისწინებს მხოლოდ ორ მონაწილეს და პაკეტი ყოველთვის იგზავნება კარიბჭეში გადასაცემად, თუ კარიბჭე აღმოაჩენს, რომ მიმღები თავად არის, მაშინ ის გადასცემს პაკეტს მისი ლოკალური პროცესი.
  
• Ethernet ითვალისწინებს მრავალი მონაწილის არსებობას და გაგზავნის თხოვნებს arp ინტერფეისში პაკეტის მიმღების მისამართით, ეს მოსალოდნელია და საკმაოდ ნორმალური ქცევა დაკავშირებული მარშრუტებისთვის.
  მაგრამ როდესაც თქვენ ცდილობთ გამოიყენოთ ინტერფეისი, როგორც მარშრუტი დისტანციური ქვექსელისთვის, მიიღებთ შემდეგ სიტუაციას: მარშრუტი აქტიურია, პინგი კარიბჭისკენ გადის, მაგრამ არ აღწევს მიმღებს მითითებული ქვექსელიდან. თუ ინტერფეისს გადახედავთ სნიფერის საშუალებით, ნახავთ 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-მა არ იცის რა ხდება კომუნიკაციასთან შემოწმებული კარიბჭის მიღმა, ამისათვის საჭიროა დამატებითი ინსტრუმენტები: სკრიპტები, რეკურსიული მარშრუტიზაცია, დინამიური მარშრუტიზაციის პროტოკოლები.

VPN და გვირაბის პროტოკოლების უმეტესობა შეიცავს ჩაშენებულ ინსტრუმენტებს კავშირის აქტივობის შესამოწმებლად, რაც საშუალებას აძლევს შემოწმების კარიბჭეს მათთვის დამატებითი (მაგრამ ძალიან მცირე) დატვირთვა ქსელისა და მოწყობილობის მუშაობისთვის.

ECMP მარშრუტები

Equal-Cost Multi-Path - პაკეტების გაგზავნა მიმღებამდე რამდენიმე კარიბჭის გამოყენებით, ერთდროულად Round Robin ალგორითმის გამოყენებით.

ECMP მარშრუტი იქმნება ადმინისტრატორის მიერ მრავალი კარიბჭის მითითებით ერთი ქვექსელისთვის (ან ავტომატურად, თუ არსებობს ორი ექვივალენტი OSPF მარშრუტი).

ECMP გამოიყენება ორ არხს შორის დატვირთვის დასაბალანსებლად, თეორიულად, თუ ecmp მარშრუტზე ორი არხია, მაშინ თითოეული პაკეტისთვის გამავალი არხი განსხვავებული უნდა იყოს. მაგრამ Routing cache მექანიზმი აგზავნის პაკეტებს კავშირიდან იმ მარშრუტის გასწვრივ, რომელიც პირველმა პაკეტმა გაიარა, შედეგად, ჩვენ ვიღებთ ერთგვარ დაბალანსებას კავშირებზე დაფუძნებული (თითო კავშირის დატვირთვის დაბალანსება).

თუ გამორთავთ Routing Cache-ს, მაშინ ECMP მარშრუტზე პაკეტები სწორად იქნება გაზიარებული, მაგრამ არის პრობლემა NAT-თან. NAT წესი ამუშავებს მხოლოდ პირველ პაკეტს კავშირიდან (დანარჩენი მუშავდება ავტომატურად) და გამოდის, რომ პაკეტები იმავე წყაროს მისამართით ტოვებენ სხვადასხვა ინტერფეისს.

შემოწმების კარიბჭე არ მუშაობს ECMP მარშრუტებში (RouterOS შეცდომა). მაგრამ ამ შეზღუდვის თავიდან აცილება შეგიძლიათ დამატებითი ვალიდაციის მარშრუტების შექმნით, რომელიც გამორთავს ჩანაწერებს ECMP-ში.

ფილტრაცია მარშრუტის საშუალებით

Type ვარიანტი განსაზღვრავს რა უნდა გააკეთოს პაკეტთან:

• unicast - გაგზავნეთ მითითებულ კარიბჭეზე (ინტერფეისი)
• შავი ხვრელი - გადააგდე პაკეტი
• აკრძალვა, მიუწვდომელი - გადააგდე პაკეტი და გაუგზავნე 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-ის მეშვეობით.

მარშრუტიზაციის მარყუჟი
მარშრუტიზაციის მარყუჟი - სიტუაცია, როდესაც პაკეტი გადის მარშრუტიზატორებს შორის ttl ვადის ამოწურვამდე. ჩვეულებრივ, ეს არის კონფიგურაციის შეცდომის შედეგი, დიდ ქსელებში მას მკურნალობენ დინამიური მარშრუტიზაციის პროტოკოლების განხორციელებით, მცირეებში - ფრთხილად.

ეს დაახლოებით ასე გამოიყურება:

მაგალითი (უმარტივესი), თუ როგორ უნდა მიიღოთ მსგავსი შედეგი:

მარშრუტიზაციის მარყუჟის მაგალითს არ აქვს პრაქტიკული გამოყენება, მაგრამ ის აჩვენებს, რომ მარშრუტიზატორებს წარმოდგენა არ აქვთ მეზობლის მარშრუტიზაციის ცხრილის შესახებ.

პოლიტიკის ბაზის მარშრუტიზაცია და დამატებითი მარშრუტიზაციის ცხრილები

მარშრუტის არჩევისას როუტერი იყენებს მხოლოდ ერთ ველს პაკეტის სათაურიდან (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]
წესები მუშავდება თანმიმდევრულად, თუ პაკეტი ემთხვევა წესის პირობებს, ის შემდგომში არ გადის.

მარშრუტიზაციის წესები საშუალებას გაძლევთ გააფართოვოთ მარშრუტიზაციის შესაძლებლობები, დაეყრდნოთ არა მხოლოდ მიმღების მისამართს, არამედ წყაროს მისამართს და ინტერფეისს, რომლითაც მიიღეს პაკეტი.

წესები შედგება პირობებისა და მოქმედებისგან:

• პირობები. პრაქტიკულად გაიმეორეთ ნიშნების სია, რომლითაც პაკეტი შემოწმებულია 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-ით. address=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
• მარშრუტიზაციის ცხრილის მიხედვით, პაკეტი უნდა გაიგზავნოს კარიბჭეზე 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) ეტაპზე, პაკეტი, მარშრუტიზაციის ცხრილის შესაბამისად, იგზავნება კარიბჭეზე 10.20.20.1 ether1 ინტერფეისის მეშვეობით. ამის გადამოწმება შეგიძლიათ პაკეტებში შესვლით [OUTPUT|Filter]
• სცენაზე [OUTPUT|Mangle] კავშირის ეტიკეტი შემოწმებულია from-isp2 და პაკეტი იღებს მარშრუტის ეტიკეტს over-isp2
• Routing Adjusment(3) ნაბიჯი ამოწმებს მარშრუტიზაციის ეტიკეტის არსებობას და აგზავნის მას შესაბამის მარშრუტიზაციის მაგიდაზე
• მარშრუტიზაციის ცხრილის მიხედვით, პაკეტი უნდა გაიგზავნოს კარიბჭეზე 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] პაკეტები სხვადასხვა კავშირიდან იღებენ სხვადასხვა ეტიკეტს
• პაკეტები შედიან ეტიკეტების შესაბამის ცხრილებში მარშრუტის რეგულირების ეტაპზე და იღებენ ახალ მარშრუტს პაკეტების გაგზავნისთვის
• მაგრამ პაკეტებს მაინც აქვთ Src. მისამართი ether1-დან, სცენაზე [Nat|Srcnat] მისამართი იცვლება ინტერფეისის მიხედვით

საინტერესოა, რომ როუტერზე ნახავთ შემდეგ კავშირების ცხრილს:

კავშირის ტრეკერი ადრე მუშაობს [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

უკან დახევა პრო dst-address-type=!local
დამატებითი მდგომარეობა dst-address-type=!local აუცილებელია, რომ მომხმარებლების ტრაფიკმა მიაღწიოს როუტერის ლოკალურ პროცესებს (dns, winbox, ssh, ...). თუ რამდენიმე ლოკალური ქვექსელი დაკავშირებულია როუტერთან, აუცილებელია დარწმუნდეთ, რომ მათ შორის ტრაფიკი არ მიდის ინტერნეტში, მაგალითად, გამოყენებით dst-address-table.

გამოყენების მაგალითში [IP]->[Route]->[Rules] ასეთი გამონაკლისები არ არსებობს, მაგრამ ტრაფიკი აღწევს ადგილობრივ პროცესებს. ფაქტია, რომ მონიშნულ FIB პაკეტში მოხვედრა [PREROUTING|Mangle] აქვს მარშრუტის ეტიკეტი და გადადის მარშრუტიზაციის ცხრილში, გარდა მთავარი, სადაც არ არის ადგილობრივი ინტერფეისი. მარშრუტიზაციის წესების შემთხვევაში, ჯერ მოწმდება, არის თუ არა პაკეტი განკუთვნილი ლოკალური პროცესისთვის და მხოლოდ მომხმარებლის 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 საპასუხო ტრაფიკი ინტერნეტიდან მიიღებს და მარშრუტიზაციის ცხრილების შესაბამისად, დაუბრუნდება პროვაიდერს.

საკომუნიკაციო არხების გადართვა

შემოწმება პინგი კარგი ინსტრუმენტია, მაგრამ ის ამოწმებს კავშირს მხოლოდ უახლოეს IP თანატოლებთან, პროვაიდერის ქსელები, როგორც წესი, შედგება დიდი რაოდენობით მარშრუტიზატორებისგან და კავშირის შეწყვეტა შეიძლება მოხდეს უახლოეს თანატოლთან მიღმა, შემდეგ კი არსებობს სატელეკომუნიკაციო ოპერატორები, რომლებიც ასევე შეიძლება გაქვთ პრობლემები, ზოგადად შემოწმება ping ყოველთვის არ აჩვენებს განახლებულ ინფორმაციას გლობალურ ქსელში წვდომის შესახებ.
თუ პროვაიდერებსა და მსხვილ კორპორაციებს აქვთ BGP დინამიური მარშრუტიზაციის პროტოკოლი, მაშინ სახლისა და ოფისის მომხმარებლებმა დამოუკიდებლად უნდა გაარკვიონ, როგორ შეამოწმონ ინტერნეტთან წვდომა კონკრეტული საკომუნიკაციო არხის საშუალებით.

როგორც წესი, გამოიყენება სკრიპტები, რომლებიც გარკვეული საკომუნიკაციო არხის საშუალებით ამოწმებენ ip მისამართის ხელმისაწვდომობას ინტერნეტში, ხოლო არჩევენ რაიმე საიმედოს, მაგალითად, google dns: 8.8.8.8. 8.8.4.4. მაგრამ Mikrotik საზოგადოებაში, ამისათვის უფრო საინტერესო ინსტრუმენტია ადაპტირებული.

რამდენიმე სიტყვა რეკურსიული მარშრუტიზაციის შესახებ
რეკურსიული მარშრუტიზაცია აუცილებელია 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-ის მიერ მიღებული დინამიური მარშრუტების გაფილტვრა

ფილტრაცია საშუალებას გაძლევთ არა მხოლოდ გააუქმოთ მარშრუტები, არამედ შეცვალოთ მრავალი ვარიანტი: მანძილი, მარშრუტის ნიშანი, კომენტარი, ფარგლები, სამიზნე ფარგლები, ...

ეს არის ძალიან ზუსტი ინსტრუმენტი და თუ რაიმეს გაკეთება შეგიძლიათ მარშრუტიზაციის ფილტრების (მაგრამ არა სკრიპტების) გარეშე, მაშინ ნუ გამოიყენებთ მარშრუტიზაციის ფილტრებს, ნუ აირევთ საკუთარ თავს და მათ, ვინც თქვენს შემდეგ დააკონფიგურირებს როუტერს. დინამიური მარშრუტის კონტექსტში, მარშრუტიზაციის ფილტრები გამოყენებული იქნება ბევრად უფრო ხშირად და უფრო პროდუქტიულად.

მარშრუტის ნიშნის დაყენება დინამიური მარშრუტებისთვის
მაგალითი სახლის როუტერიდან. მე მაქვს კონფიგურირებული ორი 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] - შესანიშნავი ინსტრუმენტი, რომელიც საშუალებას გაძლევთ თვალყური ადევნოთ პაკეტის გზას პაკეტის ნაკადის გასწვრივ, ეს მოქმედება ხელმისაწვდომია ყველა ჯაჭვში და ცხრილში

წყარო: www.habr.com