Staatilise marsruutimise põhitõed Mikrotik RouterOS-is

Marsruutimine on TCP/IP-võrkude kaudu pakettide edastamiseks parima tee leidmise protsess. Iga IPv4-võrku ühendatud seade sisaldab protsessi- ja marsruutimistabeleid.

See artikkel ei ole HOIDAS, see kirjeldab staatilist marsruutimist RouterOS-is koos näidetega, ülejäänud seaded jätsin teadlikult välja (näiteks srcnat Interneti-juurdepääsuks), nii et materjali mõistmine nõuab teatud teadmisi võrkude ja RouterOS-i kohta.

Vahetamine ja marsruutimine

Vahetamine on pakettide vahetamise protsess ühes Layer2 segmendis (Ethernet, ppp, ...). Kui seade näeb, et paketi saaja on temaga samas Etherneti alamvõrgus, õpib ta arp-protokolli kasutades teada mac-aadressi ja edastab paketi otse, ruuterist mööda minnes. Ppp (point-to-point) ühendusel saab olla ainult kaks osalejat ja pakett saadetakse alati ühele aadressile 0xff.

Marsruutimine on pakettide ülekandmine Layer2 segmentide vahel. Kui seade soovib saata paketti, mille saaja asub väljaspool Etherneti segmenti, vaatab see oma marsruutimistabelit ja edastab paketi lüüsile, mis teab, kuhu pakett järgmisena saata (või ei pruugi teada, paketi algne saatja on pole sellest teadlik).

Lihtsaim viis ruuterit pidada seadmeks, mis on ühendatud kahe või enama Layer2 segmendiga ja suudab nende vahel pakette edastada, määrates marsruutimistabelist parima marsruudi.

Kui sa kõigest aru saad või teadsid seda juba, siis loe edasi. Ülejäänud osas soovitan tungivalt tutvuda väikese, kuid väga mahukaga artikliga.

Marsruutimine RouterOS-is ja PacketFlow's

Peaaegu kõik staatilise marsruutimisega seotud funktsioonid on pakendis süsteem. Kilekott Marsruutimine lisab toe dünaamilistele marsruutimisalgoritmidele (RIP, OSPF, BGP, MME), marsruutimisfiltritele ja BFD-le.

Peamenüü marsruutimise seadistamiseks: [IP]->[Route]. Keerulised skeemid võivad nõuda, et paketid oleksid eelnevalt marsruutimismärgiga märgistatud: [IP]->[Firewall]->[Mangle] (ketid PREROUTING и OUTPUT).

PacketFlow's on kolm kohta, kus tehakse IP-pakettide marsruutimise otsused:

1. Ruuteri poolt vastuvõetud pakettide marsruutimine. Selles etapis otsustatakse, kas pakett läheb kohalikku protsessi või saadetakse edasi võrku. Transiitpakid võtavad vastu Väljundliidesele
2. Kohalike väljaminevate pakettide marsruutimine. Väljuvad paketid võetakse vastu Väljundliidesele
3. Täiendav väljaminevate pakettide marsruutimise samm võimaldab teil muuta marsruutimisotsust [Output|Mangle]

• Plokkide 1, 2 paketi tee sõltub reeglitest [IP]->[Route]
• Punktides 1, 2 ja 3 olev paketi tee sõltub reeglitest [IP]->[Route]->[Rules]
• Paketi teed plokkides 1, 3 saab mõjutada kasutades [IP]->[Firewall]->[Mangle]

RIB, FIB, marsruutimise vahemälu

Marsruutimise teabebaas
Alus, kuhu kogutakse marsruute dünaamilistest marsruutimisprotokollidest, marsruute ppp-st ja dhcp-st, staatilistest ja ühendatud marsruutidest. See andmebaas sisaldab kõiki marsruute, välja arvatud need, mille on filtreerinud administraator.

Tinglikult, võime seda eeldada [IP]->[Route] kuvab RIB.

Edastamise teabebaas

Baas, kuhu kogutakse RIB-i parimad marsruudid. Kõik FIB-i marsruudid on aktiivsed ja neid kasutatakse pakettide edastamiseks. Kui marsruut muutub passiivseks (administraatori (süsteemi) poolt keelatud või liides, mille kaudu pakett saata, ei ole aktiivne), eemaldatakse marsruut FIB-st.

Marsruutimise otsuse tegemiseks kasutab FIB tabel IP-paketi kohta järgmist teavet:

• Allika aadress
• Sihtkoha aadress
• allika liides
• Marsruudi märk
• ToS (DSCP)

FIB paketti sisenemine läbib järgmised etapid:

• Kas pakett on mõeldud kohaliku ruuteri protsessi jaoks?
• Kas paketi suhtes kehtivad süsteemi või kasutaja PBR-reeglid?
  • Kui jah, siis saadetakse pakett määratud marsruutimistabelisse
• Pakett saadetakse põhitabelisse

Tinglikult, võime seda eeldada [IP]->[Route Active=yes] kuvab FIB.

Marsruutimise vahemälu
Marsruudi vahemällu salvestamise mehhanism. Ruuter jätab meelde, kuhu paketid saadeti ja kui on sarnaseid pakette (eeldatavasti samast ühendusest), siis laseb neil sama marsruuti mööda minna, ilma FIB-is kontrollimata. Marsruudi vahemälu tühjendatakse perioodiliselt.

RouterOS-i administraatorid ei teinud tööriistu marsruutimise vahemälu vaatamiseks ja haldamiseks, vaid siis, kui selle saab keelata. [IP]->[Settings].

See mehhanism eemaldati Linuxi 3.6 tuumast, kuid RouterOS kasutab endiselt kerneli 3.3.5, võib-olla on üks põhjusi marsruutimine cahce.

Marsruudi lisamise dialoog

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

1. Alamvõrk, mille jaoks soovite marsruudi luua (vaikimisi: 0.0.0.0/0)
2. Lüüsi IP või liides, millele pakett saadetakse (neid võib olla mitu, vt allpool ECMP)
3. Lüüsi saadavuse kontroll
4. Kirje tüüp
5. Marsruudi kaugus (meetriline).
6. Marsruutimistabel
7. Selle marsruudi kaudu väljuvate kohalike pakettide IP
8. Reguleerimisala ja sihtulatuse eesmärk on kirjas artikli lõpus.

Marsruudi lipud

• X – administraator on marsruudi keelanud (disabled=yes)
• A – marsruuti kasutatakse pakettide saatmiseks
• D – marsruut lisatakse dünaamiliselt (BGP, OSPF, RIP, MME, PPP, DHCP, ühendatud)
• C – alamvõrk on ühendatud otse ruuteriga
• S - Staatiline marsruut
• r,b,o,m – marsruut, mis on lisatud ühe dünaamilise marsruutimisprotokolliga
• B,U,P – marsruudi filtreerimine (edastuse asemel kukub paketid maha)

Mida lüüsis määrata: IP-aadress või liides?

Süsteem võimaldab määrata mõlemat, samas ei vannu ega anna vihjeid, kui tegite midagi valesti.

IP-aadress
Lüüsi aadress peab olema juurdepääsetav üle kihi 2. Etherneti puhul tähendab see, et ruuteril peab ühel aktiivsel IP-liidesel olema aadress samast alamvõrgust, ppp puhul aga seda, et lüüsi aadress on alamvõrgu aadressina määratud ühel aktiivsel liidesel.
Kui Layer2 juurdepääsetavuse tingimus ei ole täidetud, loetakse marsruut passiivseks ja see ei kuulu FIB-i.

liides
Kõik on keerulisem ja ruuteri käitumine sõltub liidese tüübist:

• PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) ühendus eeldab ainult kahte osalejat ja pakett saadetakse alati lüüsile edastamiseks, kui lüüs tuvastab, et saaja on tema ise, siis edastab ta paketi selle kohalik protsess.
  
• Ethernet eeldab paljude osalejate olemasolu ja saadab arp-liidesele päringuid paketi saaja aadressiga, see on eeldatav ja ühendatud marsruutide puhul üsna tavaline käitumine.
  Kuid kui proovite liidest kasutada kaug-alamvõrgu marsruudina, saate järgmise olukorra: marsruut on aktiivne, ping lüüsile läbib, kuid ei jõua määratud alamvõrgust adressaadini. Kui vaatate liidest läbi nuusutaja, näete arp-päringuid kaug-alamvõrgu aadressidega.
  

Proovige võimalusel määrata lüüsiks IP-aadress. Erandiks on ühendatud marsruudid (loodud automaatselt) ja PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*) liidesed.

OpenVPN ei sisalda PPP päist, kuid marsruudi loomiseks saate kasutada OpenVPN-i liidese nime.

Täpsem marsruut

Marsruutimise põhireegel. Marsruut, mis kirjeldab väiksemat alamvõrku (suurima alamvõrgu maskiga), on paketi marsruutimisotsuses ülimuslik. Kirjete asukoht marsruutimistabelis ei ole valikul oluline – põhireegel on Täpsemalt.

Kõik määratud skeemi marsruudid on aktiivsed (asuvad FIB-is). osutavad erinevatele alamvõrkudele ja ei lähe üksteisega vastuollu.

Kui üks lüüsidest muutub kättesaamatuks, loetakse seotud marsruut passiivseks (eemaldatakse FIB-st) ja ülejäänud marsruutidelt otsitakse pakette.

Alamvõrguga 0.0.0.0/0 marsruudile omistatakse mõnikord eriline tähendus ja seda nimetatakse "vaikemarsruudiks" või "viimase võimaluse väravaks". Tegelikult pole selles midagi maagilist ja see sisaldab lihtsalt kõiki võimalikke IPv4 aadresse, kuid need nimed kirjeldavad hästi selle ülesannet - see näitab lüüsi, kuhu suunata paketid, mille jaoks muid täpsemaid marsruute pole.

IPv4 maksimaalne võimalik alamvõrgumask on /32, see marsruut osutab konkreetsele hostile ja seda saab kasutada marsruutimistabelis.

Konkreetsema marsruudi mõistmine on iga TCP/IP-seadme jaoks ülioluline.

kaugus

Kaugused (või mõõdikud) on vajalikud marsruutide administratiivseks filtreerimiseks ühte alamvõrku, millele on juurdepääs mitme lüüsi kaudu. Madalama mõõdikuga marsruuti peetakse prioriteetseks ja see lisatakse FIB-i. Kui madalama mõõdikuga marsruut lakkab olemast, asendatakse see FIB-is kõrgema mõõdikuga marsruudiga.

Kui samasse alamvõrku on sama mõõdikuga mitu marsruuti, lisab ruuter oma sisemisest loogikast juhindudes FIB-tabelisse ainult ühe neist.

Mõõdiku väärtus võib olla vahemikus 0 kuni 255:

• 0 – ühendatud marsruutide mõõdik. Distantsi 0 ei saa administraator määrata
• 1-254 – administraatorile marsruutide määramiseks saadaolevad mõõdikud. Madalama väärtusega mõõdikutel on kõrgem prioriteet
• 255 – administraatorile marsruutide määramiseks saadaval mõõdik. Erinevalt 1-254-st jääb marsruut mõõdikuga 255 alati passiivseks ega kuulu FIB-i
• konkreetsed mõõdikud. Dünaamilistest marsruutimisprotokollidest tuletatud marsruutidel on standardsed mõõdikud

kontrolli lüüsi

Check gateway on MikroTik RoutesOS laiendus, mis võimaldab kontrollida lüüsi saadavust icmp või arp kaudu. Kord iga 10 sekundi järel (muuta ei saa) saadetakse lüüsile päring, kui vastust ei saa kaks korda, loetakse marsruut kättesaamatuks ja eemaldatakse FIB-ist. Kui kontrolli lüüs on keelanud, jätkub kontrolli marsruut ja marsruut muutub pärast ühte edukat kontrolli uuesti aktiivseks.

Kontrolli lüüs keelab kirje, milles see on konfigureeritud, ja kõik muud kirjed (kõigis marsruutimistabelites ja ecmp marsruutides) määratud lüüsiga.

Üldiselt töötab kontrolli lüüs hästi seni, kuni lüüsile ei teki probleeme pakettide kadumisega. Check gateway ei tea, mis toimub sidega väljaspool kontrollitud lüüsi, selleks on vaja lisatööriistu: skripte, rekursiivset marsruutimist, dünaamilisi marsruutimise protokolle.

Enamik VPN-i ja tunneliprotokolle sisaldab sisseehitatud tööriistu ühenduse aktiivsuse kontrollimiseks, nende jaoks kontrolllüüsi lubamine on täiendav (kuid väga väike) koormus võrgu ja seadme jõudlusele.

ECMP marsruudid

Võrdse kuluga mitmetee – pakettide saatmine adressaadile, kasutades korraga mitut lüüsi, kasutades Round Robini algoritmi.

ECMP marsruudi loob administraator, määrates ühe alamvõrgu jaoks mitu lüüsi (või automaatselt, kui on kaks samaväärset OSPF-marsruuti).

ECMP-d kasutatakse koormuse tasakaalustamiseks kahe kanali vahel, teoreetiliselt, kui ecmp marsruudil on kaks kanalit, siis iga paketi puhul peaks väljuv kanal olema erinev. Kuid marsruutimise vahemälu mehhanism saadab ühenduselt pakette esimese paketi marsruudil, mille tulemusel saame ühendustel põhineva tasakaalustamise (ühendusepõhine laadimise tasakaalustamine).

Kui keelate marsruudi vahemälu, jagatakse ECMP marsruudi pakette õigesti, kuid probleem on NAT-iga. NAT-reegel töötleb ühendusest ainult esimest paketti (ülejäänud töödeldakse automaatselt) ja selgub, et sama lähteaadressiga paketid jätavad erinevad liidesed.

Kontrollige, kas lüüs ei tööta ECMP marsruutidel (RouterOS-i viga). Kuid saate sellest piirangust mööda minna, luues täiendavaid valideerimismarsruute, mis keelavad ECMP-s kirjed.

Filtreerimine marsruutimise abil

Valik Tüüp määrab, mida paketiga teha:

• unicast - saatmine määratud lüüsile (liidesele)
• blackhole – visake pakk ära
• keela, kättesaamatu – visake pakett ära ja saatke saatjale icmp-sõnum

Filtreerimist kasutatakse tavaliselt siis, kui on vaja turvata pakettide saatmine valet teed pidi, loomulikult saab seda filtreerida läbi tulemüüri.

Paar näidet

Marsruutimise põhiteadmiste koondamiseks.

Tüüpiline kodu ruuter

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

1. Staatiline marsruut kuni 0.0.0.0/0 (vaikemarsruut)
2. Ühendatud marsruut teenusepakkuja liideses
3. Ühendatud marsruut LAN-liidese kaudu

Tüüpiline PPPoE-ga koduruuter

1. Staatiline marsruut vaikemarsruudile, lisatakse automaatselt. see on määratud ühenduse omadustes
2. Ühendatud marsruut PPP-ühenduse jaoks
3. Ühendatud marsruut LAN-liidese kaudu

Tüüpiline koduruuter kahe pakkuja ja koondamisega

/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. Staatiline marsruut vaikemarsruudini läbi esimese pakkuja koos mõõdiku 1 ja lüüsi saadavuse kontrolliga
2. Staatiline marsruut vaikemarsruudile teise pakkuja kaudu mõõdikuga 2
3. Ühendatud marsruudid

Liiklus numbrile 0.0.0.0/0 läbib 10.10.10.1, kuni see lüüs on saadaval, vastasel juhul lülitub see versioonile 10.20.20.1

Sellist skeemi võib pidada kanali broneeringuks, kuid sellel pole ka puudusi. Kui katkestus toimub väljaspool teenusepakkuja lüüsi (näiteks operaatori võrgus), ei saa teie ruuter sellest teada ja peab marsruuti jätkuvalt aktiivseks.

Tüüpiline koduruuter kahe pakkujaga, koondamine ja 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. Staatilised marsruudid chacki lüüsi kontrollimiseks
2. ECMP marsruut
3. Ühendatud marsruudid

Kontrollitavad marsruudid on sinised (mitteaktiivsete marsruutide värv), kuid see ei sega kontrolli lüüsi. RoS praegune versioon (6.44) annab ECMP marsruudile automaatse prioriteedi, kuid parem on lisada testmarsruudid teistele marsruutimistabelitele (valik routing-mark)

Speedtestis ja muudel sarnastel saitidel kiirus ei suurene (ECMP jagab liikluse ühenduste, mitte pakettide kaupa), kuid p2p-rakendused peaksid laadima kiiremini.

Filtreerimine marsruudi kaudu

/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. Staatiline marsruut vaikemarsruudile
2. Staatiline marsruut 192.168.200.0/24 üle ipip-tunneli
3. Staatilise marsruudi keelamine Interneti-teenuse pakkuja ruuteri kaudu numbrile 192.168.200.0/24

Filtreerimisvalik, mille puhul tunneliliiklus ei lähe teenusepakkuja ruuterisse, kui ipip-liides on keelatud. Selliseid skeeme on harva vaja, sest saate rakendada tulemüüri kaudu blokeerimist.

Marsruutimissilmus
Routing loop - olukord, kus pakett jookseb ruuterite vahel enne ttl aegumist. Tavaliselt on see konfiguratsioonivea tagajärg, suurtes võrkudes käsitletakse seda dünaamiliste marsruutimisprotokollide rakendamisega, väikestes - ettevaatlikult.

See näeb välja umbes selline:

Näide (lihtsaim) sarnase tulemuse saamise kohta:

Marsruutimisahela näitel pole praktilist kasu, kuid see näitab, et ruuteritel pole naabri marsruutimistabelist aimugi.

Poliitikabaasi marsruutimine ja täiendavad marsruutimistabelid

Marsruudi valimisel kasutab ruuter ainult ühte välja paketi päisest (Dst. Address) – see on põhiline marsruutimine. Marsruutimine, mis põhineb muudel tingimustel, nagu allikaaadress, liikluse tüüp (ToS), tasakaalustamine ilma ECMP-ta, kuulub poliitikabaaside marsruutimisse (PBR) ja kasutab täiendavaid marsruutimistabeleid.

Täpsem marsruut on peamine marsruudi valimise reegel marsruutimistabelis.

Vaikimisi lisatakse kõik marsruutimisreeglid põhitabelisse. Administraator saab luua suvalise arvu täiendavaid marsruutimistabeleid ja nendesse marsruudipakette. Reeglid erinevates tabelites ei ole omavahel vastuolus. Kui pakett ei leia määratud tabelist sobivat reeglit, läheb see põhitabelisse.

Näide tulemüüri kaudu levitamisest:

• 192.168.100.10 -> 8.8.8.8
  1. Liiklus alates 192.168.100.10 märgistatakse via-isp1 в [Prerouting|Mangle]
  2. Tabeli marsruutimise etapis via-isp1 otsib marsruuti 8.8.8.8
  3. Marsruut leitud, liiklus suunatakse lüüsi 10.10.10.1
• 192.168.200.20 -> 8.8.8.8
  1. Liiklus alates 192.168.200.20 märgistatakse via-isp2 в [Prerouting|Mangle]
  2. Tabeli marsruutimise etapis via-isp2 otsib marsruuti 8.8.8.8
  3. Marsruut leitud, liiklus suunatakse lüüsi 10.20.20.1
• Kui üks lüüsidest (10.10.10.1 või 10.20.20.1) muutub kättesaamatuks, läheb pakett tabelisse põhiline ja otsib sinna sobiva marsruudi

Terminoloogia küsimused

RouterOS-il on teatud terminoloogiaprobleemid.
Kui töötate reeglitega [IP]->[Routes] marsruutimistabel on näidatud, kuigi on kirjutatud, et silt:

В [IP]->[Routes]->[Rule] kõik on õige, sildi tingimuses tabeli toimingus:

Kuidas saata pakett konkreetsesse marsruutimistabelisse

RouterOS pakub mitmeid tööriistu:

• Reeglid sisse [IP]->[Routes]->[Rules]
• Marsruudi markerid (action=mark-routing) sisse [IP]->[Firewall]->[Mangle]
• VRF

Reeglid [IP]->[Route]->[Rules]
Reegleid töödeldakse järjestikku, kui pakett vastab reegli tingimustele, siis see edasi ei liigu.

Marsruutimise reeglid võimaldavad teil laiendada marsruutimise võimalusi, tuginedes mitte ainult saaja aadressile, vaid ka lähteaadressile ja liidesele, millel pakett vastu võeti.

Reeglid koosnevad tingimustest ja tegevusest:

• Tingimused. Praktiliselt korrake märkide nimekirja, mille järgi pakki FIB-is kontrollitakse, puudu on ainult ToS.
• Tegevus
  • otsing - saatke pakett tabelisse
  • otsing ainult tabelis - lukusta pakett tabelisse, kui marsruuti ei leita, ei lähe pakett põhitabelisse
  • tilk – viska pakk
  • kättesaamatu – visake saatja märguandega pakett ära

FIB-is töödeldakse liiklust kohalikesse protsessidesse reeglitest mööda minnes [IP]->[Route]->[Rules]:

märgistus [IP]->[Firewall]->[Mangle]
Marsruutimissildid võimaldavad teil määrata paketi lüüsi, kasutades peaaegu kõiki tulemüüri tingimusi:

Praktiliselt sellepärast, et kõigil neist pole mõtet ja mõned võivad töötada ebastabiilselt.

Pakendi märgistamiseks on kaks võimalust:

• Kohe panna marsruudimärk
• Pane esikohale ühendusmärk, siis põhineb ühendusmärk panema marsruudimärk

Tulemüüri käsitlevas artiklis kirjutasin, et eelistatav on teine ​​variant. vähendab protsessori koormust, marsruutide märgistamise korral - see pole täiesti tõsi. Need märgistamismeetodid ei ole alati samaväärsed ja neid kasutatakse tavaliselt erinevate probleemide lahendamiseks.

Kasutamise näited

Liigume edasi Policy Base Routingu kasutamise näidete juurde, nende abil on palju lihtsam näidata, miks seda kõike vaja on.

MultiWAN ja väljuv (väljund) liiklus tagasi
Levinud probleem MultiWAN-i konfiguratsiooniga: Mikrotik on Internetist saadaval ainult "aktiivse" pakkuja kaudu.

Ruuterit ei huvita, mis ip-le päring tuli, vastuse genereerimisel otsib ta marsruutimise tabelist marsruuti, kus marsruut läbi isp1 on aktiivne. Lisaks filtreeritakse selline pakett suure tõenäosusega teel adressaadini.

Veel üks huvitav punkt. Kui ether1 liideses on konfigureeritud "lihtne" allika nat: /ip fi nat add out-interface=ether1 action=masquerade pakett läheb võrku src-ga. aadress=10.10.10.100, mis teeb asja veelgi hullemaks.

Probleemi lahendamiseks on mitu võimalust, kuid ükskõik milline neist nõuab täiendavaid marsruutimistabeleid:

/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

Kasutama [IP]->[Route]->[Rules]
Määrake marsruutimistabel, mida kasutatakse määratud allika IP-ga pakettide jaoks.

/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

Võib kasutada action=lookup, kuid kohaliku väljuva liikluse puhul välistab see valik täielikult vale liidese ühendused.

• Süsteem genereerib vastusepaketi koos Src-ga. Aadress: 10.20.20.200
• Marsruutimisotsuse(2) samm kontrollib [IP]->[Routes]->[Rules] ja pakett saadetakse marsruutimistabelisse üle-isp2
• Vastavalt marsruutimistabelile tuleb pakett saata lüüsi 10.20.20.1 liidese ether2 kaudu

See meetod ei nõua töötavat ühenduse jälgijat, erinevalt Mangle tabeli kasutamisest.

Kasutama [IP]->[Firewall]->[Mangle]
Ühendus algab sissetulevast paketist, seega märgime selle (action=mark-connection), määrake märgitud ühendusest väljuvate pakettide jaoks marsruutimise silt (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

Kui ühes liideses on konfigureeritud mitu IP-d, saate tingimusele lisada dst-address et olla kindel.

• Pakett avab ühenduse ether2 liidesel. Pakk läheb sisse [INPUT|Mangle] mis ütleb, et märgi kõik ühenduse paketid kui alates-isp2
• Süsteem genereerib vastusepaketi koos Src-ga. Aadress: 10.20.20.200
• Marsruutimisotsuse(2) etapis saadetakse pakett vastavalt marsruutimistabelile liidese ether10.20.20.1 kaudu lüüsile 1. Saate seda kontrollida, logides sisse paketid [OUTPUT|Filter]
• Laval [OUTPUT|Mangle] ühenduse silt on kontrollitud alates-isp2 ja pakett saab marsruudisildi üle-isp2
• Routing Adjustment(3) samm kontrollib marsruutimise sildi olemasolu ja saadab selle vastavasse marsruutimistabelisse
• Vastavalt marsruutimistabelile tuleb pakett saata lüüsi 10.20.20.1 liidese ether2 kaudu

MultiWAN ja tagastab dst-nat liiklust

Keerulisem näide on see, mida teha, kui privaatses alamvõrgus on ruuteri taga server (näiteks veeb) ja peate võimaldama sellele juurdepääsu mõne pakkuja kaudu.

/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

Probleemi olemus on sama, lahendus sarnaneb Firewall Mangle'i valikuga, kasutatakse ainult teisi ahelaid:

/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 ei näita NAT-i, kuid arvan, et kõik on selge.

MultiWAN ja väljaminevad ühendused

PBR-i võimalusi saate kasutada mitme vpn-ühenduse (näites SSTP) loomiseks erinevatest ruuteriliidestest.

Täiendavad marsruutimistabelid:

/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

Pakendi märgistus:

/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

Lihtsad NAT-reeglid, vastasel juhul lahkub pakett liidesest vale Src-ga. aadress:

/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

Parsimine:

• Ruuter loob kolm SSTP protsessi
• Marsruutimisotsuse (2) etapis valitakse nende protsesside jaoks marsruut põhimarsruutimistabeli alusel. Samalt marsruudilt saab pakett Src. Ether1 liidesega seotud aadress
• В [Output|Mangle] erinevate ühenduste paketid saavad erinevad sildid
• Paketid sisenevad marsruudi kohandamise etapis siltidele vastavatesse tabelitesse ja saavad pakettide saatmiseks uue marsruudi
• Kuid pakettidel on endiselt Src. Aadress eetrist1, laval [Nat|Srcnat] aadress asendatakse vastavalt liidesele

Huvitav on see, et ruuteril näete järgmist ühenduse tabelit:

Connection Tracker töötab varem [Mangle] и [Srcnat], nii et kõik ühendused tulevad samalt aadressilt, kui täpsemalt vaadata, siis sisse Replay Dst. Address pärast NAT-i on aadressid:

VPN-serveris (mul on üks katsestendil) näete, et kõik ühendused pärinevad õigetelt aadressidelt:

Oota teed
On lihtsam viis, saate lihtsalt määrata iga aadressi jaoks konkreetse lüüsi:

/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

Kuid sellised marsruudid ei mõjuta mitte ainult väljuvat, vaid ka transiitliiklust. Lisaks, kui te ei vaja sobimatute sidekanalite läbimiseks liiklust vpn-serverisse, peate lisama veel 6 reeglit [IP]->[Routes]с type=blackhole. Eelmises versioonis - 3 reeglit [IP]->[Route]->[Rules].

Kasutajaühenduste jaotus sidekanalite kaupa

Lihtsad igapäevased ülesanded. Jällegi on vaja täiendavaid marsruutimistabeleid:

/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

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

Kui kasutate action=lookup, siis kui üks kanal on keelatud, läheb liiklus põhitabelisse ja läbib töökanali. Kas see on vajalik või mitte, sõltub ülesandest.

Kasutades sees olevaid märgistusi [IP]->[Firewall]->[Mangle]
Lihtne näide IP-aadresside loenditega. Põhimõtteliselt saab kasutada peaaegu kõiki tingimusi. Ainus kihi 7 hoiatus, isegi kui see on seotud ühenduse siltidega, võib tunduda, et kõik töötab õigesti, kuid osa liiklusest läheb ikkagi valesti.

/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

Saate kasutajad "lukustada" ühte marsruutimistabelisse [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

Kas läbi [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
Lisatingimus dst-address-type=!local on vajalik, et kasutajate liiklus jõuaks ruuteri kohalikesse protsessidesse (dns, winbox, ssh, ...). Kui ruuteriga on ühendatud mitu kohalikku alamvõrku, tuleb tagada, et nendevaheline liiklus ei läheks näiteks Internetti dst-address-table.

Näites kasutades [IP]->[Route]->[Rules] selliseid erandeid pole, kuid liiklus jõuab kohalike protsessideni. Fakt on see, et FIB-i pakendisse sattumine on märgitud [PREROUTING|Mangle] sellel on marsruudi silt ja see läheb muusse marsruutimistabelisse kui peamine, kus puudub kohalik liides. Routing Rules’i puhul kontrollitakse esmalt, kas pakett on mõeldud kohalikule protsessile ja alles User PBR etapis läheb see määratud marsruutimistabelisse.

Kasutamine [IP]->[Firewall]->[Mangle action=route]
See toiming töötab ainult sees [Prerouting|Mangle] ja võimaldab teil suunata liiklust määratud lüüsi ilma täiendavaid marsruutimistabeleid kasutamata, määrates otse lüüsi aadressi:

/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

mõju route on madalama prioriteediga kui marsruutimisreeglid ([IP]->[Route]->[Rules]). Marsruudimärkide puhul oleneb kõik reeglite asukohast, kui reegel koos action=route rohkem väärt kui action=mark-route, siis seda kasutatakse (sõltumata lipust passtrough), vastasel juhul marsruudi tähistamine.
Vikis on selle toimingu kohta väga vähe infot ja kõik järeldused tehakse eksperimentaalselt, igatahes ei leidnud ma võimalusi, kui selle valiku kasutamine annab eeliseid teiste ees.

PPC-põhine dünaamiline tasakaalustamine

Ühenduse klassifikaator - on ECMP paindlikum analoog. Erinevalt ECMP-st jagab see liikluse ühenduste kaupa rangemalt (ECMP ei tea ühendustest midagi, aga marsruudi vahemäluga sidudes saadakse midagi sarnast).

PCC võtab määratud väljad ip-päisest, teisendab need 32-bitiseks väärtuseks ja jagab väärtusega nimetaja. Ülejäänud jaotust võrreldakse täpsustatuga ülejäänud osa ja kui need ühtivad, rakendatakse määratud toiming. Rohkem. Kõlab hullumeelselt, aga töötab.

Näide kolme aadressiga:

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

Näide liikluse dünaamilisest jaotusest src.aadressi järgi kolme kanali vahel:

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

Marsruutide märgistamisel on lisatingimus: in-interface=br-lan, ilma selle all action=mark-routing vastuse liiklus Internetist saab ja suunatakse vastavalt marsruutimistabelitele tagasi teenusepakkujale.

Sidekanalite vahetamine

Check ping on hea tööriist, kuid see kontrollib ainult ühendust lähima IP-kaaslasega, pakkujavõrgud koosnevad tavaliselt suurest hulgast ruuteritest ja väljaspool lähimat partnerit võib tekkida ühenduse katkestus ning siis on tugisideoperaatorid, kes võivad ka Kui teil on probleeme, ei näita kontroll-ping üldiselt alati värsket teavet juurdepääsu kohta globaalsele võrgule.
Kui pakkujatel ja suurettevõtetel on BGP dünaamiline marsruutimisprotokoll, peavad kodu- ja kontorikasutajad iseseisvalt välja mõtlema, kuidas kontrollida Interneti-juurdepääsu konkreetse sidekanali kaudu.

Tavaliselt kasutatakse skripte, mis teatud suhtluskanali kaudu kontrollivad IP-aadressi saadavust Internetis, valides samal ajal midagi usaldusväärset, näiteks google dns: 8.8.8.8. 8.8.4.4. Kuid Mikrotiku kogukonnas on selle jaoks kohandatud huvitavam tööriist.

Paar sõna rekursiivsest marsruutimisest
Rekursiivne marsruutimine on vajalik Multihop BGP peeringu loomisel ja sattus staatilise marsruutimise põhitõdesid käsitlevasse artiklisse ainult tänu kavalatele MikroTiku kasutajatele, kes leidsid, kuidas kasutada kontrolllüüsiga seotud rekursiivseid marsruute sidekanalite vahetamiseks ilma täiendavate skriptideta.

On aeg mõista ulatuse / sihtulatuse valikuid üldiselt ja seda, kuidas marsruut on liidesega seotud:

1. Marsruut otsib liidese paketi saatmiseks selle ulatuse väärtuse ja kõigi põhitabeli kirjete alusel, mille sihtulatuse väärtused on väiksemad või võrdsed
2. Leitud liideste hulgast valitakse see, mille kaudu saate paketi määratud lüüsile saata
3. Leitud ühendatud kirje liides valitakse paketi saatmiseks lüüsi

Rekursiivse marsruudi olemasolul toimub kõik samamoodi, kuid kahes etapis:

• 1-3 Ühendatud marsruutidele lisatakse veel üks marsruut, mille kaudu pääseb määratud lüüsi
• 4-6 Marsruudiga ühendatud marsruudi leidmine "vahepealse" lüüsi jaoks

Kõik manipulatsioonid rekursiivse otsinguga toimuvad RIB-is ja FIB-i edastatakse ainult lõpptulemus: 0.0.0.0/0 via 10.10.10.1 on ether1.

Näide rekursiivse marsruutimise kasutamisest marsruudi vahetamiseks

Konfiguratsioon:

/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

Saate kontrollida, kas paketid saadetakse 10.10.10.1:

Check gateway ei tea rekursiivsest marsruutimisest midagi ja saadab lihtsalt pingid aadressile 8.8.8.8, mis (põhitabeli põhjal) on kättesaadav lüüsi 10.10.10.1 kaudu.

Kui side katkeb ajavahemikus 10.10.10.1 kuni 8.8.8.8, siis marsruut katkestatakse, kuid paketid (sh testpingid) 8.8.8.8-le jätkavad läbimist läbi 10.10.10.1:

Kui link ether1-ga kaob, tekib ebameeldiv olukord, kui paketid enne 8.8.8.8 läbivad teise pakkuja:

See on probleem, kui kasutate NetWatchi skriptide käitamiseks, kui 8.8.8.8 pole saadaval. Kui link katkeb, töötab NetWatch lihtsalt varusidekanali kaudu ja eeldab, et kõik on korras. Lahendatud täiendava filtrimarsruudi lisamisega:

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

Seal on habré artikkel, kus vaadeldakse lähemalt NetWatchi olukorda.

Ja jah, sellise broneeringu kasutamisel ühendatakse aadress 8.8.8.8 ühe pakkujaga, seega pole selle dns-i allikaks valimine hea mõte.

Paar sõna virtuaalse marsruutimise ja edastamise (VRF) kohta

VRF-tehnoloogia on loodud mitme virtuaalse ruuteri loomiseks ühes füüsilises ruuteris, seda tehnoloogiat kasutavad telekommunikatsioonioperaatorid laialdaselt (tavaliselt koos MPLS-iga), et pakkuda L3VPN-teenuseid kattuvate alamvõrguaadressidega klientidele:

Kuid Mikrotiku VRF on korraldatud marsruutimistabelite alusel ja sellel on mitmeid puudusi, näiteks on ruuteri kohalikud IP-aadressid saadaval kõigilt VRF-idelt, saate lugeda rohkem по ссылке.

vrf konfiguratsiooni näide:

/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-ga ühendatud seadmest näeme, et ping läheb ruuteri aadressile teisest vrf-ist (ja see on probleem), samas kui ping ei lähe Internetti:

Internetti pääsemiseks peate registreerima täiendava marsruudi, mis pääseb juurde põhitabelisse (vrf-terminoloogias nimetatakse seda marsruudi lekkimiseks):

/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

Siin on kaks võimalust marsruudi lekkimiseks: marsruutimistabeli kasutamine: 172.17.0.1@main ja kasutades liidese nime: 172.17.0.1%wlan1.

Ja seadistage sissetuleva liikluse märgistus [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 

Sama aadressiga alamvõrgud
Juurdepääsu korraldamine sama aadressiga alamvõrkudele samal ruuteril VRF-i ja võrgukaardi abil:

Põhikonfiguratsioon:

/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

tulemüüri reeglid:

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

Tagasiliikluse suunamise reeglid:

#Указание имени интерфейса тоже может считаться 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 kaudu vastuvõetud marsruutide lisamine antud marsruutimistabelisse
VRF võib olla huvitav, kui peate konkreetsesse marsruutimistabelisse automaatselt lisama dünaamilise marsruudi (näiteks dhcp-kliendist).

Liidese lisamine vrf-ile:

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

Reeglid liikluse (väljuva ja transiidi) saatmiseks läbi tabeli üle-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

Täiendav võlts marsruut väljaminevaks marsruutimiseks tööle:

/interface bridge
add name=bare

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

Seda marsruuti on vaja ainult selleks, et kohalikud väljaminevad paketid saaksid enne marsruutimisotsust (2) läbida [OUTPUT|Mangle] ja hankige marsruutimise silt, kui põhitabelis on ruuteril muid aktiivseid marsruute enne 0.0.0.0/0, pole see vajalik.

Vestlused connected-in и dynamic-in в [Routing] -> [Filters]

Marsruudi filtreerimine (sissetulev ja väljaminev) on tööriist, mida tavaliselt kasutatakse koos dünaamiliste marsruutimisprotokollidega (ja seetõttu on see saadaval ainult pärast paketi installimist Marsruutimine), kuid sissetulevates filtrites on kaks huvitavat ahelat:

• connect-in — ühendatud marsruutide filtreerimine
• dynamic-in – PPP ja DCHP poolt vastuvõetud dünaamiliste marsruutide filtreerimine

Filtreerimine võimaldab teil mitte ainult marsruute kõrvale jätta, vaid ka muuta mitmeid valikuid: kaugus, marsruudimärk, kommentaar, ulatus, sihtulatus, ...

See on väga täpne tööriist ja kui saate midagi teha ilma marsruutimisfiltriteta (aga mitte skriptideta), siis ärge kasutage marsruutimisfiltreid, ärge ajage ennast ja neid, kes pärast teid ruuteri seadistavad. Dünaamilise marsruutimise kontekstis kasutatakse marsruutimisfiltreid palju sagedamini ja produktiivsemalt.

Dünaamiliste marsruutide marsruudimärgi määramine
Näide kodusest ruuterist. Mul on konfigureeritud kaks VPN-ühendust ja nende liiklus peaks olema mähitud vastavalt marsruutimistabelitele. Samal ajal soovin, et liidese aktiveerimisel tekiks marsruudid automaatselt:

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

Ma ei tea, miks, ilmselt viga, aga kui loote ppp-liidese jaoks vrf-i, siis marsruut 0.0.0.0/0-ni jõuab ikkagi põhitabelisse. Muidu oleks kõik veel lihtsam.

Ühendatud marsruutide keelamine
Mõnikord on see vajalik:

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

Silumistööriistad

RouterOS pakub mitmeid tööriistu marsruutimise silumiseks:

• [Tool]->[Tourch] - võimaldab teil vaadata liideste pakette
• /ip route check - võimaldab näha, millisele lüüsile pakett saadetakse, ei tööta marsruutimistabelitega
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - ping ja jälgi, kasutades määratud marsruutimistabelit
• action=log в [IP]->[Firewall] - suurepärane tööriist, mis võimaldab teil jälgida paketi teed mööda paketivoogu, see toiming on saadaval kõigis ahelates ja tabelites

Allikas: www.habr.com