Bazoj de Statika Vokado en Mikrotik RouterOS

Envojigo estas la procezo trovi la plej bonan vojon por transdoni pakaĵojn tra TCP/IP-retoj. Ajna aparato konektita al IPv4 reto enhavas procezon kaj vojtabulojn.

Ĉi tiu artikolo ne estas HOWTO, ĝi priskribas statikan vojigon en RouterOS kun ekzemploj, mi intence preterlasis la ceterajn agordojn (ekzemple, srcnat por aliro al Interreto), do kompreni la materialon postulas certan nivelon de scio pri retoj kaj RouterOS.

Ŝanĝado kaj vojigo

Ŝanĝi estas la procezo de interŝanĝado de pakaĵetoj ene de unu Layer2-segmento (Ethernet, ppp, ...). Se la aparato vidas, ke la ricevanto de la pako estas sur la sama Eterreto-subreto kun ĝi, ĝi lernas la mac-adreson uzante la arp-protokolon kaj transdonas la pakaĵon rekte, preterirante la enkursigilon. Ppp (punkto-al-punkta) konekto povas havi nur du partoprenantojn kaj la pakaĵeto estas ĉiam sendita al unu adreso 0xff.

Envojigo estas la procezo de translokado de pakaĵoj inter Layer2-segmentoj. Se aparato volas sendi pakaĵeton kies ricevanto estas ekster la Eterreto-segmento, ĝi rigardas en sian vojigtabelon kaj pasas la pakaĵeton al enirejo kiu scias kie sendi la pakaĵeton poste (aŭ eble ne scias, la origina sendinto de la pako estas ne konscias pri tio).

La plej facila maniero pensi pri enkursigilo estas kiel aparato ligita al du aŭ pli da Layer2-segmentoj kaj kapabla pasi pakaĵetojn inter ili determinante la plej bonan itineron de la vojtabelo.

Se vi komprenas ĉion, aŭ vi jam sciis ĝin, tiam legu plu. Por la cetero, mi forte rekomendas, ke vi familiariĝu kun malgranda, sed tre ampleksa artikoloj.

Vokado en RouterOS kaj PacketFlow

Preskaŭ ĉiuj funkcioj rilataj al senmova enrutado estas en la pakaĵo sistemo. Plasta sako enirado aldonas subtenon por dinamikaj vojaj algoritmoj (RIP, OSPF, BGP, MME), Routing Filters kaj BFD.

Ĉefa menuo por agordi vojigon: [IP]->[Route]. Kompleksaj kabaloj povas postuli pakaĵetojn esti antaŭ-etikeditaj kun vojmarko en: [IP]->[Firewall]->[Mangle] (ĉenoj PREROUTING и OUTPUT).

Estas tri lokoj sur PacketFlow, kie decidoj pri IP-pakaĵeto estas faritaj:

1. Envojigo de pakoj ricevitaj de la enkursigilo. En ĉi tiu etapo, estas decidite ĉu la pako iros al la loka procezo aŭ estos sendita plu al la reto. Transito-pakaĵoj ricevas Eligita Interfaco
2. Envojigo de lokaj eksiĝintaj pakoj. Elirantaj pakoj ricevas Eligita Interfaco
3. Plia envojiga paŝo por eksiĝintaj pakaĵoj, ebligas al vi ŝanĝi la decidon pri envojigo [Output|Mangle]

• La paka vojo en blokoj 1, 2 dependas de la reguloj en [IP]->[Route]
• La paka vojo en punktoj 1, 2 kaj 3 dependas de la reguloj en [IP]->[Route]->[Rules]
• La pakvojo en blokoj 1, 3 povas esti influita uzante [IP]->[Firewall]->[Mangle]

RIB, FIB, Routing Cache

Voja Informo-Bazo
La bazo en kiu itineroj estas kolektitaj de dinamikaj vojprotokoloj, itineroj de ppp kaj dhcp, senmovaj kaj ligitaj itineroj. Ĉi tiu datumbazo enhavas ĉiujn itinerojn, krom tiuj filtritaj de la administranto.

Kondiĉe, ni povas supozi tion [IP]->[Route] montras RIB.

Plusendado de Informo-Bazo

La bazo en kiu la plej bonaj itineroj de RIB estas kolektitaj. Ĉiuj itineroj en la FIB estas aktivaj kaj kutimas plusendi pakaĵetojn. Se la itinero iĝas neaktiva (malfunkciigita fare de la administranto (sistemo), aŭ la interfaco tra kiu la pakaĵeto devus esti sendita ne estas aktiva), la itinero estas forigita de la FIB.

Por fari decidon pri vojigo, la FIB-tabelo uzas la sekvajn informojn pri IP-pako:

• Fonta Adreso
• Destina Adreso
• fonta interfaco
• Voja marko
• ToS (DSCP)

Eniri la FIB-pakaĵon pasas tra la sekvaj etapoj:

• Ĉu la pakaĵo estas destinita por loka routerprocezo?
• Ĉu la pako estas submetata al reguloj de sistemo aŭ uzantPBR?
  • Se jes, tiam la pakaĵeto estas sendita al la specifita vojtabelo
• La pako estas sendita al la ĉefa tablo

Kondiĉe, ni povas supozi tion [IP]->[Route Active=yes] montras FIB.

Voja kaŝmemoro
Itinera kaŝmemormekanismo. La enkursigilo memoras kie la pakaĵoj estis senditaj kaj se estas similaj (supozeble de la sama konekto) ĝi lasas ilin iri laŭ la sama vojo, sen kontroli en la FIB. La itinera kaŝmemoro estas periode forigita.

Por RouterOS-administrantoj, ili ne faris ilojn por vidi kaj administri la Vojigan Kaŝmemoron, sed kiam ĝi povas esti malŝaltita en [IP]->[Settings].

Ĉi tiu mekanismo estis forigita de la linukso 3.6-kerno, sed RouterOS ankoraŭ uzas kernon 3.3.5, eble Routing cahce estas unu el la kialoj.

Aldoni itineran dialogon

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

1. Subreto por kiu vi volas krei itineron (defaŭlte: 0.0.0.0/0)
2. Enirejo IP aŭ interfaco al kiu la pakaĵo estos sendita (povas esti pluraj, vidu ECMP sube)
3. Kontrolo de Havebleco de Enirejo
4. Rekorda tipo
5. Distanco (metriko) por itinero
6. Voja tablo
7. IP por lokaj eksiĝintaj pakoj per ĉi tiu vojo
8. La celo de Scope kaj Target Scope estas skribita ĉe la fino de la artikolo.

Itineraj flagoj

• X - La itinero estas malŝaltita de la administranto (disabled=yes)
• A - La itinero estas uzata por sendi pakaĵojn
• D - Itinero aldonita dinamike (BGP, OSPF, RIP, MME, PPP, DHCP, Konektita)
• C - La subreto estas konektita rekte al la enkursigilo
• S - Senmova Itinero
• r,b,o,m - Itinero aldonita de unu el la dinamikaj vojprotokoloj
• B,U,P - Filtra vojo (falas pakaĵetojn anstataŭ transdoni)

Kion specifi en enirejo: ip-adreso aŭ interfaco?

La sistemo permesas al vi specifi ambaŭ, dum ĝi ne ĵuras kaj ne donas aludojn se vi faris ion malĝustan.

IP-adreso
La enirejo-adreso devas esti alirebla per Tavolo2. Por Eterreto, tio signifas ke la enkursigilo devas havi adreson de la sama subreto sur unu el la aktivaj ip-interfacoj, por ppp, ke la enirejo-adreso estas specifita sur unu el la aktivaj interfacoj kiel la subreta adreso.
Se la alirebleco-kondiĉo por Layer2 ne estas renkontita, la itinero estas konsiderita neaktiva kaj ne falas en la FIB.

interfaco
Ĉio estas pli komplika kaj la konduto de la enkursigilo dependas de la tipo de interfaco:

• PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) konekto supozas nur du partoprenantojn kaj la pakaĵeto ĉiam estos sendita al la enirejo por dissendo, se la enirejo detektas ke la ricevanto estas mem, tiam ĝi transdonos la pakaĵon al ĝia loka procezo.
  
• Ethernet supozas la ĉeeston de multoblaj partoprenantoj kaj sendos petojn al la arp-interfaco kun la adreso de la ricevanto de la pako, tio estas atendata kaj sufiĉe normala konduto por konektitaj itineroj.
  Sed kiam vi provas uzi la interfacon kiel itineron por fora subreto, vi ricevos la jenan situacion: la itinero estas aktiva, ping al la enirejo pasas, sed ne atingas la ricevonton de la specifita subreto. Se vi rigardas la interfacon per sniffer, vi vidos arp-petojn kun adresoj de fora subreto.
  

Provu specifi la ip-adreson kiel la enirejon kiam ajn eblas. La escepto estas konektitaj itineroj (kreitaj aŭtomate) kaj interfacoj PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*).

OpenVPN ne enhavas PPP-kapon, sed vi povas uzi la nomon de la interfaco OpenVPN por krei itineron.

Pli Specifa Itinero

Baza vojregulo. La itinero kiu priskribas la pli malgrandan subreton (kun la plej granda subreta masko) havas prioritaton en la vojigdecido de la pakaĵeto. La pozicio de la enskriboj en la vojtabelo ne rilatas al la elekto - la ĉefa regulo estas Pli Specifa.

Ĉiuj itineroj de la specifita skemo estas aktivaj (situantaj en FIB). montras malsamajn subretojn kaj ne konfliktas unu kun la alia.

Se unu el la enirejoj iĝas neatingebla, la rilata itinero estos konsiderita neaktiva (forigita de la FIB) kaj pakaĵetoj estos serĉitaj de la ceteraj itineroj.

La itinero kun subreto 0.0.0.0/0 foje ricevas specialan signifon kaj estas nomita la "Defaŭlta Itinero" aŭ "Enirejo de lasta eliro". Fakte, estas nenio magia en ĝi kaj ĝi simple inkluzivas ĉiujn eblajn IPv4-adresojn, sed ĉi tiuj nomoj bone priskribas ĝian taskon - ĝi indikas la enirejon, kie plusendi pakaĵetojn, por kiuj ne ekzistas aliaj pli precizaj itineroj.

La maksimuma ebla subreta masko por IPv4 estas /32, ĉi tiu itinero montras al specifa gastiganto kaj povas esti uzata en la vojtabelo.

Kompreni Pli Specifan Itineron estas fundamenta por iu ajn TCP/IP-aparato.

malproksimo

Distancoj (aŭ Metriko) estas postulataj por administra filtrado de itineroj al ununura subreto alirebla per multoblaj enirejoj. Itinero kun pli malalta metriko estas konsiderita prioritato kaj estos inkludita en la FIB. Se itinero kun pli malalta metriko ĉesas esti aktiva, tiam ĝi estos anstataŭigita per itinero kun pli alta metriko en la FIB.

Se ekzistas pluraj itineroj al la sama subreto kun la sama metriko, la enkursigilo aldonos nur unu el ili al la FIB-tabelo, gvidita de ĝia interna logiko.

La metriko povas preni valoron de 0 ĝis 255:

• 0 - Metriko por konektitaj itineroj. Distanco 0 ne povas esti agordita de la administranto
• 1-254 - Metrikoj haveblaj al la administranto por agordi itinerojn. Metrikoj kun pli malalta valoro havas pli altan prioritaton
• 255 - Metriko havebla al la administranto por agordi itinerojn. Male al 1-254, itinero kun metriko de 255 ĉiam restas neaktiva kaj ne falas en la FIB.
• specifaj metrikoj. Itineroj derivitaj de dinamikaj vojprotokoloj havas normajn metrikvalorojn

kontroli enirejon

Kontrola enirejo estas MikroTik RoutesOS etendo por kontroli la haveblecon de la enirejo per icmp aŭ arp. Unufoje ĉiujn 10 sekundojn (ne povas esti ŝanĝita), peto estas sendita al la enirejo, se la respondo ne estas ricevita dufoje, la itinero estas konsiderita neatingebla kaj estas forigita de la FIB. Se kontrolpordego malŝaltis la kontrolitinero daŭras kaj la itinero denove aktivas post unu sukcesa kontrolo.

Kontrola enirejo malŝaltas la eniron en kiu ĝi estas agordita kaj ĉiujn aliajn enirojn (en ĉiuj envojaj tabeloj kaj ecmp-itineroj) kun la specifita enirejo.

Ĝenerale, kontrolpordego funkcias bone kondiĉe ke ne estas problemoj kun paka perdo al la enirejo. Kontrola enirejo ne scias, kio okazas kun komunikado ekster la kontrolita enirejo, ĉi tio postulas pliajn ilojn: skriptoj, rekursiva vojigo, dinamikaj vojprotokoloj.

Plej multaj VPN- kaj tunelaj protokoloj enhavas enkonstruitajn ilojn por kontroli konektan agadon, ebligi kontrolan enirejon por ili estas plia (sed tre malgranda) ŝarĝo sur la reto kaj aparata agado.

ECMP-vojoj

Equal-Cost Multi-Path - sendante pakaĵetojn al la ricevanto uzante plurajn enirejojn samtempe uzante la Round Robin-algoritmon.

ECMP-itinero estas kreita fare de la administranto precizigante multoblajn enirejojn por unu subreto (aŭ aŭtomate, se ekzistas du ekvivalentaj OSPF-itineroj).

ECMP estas uzita por ŝarĝbalancado inter du kanaloj, en teorio, se ekzistas du kanaloj en la ecmp-itinero, tiam por ĉiu pakaĵeto la eksiĝinta kanalo devus esti malsama. Sed la Routing-kaŝmemormekanismo sendas pakaĵetojn de la konekto laŭ la itinero, kiun la unua pako prenis, kiel rezulto, ni ricevas specon de ekvilibro bazita sur konektoj (po-konekto-ŝarĝa ekvilibro).

Se vi malŝaltas Routing Cache, tiam la pakaĵoj en la ECMP-itinero estos kunhavataj ĝuste, sed estas problemo kun NAT. La NAT-regulo prilaboras nur la unuan pakaĵon de la konekto (la ceteraj estas procesitaj aŭtomate), kaj rezultas, ke pakoj kun la sama fontadreso forlasas malsamajn interfacojn.

Kontrolu enirejon ne funkcias en ECMP-itineroj (RouterOS-cimo). Sed vi povas ĉirkaŭiri ĉi tiun limigon kreante pliajn validigajn vojojn, kiuj malŝaltos enirojn en ECMP.

Filtrado per Routing

La opcio Tipo determinas kion fari kun la pako:

• unicast - sendu al la specifita enirejo (interfaco)
• blackhole - forĵeti paketon
• malpermesi, neatingebla - forĵetu la pakaĵon kaj sendu icmp-mesaĝon al la sendinto

Filtrilo estas kutime uzata kiam necesas sekurigi la sendon de pakaĵoj laŭ la malĝusta vojo, kompreneble vi povas filtri ĉi tion tra la fajroŝirmilo.

Paro da ekzemploj

Plifirmigi la bazajn aferojn pri vojigo.

Tipa hejma enkursigilo

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

1. Senmova itinero al 0.0.0.0/0 (defaŭlta itinero)
2. Konektita vojo sur la interfaco kun la provizanto
3. Konektita itinero sur LAN-interfaco

Tipa hejma enkursigilo kun PPPoE

1. Senmova itinero al defaŭlta itinero, aldonita aŭtomate. ĝi estas specifita en konektpropraĵoj
2. Konektita itinero por PPP-konekto
3. Konektita itinero sur LAN-interfaco

Tipa hejma enkursigilo kun du provizantoj kaj redundo

/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. Senmova itinero al defaŭlta itinero tra la unua provizanto kun metriko 1 kaj enirejo-kontrolo de havebleco
2. Senmova itinero al defaŭlta itinero tra dua provizanto kun metriko 2
3. Konektitaj vojoj

Trafiko al 0.0.0.0/0 trairas 10.10.10.1 dum ĉi tiu enirejo estas disponebla, alie ĝi ŝanĝas al 10.20.20.1

Tia skemo povas esti konsiderata kanala rezervo, sed ĝi ne estas sen malavantaĝoj. Se paŭzo okazas ekster la enirejo de la provizanto (ekzemple, ene de la reto de la funkciigisto), via enkursigilo ne scios pri ĝi kaj daŭre konsideros la itineron kiel aktiva.

Tipa hejma enkursigilo kun du provizantoj, redundo kaj 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. Senmovaj vojoj por kontroli chack-enirejon
2. ECMP-itinero
3. Konektitaj vojoj

Kontrolendaj itineroj estas bluaj (la koloro de neaktivaj itineroj), sed ĉi tio ne malhelpas la kontrolpordon. La nuna versio (6.44) de RoS donas aŭtomatan prioritaton al la ECMP-itinero, sed estas pli bone aldoni testvojojn al aliaj vojtabloj (opcio routing-mark)

En Speedtest kaj aliaj similaj retejoj, ne estos pliiĝo de rapideco (ECMP dividas trafikon per konektoj, ne per pakoj), sed p2p-aplikoj devus elŝuti pli rapide.

Filtrado per Enrutado

/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. Senmova itinero al defaŭlta itinero
2. Senmova vojo al 192.168.200.0/24 super ipip-tunelo
3. Malpermesante senmovan itineron al 192.168.200.0/24 per ISP-enkursigilo

Filtrila opcio en kiu tunela trafiko ne iros al la enkursigilo de la provizanto kiam la ipip-interfaco estas malŝaltita. Tiaj skemoj malofte estas postulataj, ĉar vi povas efektivigi blokadon per la fajroŝirmilo.

Enruta buklo
Voja buklo - situacio kiam pakaĵeto kuras inter enkursigiloj antaŭ ol la ttl eksvalidiĝas. Kutime ĝi estas rezulto de agorda eraro, en grandaj retoj ĝi estas traktata per efektivigo de dinamikaj enrutaj protokoloj, en malgrandaj - zorge.

Ĝi aspektas kiel ĉi tio:

Ekzemplo (plej simpla) de kiel akiri similan rezulton:

La Ekzemplo de Voja buklo estas de neniu praktika uzo, sed ĝi montras ke enkursigiloj havas neniun ideon pri la vojtabelo de sia najbaro.

Politika Baza Vokado kaj Pliaj Vojaj Tabeloj

Elektante itineron, la enkursigilo uzas nur unu kampon de la paka kaplinio (Dst. Adreso) - tio estas baza enrutigo. Vokado bazita sur aliaj kondiĉoj, kiel fontadreso, speco de trafiko (ToS), ekvilibro sen ECMP, apartenas al Policy Base Routing (PBR) kaj uzas kromajn vojtablojn.

Pli Specifa Itinero estas la ĉefitinera elektregulo ene de la vojtabelo.

Defaŭlte, ĉiuj vojreguloj estas aldonitaj al la ĉefa tabelo. La administranto povas krei arbitran nombron da aldonaj vojtabloj kaj direkti pakaĵetojn al ili. Reguloj en malsamaj tabeloj ne konfliktas inter si. Se la pakaĵo ne trovas taŭgan regulon en la specifita tabelo, ĝi iros al la ĉefa tabelo.

Ekzemplo kun distribuo per fajroŝirmilo:

• 192.168.100.10 -> 8.8.8.8
  1. Trafiko de 192.168.100.10 estas etikedita via-isp1 в [Prerouting|Mangle]
  2. Ĉe la Voja stadio en la tabelo via-isp1 serĉas vojon al 8.8.8.8
  3. Itinero trovita, trafiko estas sendita al enirejo 10.10.10.1
• 192.168.200.20 -> 8.8.8.8
  1. Trafiko de 192.168.200.20 estas etikedita via-isp2 в [Prerouting|Mangle]
  2. Ĉe la Voja stadio en la tabelo via-isp2 serĉas vojon al 8.8.8.8
  3. Itinero trovita, trafiko estas sendita al enirejo 10.20.20.1
• Se unu el la enirejoj (10.10.10.1 aŭ 10.20.20.1) fariĝas neatingebla, tiam la pako iros al la tablo. ĉefa kaj serĉos tie taŭgan vojon

Terminologiaj aferoj

RouterOS havas iujn terminologiajn problemojn.
Kiam oni laboras kun reguloj en [IP]->[Routes] la vojtabelo estas indikita, kvankam estas skribite ke la etikedo:

В [IP]->[Routes]->[Rule] ĉio estas ĝusta, en la etikedo kondiĉo en la tabela ago:

Kiel sendi pakaĵon al specifa vojtabelo

RouterOS provizas plurajn ilojn:

• Reguloj en [IP]->[Routes]->[Rules]
• Itinersignoj (action=mark-routing) en [IP]->[Firewall]->[Mangle]
• VRF

Reguloj [IP]->[Route]->[Rules]
Reguloj estas prilaboritaj sinsekve, se la pakaĵeto kongruas kun la kondiĉoj de la regulo, ĝi ne pasas plu.

Reguloj pri vojigo permesas pligrandigi la eblecojn de vojigo, fidante ne nur je la ricevadreso, sed ankaŭ je la fontadreso kaj interfaco, sur kiuj la pako estis ricevita.

Reguloj konsistas el kondiĉoj kaj ago:

• Kondiĉoj. Praktike ripetu la liston de signoj per kiuj la pakaĵo estas kontrolita en la FIB, nur ToS mankas.
• Agoj
  • serĉo - sendu paketon al tablo
  • serĉu nur en tabelo - ŝlosu la pakaĵon en la tabelo, se la itinero ne estas trovita, la pako ne iros al la ĉefa tablo
  • drop - faligi paketon
  • neatingebla - forĵetu la pakaĵon kun sendinto-sciigo

En FIB, trafiko al lokaj procezoj estas prilaborita preterirante la regulojn [IP]->[Route]->[Rules]:

Markado [IP]->[Firewall]->[Mangle]
Vojaj etikedoj permesas al vi agordi la enirejon por pako uzante preskaŭ iujn ajn Fajrmurkondiĉojn:

Praktike, ĉar ne ĉiuj havas sencon, kaj iuj povas funkcii malstabile.

Estas du manieroj por etikedi pakaĵon:

• Tuj metu vojmarko
• Metu unue konekto-marko, tiam bazita sur konekto-marko meti vojmarko

En artikolo pri fajroŝirmiloj, mi skribis, ke la dua opcio estas preferinda. reduktas la ŝarĝon sur la CPU, en la kazo de markado de itineroj - ĉi tio ne estas tute vera. Tiuj markadmetodoj ne ĉiam estas ekvivalentaj kaj kutime estas uzataj por solvi diversajn problemojn.

Uzaj Ekzemploj

Ni pluiru al la ekzemploj pri uzado de Policy Base Routing, ili estas multe pli facile montri kial ĉio ĉi estas necesa.

MultiWAN kaj resenda elira (Eligo) trafiko
Ofta problemo kun MultiWAN-agordo: Mikrotik estas havebla de la Interreto nur per "aktiva" provizanto.

La enkursigilo ne zorgas, de kiu ip venis la peto, kiam ĝi generas respondon, ĝi serĉos itineron en la vojtabelo, kie la itinero tra isp1 estas aktiva. Plue, tia pako plej verŝajne estos filtrita laŭ la vojo al la ricevanto.

Alia interesa punkto. Se "simpla" fonto nat estas agordita sur la interfaco ether1: /ip fi nat add out-interface=ether1 action=masquerade la pako enretiĝos kun src. adreso=10.10.10.100, kio eĉ plimalbonigas la aferojn.

Estas pluraj manieroj ripari la problemon, sed iu el ili postulos pliajn vojtablojn:

/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

Uzo [IP]->[Route]->[Rules]
Indiku la vojigtabelon, kiu estos uzata por pakaĵoj kun la specifita Fonta 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

Povas uzi action=lookup, sed por loka elira trafiko, ĉi tiu opcio tute ekskludas konektojn de la malĝusta interfaco.

• La sistemo generas respondpakaĵon kun Src. Adreso: 10.20.20.200
• La Voja Decido(2) paŝokontrolas [IP]->[Routes]->[Rules] kaj la pako estas sendita al la vojtabelo tro-isp2
• Laŭ la vojtabelo, la pako devas esti sendita al la enirejo 10.20.20.1 per la interfaco ether2

Ĉi tiu metodo ne postulas funkciantan Konektan Spurilon, male al uzado de la Mangle-tabelo.

Uzo [IP]->[Firewall]->[Mangle]
La konekto komenciĝas per envenanta pako, do ni markas ĝin (action=mark-connection), por elirantaj pakoj de markita konekto, agordu la vojetikedon (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

Se pluraj ips estas agordita sur unu interfaco, vi povas aldoni al la kondiĉo dst-address por esti certa.

• Pako malfermas la konekton sur la interfaco ether2. La pakaĵo eniras [INPUT|Mangle] kiu diras marki ĉiujn pakaĵojn el la konekto kiel de-isp2
• La sistemo generas respondpakaĵon kun Src. Adreso: 10.20.20.200
• Ĉe la Voja Decido (2) stadio, la pakaĵeto, laŭ la envojigtabelo, estas sendita al la enirejo 10.20.20.1 per la ether1-interfaco. Vi povas kontroli ĉi tion ensalutante la pakaĵojn [OUTPUT|Filter]
• Ĉe la scenejo [OUTPUT|Mangle] konekta etikedo estas kontrolita de-isp2 kaj la pakaĵeto ricevas itineretikedon tro-isp2
• La Paŝo de Voja Alĝustigo (3) kontrolas la ĉeeston de vojetikedo kaj sendas ĝin al la taŭga vojtabelo
• Laŭ la vojtabelo, la pako devas esti sendita al la enirejo 10.20.20.1 per la interfaco ether2

MultiWAN kaj redonu dst-nat trafikon

Ekzemplo estas pli komplika, kion fari se estas servilo (ekzemple, retejo) malantaŭ la enkursigilo sur privata subreto kaj vi devas disponigi aliron al ĝi per iu el la provizantoj.

/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

La esenco de la problemo estos la sama, la solvo estas simila al la opcio Firewall Mangle, nur aliaj ĉenoj estos uzataj:

/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

La diagramo ne montras NAT, sed mi pensas, ke ĉio estas klara.

MultiWAN kaj elirkonektoj

Vi povas uzi la PBR-kapablojn por krei plurajn vpn (SSTP en la ekzemplo) konektojn de malsamaj enkursigiloj.

Pliaj vojtabuloj:

/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

Pakaj markoj:

/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

Simplaj NAT-reguloj, alie la pako forlasos la interfacon kun la malĝusta Src. adreso:

/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

Analizado:

• Enkursigilo kreas tri SSTP-procezojn
• En la Voja Decido (2) stadio, itinero estas elektita por ĉi tiuj procezoj surbaze de la ĉefa vojtabelo. De la sama itinero, la pakaĵeto ricevas Src. Adreso ligita al ether1-interfaco
• В [Output|Mangle] pakoj de malsamaj konektoj ricevas malsamajn etikedojn
• Pakaĵetoj eniras la tabelojn respondantajn al la etikedoj ĉe la Ruta Alĝustigo kaj ricevas novan itineron por sendi pakaĵetojn.
• Sed pakaĵoj ankoraŭ havas Src. Adreso de ether1, sur scenejo [Nat|Srcnat] la adreso estas anstataŭigita laŭ la interfaco

Kurioze, sur la enkursigilo vi vidos la sekvan konektan tabelon:

Konekto-Spurilo funkcias pli frue [Mangle] и [Srcnat], do ĉiuj konektoj venas de la sama adreso, se vi rigardas pli detale, tiam en Replay Dst. Address estos adresoj post NAT:

Sur la VPN-servilo (mi havas unu sur la testbenko), vi povas vidi, ke ĉiuj konektoj venas de la ĝustaj adresoj:

Atendu manieron
Estas pli facila maniero, vi povas simple specifi specifan enirejon por ĉiu el la adresoj:

/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

Sed tiaj vojoj influos ne nur elirantan sed ankaŭ transitan trafikon. Krome, se vi ne bezonas trafikon al la vpn-servilo por trairi malkonvenajn komunikajn kanalojn, tiam vi devos aldoni 6 pliajn regulojn al [IP]->[Routes]с type=blackhole. En la antaŭa versio - 3 reguloj en [IP]->[Route]->[Rules].

Distribuado de uzantkonektoj per komunikaj kanaloj

Simplaj, ĉiutagaj taskoj. Denove, pliaj vojtabloj estos bezonataj:

/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

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

Se vi uzas action=lookup, tiam kiam unu el la kanaloj estas malŝaltita, la trafiko iros al la ĉefa tablo kaj iros tra la funkcianta kanalo. Ĉu tio estas necesa aŭ ne, dependas de la tasko.

Uzante la markojn en [IP]->[Firewall]->[Mangle]
Simpla ekzemplo kun listoj de ip-adresoj. Principe, preskaŭ ĉiuj kondiĉoj povas esti uzataj. La nura averto de layer7, eĉ se kunigita kun konektaj etikedoj, eble ŝajnas, ke ĉio funkcias ĝuste, sed iom da trafiko ankoraŭ iros malĝuste.

/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

Vi povas "ŝlosi" uzantojn en unu vojtabelo tra [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

Aŭ tra [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
Kroma kondiĉo dst-address-type=!local necesas, ke trafiko de uzantoj atingu la lokajn procezojn de la enkursigilo (dns, winbox, ssh, ...). Se pluraj lokaj subretoj estas konektitaj al la enkursigilo, necesas certigi, ke la trafiko inter ili ne iras al Interreto, ekzemple, uzante dst-address-table.

En la ekzemplo uzante [IP]->[Route]->[Rules] ne ekzistas tiaj esceptoj, sed trafiko atingas lokajn procezojn. La fakto estas, ke eniri la FIB-pakaĵon markitan [PREROUTING|Mangle] havas itineretikedon kaj iras en vojigtabelon krom ĉefa, kie ekzistas neniu loka interfaco. En la kazo de Routing Rules, unue estas kontrolite ĉu la pakaĵeto estas destinita por loka procezo kaj nur ĉe la Uzanto PBR-fazo ĝi iras al la specifita vojigtabelo.

Uzante [IP]->[Firewall]->[Mangle action=route]
Ĉi tiu ago nur funkcias en [Prerouting|Mangle] kaj permesas vin direkti trafikon al la specifita enirejo sen uzi aldonajn vojtablojn, specifante rekte la enirejon:

/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

efiko route havas pli malaltan prioritaton ol vojreguloj ([IP]->[Route]->[Rules]). En la kazo de itinero markoj, ĉio dependas de la pozicio de la reguloj, se la regulo kun action=route valoras pli ol action=mark-route, tiam ĝi estos uzata (sendepende de la flago passtrough), alie markante la itineron.
Estas tre malmulte da informoj en la vikio pri ĉi tiu ago kaj ĉiuj konkludoj estis akiritaj eksperimente, ĉiukaze, mi ne trovis eblojn kiam uzi ĉi tiun opcion donas avantaĝojn super aliaj.

PPC bazita dinamika ekvilibro

Per Connection Classifier - estas pli fleksebla analogo de ECMP. Male al ECMP, ĝi dividas trafikon per konektoj pli strikte (ECMP scias nenion pri konektoj, sed kiam parigita kun Routing Cache, io simila estas akirita).

PCC prenas specifitaj kampoj de la ip-kapo, konvertas ilin al 32-bita valoro, kaj dividas per denominatoro. La resto de la divido estas komparata kun la specifita restaĵo kaj se ili kongruas, tiam la specifita ago estas aplikata. Legi pli. Sonas freneze, sed ĝi funkcias.

Ekzemplo kun tri adresoj:

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

Ekzemplo de dinamika distribuado de trafiko per src.address inter tri kanaloj:

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

Dum markado de itineroj, ekzistas plia kondiĉo: in-interface=br-lan, sen ĝi sub action=mark-routing responda trafiko de la Interreto ricevos kaj, konforme al la envojaj tabeloj, revenos al la provizanto.

Ŝanĝi komunikajn kanalojn

Kontrolu ping estas bona ilo, sed ĝi nur kontrolas la konekton kun la plej proksima IP-kunulo, provizantaj retoj kutime konsistas el granda nombro da enkursigiloj kaj ligrompiĝo povas okazi ekster la plej proksima samulo, kaj tiam ekzistas spinaj telekomunikaj telefonistoj, kiuj ankaŭ povas. havas problemojn, ĝenerale ĉeko ping ne ĉiam montras ĝisdatajn informojn pri aliro al la tutmonda reto.
Se provizantoj kaj grandaj korporacioj havas la dinamikan enrutigan protokolon BGP, tiam hejmaj kaj oficejaj uzantoj devas sendepende eltrovi kiel kontroli interretan aliron per specifa komunika kanalo.

Kutime oni uzas skriptojn, kiuj per certa komunika kanalo kontrolas la haveblecon de ip-adreso en la Interreto, dum oni elektas ion fidindan, ekzemple google dns: 8.8.8.8. 8.8.4.4. Sed en la Mikrotik-komunumo, pli interesa ilo estis adaptita por tio.

Kelkaj vortoj pri rekursiva vojigo
Rekursiva vojigo estas necesa dum konstruado de Multihop BGP peering kaj eniris la artikolon pri la bazaĵoj de senmova vojigo nur pro ruzaj uzantoj de MikroTik, kiuj eltrovis kiel uzi rekursivajn itinerojn parigitajn kun kontrolpordejo por ŝanĝi komunikajn kanalojn sen aldonaj skriptoj.

Estas tempo por kompreni la opciojn de amplekso/cela amplekso ĝenerale kaj kiel la itinero estas ligita al la interfaco:

1. La itinero serĉas interfacon por sendi la pakaĵeton surbaze de ĝia ampleksovaloro kaj ĉiuj enskriboj en la ĉeftabelo kun malpli ol aŭ egalaj celaj ampleksovaloroj
2. El la trovitaj interfacoj, tiu tra kiu vi povas sendi pakaĵon al la specifita enirejo estas elektita
3. La interfaco de la trovita konektita eniro estas elektita por sendi la pakaĵon al la enirejo

En ĉeesto de rekursiva itinero, ĉio okazas same, sed en du stadioj:

• 1-3 Unu plia itinero estas aldonita al la ligitaj itineroj, tra kiuj la specifita enirejo povas esti atingita
• 4-6 Trovi la itineron ligitan itineron por la "meza" enirejo

Ĉiuj manipuladoj kun la rekursiva serĉo okazas en la RIB, kaj nur la finrezulto estas transdonita al la FIB: 0.0.0.0/0 via 10.10.10.1 on ether1.

Ekzemplo de uzado de rekursiva vojigo por ŝanĝi itinerojn

Agordo:

/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

Vi povas kontroli, ke pakoj estos senditaj al 10.10.10.1:

Kontrola enirejo scias nenion pri rekursiva vojigo kaj simple sendas pingojn al 8.8.8.8, kiu (surbaze de la ĉeftabelo) estas alirebla per enirejo 10.10.10.1.

Se estas perdo de komunikado inter 10.10.10.1 kaj 8.8.8.8, tiam la itinero estas malkonektita, sed pakaĵoj (inkluzive de testpingoj) al 8.8.8.8 daŭre trairas 10.10.10.1:

Se la ligo al ether1 estas perdita, tiam malagrabla situacio okazas kiam pakoj antaŭ 8.8.8.8 pasas tra la dua provizanto:

Ĉi tio estas problemo se vi uzas NetWatch por ruli skriptojn kiam 8.8.8.8 ne estas disponebla. Se la ligo estas rompita, NetWatch simple funkcios per la rezerva komunika kanalo kaj supozos, ke ĉio estas en ordo. Solvita aldonante plian filtrilan itineron:

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

Estas sur habré artikolo, kie la situacio kun NetWatch estas konsiderata pli detale.

Kaj jes, kiam oni uzas tian rezervon, la adreso 8.8.8.8 estos fiksita al unu el la provizantoj, do elekti ĝin kiel dns-fonton ne estas bona ideo.

Kelkaj vortoj pri Virtuala Vokado kaj Plusendado (VRF)

VRF-teknologio estas dizajnita por krei plurajn virtualajn enkursigilojn ene de unu fizika, tiu teknologio estas vaste uzita fare de teleentreprenistoj (kutime lige kun MPLS) por disponigi L3VPN-servojn al klientoj kun imbrikitaj subretaj adresoj:

Sed VRF en Mikrotik estas organizita surbaze de enrutaj tabeloj kaj havas kelkajn malavantaĝojn, ekzemple lokaj ip-adresoj de la enkursigilo haveblas de ĉiuj VRF-oj, vi povas legi pli ligilo.

vrf-agorda ekzemplo:

/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

De la aparato konektita al ether2, ni vidas, ke ping iras al la enkursigilo de alia vrf (kaj ĉi tio estas problemo), dum ping ne iras al Interreto:

Por aliri la Interreton, vi devas registri aldonan itineron, kiu aliras la ĉefan tabelon (en vrf-terminologio, tio estas nomita itinero liko):

/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

Jen du manieroj por liki vojon: uzante la vojtabelon: 172.17.0.1@main kaj uzante interfacan nomon: 172.17.0.1%wlan1.

Kaj starigu markadon por reventrafiko enen [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 

Subretoj kun la sama adreso
Organizo de aliro al subretoj kun la sama adresado sur la sama enkursigilo uzante VRF kaj retmapon:

Baza agordo:

/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

reguloj pri fajroŝirmilo:

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

Vojaj reguloj por reventrafiko:

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

Aldonante itinerojn ricevitajn per dhcp al donita vojtabelo
VRF povas esti interesa se vi bezonas aŭtomate aldoni dinamikan itineron (ekzemple, de dhcp-kliento) al specifa vojtabelo.

Aldonante interfacon al vrf:

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

Reguloj por sendado de trafiko (elira kaj transito) tra la tablo tro-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

Plia, falsa vojo por elira vojigo al laboro:

/interface bridge
add name=bare

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

Ĉi tiu itinero estas nur necesa por ke lokaj eksiĝintaj pakaĵoj povas trapasi la Vojigan decidon (2) antaŭe [OUTPUT|Mangle] kaj ricevu la vojetikedon, se estas aliaj aktivaj itineroj sur la enkursigilo antaŭ 0.0.0.0/0 en la ĉefa tabelo, ĝi ne estas postulata.

ĉenoj connected-in и dynamic-in в [Routing] -> [Filters]

Itinera filtrado (eniranta kaj elira) estas ilo, kiu estas kutime uzata kune kun dinamikaj envojaj protokoloj (kaj tial nur disponebla post instalo de la pakaĵo). enirado), sed estas du interesaj ĉenoj en la envenantaj filtriloj:

• connect-in — filtrante konektitajn itinerojn
• dynamic-in - filtrante dinamikajn itinerojn ricevitajn de PPP kaj DCHP

Filtrado permesas ne nur forĵeti itinerojn, sed ankaŭ ŝanĝi kelkajn eblojn: distanco, vojmarko, komento, amplekso, cela amplekso, ...

Ĉi tio estas tre preciza ilo kaj se vi povas fari ion sen Rutigaj Filtriloj (sed ne skriptoj), tiam ne uzu Rutigajn Filtrilojn, ne konfuzu vin kaj tiujn, kiuj agordos la enkursigilon post vi. En la kunteksto de dinamika vojigo, Vojaj Filtriloj estos uzataj multe pli ofte kaj pli produktive.

Agordo de la Voja Marko por Dinamaj Itineroj
Ekzemplo de hejma enkursigilo. Mi havas du VPN-konektojn agordis kaj la trafiko en ili devus esti envolvita laŭ la envojaj tabeloj. Samtempe, mi volas, ke la itineroj estu aŭtomate kreitaj kiam la interfaco estas aktivigita:

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

Mi ne scias kial, verŝajne cimo, sed se vi kreas vrf por la ppp-interfaco, tiam la vojo al 0.0.0.0/0 ankoraŭ eniros en la ĉefan tabelon. Alie, ĉio estus eĉ pli facila.

Malebligado de Konektitaj Itineroj
Kelkfoje ĉi tio estas postulata:

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

Sencimigaj iloj

RouterOS disponigas kelkajn ilojn por sencimigi vojigon:

• [Tool]->[Tourch] - permesas vin vidi pakaĵojn sur interfacoj
• /ip route check - ebligas al vi vidi al kiu enirejo la pakaĵo estos sendita, ne funkcias kun vojtabloj
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - ping kaj spuri uzante la specifitan enrutigan tabelon
• action=log в [IP]->[Firewall] - bonega ilo, kiu permesas vin spuri la vojon de pako laŭ la paka fluo, ĉi tiu ago disponeblas en ĉiuj ĉenoj kaj tabeloj

fonto: www.habr.com