Grunnatriði kyrrstæðrar leiðargerðar í Mikrotik RouterOS

Leiðsögn er ferlið við að finna bestu leiðina til að senda pakka yfir TCP/IP net. Öll tæki sem eru tengd við IPv4 net innihalda ferli og leiðartöflur.

Þessi grein er ekki HOWTO, hún lýsir kyrrstöðu leið í RouterOS með dæmum, ég sleppti vísvitandi restinni af stillingunum (til dæmis srcnat fyrir aðgang að internetinu), svo að skilja efnið krefst ákveðinnar þekkingar á netkerfum og RouterOS.

Skipti og leið

Skipting er ferlið við að skiptast á pökkum innan eins Layer2 hluta (Ethernet, ppp, ...). Ef tækið sér að viðtakandi pakkans er á sama Ethernet undirneti með því, lærir það mac vistfangið með því að nota arp samskiptareglur og sendir pakkann beint, framhjá leiðinni. A ppp (point-to-point) tenging getur aðeins haft tvo þátttakendur og pakkinn er alltaf sendur á eitt netfang 0xff.

Routing er ferlið við að flytja pakka á milli Layer2 hluta. Ef tæki vill senda pakka þar sem viðtakandinn er utan Ethernet-hlutans, skoðar það leiðartöfluna og sendir pakkann til gáttarinnar, sem veit hvert á að senda pakkann næst (eða veit kannski ekki, upprunalega sendanda pakkans veit ekki af þessu).

Auðveldasta leiðin til að hugsa um bein er sem tæki sem er tengt tveimur eða fleiri Layer2 hluta og fær um að senda pakka á milli þeirra með því að ákvarða bestu leiðina úr leiðartöflunni.

Ef þú skilur allt, eða þú vissir það þegar, lestu þá áfram. Að öðru leyti mæli ég eindregið með því að þú kynnir þér lítið, en mjög rúmgott greinar.

Beining í RouterOS og PacketFlow

Næstum öll virkni sem tengist kyrrstöðu leið er í pakkanum kerfið. Plastpoki venja bætir við stuðningi við kraftmikla leiðaralgrím (RIP, OSPF, BGP, MME), leiðarsíur og BFD.

Aðalvalmynd til að setja upp leið: [IP]->[Route]. Flókið kerfi gæti krafist þess að pakkar séu fyrirfram merktir með leiðarmerki í: [IP]->[Firewall]->[Mangle] (keðjur PREROUTING и OUTPUT).

Það eru þrír staðir á PacketFlow þar sem ákvarðanir um IP-pakkaleiðingu eru teknar:

1. Leiðarpakka sem beini tekur við. Á þessu stigi er ákveðið hvort pakkinn fari í staðbundið ferli eða verði sendur áfram á netið. Transit pakkar taka á móti Output Interface
2. Beining staðbundinna útgefinna pakka. Sendandi pakkar taka á móti Output Interface
3. Viðbótarleiðarskref fyrir sendandi pakka, gerir þér kleift að breyta leiðarákvörðuninni í [Output|Mangle]

• Pakkaslóðin í blokkum 1, 2 fer eftir reglum í [IP]->[Route]
• Pakkaslóðin í liðum 1, 2 og 3 fer eftir reglum í [IP]->[Route]->[Rules]
• Hægt er að hafa áhrif á pakkaleiðina í blokkum 1, 3 með því að nota [IP]->[Firewall]->[Mangle]

RIB, FIB, leiðarskyndiminni

Leiðarupplýsingagrunnur
Grunnurinn þar sem leiðum er safnað frá kraftmiklum leiðarreglum, leiðum frá ppp og dhcp, kyrrstæðum og tengdum leiðum. Þessi gagnagrunnur inniheldur allar leiðir, nema þær sem kerfisstjórinn síar.

Skilyrt, við getum gert ráð fyrir því [IP]->[Route] sýnir RIB.

Upplýsingagrunnur framsendingar

Grunnurinn þar sem bestu leiðunum frá RIB er safnað. Allar leiðir í FIB eru virkar og eru notaðar til að framsenda pakka. Ef leiðin verður óvirk (slökkt af stjórnanda (kerfi), eða viðmótið sem pakkann ætti að senda er ekki virkt) er leiðin fjarlægð úr FIB.

Til að taka ákvörðun um leið notar FIB taflan eftirfarandi upplýsingar um IP pakka:

• Heimildarfang
• Heimilisfang
• upprunaviðmót
• Leiðarmerki
• ToS (DSCP)

Að komast inn í FIB pakkann fer í gegnum eftirfarandi stig:

• Er pakkinn ætlaður fyrir staðbundið leiðarferli?
• Er pakkinn háður PBR reglum kerfis eða notenda?
  • Ef já, þá er pakkinn sendur í tilgreinda leiðartöflu
• Pakkinn er sendur á aðalborðið

Skilyrt, við getum gert ráð fyrir því [IP]->[Route Active=yes] sýnir FIB.

Leiðarskyndiminni
Vélbúnaður fyrir skyndiminni leiðar. Beininn man hvert pakkarnir voru sendir og ef þeir eru svipaðir (væntanlega frá sömu tengingu) lætur hann þá fara sömu leiðina, án þess að athuga í FIB. Skyndiminni leiðarinnar er hreinsað reglulega.

Fyrir RouterOS-stjórnendur bjuggu þeir ekki til verkfæri til að skoða og stjórna leiðarskyndiminni, heldur þegar hægt er að slökkva á því í [IP]->[Settings].

Þetta fyrirkomulag var fjarlægt úr Linux 3.6 kjarnanum, en RouterOS notar enn kjarna 3.3.5, kannski er Routing cahce ein af ástæðunum.

Bæta við leiðarglugga

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

1. Undirnet sem þú vilt búa til leið fyrir (sjálfgefið: 0.0.0.0/0)
2. IP gátt eða tengi sem pakkinn verður sendur til (það geta verið nokkrir, sjá ECMP hér að neðan)
3. Athugun á framboði hliðs
4. Tegund upptöku
5. Vegalengd (mæling) fyrir leið
6. Leiðartöflu
7. IP fyrir staðbundna sendandi pakka um þessa leið
8. Tilgangur umfangs og marksviðs er skrifaður í lok greinarinnar.

Leiðarfánar

• X - Leiðin er óvirk af stjórnanda (disabled=yes)
• A - Leiðin er notuð til að senda pakka
• D - Leið bætt við á virkan hátt (BGP, OSPF, RIP, MME, PPP, DHCP, tengd)
• C - Undirnetið er tengt beint við beininn
• S - Static Route
• r,b,o,m - Leið bætt við með einni af kraftmiklu leiðarsamskiptareglunum
• B,U,P - Síunarleið (sleppir pökkum í stað þess að senda)

Hvað á að tilgreina í gáttinni: ip-tölu eða viðmót?

Kerfið gerir þér kleift að tilgreina bæði, á meðan það blótar ekki og gefur ekki vísbendingar ef þú gerðir eitthvað rangt.

IP-tölu
Heimilisfang gáttarinnar verður að vera aðgengilegt yfir Layer2. Fyrir Ethernet þýðir þetta að beininn verður að hafa heimilisfang frá sama undirneti á einu af virku ip viðmótunum, fyrir ppp, að gáttarvistfangið sé tilgreint á einu af virku viðmótunum sem undirnetfang.
Ef aðgengisskilyrði fyrir Layer2 eru ekki uppfyllt telst leiðin óvirk og fellur ekki undir FIB.

tengi
Allt er flóknara og hegðun leiðarinnar fer eftir gerð viðmótsins:

• PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) tenging gerir ráð fyrir aðeins tveimur þátttakendum og pakkinn verður alltaf sendur í gátt til sendingar, ef gáttin skynjar að viðtakandinn er hann sjálfur, þá mun hann flytja pakkann til staðbundið ferli þess.
  
• Ethernet gerir ráð fyrir viðveru margra þátttakenda og mun senda beiðnir til arp viðmótsins með heimilisfangi viðtakanda pakkans, þetta er gert ráð fyrir og alveg eðlileg hegðun fyrir tengdar leiðir.
  En þegar þú reynir að nota viðmótið sem leið fyrir ytra undirnet færðu eftirfarandi aðstæður: leiðin er virk, ping að gáttinni fer, en nær ekki til viðtakanda frá tilgreindu undirneti. Ef þú horfir á viðmótið í gegnum sniffer muntu sjá arp beiðnir með vistföngum frá ytra undirneti.
  

Reyndu að tilgreina ip-tölu sem gátt þegar mögulegt er. Undantekningin eru tengdar leiðir (búnar til sjálfkrafa) og PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*) tengi.

OpenVPN inniheldur ekki PPP haus, en þú getur notað OpenVPN viðmótsheitið til að búa til leið.

Nánari leið

Grunnleiðarregla. Leiðin sem lýsir minna undirnetinu (með stærstu undirnetmaskanum) hefur forgang í leiðarákvörðun pakkans. Staða færslna í leiðartöflunni skiptir ekki máli fyrir valið - aðalreglan er nákvæmari.

Allar leiðir frá tilgreindu kerfi eru virkar (staðsettar í FIB). benda á mismunandi undirnet og stangast ekki á við hvert annað.

Ef ein af gáttunum verður ekki tiltæk, verður tengd leið talin óvirk (fjarlægð úr FIB) og pökkum verður leitað frá þeim leiðum sem eftir eru.

Leiðin með undirneti 0.0.0.0/0 er stundum gefin sérstök merking og er kölluð „Sjálfgefin leið“ eða „Gátt til þrautavara“. Reyndar er ekkert töfrandi við það og það inniheldur einfaldlega öll möguleg IPv4 vistföng, en þessi nöfn lýsa verkefni þess vel - það gefur til kynna gáttina hvert á að framsenda pakka sem engar aðrar, nákvæmari leiðir eru til.

Hámarks möguleg undirnetmaska ​​fyrir IPv4 er /32, þessi leið bendir á tiltekinn hýsil og hægt er að nota hana í leiðartöflunni.

Að skilja nákvæmari leið er grundvallaratriði fyrir hvaða TCP/IP tæki sem er.

Fjarlægð

Vegalengdir (eða mæligildi) eru nauðsynlegar fyrir stjórnunarsíun á leiðum í eitt undirnet sem er aðgengilegt í gegnum margar gáttir. Leið með lægri mæligildi er talin forgangsverkefni og verður innifalin í FIB. Ef leið með lægri mæligildi hættir að vera virk, þá verður henni skipt út fyrir leið með hærri mæligildi í FIB.

Ef það eru nokkrar leiðir á sama undirnetið með sömu mæligildi, bætir beininn aðeins einni þeirra við FIB töfluna, með innri rökfræði að leiðarljósi.

Mælingin getur tekið gildi frá 0 til 255:

• 0 - Mæling fyrir tengdar leiðir. Fjarlægð 0 er ekki hægt að stilla af stjórnanda
• 1-254 - Mælingar í boði fyrir stjórnanda til að stilla leiðir. Mælingar með lægra gildi hafa meiri forgang
• 255 - Mæling í boði fyrir stjórnanda til að stilla leiðir. Ólíkt 1-254 er leið með mæligildi 255 alltaf óvirk og fellur ekki undir FIB
• sérstakar mælikvarðar. Leiðir fengnar úr kraftmiklum leiðarreglum hafa staðlað mæligildi

athuga hlið

Athugaðu gátt er MikroTik RoutesOS viðbót til að athuga hvort gáttin sé tiltæk í gegnum icmp eða arp. Einu sinni á 10 sekúndna fresti (ekki hægt að breyta) er beiðni send til gáttarinnar, ef svarið berst ekki tvisvar, telst leiðin ófær og er fjarlægð úr FIB. Ef athugunargátt hefur verið óvirkt heldur athugunarleiðin áfram og leiðin verður virk aftur eftir eina árangursríka athugun.

Athugaðu gátt slekkur á færslunni sem hún er stillt í og ​​allar aðrar færslur (í öllum leiðartöflum og ecmp leiðum) með tilgreindri gátt.

Almennt séð virkar gáttin vel svo lengi sem engin vandamál eru með pakkatap í gáttina. Athuga gátt veit ekki hvað er að gerast með samskipti utan tékkaðrar gáttar, þetta krefst viðbótarverkfæra: forskriftir, endurkvæma leið, kraftmikla leiðarsamskiptareglur.

Flestar VPN- og göngsamskiptareglur innihalda innbyggð verkfæri til að athuga tengingarvirkni, sem gerir athugunargátt fyrir þær kleift er auka (en mjög lítið) álag á netið og afköst tækisins.

ECMP leiðir

Equal-Cost Multi-Path - senda pakka til viðtakandans með því að nota nokkrar gáttir samtímis með því að nota Round Robin reikniritið.

ECMP leiðin er búin til af stjórnanda með því að tilgreina margar gáttir fyrir sama undirnetið (eða sjálfkrafa, ef það eru tvær jafngildar OSPF leiðir).

ECMP er notað fyrir álagsjafnvægi milli tveggja rása, í orði, ef það eru tvær rásir í ecmp leiðinni, þá ætti útleiðandi rás að vera öðruvísi fyrir hvern pakka. En Routing skyndiminni vélbúnaðurinn sendir pakka frá tengingunni eftir leiðinni sem fyrsti pakkinn tók, þar af leiðandi fáum við eins konar jafnvægi byggt á tengingum (hleðslujafnvægi á hverja tengingu).

Ef þú slekkur á Routing Cache, þá verður pökkunum í ECMP leiðinni deilt rétt, en það er vandamál með NAT. NAT reglan vinnur aðeins úr fyrsta pakkanum úr tengingunni (afgangurinn er unnin sjálfkrafa), og það kemur í ljós að pakkar með sama upprunavistfang skilja eftir mismunandi viðmót.

Athugaðu að gátt virkar ekki í ECMP leiðum (RouterOS galla). En þú getur komist í kringum þessa takmörkun með því að búa til viðbótar staðfestingarleiðir sem slökkva á færslum í ECMP.

Sía með leið

Tegund valkosturinn ákvarðar hvað á að gera við pakkann:

• unicast - sendu í tilgreinda gátt (viðmót)
• svarthol - fargaðu pakka
• banna, óaðgengilegt - fargaðu pakkanum og sendu icmp skilaboð til sendanda

Síun er venjulega notuð þegar það þarf að tryggja sendingu pakka í ranga átt, auðvitað er hægt að sía þetta í gegnum eldvegginn.

Nokkur dæmi

Til að treysta grunnatriðin um leiðsögn.

Dæmigerður heimabeini

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

1. Statísk leið til 0.0.0.0/0 (sjálfgefin leið)
2. Tengd leið á viðmóti við þjónustuveituna
3. Tengd leið á LAN tengi

Dæmigerður heimabeini með PPPoE

1. Statísk leið á sjálfgefna leið, bætt sjálfkrafa við. það er tilgreint í tengieiginleikum
2. Tengd leið fyrir PPP tengingu
3. Tengd leið á LAN tengi

Dæmigerður heimabeini með tveimur veitum og offramboði

/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. Statísk leið að sjálfgefna leið í gegnum fyrstu þjónustuveituna með mæligildi 1 og gáttathugun
2. Statísk leið að sjálfgefna leið í gegnum aðra þjónustuaðila með mæligildi 2
3. Tengdar leiðir

Umferð í 0.0.0.0/0 fer í gegnum 10.10.10.1 á meðan þessi gátt er tiltæk, annars skiptir hún yfir í 10.20.20.1

Slíkt kerfi getur talist rásfyrirvara, en það er ekki án galla. Ef hlé á sér stað fyrir utan gátt þjónustuveitunnar (til dæmis innan netkerfis símafyrirtækisins) mun beininn þinn ekki vita af því og mun halda áfram að líta á leiðina sem virka.

Dæmigerður heimabeini með tveimur veitendum, offramboði og 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. Statískar leiðir til að athuga chack gátt
2. ECMP leið
3. Tengdar leiðir

Leiðir til að athuga eru bláar (litur óvirkra leiða), en þetta truflar ekki eftirlitsgáttina. Núverandi útgáfa (6.44) af RoS gefur ECMP leiðinni sjálfkrafa forgang, en það er betra að bæta prófunarleiðum við aðrar leiðartöflur (valkostur routing-mark)

Á Speedtest og öðrum sambærilegum síðum verður engin hraðaaukning (ECMP skiptir umferð eftir tengingum, ekki eftir pökkum), en p2p forrit ættu að hlaðast niður hraðar.

Sía í gegnum leið

/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. Statísk leið í sjálfgefna leið
2. Statísk leið til 192.168.200.0/24 yfir ipip göng
3. Banna fasta leið til 192.168.200.0/24 í gegnum ISP bein

Síuvalkostur þar sem umferð um jarðgöng fer ekki á beini þjónustuveitunnar þegar slökkt er á ipip viðmótinu. Slíkar áætlanir eru sjaldan nauðsynlegar, vegna þess. þú getur útfært blokkun í gegnum eldvegginn.

Leiðarlykja
Leiðarlykkja - ástand þegar pakki keyrir á milli beina áður en ttl rennur út. Venjulega er það afleiðing af stillingarvillu, í stórum netum er það meðhöndlað með innleiðingu á kraftmiklum leiðarsamskiptareglum, í litlum - með varúð.

Það lítur eitthvað svona út:

Dæmi (einfaldast) um hvernig á að fá svipaða niðurstöðu:

Dæmið um leiðarlykkju er ekkert hagnýtt, en það sýnir að beinar hafa ekki hugmynd um leiðartöflu nágranna síns.

Stefnumótun og viðbótarleiðartöflur

Þegar leið er valin notar beininn aðeins einn reit úr pakkahausnum (Dst. Address) - þetta er grunnleið. Leiding byggð á öðrum skilyrðum, svo sem heimilisfangi uppruna, gerð umferðar (ToS), jafnvægi án ECMP, tilheyrir Policy Base Routing (PBR) og notar viðbótarleiðartöflur.

Nánari leið er aðal leiðarvalsreglan innan leiðartöflunnar.

Sjálfgefið er að öllum leiðarreglum er bætt við aðaltöfluna. Kerfisstjórinn getur búið til handahófskenndan fjölda af leiðartöflum til viðbótar og leiðarpakka til þeirra. Reglur í mismunandi töflum stangast ekki á. Ef pakkinn finnur ekki viðeigandi reglu í tilgreindri töflu fer hann í aðaltöfluna.

Dæmi um dreifingu í gegnum eldvegg:

• 192.168.100.10 -> 8.8.8.8
  1. Umferð frá 192.168.100.10 verður merkt gegnum-isp1 в [Prerouting|Mangle]
  2. Á leiðarstiginu í töflunni gegnum-isp1 leitar að leið til 8.8.8.8
  3. Leið fannst, umferð er send á gátt 10.10.10.1
• 192.168.200.20 -> 8.8.8.8
  1. Umferð frá 192.168.200.20 verður merkt gegnum-isp2 в [Prerouting|Mangle]
  2. Á leiðarstiginu í töflunni gegnum-isp2 leitar að leið til 8.8.8.8
  3. Leið fannst, umferð er send á gátt 10.20.20.1
• Ef ein af gáttunum (10.10.10.1 eða 10.20.20.1) verður ekki tiltæk, þá fer pakkinn á borðið helstu og mun leita hentuga leiðar þangað

Orðafræðimál

RouterOS hefur ákveðin hugtakavandamál.
Þegar unnið er með reglur í [IP]->[Routes] leiðartaflan er sýnd, þó að það sé skrifað að merkimiðinn:

В [IP]->[Routes]->[Rule] allt er rétt, í ástandi merkimiða í töfluaðgerðinni:

Hvernig á að senda pakka í tiltekna leiðartöflu

RouterOS býður upp á nokkur verkfæri:

• Reglur í [IP]->[Routes]->[Rules]
• Leiðarmerki (action=mark-routing) í [IP]->[Firewall]->[Mangle]
• VRF

reglugerðir [IP]->[Route]->[Rules]
Reglur eru unnar í röð, ef pakkinn passar við skilyrði reglunnar fer hann ekki lengra.

Leiðarreglur gera þér kleift að auka möguleika á leiðsögn, ekki aðeins að treysta á heimilisfang viðtakanda, heldur einnig á uppruna heimilisfangi og viðmóti sem pakkinn var móttekinn á.

Reglur samanstanda af skilyrðum og aðgerð:

• Skilyrði. Endurtaktu nánast listann yfir skilti sem pakkinn er athugaður með í FIB, aðeins ToS vantar.
• Afþreying
  • leit - sendu pakka í borð
  • flettu aðeins í töflu - læstu pakkanum í töflunni, ef leiðin finnst ekki fer pakkinn ekki í aðaltöfluna
  • slepptu - slepptu pakka
  • óaðgengilegt - fargaðu pakkanum með sendandatilkynningu

Í FIB er umferð til staðbundinna ferla unnin framhjá reglum [IP]->[Route]->[Rules]:

merkingar [IP]->[Firewall]->[Mangle]
Leiðarmerki gerir þér kleift að stilla gátt fyrir pakka með því að nota næstum hvaða eldveggsskilyrði sem er:

Nánast vegna þess að þau eru ekki öll skynsamleg og sum geta virkað óstöðug.

Það eru tvær leiðir til að merkja pakka:

• Settu strax leiðarmerki
• Settu fyrst tengi-merki, þá byggt á tengi-merki að setja leiðarmerki

Í grein um eldveggi skrifaði ég að seinni kosturinn væri æskilegur. dregur úr álagi á örgjörva, þegar um er að ræða merkingar á leiðum - þetta er ekki alveg satt. Þessar merkingaraðferðir eru ekki alltaf jafngildar og eru venjulega notaðar til að leysa ýmis vandamál.

Dæmi um notkun

Við skulum halda áfram að dæmunum um að nota Policy Base Routing, þau eru miklu auðveldara að sýna hvers vegna allt þetta er þörf.

MultiWAN og skila útleið (Output) umferð
Algengt vandamál með MultiWAN uppsetningu: Mikrotik er aðeins fáanlegt af internetinu í gegnum „virka“ þjónustuaðila.

Beini er sama hvaða ip beiðnin kom til, þegar svar er búið til mun hann leita að leið í leiðartöflunni þar sem leiðin í gegnum isp1 er virk. Ennfremur mun slíkur pakki líklegast vera síaður á leiðinni til viðtakandans.

Annar áhugaverður punktur. Ef "einfalt" source nat er stillt á ether1 viðmótinu: /ip fi nat add out-interface=ether1 action=masquerade pakkinn fer á netið með src. address=10.10.10.100, sem gerir hlutina enn verri.

Það eru nokkrar leiðir til að laga vandamálið, en hver þeirra mun krefjast viðbótar leiðartöflu:

/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

Nota [IP]->[Route]->[Rules]
Tilgreindu leiðartöfluna sem verður notuð fyrir pakka með tilgreindri uppruna 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

Getur notað action=lookup, en fyrir staðbundna útsendu umferð útilokar þessi valkostur algjörlega tengingar frá röngu viðmóti.

• Kerfið býr til svarpakka með Src. Heimilisfang: 10.20.20.200
• Leiðarákvörðun(2) skref athuganir [IP]->[Routes]->[Rules] og pakkinn er sendur á leiðartöfluna yfir-isp2
• Samkvæmt leiðartöflunni verður að senda pakkann í gáttina 10.20.20.1 í gegnum ether2 viðmótið

Þessi aðferð krefst ekki virks Connection Tracker, ólíkt því að nota Mangle töfluna.

Nota [IP]->[Firewall]->[Mangle]
Tengingin byrjar með pakka sem kemur inn, þannig að við merkjum hann (action=mark-connection), fyrir sendandi pakka frá merktri tengingu, stilltu leiðarmerkið (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

Ef nokkrir IP-tölvur eru stilltir á einu viðmóti geturðu bætt við ástandið dst-address til að vera viss.

• Pakki opnar tenginguna á ether2 tengi. Pakkinn fer inn [INPUT|Mangle] sem segir að merkja alla pakka úr tengingunni sem frá-isp2
• Kerfið býr til svarpakka með Src. Heimilisfang: 10.20.20.200
• Á stigi leiðarákvörðunar(2) er pakkinn, í samræmi við leiðartöfluna, sendur í gáttina 10.20.20.1 í gegnum ether1 viðmótið. Þú getur staðfest þetta með því að skrá pakkana inn [OUTPUT|Filter]
• Á sviðinu [OUTPUT|Mangle] tengimerki er athugað frá-isp2 og pakkinn fær leiðarmerki yfir-isp2
• Leiðaraðlögun(3) skrefið athugar hvort leiðarmerki sé til staðar og sendir það í viðeigandi leiðartöflu
• Samkvæmt leiðartöflunni verður að senda pakkann í gáttina 10.20.20.1 í gegnum ether2 viðmótið

MultiWAN og skila dst-nat umferð

Dæmi er flóknara, hvað á að gera ef það er netþjónn (til dæmis vefur) á bakvið beininn á einka undirneti og þú þarft að veita aðgang að honum í gegnum einhverja þjónustuveituna.

/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

Kjarni vandans verður sá sami, lausnin er svipuð og Firewall Mangle valkosturinn, aðeins aðrar keðjur verða notaðar:

/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

Skýringarmyndin sýnir ekki NAT, en ég held að allt sé skýrt.

MultiWAN og útleið tengingar

Þú getur notað PBR getu til að búa til margar vpn (SSTP í dæminu) tengingar frá mismunandi leiðarviðmótum.

Viðbótarleiðartöflur:

/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

Pakkningamerki:

/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

Einfaldar NAT reglur, annars mun pakkinn yfirgefa viðmótið með röngum Src. heimilisfang:

/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

Ritun:

• Beininn býr til þrjú SSTP ferli
• Á stigi leiðarákvörðunar (2) er leið valin fyrir þessa ferla byggða á aðalleiðartöflunni. Frá sömu leið fær pakkinn Src. Heimilisfang bundið við ether1 tengi
• В [Output|Mangle] pakkar frá mismunandi tengingum fá mismunandi merki
• Pakkar fara inn í töflurnar sem samsvara merkingunum á leiðréttingarstigi og fá nýja leið til að senda pakka
• En pakkar hafa enn Src. Ávarp frá ether1, á sviðinu [Nat|Srcnat] heimilisfanginu er skipt út í samræmi við viðmótið

Athyglisvert er að á leiðinni muntu sjá eftirfarandi tengitöflu:

Connection Tracker virkar fyrr [Mangle] и [Srcnat], þannig að allar tengingar koma frá sama heimilisfangi, ef þú skoðar nánar, þá inn Replay Dst. Address það verða heimilisföng eftir NAT:

Á VPN netþjóninum (ég er með einn á prófunarbekknum) geturðu séð að allar tengingar koma frá réttum netföngum:

Bíddu einhvern veginn
Það er auðveldari leið, þú getur einfaldlega tilgreint ákveðna gátt fyrir hvert heimilisföng:

/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

En slíkar leiðir munu ekki aðeins hafa áhrif á útleið heldur einnig flutningaumferð. Auk þess, ef þú þarft ekki umferð á vpn netþjóninn til að fara í gegnum óviðeigandi samskiptaleiðir, þá verður þú að bæta við 6 reglum í viðbót við [IP]->[Routes]с type=blackhole. Í fyrri útgáfu - 3 reglur í [IP]->[Route]->[Rules].

Dreifing notendatenginga eftir samskiptaleiðum

Einföld, hversdagsleg verkefni. Aftur verður þörf á frekari leiðartöflum:

/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

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

Ef notkun action=lookup, þá þegar ein af rásunum er óvirk, mun umferðin fara í aðalborðið og fara í gegnum vinnurásina. Hvort þetta er nauðsynlegt eða ekki fer eftir verkefninu.

Notaðu merkingarnar í [IP]->[Firewall]->[Mangle]
Einfalt dæmi með listum yfir ip tölur. Í grundvallaratriðum er hægt að nota nánast hvaða skilyrði sem er. Eini fyrirvarinn við lag7, jafnvel þegar það er parað með tengimerkjum, kann að virðast sem allt virki rétt, en hluti af umferðinni mun samt fara á rangan hátt.

/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

Þú getur „læst“ notendum í einni leiðartöflu í gegn [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

Annað hvort í gegn [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 atvinnumaður dst-address-type=!local
Viðbótarskilyrði dst-address-type=!local það er nauðsynlegt að umferð frá notendum nái til staðbundinna ferla leiðarinnar (dns, winbox, ssh, ...). Ef nokkur staðbundin undirnet eru tengd við beininn er nauðsynlegt að tryggja að umferðin á milli þeirra fari ekki á internetið, td með því að nota dst-address-table.

Í dæminu með því að nota [IP]->[Route]->[Rules] það eru engar slíkar undantekningar, en umferð nær staðbundnum ferlum. Staðreyndin er sú að komast inn í FIB pakkann merktur inn [PREROUTING|Mangle] er með leiðarmerki og fer inn í aðra leiðartöflu en aðal, þar sem ekki er staðbundið viðmót. Þegar um leiðarreglur er að ræða er fyrst athugað hvort pakkinn sé ætlaður fyrir staðbundið ferli og aðeins á notanda PBR stigi fer hann í tilgreinda leiðartöflu.

Notkun [IP]->[Firewall]->[Mangle action=route]
Þessi aðgerð virkar aðeins í [Prerouting|Mangle] og gerir þér kleift að beina umferð að tilgreindu gáttinni án þess að nota frekari leiðartöflur, með því að tilgreina gáttarvistfangið beint:

/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

áhrif route hefur lægri forgang en leiðarreglur ([IP]->[Route]->[Rules]). Þegar um leiðarmerki er að ræða fer allt eftir afstöðu reglna, ef reglan með action=route meira virði en action=mark-route, þá verður það notað (óháð fánanum passtrough), annars merkja leiðina.
Það eru mjög litlar upplýsingar á wiki um þessa aðgerð og allar ályktanir eru fengnar í tilraunaskyni, í öllum tilvikum, ég fann ekki valkosti þegar þessi valkostur er notaður gefur kost á öðrum.

PPC byggt kraftmikið jafnvægi

Per Connection Classifier - er sveigjanlegri hliðstæða ECMP. Ólíkt ECMP deilir það umferð eftir tengingum strangari (ECMP veit ekkert um tengingar, en þegar það er parað við Routing Cache fæst eitthvað svipað).

PCC tekur tilgreindum reitum úr ip hausnum, breytir þeim í 32 bita gildi og deilir með nefnara. Það sem eftir er af skiptingunni er borið saman við tilgreinda afganginn og ef þau passa saman, þá er tilgreind aðgerð beitt. meira. Hljómar klikkað, en það virkar.

Dæmi með þremur heimilisföngum:

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

Dæmi um kraftmikla dreifingu umferðar eftir src.address milli þriggja rása:

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

Við merkingu leiða er viðbótarskilyrði: in-interface=br-lan, án þess að vera undir action=mark-routing svarumferð frá internetinu mun fá og, í samræmi við leiðartöflur, mun fara aftur til þjónustuveitunnar.

Skipt um samskiptaleiðir

Athugaðu ping er gott tól, en það athugar aðeins tenginguna við næsta IP jafningja, net veitenda samanstanda venjulega af miklum fjölda beina og sambandsrof getur átt sér stað utan næsta jafningja, og svo eru það fjarskiptafyrirtæki sem geta líka hafa vandamál, almennt athuga ping sýnir ekki alltaf uppfærðar upplýsingar um aðgang að alþjóðlegu neti.
Ef veitendur og stór fyrirtæki hafa BGP dynamic routing samskiptareglur, þá verða heimilis- og skrifstofunotendur sjálfstætt að finna út hvernig á að athuga internetaðgang í gegnum tiltekna samskiptarás.

Venjulega eru forskriftir notaðar sem, í gegnum ákveðna samskiptaleið, athuga hvort ip-tölu sé tiltæk á netinu, en velja eitthvað áreiðanlegt, til dæmis, google dns: 8.8.8.8. 8.8.4.4. En í Mikrotik samfélaginu hefur áhugaverðara tæki verið aðlagað fyrir þetta.

Nokkur orð um endurkvæma leið
Endurkvæm leið er nauðsynleg þegar Multihop BGP jafningi er byggt og kom inn í greinina um grunnatriði kyrrstæða leiðar eingöngu vegna slægra MikroTik notenda sem komust að því hvernig ætti að nota endurkvæmar leiðir pöraðar við athuga gátt til að skipta um samskiptarás án viðbótarforskrifta.

Það er kominn tími til að skilja umfang/marksviðsvalkosti almennt og hvernig leiðin er bundin við viðmótið:

1. Leiðin flettir upp viðmóti til að senda pakkann út frá umfangsgildi hans og öllum færslum í aðaltöflunni með minna en eða jöfn markumfangsgildi
2. Úr viðmótunum sem fundust er sá valinn sem þú getur sent pakka í gegnum til tilgreindrar gáttar
3. Viðmót tengdrar færslu sem fannst er valið til að senda pakkann í gáttina

Í viðurvist endurkvæmrar leiðar gerist allt eins, en í tveimur áföngum:

• 1-3 Enn er einni leið bætt við tengdu leiðirnar, þar sem hægt er að ná tilgreindri hlið
• 4-6 Að finna leiðartengda leið fyrir „milligöngu“

Allar meðferðir með endurkvæmri leit eiga sér stað í RIB og aðeins lokaniðurstaðan er flutt yfir á FIB: 0.0.0.0/0 via 10.10.10.1 on ether1.

Dæmi um að nota endurkvæma leið til að skipta um leið

Stillingar:

/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

Þú getur athugað að pakkar verði sendir til 10.10.10.1:

Athugaðu gátt veit ekkert um endurkvæma leið og sendir einfaldlega ping til 8.8.8.8, sem (miðað við aðaltöfluna) er aðgengileg í gegnum gátt 10.10.10.1.

Ef samskiptatap verður á milli 10.10.10.1 og 8.8.8.8, þá er leiðin aftengd, en pakkar (þar á meðal prófunarpingar) til 8.8.8.8 halda áfram að fara í gegnum 10.10.10.1:

Ef hlekkurinn á ether1 glatast, þá koma óþægilegar aðstæður upp þegar pakkar fyrir 8.8.8.8 fara í gegnum seinni þjónustuveituna:

Þetta er vandamál ef þú ert að nota NetWatch til að keyra forskriftir þegar 8.8.8.8 er ekki tiltækt. Ef hlekkurinn er rofinn mun NetWatch einfaldlega vinna í gegnum öryggisafritsamskiptarásina og gera ráð fyrir að allt sé í lagi. Leyst með því að bæta við viðbótar síuleið:

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

Það er á habré grein, þar sem ástandið með NetWatch er skoðað nánar.

Og já, þegar þú notar slíka fyrirvara verður netfangið 8.8.8.8 tengt við einn af veitendum, þannig að það er ekki góð hugmynd að velja það sem dns uppspretta.

Nokkur orð um sýndarleið og framsendingu (VRF)

VRF tækni er hönnuð til að búa til nokkra sýndarbeini innan eins líkamlegs beins, þessi tækni er mikið notuð af fjarskiptafyrirtækjum (venjulega í tengslum við MPLS) til að veita L3VPN þjónustu til viðskiptavina með undirnetföng sem skarast:

En VRF í Mikrotik er skipulagt út frá leiðartöflum og hefur ýmsa ókosti, til dæmis eru staðbundnar ip tölur beinisins fáanlegar frá öllum VRF, þú getur lesið meira по ссылке.

vrf stillingar dæmi:

/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

Frá tækinu sem er tengt við ether2 sjáum við að ping fer á netfangið frá öðrum vrf (og þetta er vandamál), á meðan ping fer ekki á internetið:

Til að komast á internetið þarftu að skrá viðbótarleið sem opnar aðaltöfluna (í vrf hugtökum er þetta kallað leið leki):

/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

Hér eru tvær leiðir til að leiða leka: með því að nota leiðartöfluna: 172.17.0.1@main og nota tengiheiti: 172.17.0.1%wlan1.

Og settu upp merkingar fyrir umferð til baka inn [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 

Undirnet með sama heimilisfangi
Skipulag aðgangs að undirnetum með sömu vistföng á sama beini með VRF og netkorti:

Grunnstilling:

/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

eldveggsreglur:

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

Leiðarreglur fyrir umferð til baka:

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

Bætir leiðum sem berast um dhcp við tiltekna leiðartöflu
VRF getur verið áhugavert ef þú þarft sjálfkrafa að bæta kraftmikilli leið (til dæmis frá dhcp biðlara) við ákveðna leiðartöflu.

Bætir viðmóti við vrf:

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

Reglur um að senda umferð (á útleið og flutning) í gegnum töfluna yfir-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

Viðbótar, fölsuð leið fyrir útleið til vinnu:

/interface bridge
add name=bare

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

Þessi leið er aðeins nauðsynleg til þess að staðbundnir pakkar sem fara út geti farið í gegnum leiðarákvörðunina (2) áður [OUTPUT|Mangle] og fáðu leiðarmerkið, ef það eru aðrar virkar leiðir á leiðinni fyrir 0.0.0.0/0 í aðaltöflunni, þá er það ekki krafist.

Keðjur connected-in и dynamic-in в [Routing] -> [Filters]

Leiðarsíun (á heimleið og útleið) er tól sem er venjulega notað í tengslum við kraftmikla leiðarsamskiptareglur (og því aðeins fáanlegt eftir að pakkinn hefur verið settur upp venja), en það eru tvær áhugaverðar keðjur í síunum sem koma inn:

• tengdur - síar tengdar leiðir
• dynamic-in - síun á kraftmiklum leiðum sem PPP og DCHP berast

Sía gerir þér ekki aðeins kleift að henda leiðum, heldur einnig að breyta fjölda valkosta: fjarlægð, leiðarmerki, athugasemd, umfang, marksvigrúm, ...

Þetta er mjög nákvæmt tól og ef þú getur gert eitthvað án Routing Filters (en ekki scripts), þá skaltu ekki nota Routing Filters, ekki rugla sjálfum þér og þeim sem munu stilla routerinn eftir þig. Í samhengi við kraftmikla leiðsögn verða leiðarsíur notaðar mun oftar og afkastameiri.

Stilling leiðarmerkis fyrir kvikar leiðir
Dæmi úr heimabeini. Ég er með tvær VPN-tengingar stilltar og umferðin í þeim ætti að vera í samræmi við leiðartöflurnar. Á sama tíma vil ég að leiðirnar verði búnar til sjálfkrafa þegar viðmótið er virkjað:

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

Ég veit ekki hvers vegna, líklega villa, en ef þú býrð til vrf fyrir ppp viðmótið, þá mun leiðin til 0.0.0.0/0 samt komast inn í aðaltöfluna. Annars væri allt enn auðveldara.

Slökkva á tengdum leiðum
Stundum þarf þetta:

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

Villuleitartæki

RouterOS býður upp á fjölda verkfæra til að kemba leið:

• [Tool]->[Tourch] - gerir þér kleift að skoða pakka á viðmótum
• /ip route check - gerir þér kleift að sjá í hvaða gátt pakkinn verður sendur, virkar ekki með leiðartöflum
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - ping og rekja með því að nota tilgreinda leiðartöflu
• action=log в [IP]->[Firewall] - frábært tól sem gerir þér kleift að rekja slóð pakka meðfram pakkaflæðinu, þessi aðgerð er fáanleg í öllum keðjum og töflum

Heimild: www.habr.com