Statiskās maršrutēšanas pamati Mikrotik RouterOS

Maršrutēšana ir process, kurā tiek atrasts labākais ceļš pakešu pārsūtīšanai TCP/IP tīklos. Jebkura ierīce, kas savienota ar IPv4 tīklu, satur procesu un maršrutēšanas tabulas.

Šis raksts nav HOWTO, tajā ir aprakstīta statiskā maršrutēšana RouterOS ar piemēriem, pārējos iestatījumus es apzināti izlaidu (piemēram, srcnat piekļuvei internetam), tāpēc materiāla izpratnei ir nepieciešamas noteiktas zināšanas par tīkliem un RouterOS.

Pārslēgšana un maršrutēšana

Pārslēgšana ir pakešu apmaiņas process vienā Layer2 segmentā (Ethernet, ppp, ...). Ja ierīce redz, ka paketes saņēmējs atrodas tajā pašā Ethernet apakštīklā ar to, tā uzzina mac adresi, izmantojot arp protokolu, un pārsūta paketi tieši, apejot maršrutētāju. Ppp (point-to-point) savienojumam var būt tikai divi dalībnieki, un pakete vienmēr tiek nosūtīta uz vienu adresi 0xff.

Maršrutēšana ir pakešu pārsūtīšanas process starp Layer2 segmentiem. Ja ierīce vēlas nosūtīt paketi, kuras adresāts atrodas ārpus Ethernet segmenta, tā izskata maršrutēšanas tabulu un nodod paketi vārtejai, kas zina, kur sūtīt paketi nākamo (vai var nezināt, sākotnējais paketes sūtītājs ir par to nezina).

Vienkāršākais veids, kā domāt par maršrutētāju, ir ierīce, kas savienota ar diviem vai vairākiem Layer2 segmentiem un spēj pārraidīt paketes starp tiem, nosakot labāko maršrutu no maršrutēšanas tabulas.

Ja visu saproti vai jau zināji, tad lasi tālāk. Attiecībā uz pārējo es ļoti iesaku jums iepazīties ar nelielu, bet ļoti ietilpīgu rakstus.

Maršrutēšana RouterOS un PacketFlow

Gandrīz visa ar statisko maršrutēšanu saistītā funkcionalitāte ir iekļauta pakotnē sistēma. Plastmasas maisiņš Maršrutēšana pievieno atbalstu dinamiskiem maršrutēšanas algoritmiem (RIP, OSPF, BGP, MME), maršrutēšanas filtriem un BFD.

Galvenā maršrutēšanas iestatīšanas izvēlne: [IP]->[Route]. Sarežģītās shēmās var būt nepieciešams, lai paketes būtu iepriekš marķētas ar maršrutēšanas zīmi: [IP]->[Firewall]->[Mangle] (ķēdes PREROUTING и OUTPUT).

PacketFlow ir trīs vietas, kur tiek pieņemti lēmumi par IP pakešu maršrutēšanu:

1. Maršrutētāja saņemto pakešu maršrutēšana. Šajā posmā tiek izlemts, vai pakete nonāks lokālajā procesā vai tiks nosūtīta tālāk uz tīklu. Saņem tranzīta pakas Izejas interfeiss
2. Vietējo izejošo pakešu maršrutēšana. Saņem izejošās paketes Izejas interfeiss
3. Papildu maršrutēšanas solis izejošajām paketēm ļauj mainīt maršrutēšanas lēmumu [Output|Mangle]

• Pakešu ceļš blokos 1, 2 ir atkarīgs no noteikumiem [IP]->[Route]
• Pakešu ceļš 1., 2. un 3. punktā ir atkarīgs no noteikumiem [IP]->[Route]->[Rules]
• Pakotnes ceļu blokos 1, 3 var ietekmēt, izmantojot [IP]->[Firewall]->[Mangle]

RIB, FIB, maršrutēšanas kešatmiņa

Maršrutēšanas informācijas bāze
Bāze, kurā tiek apkopoti maršruti no dinamiskajiem maršrutēšanas protokoliem, maršruti no ppp un dhcp, statiskie un savienotie maršruti. Šajā datu bāzē ir visi maršruti, izņemot tos, kurus filtrējis administrators.

Nosacīti, mēs to varam pieņemt [IP]->[Route] parāda RIB.

Pārsūtīšanas informācijas bāze

Bāze, kurā tiek apkopoti labākie maršruti no RIB. Visi FIB maršruti ir aktīvi un tiek izmantoti pakešu pārsūtīšanai. Ja maršruts kļūst neaktīvs (atspējojis administrators (sistēma), vai interfeiss, caur kuru jānosūta pakete, nav aktīvs), maršruts tiek noņemts no FIB.

Lai pieņemtu lēmumu par maršrutēšanu, FIB tabula izmanto šādu informāciju par IP paketi:

• Avota adrese
• Galamērķa adrese
• avota interfeiss
• Maršruta atzīme
• ToS (DSCP)

Lai iekļūtu FIB paketē, notiek šādi posmi:

• Vai pakotne ir paredzēta vietējam maršrutētāja procesam?
• Vai uz paketi attiecas sistēmas vai lietotāja PBR noteikumi?
  • Ja jā, tad pakete tiek nosūtīta uz norādīto maršrutēšanas tabulu
• Pakete tiek nosūtīta uz galveno tabulu

Nosacīti, mēs to varam pieņemt [IP]->[Route Active=yes] parāda FIB.

Maršrutēšanas kešatmiņa
Maršruta kešatmiņas mehānisms. Maršrutētājs atceras, kur tika nosūtītas paketes, un, ja ir līdzīgas (domājams, no viena savienojuma), tas ļauj tām iet pa to pašu maršrutu, neveicot FIB pārbaudi. Maršruta kešatmiņa tiek periodiski notīrīta.

RouterOS administratoriem viņi neizgatavoja rīkus maršrutēšanas kešatmiņas skatīšanai un pārvaldībai, bet gan tad, kad to var atspējot [IP]->[Settings].

Šis mehānisms tika noņemts no Linux 3.6 kodola, bet RouterOS joprojām izmanto kodolu 3.3.5, iespējams, maršrutēšana cahce ir viens no iemesliem.

Maršruta pievienošanas dialoglodziņš

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

1. Apakštīkls, kuram vēlaties izveidot maršrutu (noklusējums: 0.0.0.0/0)
2. Vārtejas IP vai interfeiss, uz kuru tiks nosūtīta pakete (var būt vairākas, skatiet ECMP tālāk)
3. Vārtejas pieejamības pārbaude
4. Ieraksta veids
5. Maršruta attālums (metriska).
6. Maršrutēšanas tabula
7. IP vietējām izejošajām paketēm, izmantojot šo maršrutu
8. Darbības jomas un mērķa darbības jomas mērķis ir rakstīts raksta beigās.

Maršrutu karogi

• X — administrators ir atspējojis maršrutu (disabled=yes)
• A — maršruts tiek izmantots pakešu nosūtīšanai
• D — maršruts pievienots dinamiski (BGP, OSPF, RIP, MME, PPP, DHCP, savienots)
• C - apakštīkls ir tieši savienots ar maršrutētāju
• S - Statiskais maršruts
• r,b,o,m — maršruts, kas pievienots ar vienu no dinamiskajiem maršrutēšanas protokoliem
• B,U,P — filtrēšanas maršruts (pakešu nomešana, nevis pārsūtīšana)

Ko norādīt vārtejā: IP adrese vai interfeiss?

Sistēma ļauj norādīt abus, kamēr tā nelamājas un nedod mājienus, ja esat izdarījis kaut ko nepareizi.

IP adrese
Vārtejas adresei jābūt pieejamai 2. slānī. Ethernet gadījumā tas nozīmē, ka maršrutētājam ir jābūt adresei no tā paša apakštīkla vienā no aktīvajām IP saskarnēm, bet ppp gadījumā vārtejas adrese ir norādīta vienā no aktīvajām saskarnēm kā apakštīkla adrese.
Ja Layer2 pieejamības nosacījums nav izpildīts, maršruts tiek uzskatīts par neaktīvu un neietilpst FIB.

interfeiss
Viss ir sarežģītāk, un maršrutētāja darbība ir atkarīga no saskarnes veida:

• PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) savienojumā tiek pieņemti tikai divi dalībnieki un pakete vienmēr tiks nosūtīta uz vārteju pārsūtīšanai, ja vārteja konstatē, ka adresāts ir viņš pats, tad tā pārsūtīs paketi uz tā vietējais process.
  
• Ethernet uzņemas daudzu dalībnieku klātbūtni un nosūtīs pieprasījumus arp interfeisam ar paketes saņēmēja adresi, tas ir sagaidāms un diezgan normāls savienotajiem maršrutiem.
  Bet, mēģinot izmantot saskarni kā attālā apakštīkla maršrutu, jūs iegūsit šādu situāciju: maršruts ir aktīvs, ping uz vārteju iet, bet nesasniedz adresātu no norādītā apakštīkla. Ja skatāties uz saskarni, izmantojot sniffer, jūs redzēsit ARP pieprasījumus ar adresēm no attālā apakštīkla.
  

Mēģiniet norādīt IP adresi kā vārteju, kad vien iespējams. Izņēmums ir savienotie maršruti (izveidoti automātiski) un PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*) saskarnes.

OpenVPN nesatur PPP galveni, taču varat izmantot OpenVPN saskarnes nosaukumu, lai izveidotu maršrutu.

Konkrētāks maršruts

Pamata maršrutēšanas noteikums. Maršrutam, kas apraksta mazāko apakštīklu (ar lielāko apakštīkla masku), ir prioritāte paketes maršrutēšanas lēmumā. Ierakstu pozīcija maršrutēšanas tabulā nav būtiska izvēlei - galvenais noteikums ir Konkrētāks.

Visi maršruti no norādītās shēmas ir aktīvi (atrodas FIB). norāda uz dažādiem apakštīkliem un nav pretrunā viens ar otru.

Ja kāda no vārtejām kļūst nepieejama, saistītais maršruts tiks uzskatīts par neaktīvu (noņemts no FIB) un tiks meklētas paketes no atlikušajiem maršrutiem.

Maršrutam ar apakštīklu 0.0.0.0/0 dažreiz tiek piešķirta īpaša nozīme, un to sauc par "noklusējuma maršrutu" vai "pēdējās iespējas vārteju". Patiesībā tajā nav nekā maģiska un tajā ir vienkārši iekļautas visas iespējamās IPv4 adreses, taču šie nosaukumi labi raksturo tā uzdevumu – tas norāda vārteju, kur pārsūtīt paketes, kurām citu, precīzāku maršrutu nav.

Maksimālā iespējamā IPv4 apakštīkla maska ​​ir /32, šis maršruts norāda uz konkrētu resursdatoru un to var izmantot maršrutēšanas tabulā.

Konkrētāka maršruta izpratne ir būtiska jebkurai TCP/IP ierīcei.

Attālums

Attālumi (vai metrika) ir nepieciešami, lai administratīvi filtrētu maršrutus uz vienu apakštīklu, kuram var piekļūt, izmantojot vairākas vārtejas. Maršruts ar zemāku metriku tiek uzskatīts par prioritāti un tiks iekļauts FIB. Ja maršruts ar zemāku metriku pārstāj būt aktīvs, tas tiks aizstāts ar maršrutu ar augstāku metriku FIB.

Ja uz vienu un to pašu apakštīklu ir vairāki maršruti ar vienu un to pašu metriku, maršrutētājs FIB tabulai pievienos tikai vienu no tiem, vadoties pēc savas iekšējās loģikas.

Metrikas vērtība var būt no 0 līdz 255:

• 0 — savienoto maršrutu metrika. Administrators nevar iestatīt attālumu 0
• 1-254 — administratoram pieejamā metrika maršrutu iestatīšanai. Metrikai ar zemāku vērtību ir augstāka prioritāte
• 255 — administratoram pieejama metrika maršrutu iestatīšanai. Atšķirībā no 1-254, maršruts ar metriku 255 vienmēr paliek neaktīvs un neietilpst FIB
• specifiski rādītāji. Maršrutiem, kas iegūti no dinamiskajiem maršrutēšanas protokoliem, ir standarta metrikas vērtības

pārbaudes vārteja

Check gateway ir MikroTik RoutesOS paplašinājums, lai pārbaudītu vārtejas pieejamību, izmantojot icmp vai arp. Reizi 10 sekundēs (nevar mainīt) uz vārteju tiek nosūtīts pieprasījums, ja atbilde netiek saņemta divas reizes, maršruts tiek uzskatīts par nepieejamu un tiek noņemts no FIB. Ja pārbaudes vārteja ir atspējota, pārbaudes maršruts turpinās un maršruts atkal kļūs aktīvs pēc vienas veiksmīgas pārbaudes.

Pārbaudes vārteja atspējo ierakstu, kurā tas ir konfigurēts, un visus citus ierakstus (visās maršrutēšanas tabulās un ecmp maršrutos) ar norādīto vārteju.

Kopumā pārbaudes vārteja darbojas labi, kamēr vārtejai nav problēmu ar pakešu zudumu. Pārbaudes vārteja nezina, kas notiek ar komunikāciju ārpus pārbaudītās vārtejas, tam ir nepieciešami papildu rīki: skripti, rekursīvā maršrutēšana, dinamiskie maršrutēšanas protokoli.

Lielākajā daļā VPN un tuneļu protokolu ir iebūvēti rīki savienojuma darbības pārbaudei, un pārbaudes vārtejas iespējošana tiem ir papildu (bet ļoti maza) slodze tīkla un ierīces veiktspējai.

ECMP maršruti

Vienādas izmaksas Multi-Path - pakešu nosūtīšana adresātam, izmantojot vairākas vārtejas vienlaikus, izmantojot Round Robin algoritmu.

ECMP maršrutu izveido administrators, vienam apakštīklam norādot vairākas vārtejas (vai automātiski, ja ir divi līdzvērtīgi OSPF maršruti).

ECMP tiek izmantots slodzes balansēšanai starp diviem kanāliem, teorētiski, ja ecmp maršrutā ir divi kanāli, tad katrai paketei izejošajam kanālam jābūt citam. Bet maršrutēšanas kešatmiņas mehānisms sūta paketes no savienojuma pa maršrutu, kuru paņēma pirmā pakete, kā rezultātā mēs iegūstam sava veida balansēšanu, pamatojoties uz savienojumiem (katra savienojuma slodzes balansēšana).

Ja atspējojat maršrutēšanas kešatmiņu, ECMP maršruta paketes tiks kopīgotas pareizi, taču ir problēma ar NAT. NAT kārtula apstrādā tikai pirmo paketi no savienojuma (pārējās tiek apstrādātas automātiski), un izrādās, ka paketes ar vienādu avota adresi atstāj dažādas saskarnes.

Pārbaudiet, vai vārteja nedarbojas ECMP maršrutos (RouterOS kļūda). Taču jūs varat apiet šo ierobežojumu, izveidojot papildu validācijas maršrutus, kas atspējos ierakstus ECMP.

Filtrēšana, izmantojot maršrutēšanu

Opcija Tips nosaka, ko darīt ar paketi:

• unicast — nosūtīt uz norādīto vārteju (interfeisu)
• melnais caurums - izmet paciņu
• aizliegt, nesasniedzams - atmest paketi un nosūtīt icmp ziņojumu sūtītājam

Filtrēšana parasti tiek izmantota, ja ir nepieciešams nodrošināt pakešu nosūtīšanu pa nepareizo ceļu, protams, to var filtrēt caur ugunsmūri.

Pāris piemēri

Lai konsolidētu pamata lietas par maršrutēšanu.

Tipisks mājas maršrutētājs

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

1. Statisks maršruts uz 0.0.0.0/0 (noklusējuma maršruts)
2. Savienots maršruts saskarnē ar pakalpojumu sniedzēju
3. Savienots maršruts LAN interfeisā

Tipisks mājas maršrutētājs ar PPPoE

1. Statisks maršruts noklusējuma maršrutam, pievienots automātiski. tas ir norādīts savienojuma rekvizītos
2. Savienots maršruts PPP savienojumam
3. Savienots maršruts LAN interfeisā

Tipisks mājas maršrutētājs ar diviem pakalpojumu sniedzējiem un atlaišanu

/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. Statisks maršruts uz noklusējuma maršrutu caur pirmo pakalpojumu sniedzēju ar 1. metriku un vārtejas pieejamības pārbaudi
2. Statisks ceļš uz noklusējuma maršrutu caur otro pakalpojumu sniedzēju ar 2. metriku
3. Savienotie maršruti

Satiksme uz 0.0.0.0/0 iet caur 10.10.10.1, kamēr šī vārteja ir pieejama, pretējā gadījumā tā tiek pārslēgta uz 10.20.20.1

Šādu shēmu var uzskatīt par kanāla rezervāciju, taču tai nav arī trūkumi. Ja pārtraukums notiek ārpus pakalpojumu sniedzēja vārtejas (piemēram, operatora tīklā), jūsu maršrutētājs par to nezinās un turpinās uzskatīt, ka maršruts ir aktīvs.

Tipisks mājas maršrutētājs ar diviem pakalpojumu sniedzējiem, atlaišanu un 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. Statiski maršruti čaka vārtejas pārbaudei
2. ECMP maršruts
3. Savienotie maršruti

Pārbaudāmie maršruti ir zilā krāsā (neaktīvo maršrutu krāsa), taču tas netraucē pārbaudes vārtejai. Pašreizējā RoS versija (6.44) piešķir automātisku prioritāti ECMP maršrutam, taču labāk ir pievienot testa maršrutus citām maršrutēšanas tabulām (opcija routing-mark)

Speedtest un citās līdzīgās vietnēs ātrums nepalielināsies (ECMP sadala trafiku pēc savienojumiem, nevis paketēm), taču p2p lietojumprogrammām vajadzētu lejupielādēt ātrāk.

Filtrēšana, izmantojot maršrutēšanu

/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. Statisks maršruts uz noklusējuma maršrutu
2. Statisks maršruts uz 192.168.200.0/24 pa ipip tuneli
3. Aizliegts statisks maršruts uz 192.168.200.0/24 caur ISP maršrutētāju

Filtrēšanas opcija, kurā tuneļa datplūsma nenonāks uz pakalpojumu sniedzēja maršrutētāju, kad ipip saskarne ir atspējota. Šādas shēmas ir reti nepieciešamas, jo Jūs varat ieviest bloķēšanu caur ugunsmūri.

Maršrutēšanas cilpa
Maršrutēšanas cilpa - situācija, kad pakete darbojas starp maršrutētājiem pirms ttl derīguma termiņa beigām. Parasti tas ir konfigurācijas kļūdas rezultāts, lielos tīklos tas tiek apstrādāts, ieviešot dinamiskus maršrutēšanas protokolus, mazos - uzmanīgi.

Tas izskatās apmēram šādi:

Piemērs (vienkāršākais), kā iegūt līdzīgu rezultātu:

Maršrutēšanas cilpas piemērs praktiski neder, taču tas parāda, ka maršrutētājiem nav ne jausmas par sava kaimiņa maršrutēšanas tabulu.

Politikas bāzes maršrutēšana un papildu maršrutēšanas tabulas

Izvēloties maršrutu, maršrutētājs izmanto tikai vienu lauku no paketes galvenes (Dst. Address) - tas ir pamata maršrutēšana. Maršrutēšana, kuras pamatā ir citi nosacījumi, piemēram, avota adrese, trafika veids (ToS), balansēšana bez ECMP, pieder pie politikas bāzes maršrutēšanas (PBR) un izmanto papildu maršrutēšanas tabulas.

Konkrētāks maršruts ir galvenais maršruta izvēles noteikums maršrutēšanas tabulā.

Pēc noklusējuma visi maršrutēšanas noteikumi tiek pievienoti galvenajai tabulai. Administrators var izveidot patvaļīgu skaitu papildu maršrutēšanas tabulu un maršruta pakešu uz tām. Noteikumi dažādās tabulās nav pretrunā viens ar otru. Ja pakotne neatradīs piemērotu noteikumu norādītajā tabulā, tā nonāks galvenajā tabulā.

Piemērs izplatīšanai, izmantojot ugunsmūri:

• 192.168.100.10 -> 8.8.8.8
  1. Satiksme no 192.168.100.10 tiek apzīmēta via-isp1 в [Prerouting|Mangle]
  2. Tabulas maršrutēšanas posmā via-isp1 meklē maršrutu uz 8.8.8.8
  3. Maršruts atrasts, satiksme nosūtīta uz vārteju 10.10.10.1
• 192.168.200.20 -> 8.8.8.8
  1. Satiksme no 192.168.200.20 tiek apzīmēta via-isp2 в [Prerouting|Mangle]
  2. Tabulas maršrutēšanas posmā via-isp2 meklē maršrutu uz 8.8.8.8
  3. Maršruts atrasts, satiksme nosūtīta uz vārteju 10.20.20.1
• Ja kāda no vārtejām (10.10.10.1 vai 10.20.20.1) kļūst nepieejama, pakete nonāks tabulā. galvenais un tur meklēs piemērotu maršrutu

Terminoloģijas jautājumi

RouterOS ir noteiktas terminoloģijas problēmas.
Strādājot ar noteikumiem [IP]->[Routes] ir norādīta maršrutēšanas tabula, lai gan ir rakstīts, ka etiķete:

В [IP]->[Routes]->[Rule] viss ir pareizi, etiķetes nosacījumā tabulas darbībā:

Kā nosūtīt paketi uz noteiktu maršrutēšanas tabulu

RouterOS nodrošina vairākus rīkus:

• Noteikumi iekšā [IP]->[Routes]->[Rules]
• Maršruta marķieri (action=mark-routing) iekšā [IP]->[Firewall]->[Mangle]
• VRF

Noteikumi [IP]->[Route]->[Rules]
Noteikumi tiek apstrādāti secīgi, ja pakete atbilst noteikuma nosacījumiem, tā netiek tālāk.

Maršrutēšanas noteikumi ļauj paplašināt maršrutēšanas iespējas, paļaujoties ne tikai uz adresāta adresi, bet arī uz avota adresi un interfeisu, kurā pakete tika saņemta.

Noteikumi sastāv no nosacījumiem un darbības:

• Nosacījumi. Praktiski atkārtojiet to zīmju sarakstu, pēc kurām FIB tiek pārbaudīta paka, trūkst tikai ToS.
• Aktivitāte
  • uzmeklēšana - nosūtiet paketi uz tabulu
  • meklēt tikai tabulā - bloķējiet pakotni tabulā, ja maršruts netiek atrasts, pakotne nenonāks uz galveno tabulu
  • nomest - nomest paciņu
  • nesasniedzams - izmetiet paketi ar sūtītāja paziņojumu

FIB trafiku uz vietējiem procesiem apstrādā, apejot noteikumus [IP]->[Route]->[Rules]:

marķēšana [IP]->[Firewall]->[Mangle]
Maršrutēšanas etiķetes ļauj iestatīt vārteju paketei, izmantojot gandrīz visus ugunsmūra nosacījumus:

Praktiski tāpēc, ka ne visiem ir jēga, un daži var darboties nestabili.

Ir divi veidi, kā marķēt iepakojumu:

• Uzreiz likts maršrutēšanas zīme
• Liek pirmajā vietā savienojuma zīme, tad pamatojoties uz savienojuma zīme ielikt maršrutēšanas zīme

Rakstā par ugunsmūriem rakstīju, ka priekšroka dodama otrajam variantam. samazina CPU slodzi, maršrutu marķēšanas gadījumā - tas nav pilnīgi taisnība. Šīs marķēšanas metodes ne vienmēr ir līdzvērtīgas un parasti tiek izmantotas dažādu problēmu risināšanai.

Lietošanas piemēri

Pāriesim pie politikas bāzes maršrutēšanas izmantošanas piemēriem, tajos ir daudz vieglāk parādīt, kāpēc tas viss ir vajadzīgs.

MultiWAN un atgriež izejošo (Output) trafiku
Izplatīta problēma ar MultiWAN konfigurāciju: Mikrotik ir pieejams no interneta tikai caur "aktīvo" pakalpojumu sniedzēju.

Maršrutētājam ir vienalga, uz kuru IP adrese tika saņemta, ģenerējot atbildi, tas maršrutēšanas tabulā meklēs maršrutu, kurā ir aktīvs maršruts caur isp1. Turklāt šāda pakete, visticamāk, tiks filtrēta ceļā uz adresātu.

Vēl viens interesants punkts. Ja ether1 saskarnē ir konfigurēts "vienkāršs" avota nat: /ip fi nat add out-interface=ether1 action=masquerade pakotne nonāks tiešsaistē, izmantojot src. adrese=10.10.10.100, kas padara lietas vēl sliktākas.

Ir vairāki veidi, kā novērst problēmu, taču jebkuram no tiem būs nepieciešamas papildu maršrutēšanas tabulas:

/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

Izmantot [IP]->[Route]->[Rules]
Norādiet maršrutēšanas tabulu, kas tiks izmantota paketēm ar norādīto avota 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

Var izmantot action=lookup, bet vietējai izejošajai trafikai šī opcija pilnībā izslēdz savienojumus no nepareizās saskarnes.

• Sistēma ģenerē atbildes paketi ar Src. Adrese: 10.20.20.200
• Maršrutēšanas lēmuma(2) solis pārbauda [IP]->[Routes]->[Rules] un pakete tiek nosūtīta uz maršrutēšanas tabulu over-isp2
• Saskaņā ar maršrutēšanas tabulu pakete ir jānosūta uz vārteju 10.20.20.1, izmantojot interfeisu ether2

Šai metodei nav nepieciešams funkcionējošs savienojuma izsekotājs, atšķirībā no tabulas Mangle izmantošanas.

Izmantot [IP]->[Firewall]->[Mangle]
Savienojums sākas ar ienākošu paketi, tāpēc mēs to atzīmējam (action=mark-connection), izejošām paketēm no atzīmēta savienojuma iestatiet maršrutēšanas etiķeti (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

Ja vienā saskarnē ir konfigurēti vairāki IP, varat pievienot nosacījumu dst-address lai pārliecinātos.

• Pakete atver savienojumu ether2 interfeisā. Paciņa nonāk iekšā [INPUT|Mangle] kas saka atzīmēt visas paketes no savienojuma kā no-isp2
• Sistēma ģenerē atbildes paketi ar Src. Adrese: 10.20.20.200
• Maršrutēšanas lēmuma (2) posmā pakete saskaņā ar maršrutēšanas tabulu tiek nosūtīta uz vārteju 10.20.20.1, izmantojot interfeisu ether1. To varat pārbaudīt, piesakoties pakotnēs [OUTPUT|Filter]
• Pie skatuves [OUTPUT|Mangle] savienojuma etiķete ir pārbaudīta no-isp2 un pakete saņem maršruta etiķeti over-isp2
• Routing Adjustment (3) darbība pārbauda maršrutēšanas etiķetes esamību un nosūta to uz atbilstošo maršrutēšanas tabulu.
• Saskaņā ar maršrutēšanas tabulu pakete ir jānosūta uz vārteju 10.20.20.1, izmantojot interfeisu ether2

MultiWAN un atgriež dst-nat trafiku

Sarežģītāks ir piemērs, ko darīt, ja privātā apakštīklā aiz maršrutētāja atrodas serveris (piemēram, tīmeklis) un jums ir jānodrošina piekļuve tam caur kādu no pakalpojumu sniedzējiem.

/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

Problēmas būtība būs tāda pati, risinājums ir līdzīgs Firewall Mangle opcijai, tiks izmantotas tikai citas ķēdes:

/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

Diagrammā nav redzams NAT, bet es domāju, ka viss ir skaidrs.

MultiWAN un izejošie savienojumi

Varat izmantot PBR iespējas, lai izveidotu vairākus vpn (piemērā SSTP) savienojumus no dažādām maršrutētāja saskarnēm.

Papildu maršrutēšanas tabulas:

/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

Iepakojuma marķējumi:

/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

Vienkārši NAT noteikumi, pretējā gadījumā pakete atstās saskarni ar nepareizu Src. adrese:

/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

Parsēšana:

• Maršrutētājs izveido trīs SSTP procesus
• Maršrutēšanas lēmuma (2) posmā šiem procesiem tiek izvēlēts maršruts, pamatojoties uz galveno maršrutēšanas tabulu. No tā paša maršruta pakete saņem Src. Adrese ir saistīta ar ether1 interfeisu
• В [Output|Mangle] paketes no dažādiem savienojumiem saņem dažādas etiķetes
• Paketes ievada etiķetēm atbilstošajās tabulās maršruta pielāgošanas posmā un saņem jaunu maršrutu pakešu nosūtīšanai
• Bet iepakojumos joprojām ir Src. Uzruna no etera1, uz skatuves [Nat|Srcnat] adrese tiek aizstāta atbilstoši saskarnei

Interesanti, ka maršrutētājā jūs redzēsit šādu savienojuma tabulu:

Savienojuma izsekotājs darbojas agrāk [Mangle] и [Srcnat], tāpēc visi savienojumi nāk no vienas adreses, ja paskatās sīkāk, tad iekšā Replay Dst. Address pēc NAT būs adreses:

VPN serverī (man tāds ir pārbaudes stendā) varat redzēt, ka visi savienojumi nāk no pareizajām adresēm:

Turiet ceļu
Ir vienkāršāks veids, katrai adresei varat vienkārši norādīt konkrētu vārteju:

/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

Bet šādi maršruti ietekmēs ne tikai izejošo, bet arī tranzīta satiksmi. Turklāt, ja jums nav nepieciešama trafika uz vpn serveri, lai izietu cauri neatbilstošiem saziņas kanāliem, jums būs jāpievieno vēl 6 noteikumi [IP]->[Routes]с type=blackhole. Iepriekšējā versijā - 3 noteikumi iekšā [IP]->[Route]->[Rules].

Lietotāju savienojumu sadale pa sakaru kanāliem

Vienkārši, ikdienas darbi. Atkal būs nepieciešamas papildu maršrutēšanas tabulas:

/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

Izmantojot [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

Ja lieto action=lookup, tad, kad kāds no kanāliem ir atspējots, trafika pāries uz galveno tabulu un iet caur darba kanālu. Tas, vai tas ir nepieciešams, ir atkarīgs no uzdevuma.

Izmantojot marķējumus iekšā [IP]->[Firewall]->[Mangle]
Vienkāršs piemērs ar IP adrešu sarakstiem. Principā var izmantot gandrīz visus nosacījumus. Vienīgais 7. slāņa brīdinājums, pat ja tas ir savienots pārī ar savienojuma etiķetēm, var šķist, ka viss darbojas pareizi, taču daļa trafika joprojām notiks nepareizā virzienā.

/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

Varat “bloķēt” lietotājus vienā maršrutēšanas tabulā [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

Vai nu cauri [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
Papildu nosacījums dst-address-type=!local ir nepieciešams, lai lietotāju trafika sasniegtu maršrutētāja vietējos procesus (dns, winbox, ssh, ...). Ja maršrutētājam ir pievienoti vairāki vietējie apakštīkli, ir jānodrošina, lai trafika starp tiem nenonāktu uz internetu, piemēram, izmantojot dst-address-table.

Piemērā izmantojot [IP]->[Route]->[Rules] tādu izņēmumu nav, bet satiksme sasniedz vietējos procesus. Fakts ir tāds, ka nokļūstot FIB iepakojumā, kas atzīmēts [PREROUTING|Mangle] ir maršruta etiķete, un tā nonāk maršrutēšanas tabulā, kas nav galvenā, kur nav lokālas saskarnes. Maršrutēšanas kārtulu gadījumā vispirms tiek pārbaudīts, vai pakete ir paredzēta lokālam procesam un tikai User PBR posmā tā nonāk norādītajā maršrutēšanas tabulā.

Izmantojot [IP]->[Firewall]->[Mangle action=route]
Šī darbība darbojas tikai [Prerouting|Mangle] un ļauj novirzīt trafiku uz norādīto vārteju, neizmantojot papildu maršrutēšanas tabulas, tieši norādot vārtejas adresi:

/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

efekts route ir zemāka prioritāte nekā maršrutēšanas noteikumiem ([IP]->[Route]->[Rules]). Maršruta atzīmju gadījumā viss ir atkarīgs no noteikumu pozīcijas, ja noteikums ar action=route vērts vairāk nekā action=mark-route, tad tas tiks izmantots (neatkarīgi no karoga passtrough), pretējā gadījumā marķējot maršrutu.
Wiki ir ļoti maz informācijas par šo darbību un visi secinājumi tika iegūti eksperimentāli, katrā ziņā es neatradu variantus, kad šī opcija dod priekšrocības salīdzinājumā ar citiem.

Uz PPC balstīta dinamiskā balansēšana

Per Connection Klasifikators - ir elastīgāks ECMP analogs. Atšķirībā no ECMP, tas stingrāk sadala trafiku pa savienojumiem (ECMP neko nezina par savienojumiem, bet savienojot pārī ar Routing Cache, tiek iegūts kaut kas līdzīgs).

PCC ņem norādītos laukus no ip galvenes, pārvērš tos 32 bitu vērtībā un dala ar saucējs. Atlikušo sadalījumu salīdzina ar norādīto atlikumu un, ja tie sakrīt, tiek piemērota norādītā darbība. vairāk. Izklausās traki, bet tas darbojas.

Piemērs ar trim adresēm:

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

Piemērs dinamiskai trafika sadalei pēc src.adreses starp trim kanāliem:

#Таблица маршрутизации
/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

Maršrutu marķēšanai ir papildu nosacījums: in-interface=br-lan, bez tā zem action=mark-routing atbildes trafiks no interneta saņems un saskaņā ar maršrutēšanas tabulām atgriezīsies pie pakalpojumu sniedzēja.

Komunikācijas kanālu pārslēgšana

Pārbaudes ping ir labs rīks, taču tas pārbauda tikai savienojumu ar tuvāko IP vienādrangu, pakalpojumu sniedzēju tīkli parasti sastāv no liela skaita maršrutētāju un savienojuma pārtraukums var notikt ārpus tuvākā vienādranga, un tad ir mugurkaula telekomunikāciju operatori, kas var arī Ja rodas problēmas, parasti pārbaudes ping ne vienmēr parāda jaunāko informāciju par piekļuvi globālajam tīklam.
Ja pakalpojumu sniedzējiem un lielām korporācijām ir BGP dinamiskās maršrutēšanas protokols, mājas un biroja lietotājiem ir patstāvīgi jāizdomā, kā pārbaudīt piekļuvi internetam, izmantojot noteiktu sakaru kanālu.

Parasti tiek izmantoti skripti, kas, izmantojot noteiktu saziņas kanālu, pārbauda ip adreses pieejamību internetā, vienlaikus izvēloties ko uzticamu, piemēram, google dns: 8.8.8.8. 8.8.4.4. Bet Mikrotik kopienā šim nolūkam ir pielāgots interesantāks rīks.

Daži vārdi par rekursīvo maršrutēšanu
Rekursīvais maršrutēšana ir nepieciešama, veidojot Multihop BGP peering, un rakstā par statiskās maršrutēšanas pamatiem nokļuva tikai viltīgo MikroTik lietotāju dēļ, kuri izdomāja, kā izmantot rekursīvos maršrutus, kas savienoti pārī ar čeku vārteju, lai pārslēgtu sakaru kanālus bez papildu skriptiem.

Ir pienācis laiks vispārīgi izprast tvēruma/mērķa tvēruma opcijas un to, kā maršruts ir saistīts ar saskarni:

1. Maršruts meklē saskarni, lai nosūtītu paketi, pamatojoties uz tās tvēruma vērtību un visiem ierakstiem galvenajā tabulā ar mazākām vai vienādām mērķa tvēruma vērtībām
2. No atrastajām saskarnēm tiek atlasīta tā, caur kuru jūs varat nosūtīt paketi uz norādīto vārteju
3. Atrastā savienotā ieraksta saskarne ir atlasīta, lai nosūtītu paketi uz vārteju

Rekursīva maršruta klātbūtnē viss notiek tāpat, bet divos posmos:

• 1-3 Savienotajiem maršrutiem tiek pievienots vēl viens maršruts, caur kuru var sasniegt norādīto vārteju
• 4-6 Maršruta savienojuma maršruta atrašana "starpposma" vārtejai

Visas manipulācijas ar rekursīvo meklēšanu notiek RIB, un tikai gala rezultāts tiek pārsūtīts uz FIB: 0.0.0.0/0 via 10.10.10.1 on ether1.

Rekursīvās maršrutēšanas izmantošanas piemērs, lai pārslēgtu maršrutus

Konfigurācija:

/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

Varat pārbaudīt, vai paketes tiks nosūtītas uz 10.10.10.1:

Pārbaudes vārteja neko nezina par rekursīvo maršrutēšanu un vienkārši nosūta ping uz 8.8.8.8, kas (pamatojoties uz galveno tabulu) ir pieejama caur vārteju 10.10.10.1.

Ja starp 10.10.10.1 un 8.8.8.8 ir sakaru zudums, maršruts tiek atvienots, bet paketes (ieskaitot testa ping) uz 8.8.8.8 turpina iet caur 10.10.10.1:

Ja tiek zaudēta saite uz ether1, rodas nepatīkama situācija, kad paketes pirms 8.8.8.8 iet caur otro pakalpojumu sniedzēju:

Tā ir problēma, ja izmantojat NetWatch, lai palaistu skriptus, kad 8.8.8.8 nav pieejams. Ja saite ir bojāta, NetWatch vienkārši darbosies caur rezerves sakaru kanālu un pieņems, ka viss ir kārtībā. Atrisināts, pievienojot papildu filtra maršrutu:

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

Ir uz habré raksts, kur sīkāk aplūkota situācija ar NetWatch.

Un jā, izmantojot šādu rezervāciju, adrese 8.8.8.8 tiks pieslēgta kādam no pakalpojumu sniedzējiem, tāpēc izvēlēties to kā dns avotu nav laba ideja.

Daži vārdi par virtuālo maršrutēšanu un pārsūtīšanu (VRF)

VRF tehnoloģija ir izstrādāta, lai izveidotu vairākus virtuālos maršrutētājus vienā fiziskajā maršrutētājā, šo tehnoloģiju plaši izmanto telekomunikāciju operatori (parasti kopā ar MPLS), lai nodrošinātu L3VPN pakalpojumus klientiem, kuru apakštīkla adreses pārklājas:

Bet VRF Mikrotikā ir organizēts, pamatojoties uz maršrutēšanas tabulām, un tam ir vairāki trūkumi, piemēram, maršrutētāja vietējās IP adreses ir pieejamas no visiem VRF, varat lasīt vairāk по ссылке.

vrf konfigurācijas piemērs:

/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

No ierīces, kas savienota ar ether2, mēs redzam, ka ping tiek nosūtīts uz maršrutētāja adresi no cita vrf (un tā ir problēma), savukārt ping nenonāk internetā:

Lai piekļūtu internetam, ir jāreģistrē papildu maršruts, kas piekļūst galvenajai tabulai (vrf terminoloģijā to sauc par maršruta noplūdi):

/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

Šeit ir divi maršruta noplūdes veidi: izmantojot maršrutēšanas tabulu: 172.17.0.1@main un izmantojot interfeisa nosaukumu: 172.17.0.1%wlan1.

Un iestatiet marķējumu atgriešanās satiksmei [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 

Apakštīkli ar tādu pašu adresi
Piekļuves organizēšana apakštīkliem ar vienādu adresi tajā pašā maršrutētājā, izmantojot VRF un tīkla karti:

Pamatkonfigurācija:

/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

ugunsmūra noteikumi:

#Маркируем пакеты для отправки в правильную таблицу маршрутизации
/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

Maršrutēšanas noteikumi atpakaļgaitas satiksmei:

#Указание имени интерфейса тоже может считаться 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

Caur dhcp saņemto maršrutu pievienošana noteiktai maršrutēšanas tabulai
VRF var būt interesants, ja konkrētai maršrutēšanas tabulai automātiski jāpievieno dinamisks maršruts (piemēram, no dhcp klienta).

Saskarnes pievienošana vrf:

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

Noteikumi trafika (izejošā un tranzīta) nosūtīšanai caur tabulu 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

Papildu, viltus maršruts izejošajam maršrutam uz darbu:

/interface bridge
add name=bare

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

Šis maršruts ir nepieciešams tikai tāpēc, lai vietējās izejošās paketes varētu iziet cauri maršrutēšanas lēmumam (2). [OUTPUT|Mangle] un iegūstiet maršrutēšanas etiķeti, ja maršrutētājā ir citi aktīvi maršruti pirms 0.0.0.0/0 galvenajā tabulā, tas nav nepieciešams.

Ķēdes connected-in и dynamic-in в [Routing] -> [Filters]

Maršruta filtrēšana (ienākošais un izejošais) ir rīks, ko parasti izmanto kopā ar dinamiskajiem maršrutēšanas protokoliem (un tāpēc tas ir pieejams tikai pēc pakotnes instalēšanas Maršrutēšana), taču ienākošajos filtros ir divas interesantas ķēdes:

• connect-in — savienoto maršrutu filtrēšana
• dynamic-in - PPP un DCHP saņemto dinamisko maršrutu filtrēšana

Filtrēšana ļauj ne tikai atmest maršrutus, bet arī mainīt vairākas iespējas: attālumu, maršruta atzīmi, komentāru, tvērumu, mērķa tvērumu, ...

Šis ir ļoti precīzs rīks un ja vari kaut ko izdarīt bez maršrutēšanas filtriem (bet ne skriptiem), tad nelieto Routing Filters, nemulsina sevi un tos, kas pēc tevis konfigurēs rūteri. Dinamiskās maršrutēšanas kontekstā maršrutēšanas filtri tiks izmantoti daudz biežāk un produktīvāk.

Maršruta atzīmes iestatīšana dinamiskiem maršrutiem
Piemērs no mājas maršrutētāja. Man ir konfigurēti divi VPN savienojumi, un trafika tajos ir jāietver saskaņā ar maršrutēšanas tabulām. Tajā pašā laikā es vēlos, lai maršruti tiktu izveidoti automātiski, kad saskarne ir aktivizēta:

#При создании 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

Es nezinu, kāpēc, iespējams, kļūda, bet, ja izveidojat vrf ppp saskarnei, maršruts uz 0.0.0.0/0 joprojām tiks iekļauts galvenajā tabulā. Citādi viss būtu vēl vienkāršāk.

Savienoto maršrutu atspējošana
Dažreiz tas ir nepieciešams:

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

Atkļūdošanas rīki

RouterOS nodrošina vairākus rīkus maršrutēšanas atkļūdošanai:

• [Tool]->[Tourch] - ļauj skatīt paketes saskarnēs
• /ip route check - ļauj redzēt, uz kuru vārteju pakete tiks nosūtīta, nedarbojas ar maršrutēšanas tabulām
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - ping un izsekot, izmantojot norādīto maršrutēšanas tabulu
• action=log в [IP]->[Firewall] - lielisks rīks, kas ļauj izsekot paketes ceļam pa pakešu plūsmu, šī darbība ir pieejama visās ķēdēs un tabulās

Avots: www.habr.com