Základy statického smerovania v systéme Mikrotik RouterOS

Smerovanie je proces hľadania najlepšej cesty na prenos paketov cez siete TCP/IP. Každé zariadenie pripojené k sieti IPv4 obsahuje procesné a smerovacie tabuľky.

Tento článok nie je HOWTO, popisuje statické smerovanie v RouterOS s príkladmi, schválne som vynechal zvyšok nastavení (napríklad srcnat pre prístup na internet), takže pochopenie materiálu vyžaduje určitú úroveň znalostí sietí a RouterOS.

Prepínanie a smerovanie

Prepínanie je proces výmeny paketov v rámci jedného segmentu Layer2 (Ethernet, ppp, ...). Ak zariadenie vidí, že príjemca paketu je na rovnakej ethernetovej podsieti ako zariadenie, naučí sa mac adresu pomocou protokolu arp a odošle paket priamo, pričom obíde smerovač. Spojenie ppp (point-to-point) môže mať iba dvoch účastníkov a paket je vždy odoslaný na jednu adresu 0xff.

Smerovanie je proces prenosu paketov medzi segmentmi vrstvy 2. Ak chce zariadenie odoslať paket, ktorého príjemca je mimo segmentu Ethernet, pozrie sa do jeho smerovacej tabuľky a odošle paket bráne, ktorá vie, kam má paket poslať ďalej (alebo nemusí vedieť, pôvodný odosielateľ paketu nie je si toho vedomý).

Najjednoduchší spôsob, ako si predstaviť smerovač, je zariadenie pripojené k dvom alebo viacerým segmentom vrstvy 2 a schopné medzi nimi prenášať pakety určením najlepšej cesty zo smerovacej tabuľky.

Ak všetkému rozumiete, alebo ste to už vedeli, tak čítajte ďalej. Pokiaľ ide o zvyšok, dôrazne vám odporúčam, aby ste sa oboznámili s malým, ale veľmi priestranným článok.

Smerovanie v RouterOS a PacketFlow

Takmer všetky funkcie súvisiace so statickým smerovaním sú v balíku systém. Plastový sáčok routing pridáva podporu pre dynamické smerovacie algoritmy (RIP, OSPF, BGP, MME), smerovacie filtre a BFD.

Hlavné menu pre nastavenie smerovania: [IP]->[Route]. Komplexné schémy môžu vyžadovať, aby boli pakety vopred označené značkou smerovania v: [IP]->[Firewall]->[Mangle] (reťaze PREROUTING и OUTPUT).

Existujú tri miesta na PacketFlow, kde sa prijímajú rozhodnutia o smerovaní paketov IP:

1. Smerovanie paketov prijatých smerovačom. V tejto fáze sa rozhoduje, či paket pôjde do lokálneho procesu, alebo bude poslaný ďalej do siete. Prijímajú tranzitné balíky Výstupné rozhranie
2. Smerovanie miestnych odchádzajúcich paketov. Odchádzajúce pakety prijímajú Výstupné rozhranie
3. Dodatočný krok smerovania pre odchádzajúce pakety vám umožňuje zmeniť rozhodnutie o smerovaní [Output|Mangle]

• Cesta paketu v blokoch 1, 2 závisí od pravidiel v [IP]->[Route]
• Cesta paketu v bodoch 1, 2 a 3 závisí od pravidiel v [IP]->[Route]->[Rules]
• Dráhu balíka v blokoch 1, 3 možno ovplyvniť pomocou [IP]->[Firewall]->[Mangle]

RIB, FIB, smerovacia vyrovnávacia pamäť

Smerovacia informačná základňa
Základ, v ktorom sa zhromažďujú cesty z dynamických smerovacích protokolov, cesty z ppp a dhcp, statické a pripojené cesty. Táto databáza obsahuje všetky trasy okrem tých, ktoré filtruje správca.

Podmienečne, to môžeme predpokladať [IP]->[Route] zobrazí RIB.

Preposielacia informačná základňa

Základňa, v ktorej sa zhromažďujú najlepšie trasy z RIB. Všetky trasy vo FIB sú aktívne a používajú sa na preposielanie paketov. Ak sa trasa stane neaktívnou (zakáže ju správca (systém), alebo nie je aktívne rozhranie, cez ktoré má byť paket odoslaný), trasa sa z FIB odstráni.

Na rozhodnutie o smerovaní používa tabuľka FIB nasledujúce informácie o pakete IP:

• Adresa zdroja
• Cieľová adresa
• zdrojové rozhranie
• Smerovacia značka
• zmluvné podmienky (DSCP)

Vstup do balíka FIB prechádza nasledujúcimi fázami:

• Je balík určený pre proces lokálneho smerovača?
• Podlieha paket systémovým alebo užívateľským pravidlám PBR?
  • Ak áno, potom sa paket odošle do zadanej smerovacej tabuľky
• Paket sa odošle do hlavnej tabuľky

Podmienečne, to môžeme predpokladať [IP]->[Route Active=yes] zobrazí FIB.

Smerovacia vyrovnávacia pamäť
Mechanizmus ukladania trasy do vyrovnávacej pamäte. Router si pamätá, kam boli pakety odoslané, a ak existujú podobné (pravdepodobne z rovnakého pripojenia), nechá ich ísť po rovnakej trase bez kontroly FIB. Vyrovnávacia pamäť trasy sa pravidelne vymazáva.

Pre správcov RouterOS nevytvorili nástroje na prezeranie a správu vyrovnávacej pamäte smerovania, ale keď ju možno deaktivovať v [IP]->[Settings].

Tento mechanizmus bol odstránený z jadra linuxu 3.6, ale RouterOS stále používa jadro 3.3.5, možno je jedným z dôvodov smerovanie cahce.

Dialógové okno Pridať trasu

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

1. Podsieť, pre ktorú chcete vytvoriť trasu (predvolené: 0.0.0.0/0)
2. IP brány alebo rozhranie, na ktoré bude paket odoslaný (môže ich byť niekoľko, pozri ECMP nižšie)
3. Kontrola dostupnosti brány
4. Typ záznamu
5. Vzdialenosť (metrická) pre trasu
6. Smerovacia tabuľka
7. IP pre lokálne odchádzajúce pakety cez túto cestu
8. Účel rozsahu a cieľového rozsahu je napísaný na konci článku.

Traťové vlajky

• X - Cesta je zakázaná správcom (disabled=yes)
• A - Trasa sa používa na odosielanie paketov
• D – Trasa pridaná dynamicky (BGP, OSPF, RIP, MME, PPP, DHCP, Connected)
• C - Podsieť je pripojená priamo k smerovaču
• S - Statická cesta
• r,b,o,m - Trasa pridaná jedným z dynamických smerovacích protokolov
• B,U,P - Filtrovanie trasy (zahodí pakety namiesto prenosu)

Čo zadať v bráne: IP adresa alebo rozhranie?

Systém umožňuje špecifikovať oboje, pričom nenadáva a nenapovedá, ak ste niečo urobili zle.

IP adresa
Adresa brány musí byť prístupná cez vrstvu 2. Pre Ethernet to znamená, že router musí mať adresu z rovnakej podsiete na jednom z aktívnych ip rozhraní, pre ppp, že adresa brány je špecifikovaná na jednom z aktívnych rozhraní ako adresa podsiete.
Ak nie je splnená podmienka dostupnosti pre vrstvu 2, trasa sa považuje za neaktívnu a nespadá do FIB.

rozhranie
Všetko je komplikovanejšie a správanie smerovača závisí od typu rozhrania:

• Pripojenie PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) predpokladá iba dvoch účastníkov a paket bude vždy odoslaný bráne na prenos, ak brána zistí, že príjemcom je sama, potom prenesie paket na jeho lokálny proces.
  
• Ethernet predpokladá prítomnosť mnohých účastníkov a bude odosielať požiadavky na rozhranie arp s adresou príjemcu paketu, čo je očakávané a celkom normálne správanie pre pripojené trasy.
  Keď sa však pokúsite použiť rozhranie ako cestu pre vzdialenú podsieť, dostanete sa do nasledujúcej situácie: trasa je aktívna, ping na bránu prejde, ale nedosiahne príjemcu zo zadanej podsiete. Ak sa pozriete na rozhranie cez sniffer, uvidíte arp požiadavky s adresami zo vzdialenej podsiete.
  

Pokúste sa zadať adresu IP ako bránu vždy, keď je to možné. Výnimkou sú pripojené trasy (vytvorené automaticky) a rozhrania PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*).

OpenVPN neobsahuje hlavičku PPP, ale na vytvorenie trasy môžete použiť názov rozhrania OpenVPN.

Špecifickejšia trasa

Základné pravidlo smerovania. Smerovanie, ktoré popisuje menšiu podsieť (s najväčšou maskou podsiete), má prednosť pri rozhodovaní o smerovaní paketu. Pozícia záznamov v smerovacej tabuľke nie je pre výber relevantná - hlavné pravidlo je Špecifickejšie.

Všetky cesty zo zadanej schémy sú aktívne (umiestnené vo FIB). smerujú na rôzne podsiete a nie sú vo vzájomnom konflikte.

Ak sa jedna z brán stane nedostupnou, pridružená trasa sa bude považovať za neaktívnu (odstránená z FIB) a pakety sa budú hľadať zo zostávajúcich trás.

Trasa s podsieťou 0.0.0.0/0 má niekedy špeciálny význam a nazýva sa „predvolená trasa“ alebo „brána poslednej inštancie“. V skutočnosti na tom nie je nič magické a jednoducho obsahuje všetky možné IPv4 adresy, no tieto názvy dobre vystihujú jeho úlohu – označuje bránu, kam má preposielať pakety, pre ktoré neexistujú iné presnejšie trasy.

Maximálna možná maska ​​podsiete pre IPv4 je /32, táto trasa ukazuje na konkrétneho hostiteľa a možno ju použiť v smerovacej tabuľke.

Pochopenie konkrétnejšej trasy je základom každého zariadenia TCP/IP.

vzdialenosť

Vzdialenosti (alebo metriky) sú potrebné na administratívne filtrovanie trás do jednej podsiete prístupnej cez viacero brán. Trasa s nižšou metrikou sa považuje za prioritu a bude zahrnutá do FIB. Ak trasa s nižšou metrikou prestane byť aktívna, bude nahradená trasou s vyššou metrikou vo FIB.

Ak existuje niekoľko trás do rovnakej podsiete s rovnakou metrikou, smerovač pridá do tabuľky FIB iba jednu z nich podľa svojej vnútornej logiky.

Metrika môže mať hodnotu od 0 do 255:

• 0 – Metrika pre prepojené trasy. Vzdialenosť 0 nemôže byť nastavená správcom
• 1-254 - Metriky dostupné správcovi na nastavenie trás. Metriky s nižšou hodnotou majú vyššiu prioritu
• 255 - Metrika dostupná správcovi na nastavenie trás. Na rozdiel od 1-254 zostáva trasa s metrikou 255 vždy neaktívna a nespadá do FIB
• špecifické metriky. Trasy odvodené z dynamických smerovacích protokolov majú štandardné metrické hodnoty

skontrolovať bránu

Check gateway je rozšírenie MikroTik RoutesOS na kontrolu dostupnosti brány cez icmp alebo arp. Raz za 10 sekúnd (nedá sa zmeniť) sa odošle požiadavka na bránu, ak odpoveď nedostane dvakrát, trasa sa považuje za nedostupnú a odstráni sa z FIB. Ak je kontrolná brána deaktivovaná, kontrolná cesta pokračuje a po jednej úspešnej kontrole sa trasa opäť aktivuje.

Check gateway zakáže položku, v ktorej je nakonfigurovaná, a všetky ostatné položky (vo všetkých smerovacích tabuľkách a cestách ecmp) so zadanou bránou.

Vo všeobecnosti platí, že kontrolná brána funguje dobre, pokiaľ nie sú problémy so stratou paketov na bránu. Kontrolná brána nevie, čo sa deje s komunikáciou mimo kontrolovanej brány, na to sú potrebné ďalšie nástroje: skripty, rekurzívne smerovanie, dynamické smerovacie protokoly.

Väčšina protokolov VPN a tunelových protokolov obsahuje vstavané nástroje na kontrolu aktivity pripojenia, pričom aktivácia kontrolnej brány pre nich predstavuje dodatočné (ale veľmi malé) zaťaženie siete a výkonu zariadenia.

ECMP cesty

Equal-Cost Multi-Path – odosielanie paketov príjemcovi pomocou niekoľkých brán súčasne pomocou algoritmu Round Robin.

Smerovanie ECMP vytvorí správca zadaním viacerých brán pre jednu podsieť (alebo automaticky, ak existujú dve rovnocenné smerovania OSPF).

ECMP sa používa na vyrovnávanie záťaže medzi dvoma kanálmi, teoreticky, ak sú na trase ecmp dva kanály, potom by pre každý paket mal byť odchádzajúci kanál odlišný. Mechanizmus Routing cache však posiela pakety zo spojenia po trase, ktorou prešiel prvý paket, výsledkom čoho je akési vyvažovanie na základe pripojení (vyvažovanie zaťaženia podľa spojenia).

Ak zakážete Routing Cache, pakety v trase ECMP budú zdieľané správne, ale vyskytol sa problém s NAT. Pravidlo NAT spracuje iba prvý paket z pripojenia (zvyšné sa spracujú automaticky) a ukáže sa, že pakety s rovnakou zdrojovou adresou opúšťajú rôzne rozhrania.

Kontrolná brána nefunguje v trasách ECMP (chyba RouterOS). Toto obmedzenie však môžete obísť vytvorením ďalších overovacích trás, ktoré zakážu položky v ECMP.

Filtrovanie pomocou smerovania

Možnosť Typ určuje, čo sa má s balíkom urobiť:

• unicast - odoslať na zadanú bránu (rozhranie)
• blackhole - zahoďte paket
• zakázať, nedostupný - paket zahodiť a odoslať icmp správu odosielateľovi

Filtrovanie sa používa väčšinou vtedy, keď je potrebné zabezpečiť odosielanie paketov nesprávnym smerom, samozrejme to môžete filtrovať cez firewall.

Pár príkladov

Na upevnenie základných vecí o smerovaní.

Typický domáci router

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

1. Statická trasa na 0.0.0.0/0 (predvolená trasa)
2. Pripojená trasa na rozhraní s poskytovateľom
3. Pripojená trasa na rozhraní LAN

Typický domáci router s PPPoE

1. Statická trasa k predvolenej trase, pridaná automaticky. je uvedené vo vlastnostiach pripojenia
2. Pripojená trasa pre pripojenie PPP
3. Pripojená trasa na rozhraní LAN

Typický domáci router s dvoma poskytovateľmi a redundanciou

/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. Statická cesta k predvolenej trase cez prvého poskytovateľa s metrikou 1 a kontrolou dostupnosti brány
2. Statická cesta k predvolenej trase cez druhého poskytovateľa s metrikou 2
3. Prepojené trasy

Prevádzka na 0.0.0.0/0 prechádza cez 10.10.10.1, kým je táto brána dostupná, inak sa prepne na 10.20.20.1

Takúto schému možno považovať za rezerváciu kanála, ale nie je bez nevýhod. Ak dôjde k prerušeniu mimo brány poskytovateľa (napríklad vo vnútri siete operátora), váš router o tom nebude vedieť a bude trasu naďalej považovať za aktívnu.

Typický domáci router s dvoma poskytovateľmi, redundanciou a 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. Statické cesty na kontrolu chck brány
2. ECMP cesta
3. Prepojené trasy

Cesty na kontrolu sú modré (farba neaktívnych trás), ale to nezasahuje do kontrolnej brány. Aktuálna verzia (6.44) RoS dáva automaticky prioritu ECMP trase, ale je lepšie pridať testovacie trasy do iných smerovacích tabuliek (možnosť routing-mark)

Na Speedteste a ďalších podobných stránkach nedôjde k zvýšeniu rýchlosti (ECMP rozdeľuje prevádzku podľa pripojení, nie podľa paketov), ​​no p2p aplikácie by sa mali sťahovať rýchlejšie.

Filtrovanie cez smerovanie

/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. Statická trasa k predvolenej trase
2. Statická trasa na 192.168.200.0/24 cez tunel ipip
3. Zakázanie statickej cesty na 192.168.200.0/24 cez smerovač ISP

Možnosť filtrovania, pri ktorej prevádzka tunela nebude smerovať do smerovača poskytovateľa, keď je rozhranie ipip vypnuté. Takéto schémy sa zriedka vyžadujú, pretože môžete implementovať blokovanie cez firewall.

Smerovacia slučka
Smerovacia slučka – situácia, keď medzi smerovačmi prebehne paket pred vypršaním ttl. Zvyčajne je to výsledok chyby konfigurácie, vo veľkých sieťach sa s tým zaobchádza implementáciou dynamických smerovacích protokolov, v malých - opatrne.

Vyzerá to takto:

Príklad (najjednoduchší), ako získať podobný výsledok:

Príklad smerovacej slučky nemá praktické využitie, ale ukazuje, že smerovače nemajú žiadnu predstavu o smerovacej tabuľke svojho suseda.

Základné smerovanie pravidiel a ďalšie smerovacie tabuľky

Pri výbere trasy router používa iba jedno pole z hlavičky paketu (Dst. Address) - ide o základné smerovanie. Smerovanie na základe iných podmienok, ako je zdrojová adresa, typ prevádzky (ToS), vyvažovanie bez ECMP, patrí do Policy Base Routing (PBR) a používa ďalšie smerovacie tabuľky.

Špecifickejšia trasa je hlavné pravidlo výberu trasy v rámci smerovacej tabuľky.

Štandardne sú všetky pravidlá smerovania pridané do hlavnej tabuľky. Administrátor môže vytvoriť ľubovoľný počet ďalších smerovacích tabuliek a smerovať do nich pakety. Pravidlá v rôznych tabuľkách nie sú vo vzájomnom rozpore. Ak balík nenájde vhodné pravidlo v zadanej tabuľke, prejde do hlavnej tabuľky.

Príklad s distribúciou cez bránu firewall:

• 192.168.100.10 -> 8.8.8.8
  1. Premávka z 192.168.100.10 je označená via-isp1 в [Prerouting|Mangle]
  2. Vo fáze smerovania v tabuľke via-isp1 hľadá cestu do 8.8.8.8
  3. Trasa nájdená, prevádzka je odoslaná na bránu 10.10.10.1
• 192.168.200.20 -> 8.8.8.8
  1. Premávka z 192.168.200.20 je označená via-isp2 в [Prerouting|Mangle]
  2. Vo fáze smerovania v tabuľke via-isp2 hľadá cestu do 8.8.8.8
  3. Trasa nájdená, prevádzka je odoslaná na bránu 10.20.20.1
• Ak sa jedna z brán (10.10.10.1 alebo 10.20.20.1) stane nedostupnou, paket pôjde na stôl hlavné a bude tam hľadať vhodnú trasu

Otázky terminológie

RouterOS má určité problémy s terminológiou.
Pri práci s pravidlami v [IP]->[Routes] je uvedená smerovacia tabuľka, aj keď je napísané, že štítok:

В [IP]->[Routes]->[Rule] všetko je správne, v stave označenia v akcii tabuľky:

Ako poslať paket do konkrétnej smerovacej tabuľky

RouterOS poskytuje niekoľko nástrojov:

• Pravidlá v [IP]->[Routes]->[Rules]
• Značky trasy (action=mark-routing) V [IP]->[Firewall]->[Mangle]
• VRF

predpisy [IP]->[Route]->[Rules]
Pravidlá sú spracované postupne, ak paket vyhovuje podmienkam pravidla, ďalej neprejde.

Pravidlá smerovania umožňujú rozšíriť možnosti smerovania, pričom sa spoliehajú nielen na adresu príjemcu, ale aj na zdrojovú adresu a rozhranie, na ktorom bol paket prijatý.

Pravidlá pozostávajú z podmienok a akcie:

• Podmienky. Prakticky si zopakujte zoznam znakov, ktorými sa balík kontroluje vo FIB, chýba už len ToS.
• Činnosť
  • vyhľadávanie - odoslanie paketu na stôl
  • vyhľadávanie iba v tabuľke - uzamknutie balíka v tabuľke, ak sa trasa nenájde, balík neprejde do hlavnej tabuľky
  • drop - drop paket
  • nedostupný - zahoďte paket s upozornením odosielateľa

Vo FIB sa prevádzka miestnych procesov spracováva obchádzaním pravidiel [IP]->[Route]->[Rules]:

značkovanie [IP]->[Firewall]->[Mangle]
Smerovacie štítky vám umožňujú nastaviť bránu pre paket pomocou takmer akýchkoľvek podmienok brány firewall:

Prakticky preto, že nie všetky dávajú zmysel a niektoré môžu fungovať nestabilne.

Balík môžete označiť dvoma spôsobmi:

• Okamžite položiť smerovacia značka
• Dajte prvý spojenie-značka, potom na základe spojenie-značka položiť smerovacia značka

V článku o firewalloch som napísal, že je vhodnejšia druhá možnosť. znižuje zaťaženie cpu, v prípade značenia trás - to nie je úplne pravda. Tieto spôsoby označovania nie sú vždy rovnocenné a zvyčajne sa používajú na riešenie rôznych problémov.

Príklady použitia

Prejdime na príklady použitia Policy Base Routing, je na nich oveľa jednoduchšie ukázať, prečo je toto všetko potrebné.

MultiWAN a návrat odchádzajúcej (výstupnej) prevádzky
Častý problém s konfiguráciou MultiWAN: Mikrotik je dostupný z internetu len cez „aktívneho“ poskytovateľa.

Smerovaču je jedno na akú ip prišla požiadavka, pri generovaní odpovede bude hľadať cestu v smerovacej tabuľke, kde je aktívna cesta cez isp1. Ďalej, takýto paket bude s najväčšou pravdepodobnosťou filtrovaný na ceste k príjemcovi.

Ďalší zaujímavý bod. Ak je na rozhraní ether1 nakonfigurovaný „jednoduchý“ zdrojový nat: /ip fi nat add out-interface=ether1 action=masquerade balík bude online s src. address=10.10.10.100, čo všetko ešte zhoršuje.

Existuje niekoľko spôsobov, ako problém vyriešiť, ale každý z nich bude vyžadovať ďalšie smerovacie tabuľky:

/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

Použitie [IP]->[Route]->[Rules]
Zadajte smerovaciu tabuľku, ktorá sa použije pre pakety so zadanou zdrojovou 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

Môže sa použiť action=lookup, ale v prípade lokálnej odchádzajúcej prevádzky táto možnosť úplne vylučuje pripojenia z nesprávneho rozhrania.

• Systém vygeneruje paket odpovede so Src. Adresa: 10.20.20.200
• Kontroluje sa krok Rozhodnutia o smerovaní(2). [IP]->[Routes]->[Rules] a paket je odoslaný do smerovacej tabuľky over-isp2
• Podľa smerovacej tabuľky musí byť paket odoslaný na bránu 10.20.20.1 cez rozhranie ether2

Táto metóda nevyžaduje funkčný Connection Tracker, na rozdiel od použitia tabuľky Mangle.

Použitie [IP]->[Firewall]->[Mangle]
Spojenie začína prichádzajúcim paketom, preto ho označíme (action=mark-connection), pre odchádzajúce pakety z označeného spojenia nastavte smerovací štítok (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

Ak je na jednom rozhraní nakonfigurovaných niekoľko ips, môžete podmienku pridať dst-address byť si istý.

• Paket otvorí spojenie na rozhraní ether2. Balík ide do [INPUT|Mangle] ktorý hovorí, že všetky pakety zo spojenia treba označiť ako od-isp2
• Systém vygeneruje paket odpovede so Src. Adresa: 10.20.20.200
• V štádiu rozhodnutia o smerovaní (2) sa paket v súlade so smerovacou tabuľkou odošle na bránu 10.20.20.1 cez rozhranie ether1. Môžete si to overiť prihlásením balíkov [OUTPUT|Filter]
• Na javisku [OUTPUT|Mangle] skontroluje sa štítok pripojenia od-isp2 a paket dostane označenie trasy over-isp2
• Krok Routing Adjument(3) skontroluje prítomnosť smerovacieho štítka a odošle ho do príslušnej smerovacej tabuľky
• Podľa smerovacej tabuľky musí byť paket odoslaný na bránu 10.20.20.1 cez rozhranie ether2

MultiWAN a spätná prevádzka dst-nat

Príklad je zložitejší, čo robiť, ak je za routerom na súkromnej podsieti server (napríklad web) a potrebujete k nemu poskytnúť prístup cez niektorého z poskytovateľov.

/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

Podstata problému bude rovnaká, riešenie je podobné možnosti Firewall Mangle, použijú sa iba iné reťazce:

/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

Diagram nezobrazuje NAT, ale myslím, že je všetko jasné.

MultiWAN a odchádzajúce pripojenia

Možnosti PBR môžete použiť na vytvorenie viacerých pripojení vpn (v príklade SSTP) z rôznych rozhraní smerovača.

Ďalšie smerovacie tabuľky:

/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

Označenie balenia:

/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

Jednoduché pravidlá NAT, inak paket opustí rozhranie s nesprávnym Src. adresa:

/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

Pri analýze:

• Router vytvára tri SSTP procesy
• Vo fáze rozhodnutia o smerovaní (2) sa pre tieto procesy vyberie trasa na základe hlavnej tabuľky smerovania. Z tej istej cesty paket prijíma Src. Adresa viazaná na rozhranie ether1
• В [Output|Mangle] pakety z rôznych spojení dostávajú rôzne označenia
• Pakety vstupujú do tabuliek zodpovedajúcich označeniam vo fáze nastavenia smerovania a prijímajú novú cestu na odosielanie paketov
• Ale balíčky stále majú Src. Adresa z etheru1 na pódiu [Nat|Srcnat] adresa je nahradená podľa rozhrania

Zaujímavé je, že na smerovači uvidíte nasledujúcu tabuľku pripojenia:

Connection Tracker funguje skôr [Mangle] и [Srcnat], takže všetky spojenia prichádzajú z rovnakej adresy, ak sa pozriete podrobnejšie, tak v Replay Dst. Address po NAT budú adresy:

Na serveri VPN (jeden mám na testovacej stolici) môžete vidieť, že všetky pripojenia pochádzajú zo správnych adries:

Držte cestu
Existuje jednoduchší spôsob, môžete jednoducho zadať špecifickú bránu pre každú z adries:

/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

Ale takéto trasy ovplyvnia nielen odchádzajúcu, ale aj tranzitnú dopravu. Navyše, ak nepotrebujete, aby návštevnosť servera vpn prechádzala nevhodnými komunikačnými kanálmi, budete musieť pridať ďalších 6 pravidiel [IP]->[Routes]с type=blackhole. V predchádzajúcej verzii - 3 pravidlá v [IP]->[Route]->[Rules].

Distribúcia užívateľských spojení komunikačnými kanálmi

Jednoduché, každodenné úlohy. Opäť budú potrebné ďalšie smerovacie tabuľky:

/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

použitím [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

Ak sa používa action=lookup, potom, keď je jeden z kanálov zakázaný, prevádzka prejde na hlavnú tabuľku a prejde cez pracovný kanál. Či je to potrebné alebo nie, závisí od úlohy.

Pomocou značiek v [IP]->[Firewall]->[Mangle]
Jednoduchý príklad so zoznamami IP adries. V zásade možno použiť takmer akékoľvek podmienky. Jedinou výhradou vrstvy 7, aj keď je spárovaná so štítkami pripojení, sa môže zdať, že všetko funguje správne, ale časť prevádzky bude stále smerovať nesprávnym smerom.

/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

Používateľov môžete „uzamknúť“ v jednej smerovacej tabuľke [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

Buď cez [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
Dodatočná podmienka dst-address-type=!local je potrebné, aby sa prevádzka od používateľov dostávala do lokálnych procesov smerovača (dns, winbox, ssh, ...). Ak je k smerovaču pripojených niekoľko lokálnych podsietí, je potrebné zabezpečiť, aby prevádzka medzi nimi nesmerovala do internetu, napr. dst-address-table.

V príklade použitia [IP]->[Route]->[Rules] neexistujú žiadne takéto výnimky, ale návštevnosť dosahuje miestne procesy. Faktom je, že dostať sa do balíka FIB označeného v [PREROUTING|Mangle] má označenie trasy a prechádza do inej smerovacej tabuľky ako hlavnej, kde nie je žiadne lokálne rozhranie. V prípade Routing Rules sa najprv skontroluje, či je paket určený pre lokálny proces a až vo fáze User PBR ide do zadanej smerovacej tabuľky.

použitím [IP]->[Firewall]->[Mangle action=route]
Táto akcia funguje iba v [Prerouting|Mangle] a umožňuje vám nasmerovať prevádzku na zadanú bránu bez použitia ďalších smerovacích tabuliek, pričom priamo zadáte adresu brány:

/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

účinok route má nižšiu prioritu ako pravidlá smerovania ([IP]->[Route]->[Rules]). V prípade značiek trasy všetko závisí od polohy pravidiel, ak je pravidlo s action=route v hodnote viac ako action=mark-route, potom sa použije (bez ohľadu na príznak passtrough), inak značenie trasy.
Na wiki je o tejto akcii veľmi málo informácií a všetky závery sa získavajú experimentálne, v každom prípade som nenašiel možnosti, keď použitie tejto možnosti dáva výhody oproti ostatným.

Dynamické vyvažovanie založené na PPC

Per Connection Classifier - je flexibilnejší analóg ECMP. Na rozdiel od ECMP rozdeľuje prevádzku podľa spojení prísnejšie (ECMP nevie nič o spojeniach, ale pri spárovaní s Routing Cache sa získa niečo podobné).

PCC berie špecifikované polia z hlavičky ip, skonvertuje ich na 32-bitovú hodnotu a vydelí menovateľ. Zvyšok delenia sa porovná so špecifikovaným zvyšok a ak sa zhodujú, použije sa zadaná akcia. viac. Znie to šialene, ale funguje to.

Príklad s tromi adresami:

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

Príklad dynamickej distribúcie návštevnosti podľa src.address medzi tromi kanálmi:

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

Pri označovaní trás existuje ďalšia podmienka: in-interface=br-lan, bez toho pod action=mark-routing odozvu prevádzka z internetu dostane a v súlade so smerovacími tabuľkami bude smerovať späť k poskytovateľovi.

Prepínanie komunikačných kanálov

Check ping je dobrý nástroj, ale kontroluje len spojenie s najbližším IP peerom, siete providerov sa zvyčajne skladajú z veľkého počtu routerov a prerušenie spojenia môže nastať aj mimo najbližšieho peeru a potom sú tu páteřní telekomunikační operátori, ktorí môžu tiež majú problémy, vo všeobecnosti kontrola ping neukazuje vždy aktuálne informácie o prístupe do globálnej siete.
Ak poskytovatelia a veľké korporácie majú dynamický smerovací protokol BGP, potom domáci a kancelárski používatelia musia nezávisle zistiť, ako skontrolovať prístup na internet prostredníctvom špecifického komunikačného kanála.

Zvyčajne sa používajú skripty, ktoré prostredníctvom určitého komunikačného kanála skontrolujú dostupnosť adresy IP na internete a vyberú niečo spoľahlivé, napríklad google dns: 8.8.8.8. 8.8.4.4. Ale v komunite Mikrotik je na to prispôsobený zaujímavejší nástroj.

Pár slov o rekurzívnom smerovaní
Rekurzívne smerovanie je potrebné pri budovaní Multihop BGP peeringu a do článku o základoch statického smerovania sa dostalo len vďaka prefíkaným používateľom MikroTiku, ktorí prišli na to, ako použiť rekurzívne smerovanie spárované s kontrolnou bránou na prepínanie komunikačných kanálov bez ďalších skriptov.

Je čas pochopiť možnosti rozsahu / cieľového rozsahu vo všeobecnosti a ako je trasa viazaná na rozhranie:

1. Trasa vyhľadá rozhranie na odoslanie paketu na základe hodnoty jeho rozsahu a všetkých položiek v hlavnej tabuľke s menšími alebo rovnakými hodnotami cieľového rozsahu
2. Z nájdených rozhraní sa vyberie to, cez ktoré môžete poslať paket na zadanú bránu
3. Rozhranie nájdeného pripojeného záznamu sa vyberie na odoslanie paketu na bránu

V prítomnosti rekurzívnej cesty sa všetko deje rovnako, ale v dvoch fázach:

• 1-3 K pripojeným trasám sa pridá ešte jedna trasa, cez ktorú je možné dosiahnuť zadanú bránu
• 4-6 Nájdenie trasy prepojenej s trasou pre „strednú“ bránu

Všetky manipulácie s rekurzívnym vyhľadávaním prebiehajú v RIB a do FIB sa prenesie iba konečný výsledok: 0.0.0.0/0 via 10.10.10.1 on ether1.

Príklad použitia rekurzívneho smerovania na prepínanie trás

Konfigurácia:

/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

Môžete skontrolovať, že pakety budú odoslané 10.10.10.1:

Check gateway nevie nič o rekurzívnom smerovaní a len posiela pingy na adresu 8.8.8.8, ktorá je (na základe hlavnej tabuľky) dosiahnuteľná cez bránu 10.10.10.1.

Ak dôjde k strate komunikácie medzi 10.10.10.1 a 8.8.8.8, potom je trasa odpojená, ale pakety (vrátane testovacích pingov) do 8.8.8.8 naďalej prechádzajú cez 10.10.10.1:

Ak dôjde k strate spojenia na ether1, nastane nepríjemná situácia, keď pakety pred 8.8.8.8 prechádzajú cez druhého poskytovateľa:

Toto je problém, ak používate NetWatch na spúšťanie skriptov, keď 8.8.8.8 nie je k dispozícii. Ak je prepojenie prerušené, NetWatch bude jednoducho fungovať cez záložný komunikačný kanál a bude predpokladať, že je všetko v poriadku. Vyriešené pridaním ďalšej trasy filtra:

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

Existuje na habré článok, kde sa situácia s NetWatch zaoberá podrobnejšie.

A áno, pri použití takejto rezervácie bude adresa 8.8.8.8 napevno pripojená k jednému z poskytovateľov, takže vybrať si ju ako zdroj dns nie je dobrý nápad.

Niekoľko slov o virtuálnom smerovaní a presmerovaní (VRF)

Technológia VRF je navrhnutá na vytvorenie niekoľkých virtuálnych smerovačov v rámci jedného fyzického, túto technológiu široko používajú telekomunikační operátori (zvyčajne v spojení s MPLS) na poskytovanie služieb L3VPN klientom s prekrývajúcimi sa adresami podsiete:

Ale VRF v Mikrotiku je organizovaný na základe smerovacích tabuliek a má množstvo nevýhod, napríklad lokálne ip adresy smerovača sú dostupné zo všetkých VRF, môžete si prečítať viac по ссылке.

príklad konfigurácie vrf:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.200.1/24 interface=ether2 network=192.168.200.0

Zo zariadenia pripojeného k ether2 vidíme, že ping ide na adresu smerovača z iného vrf (a to je problém), zatiaľ čo ping nejde na internet:

Ak chcete získať prístup na internet, musíte zaregistrovať ďalšiu cestu, ktorá pristupuje k hlavnej tabuľke (v terminológii vrf sa to nazýva únik trasy):

/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

Tu sú dva spôsoby úniku trasy: pomocou smerovacej tabuľky: 172.17.0.1@main a pomocou názvu rozhrania: 172.17.0.1%wlan1.

A nastavte značenie pre spätnú dopravu [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 

Podsiete s rovnakou adresou
Organizácia prístupu do podsietí s rovnakou adresou na rovnakom routeri pomocou VRF a sieťovej mapy:

Základná konfigurácia:

/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

pravidlá brány firewall:

#Маркируем пакеты для отправки в правильную таблицу маршрутизации
/ip firewall mangle
add chain=prerouting dst-address=192.168.101.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf1 passthrough=no
add chain=prerouting dst-address=192.168.102.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf2 passthrough=no

#Средствами netmap заменяем адреса "эфимерных" подсетей на реальные подсети
/ip firewall nat
add chain=dstnat dst-address=192.168.101.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24
add chain=dstnat dst-address=192.168.102.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24

Pravidlá smerovania pre spätnú prevádzku:

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

Pridanie trás prijatých cez dhcp do danej smerovacej tabuľky
VRF môže byť zaujímavé, ak potrebujete automaticky pridať dynamickú cestu (napríklad z dhcp klienta) do konkrétnej smerovacej tabuľky.

Pridanie rozhrania do vrf:

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

Pravidlá pre odosielanie prevádzky (odchádzajúcej a tranzitnej) cez tabuľku over-isp1:

/ip firewall mangle
add chain=output out-interface=!br-lan action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting in-interface=br-lan dst-address-type=!local action=mark-routing new-routing-mark=over-isp1 passthrough=no

Ďalšia falošná trasa pre odchádzajúce smerovanie do práce:

/interface bridge
add name=bare

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

Táto cesta je potrebná len na to, aby miestne odchádzajúce pakety mohli predtým prejsť rozhodnutím o smerovaní (2). [OUTPUT|Mangle] a získajte smerovací štítok, ak sú na smerovači iné aktívne cesty pred 0.0.0.0/0 v hlavnej tabuľke, nie je to potrebné.

reťaz connected-in и dynamic-in в [Routing] -> [Filters]

Filtrovanie trás (prichádzajúce a odchádzajúce) je nástroj, ktorý sa zvyčajne používa v spojení s protokolmi dynamického smerovania (a preto je dostupný až po inštalácii balíka routing), ale v prichádzajúcich filtroch sú dva zaujímavé reťazce:

• connect-in — filtrovanie pripojených trás
• dynamic-in - filtrovanie dynamických ciest prijímaných PPP a DCHP

Filtrovanie vám umožňuje nielen zahodiť trasy, ale aj zmeniť množstvo možností: vzdialenosť, smerovacia značka, komentár, rozsah, cieľový rozsah, ...

Toto je veľmi precízny nástroj a ak niečo dokážete bez Routing Filters (ale nie skriptov), ​​tak Routing Filters nepoužívajte, nezamieňajte seba a tých, ktorí budú router konfigurovať po vás. V kontexte dynamického smerovania sa budú filtre smerovania používať oveľa častejšie a produktívnejšie.

Nastavenie značky smerovania pre dynamické trasy
Príklad z domáceho smerovača. Mám nakonfigurované dve pripojenia VPN a prevádzka v nich by mala byť zabalená v súlade so smerovacími tabuľkami. Zároveň chcem, aby sa trasy vytvárali automaticky pri aktivácii rozhrania:

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

Neviem prečo, pravdepodobne chyba, ale ak vytvoríte vrf pre rozhranie ppp, cesta k 0.0.0.0/0 sa stále dostane do hlavnej tabuľky. Inak by bolo všetko ešte jednoduchšie.

Vypnutie pripojených trás
Niekedy sa to vyžaduje:

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

Nástroje na ladenie

RouterOS poskytuje množstvo nástrojov na ladenie smerovania:

• [Tool]->[Tourch] - umožňuje prezerať pakety na rozhraniach
• /ip route check - umožňuje vidieť, na ktorú bránu bude paket odoslaný, nefunguje so smerovacími tabuľkami
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - ping a sledovanie pomocou špecifikovanej smerovacej tabuľky
• action=log в [IP]->[Firewall] - vynikajúci nástroj, ktorý vám umožňuje sledovať cestu paketu pozdĺž toku paketov, táto akcia je dostupná vo všetkých reťazcoch a tabuľkách

Zdroj: hab.com