Základy statického směrování v Mikrotik RouterOS

Směrování je proces hledání nejlepší cesty pro přenos paketů přes sítě TCP/IP. Každé zařízení připojené k síti IPv4 obsahuje procesní a směrovací tabulky.

Tento článek není HOWTO, popisuje statické směrování v RouterOS na příkladech, schválně jsem vynechal zbytek nastavení (například srcnat pro přístup na internet), takže pochopení látky vyžaduje určitou úroveň znalostí sítí a RouterOS.

Přepínání a směrování

Přepínání je proces výměny paketů v rámci jednoho segmentu Layer2 (Ethernet, ppp, ...). Pokud zařízení vidí, že se příjemce paketu nachází ve stejné ethernetové podsíti jako on, zjistí mac adresu pomocí protokolu arp a přenese paket přímo, přičemž obchází router. Spojení ppp (point-to-point) může mít pouze dva účastníky a paket je vždy odeslán na jednu adresu 0xff.

Směrování je proces přenosu paketů mezi segmenty vrstvy 2. Pokud chce zařízení odeslat paket, jehož příjemce je mimo ethernetový segment, podívá se do jeho směrovací tabulky a předá paket bráně, která ví, kam má paket poslat dál (nebo nemusí vědět, původní odesílatel paketu si toho není vědom).

Nejjednodušší způsob, jak si představit směrovač, je jako zařízení připojené ke dvěma nebo více segmentům Layer2 a schopné mezi nimi předávat pakety určením nejlepší cesty ze směrovací tabulky.

Pokud všemu rozumíte, nebo jste to již věděli, pak čtěte dále. Pro zbytek důrazně doporučuji, abyste se seznámili s malým, ale velmi prostorným článek.

Směrování v RouterOS a PacketFlow

Téměř všechny funkce související se statickým směrováním jsou v balíčku systém. Igelitová taška Směrování přidává podporu pro dynamické směrovací algoritmy (RIP, OSPF, BGP, MME), směrovací filtry a BFD.

Hlavní nabídka pro nastavení směrování: [IP]->[Route]. Složitá schémata mohou vyžadovat, aby pakety byly předem označeny směrovací značkou v: [IP]->[Firewall]->[Mangle] (řetězy PREROUTING и OUTPUT).

Na PacketFlow jsou tři místa, kde se rozhodují o směrování paketů IP:

1. Směrování paketů přijatých směrovačem. V této fázi se rozhoduje, zda paket půjde do lokálního procesu, nebo bude poslán dále do sítě. Přijímají tranzitní balíčky Výstupní rozhraní
2. Směrování místních odchozích paketů. Přijímají odchozí pakety Výstupní rozhraní
3. Další krok směrování pro odchozí pakety vám umožňuje změnit rozhodnutí o směrování v [Output|Mangle]

• Cesta paketu v blocích 1, 2 závisí na pravidlech v [IP]->[Route]
• Cesta paketu v bodech 1, 2 a 3 závisí na pravidlech v [IP]->[Route]->[Rules]
• Cestu balíku v blocích 1, 3 lze ovlivnit pomocí [IP]->[Firewall]->[Mangle]

RIB, FIB, Routing Cache

Informační základna směrování
Základ, ve kterém se shromažďují cesty z dynamických směrovacích protokolů, cesty z ppp a dhcp, statické a připojené cesty. Tato databáze obsahuje všechny cesty kromě cest filtrovaných administrátorem.

Podmíněně, to můžeme předpokládat [IP]->[Route] zobrazí RIB.

Předávací informační základna

Základna, ve které se shromažďují nejlepší trasy z RIB. Všechny cesty ve FIB jsou aktivní a slouží k předávání paketů. Pokud se cesta stane neaktivní (zakázána administrátorem (systémem), nebo není aktivní rozhraní, přes které má být paket odeslán), je trasa odstraněna z FIB.

K rozhodnutí o směrování používá tabulka FIB následující informace o paketu IP:

• Zdrojová adresa
• Cílová adresa
• zdrojové rozhraní
• Směrovací značka
• smluvní podmínky (DSCP)

Vstup do FIB balíčku prochází následujícími fázemi:

• Je balíček určen pro proces místního routeru?
• Podléhá paket systémovým nebo uživatelským pravidlům PBR?
  • Pokud ano, paket je odeslán do zadané směrovací tabulky
• Paket je odeslán do hlavní tabulky

Podmíněně, to můžeme předpokládat [IP]->[Route Active=yes] zobrazí FIB.

Směrovací mezipaměť
Mechanismus ukládání do mezipaměti trasy. Router si pamatuje, kam byly pakety odeslány, a pokud existují podobné (pravděpodobně ze stejného připojení), pustí je po stejné trase, aniž by kontroloval FIB. Mezipaměť trasy se pravidelně maže.

Pro administrátory RouterOS nevytvořili nástroje pro prohlížení a správu Router Cache, ale když ji lze deaktivovat v [IP]->[Settings].

Tento mechanismus byl odstraněn z jádra linux 3.6, ale RouterOS stále používá jádro 3.3.5, možná Routing cahce je jedním z důvodů.

Dialog pro přidání trasy

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

1. Podsíť, pro kterou chcete vytvořit trasu (výchozí: 0.0.0.0/0)
2. IP brány nebo rozhraní, na které bude paket odeslán (může jich být několik, viz ECMP níže)
3. Kontrola dostupnosti brány
4. Typ záznamu
5. Vzdálenost (metrická) pro trasu
6. Směrovací tabulka
7. IP pro místní odchozí pakety přes tuto cestu
8. Účel rozsahu a cílového rozsahu je napsán na konci článku.

Traťové příznaky

• X - Cesta je zakázána administrátorem (disabled=yes)
• A - Trasa se používá k odesílání paketů
• D – Trasa přidána dynamicky (BGP, OSPF, RIP, MME, PPP, DHCP, Connected)
• C - Podsíť je připojena přímo k routeru
• S - Statická trasa
• r,b,o,m - Trasa přidaná jedním z dynamických směrovacích protokolů
• B,U,P - Filtrování trasy (zahazuje pakety místo přenosu)

Co zadat v bráně: IP adresa nebo rozhraní?

Systém umožňuje specifikovat obojí, přitom nenadává a nenapovídá, pokud jste něco udělali špatně.

IP adresa
Adresa brány musí být dostupná přes Layer2. Pro Ethernet to znamená, že router musí mít adresu ze stejné podsítě na jednom z aktivních ip rozhraní, pro ppp, že adresa brány je zadána na jednom z aktivních rozhraní jako adresa podsítě.
Pokud není splněna podmínka přístupnosti pro Layer2, je trasa považována za neaktivní a nespadá do FIB.

rozhraní
Vše je složitější a chování routeru závisí na typu rozhraní:

• Spojení PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) předpokládá pouze dva účastníky a paket bude vždy odeslán k bráně k přenosu, pokud brána zjistí, že příjemce je sama, pak paket předá jeho lokální proces.
  
• Ethernet předpokládá přítomnost mnoha účastníků a bude posílat požadavky na rozhraní arp s adresou příjemce paketu, což je u připojených tras očekávané a zcela běžné chování.
  Ale když se pokusíte použít rozhraní jako cestu pro vzdálenou podsíť, dostanete následující situaci: trasa je aktivní, ping na bránu projde, ale nedosáhne příjemce ze zadané podsítě. Pokud se podíváte na rozhraní přes sniffer, uvidíte arp požadavky s adresami ze vzdálené podsítě.
  

Pokuste se zadat adresu IP jako bránu, kdykoli je to možné. Výjimkou jsou připojené trasy (vytvořené automaticky) a rozhraní PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*).

OpenVPN neobsahuje hlavičku PPP, ale k vytvoření trasy můžete použít název rozhraní OpenVPN.

Konkrétnější trasa

Základní směrovací pravidlo. Trasa, která popisuje menší podsíť (s největší maskou podsítě), má přednost při rozhodování o směrování paketu. Pozice záznamů ve směrovací tabulce není pro výběr relevantní – hlavní pravidlo je Přesnější.

Všechny cesty ze zadaného schématu jsou aktivní (umístěné ve FIB). ukazují na různé podsítě a nejsou ve vzájemném konfliktu.

Pokud se jedna z bran stane nedostupnou, přidružená trasa bude považována za neaktivní (odstraněná z FIB) a pakety budou prohledávány ze zbývajících tras.

Trasa s podsítí 0.0.0.0/0 má někdy zvláštní význam a nazývá se „Výchozí trasa“ nebo „Brána poslední instance“. Ve skutečnosti v tom není nic magického a prostě zahrnuje všechny možné IPv4 adresy, ale tyto názvy dobře vystihují jeho úkol – označuje bránu, kam přeposílat pakety, pro které neexistují jiné přesnější cesty.

Maximální možná maska ​​podsítě pro IPv4 je /32, tato trasa ukazuje na konkrétního hostitele a lze ji použít ve směrovací tabulce.

Pochopení specifičtější cesty je základem jakéhokoli zařízení TCP/IP.

Vzdálenost

Vzdálenosti (nebo metriky) jsou vyžadovány pro administrativní filtrování tras do jedné podsítě přístupné přes více bran. Trasa s nižší metrikou je považována za prioritu a bude zahrnuta do FIB. Pokud trasa s nižší metrikou přestane být aktivní, bude nahrazena trasou s vyšší metrikou ve FIB.

Pokud existuje několik tras do stejné podsítě se stejnou metrikou, router přidá do tabulky FIB pouze jednu z nich podle své vnitřní logiky.

Metrika může nabývat hodnoty od 0 do 255:

• 0 - Metrika pro připojené trasy. Vzdálenost 0 nemůže být nastavena administrátorem
• 1-254 – Metriky dostupné administrátorovi pro nastavení tras. Metriky s nižší hodnotou mají vyšší prioritu
• 255 – Metrika dostupná administrátorovi pro nastavení tras. Na rozdíl od 1-254 zůstává trasa s metrikou 255 vždy neaktivní a nespadá do FIB
• konkrétní metriky. Trasy odvozené z dynamických směrovacích protokolů mají standardní metrické hodnoty

zkontrolovat bránu

Check gateway je rozšíření MikroTik RoutesOS pro kontrolu dostupnosti brány přes icmp nebo arp. Jednou za 10 sekund (nelze změnit) je odeslán požadavek na bránu, pokud odpověď není přijata dvakrát, je trasa považována za nedostupnou a je odstraněna z FIB. Pokud je kontrolní brána deaktivována, kontrolní trasa pokračuje a po jedné úspěšné kontrole se trasa znovu aktivuje.

Check gateway zakáže položku, ve které je nakonfigurována, a všechny ostatní položky (ve všech směrovacích tabulkách a ecmp cestách) se zadanou bránou.

Obecně platí, že kontrolní brána funguje dobře, pokud nedochází k problémům se ztrátou paketů k bráně. Kontrolní brána neví, co se děje s komunikací mimo kontrolovanou bránu, to vyžaduje další nástroje: skripty, rekurzivní směrování, dynamické směrovací protokoly.

Většina protokolů VPN a tunelů obsahuje vestavěné nástroje pro kontrolu aktivity připojení, povolení kontrolní brány pro ně představuje další (ale velmi malé) zatížení sítě a výkonu zařízení.

ECMP trasy

Stejné náklady na více cest - odesílání paketů příjemci pomocí několika bran současně pomocí algoritmu Round Robin.

Trasu ECMP vytváří administrátor zadáním více bran pro jednu podsíť (nebo automaticky, pokud existují dvě rovnocenné trasy OSPF).

ECMP se používá pro vyrovnávání zátěže mezi dvěma kanály, pokud teoreticky existují dva kanály v trase ecmp, pak by měl být pro každý paket odchozí kanál jiný. Mechanismus Routing cache ale posílá pakety ze spojení po trase, kterou prošel první paket, v důsledku toho dostáváme jakési vyvažování na základě spojení (vyvažování zatížení na spojení).

Pokud zakážete Routing Cache, pakety v trase ECMP budou sdíleny správně, ale je problém s NAT. Pravidlo NAT zpracovává pouze první paket ze spojení (zbytek se zpracovává automaticky) a ukazuje se, že pakety se stejnou zdrojovou adresou opouštějí různá rozhraní.

Kontrolní brána nefunguje v trasách ECMP (chyba RouterOS). Toto omezení však můžete obejít vytvořením dalších ověřovacích cest, které zakážou položky v ECMP.

Filtrování pomocí směrování

Možnost Typ určuje, co se má s balíčkem dělat:

• unicast - odeslat na zadanou bránu (rozhraní)
• blackhole - zahodit balíček
• zakázat, nedostupný - paket zahodit a odeslat icmp zprávu odesílateli

Filtrování se obvykle používá, když je potřeba zabezpečit odesílání paketů po špatné cestě, samozřejmě to můžete filtrovat přes firewall.

Pár příkladů

Upevnit základní věci o směrování.

Typický domácí 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 (výchozí trasa)
2. Připojená trasa na rozhraní s poskytovatelem
3. Připojená trasa na rozhraní LAN

Typický domácí router s PPPoE

1. Statická trasa k výchozí trase, přidána automaticky. je specifikováno ve vlastnostech připojení
2. Připojená trasa pro připojení PPP
3. Připojená trasa na rozhraní LAN

Typický domácí router se dvěma poskytovateli a redundancí

/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 výchozí trase přes prvního poskytovatele s metrikou 1 a kontrolou dostupnosti brány
2. Statická trasa k výchozí trase přes druhého poskytovatele s metrikou 2
3. Propojené trasy

Provoz na 0.0.0.0/0 prochází 10.10.10.1, dokud je tato brána dostupná, jinak se přepne na 10.20.20.1

Takové schéma lze považovat za rezervaci kanálu, ale není bez nevýhod. Pokud dojde k přerušení mimo bránu poskytovatele (například uvnitř sítě operátora), váš router o tom nebude vědět a bude trasu nadále považovat za aktivní.

Typický domácí router se dvěma poskytovateli, redundance 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 pro kontrolu chck brány
2. ECMP cesta
3. Propojené trasy

Cesty ke kontrole jsou modré (barva neaktivních cest), ale to neovlivňuje kontrolní bránu. Aktuální verze (6.44) RoS dává automaticky prioritu ECMP trase, ale je lepší přidat testovací trasy do jiných směrovacích tabulek (volba routing-mark)

Na Speedtestu a dalších podobných stránkách nedojde ke zvýšení rychlosti (ECMP rozděluje provoz podle připojení, nikoli podle paketů), ale p2p aplikace by se měly stahovat rychleji.

Filtrování přes směrování

/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 výchozí trase
2. Statická cesta k 192.168.200.0/24 přes iipip tunel
3. Zákaz statické cesty na 192.168.200.0/24 přes router ISP

Možnost filtrování, při které provoz tunelu nepůjde do routeru poskytovatele, když je zakázáno rozhraní ipip. Taková schémata jsou zřídka vyžadována, protože můžete implementovat blokování přes firewall.

Směrovací smyčka
Směrovací smyčka – situace, kdy paket běží mezi routery před vypršením ttl. Obvykle je to výsledek konfigurační chyby, ve velkých sítích je ošetřen implementací dynamických směrovacích protokolů, v malých - opatrně.

Vypadá to takto:

Příklad (nejjednodušší), jak získat podobný výsledek:

Příklad směrovací smyčky nemá praktické využití, ale ukazuje, že směrovače nemají ponětí o směrovací tabulce svého souseda.

Základní směrování zásad a další směrovací tabulky

Při volbě cesty router používá pouze jedno pole z hlavičky paketu (Dst. Address) - jde o základní směrování. Směrování na základě dalších podmínek, jako je zdrojová adresa, typ provozu (ToS), vyvažování bez ECMP, patří do Policy Base Routing (PBR) a používá další směrovací tabulky.

Konkrétnější trasa je hlavní pravidlo výběru trasy ve směrovací tabulce.

Ve výchozím nastavení jsou všechna pravidla směrování přidána do hlavní tabulky. Správce může vytvořit libovolný počet dalších směrovacích tabulek a směrovat do nich pakety. Pravidla v různých tabulkách nejsou v rozporu. Pokud balíček nenajde vhodné pravidlo v zadané tabulce, přejde do hlavní tabulky.

Příklad s distribucí přes bránu firewall:

• 192.168.100.10 -> 8.8.8.8
  1. Provoz z 192.168.100.10 bude označen via-isp1 в [Prerouting|Mangle]
  2. Ve fázi směrování v tabulce via-isp1 hledá cestu do 8.8.8.8
  3. Trasa nalezena, provoz je odeslán na bránu 10.10.10.1
• 192.168.200.20 -> 8.8.8.8
  1. Provoz z 192.168.200.20 bude označen via-isp2 в [Prerouting|Mangle]
  2. Ve fázi směrování v tabulce via-isp2 hledá cestu do 8.8.8.8
  3. Trasa nalezena, provoz je odeslán na bránu 10.20.20.1
• Pokud se jedna z bran (10.10.10.1 nebo 10.20.20.1) stane nedostupnou, paket půjde na stůl hlavní a bude tam hledat vhodnou cestu

Terminologické problémy

RouterOS má určité problémy s terminologií.
Při práci s pravidly v [IP]->[Routes] je uvedena směrovací tabulka, ačkoli je napsáno, že štítek:

В [IP]->[Routes]->[Rule] vše je v pořádku, ve stavu štítku v akci tabulky:

Jak odeslat paket do konkrétní směrovací tabulky

RouterOS poskytuje několik nástrojů:

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

Pravidla [IP]->[Route]->[Rules]
Pravidla jsou zpracovávána sekvenčně, pokud paket vyhovuje podmínkám pravidla, dále neprojde.

Pravidla směrování umožňují rozšířit možnosti směrování, přičemž se nespoléhají pouze na adresu příjemce, ale také na zdrojovou adresu a rozhraní, na kterém byl paket přijat.

Pravidla se skládají z podmínek a akce:

• Podmínky. Prakticky zopakujte seznam znaků, kterými se balík kontroluje ve FIB, chybí pouze ToS.
• Činnost
  • lookup - odeslání paketu do tabulky
  • hledat pouze v tabulce - uzamknout balíček v tabulce, pokud nebude cesta nalezena, balíček nepůjde do hlavní tabulky
  • drop - zahodit paket
  • nedostupný - zahoďte paket s upozorněním odesílatele

Ve FIB se provoz na místní procesy zpracovává obcházením pravidel [IP]->[Route]->[Rules]:

značkování [IP]->[Firewall]->[Mangle]
Směrovací štítky vám umožňují nastavit bránu pro paket pomocí téměř jakýchkoli podmínek brány firewall:

Prakticky proto, že ne všechny dávají smysl a některé mohou fungovat nestabilně.

Balíček lze označit dvěma způsoby:

• Okamžitě položit směrovací značka
• Dejte první připojení-značka, pak na základě připojení-značka dát směrovací značka

V článku o firewallech jsem napsal, že je vhodnější druhá možnost. snižuje zátěž cpu, v případě značení tras - není to úplně pravda. Tyto způsoby značení nejsou vždy ekvivalentní a obvykle se používají k řešení různých problémů.

Příklady použití

Přejděme k příkladům použití Policy Base Routing, je na nich mnohem snazší ukázat, proč je to všechno potřeba.

MultiWAN a vrátit odchozí (výstupní) provoz
Častý problém s konfigurací MultiWAN: Mikrotik je dostupný z internetu pouze přes „aktivního“ poskytovatele.

Routeru je jedno na jakou ip požadavek přišel, při generování odpovědi bude hledat cestu v routovací tabulce, kde je aktivní trasa přes isp1. Dále bude takový paket s největší pravděpodobností filtrován na cestě k příjemci.

Další zajímavý bod. Pokud je na rozhraní ether1 nakonfigurován „jednoduchý“ zdrojový nat: /ip fi nat add out-interface=ether1 action=masquerade balíček bude online s src. address=10.10.10.100, což situaci ještě zhoršuje.

Existuje několik způsobů, jak problém vyřešit, ale každý z nich bude vyžadovat další směrovací tabulky:

/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žití [IP]->[Route]->[Rules]
Zadejte směrovací tabulku, která bude použita pro pakety se 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 použít action=lookup, ale pro místní odchozí provoz tato možnost zcela vylučuje připojení z nesprávného rozhraní.

• Systém vygeneruje paket odpovědi s Src. Adresa: 10.20.20.200
• Kontroluje se krok rozhodnutí o směrování(2). [IP]->[Routes]->[Rules] a paket je odeslán do směrovací tabulky over-isp2
• Podle směrovací tabulky musí být paket odeslán na bránu 10.20.20.1 přes rozhraní ether2

Tato metoda nevyžaduje funkční Connection Tracker, na rozdíl od použití tabulky Mangle.

Použití [IP]->[Firewall]->[Mangle]
Spojení začíná příchozím paketem, takže jej označíme (action=mark-connection), pro odchozí pakety z označeného spojení nastavte směrovací štítek (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

Pokud je na jednom rozhraní nakonfigurováno několik ips, můžete podmínku přidat dst-address si být jisti.

• Paket otevře spojení na rozhraní ether2. Balíček jde do [INPUT|Mangle] který říká označit všechny pakety ze spojení jako od-isp2
• Systém vygeneruje paket odpovědi s Src. Adresa: 10.20.20.200
• Ve fázi rozhodnutí o směrování(2) je paket v souladu se směrovací tabulkou odeslán do brány 10.20.20.1 přes rozhraní ether1. Můžete si to ověřit přihlášením balíčků [OUTPUT|Filter]
• Na jevišti [OUTPUT|Mangle] je zkontrolován štítek připojení od-isp2 a paket obdrží značku cesty over-isp2
• Krok Routing Adjusment(3) zkontroluje přítomnost směrovacího štítku a odešle jej do příslušné směrovací tabulky.
• Podle směrovací tabulky musí být paket odeslán na bránu 10.20.20.1 přes rozhraní ether2

MultiWAN a zpětný provoz dst-nat

Složitější příklad je, co dělat, když je za routerem na privátní podsíti server (například web) a potřebujete k němu zajistit přístup přes některého z poskytovatelů.

/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 stejná, řešení je podobné jako u možnosti Firewall Mangle, budou použity pouze jiné řetězce:

/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 neukazuje NAT, ale myslím, že je vše jasné.

MultiWAN a odchozí připojení

Možnosti PBR můžete použít k vytvoření více připojení vpn (v příkladu SSTP) z různých rozhraní routeru.

Další směrovací tabulky:

/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čení balení:

/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á pravidla NAT, jinak paket opustí rozhraní s nesprávným 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

Analýza:

• Router vytváří tři procesy SSTP
• Ve fázi rozhodnutí o směrování (2) je pro tyto procesy vybrána trasa na základě hlavní směrovací tabulky. Ze stejné cesty paket přijímá Src. Adresa vázaná na rozhraní ether1
• В [Output|Mangle] pakety z různých připojení obdrží různé štítky
• Pakety vstupují do tabulek odpovídajících štítkům ve fázi Routing Adjument a obdrží novou trasu pro odesílání paketů.
• Ale balíčky stále mají Src. Adresa z ether1, na pódiu [Nat|Srcnat] adresa je nahrazena podle rozhraní

Zajímavé je, že na routeru uvidíte následující tabulku připojení:

Connection Tracker funguje dříve [Mangle] и [Srcnat], takže všechna spojení pocházejí ze stejné adresy, pokud se podíváte podrobněji, tak v Replay Dst. Address po NAT budou adresy:

Na serveru VPN (jeden mám na testovací stolici) můžete vidět, že všechna připojení pocházejí ze správných adres:

Držte cestu
Existuje jednodušší způsob, můžete jednoduše zadat konkrétní bránu pro každou z adres:

/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

Takové trasy ale ovlivní nejen odchozí, ale i tranzitní dopravu. Navíc, pokud nepotřebujete, aby provoz na vpn serveru procházel nevhodnými komunikačními kanály, budete muset přidat dalších 6 pravidel do [IP]->[Routes]с type=blackhole. V předchozí verzi - 3 pravidla [IP]->[Route]->[Rules].

Distribuce uživatelských spojení komunikačními kanály

Jednoduché, každodenní úkoly. Opět budou potřeba další směrovací tabulky:

/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í [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

Při použití action=lookup, pak když je jeden z kanálů deaktivován, provoz půjde do hlavní tabulky a projde pracovním kanálem. Zda je to nutné nebo ne, závisí na úkolu.

Pomocí označení v [IP]->[Firewall]->[Mangle]
Jednoduchý příklad se seznamy IP adres. V zásadě lze použít téměř jakékoli podmínky. Jediná námitka vrstvy7, i když je spárována se štítky připojení, může se zdát, že vše funguje správně, ale část provozu bude stále jít špatným směrem.

/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

Uživatele můžete „uzamknout“ v jedné směrovací tabulce [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ď skrz [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
Dodatečná podmínka dst-address-type=!local je nutné, aby se provoz od uživatelů dostával do lokálních procesů routeru (dns, winbox, ssh, ...). Pokud je k routeru připojeno více lokálních podsítí, je nutné zajistit, aby provoz mezi nimi nesměřoval do Internetu, např. dst-address-table.

V příkladu použití [IP]->[Route]->[Rules] neexistují žádné takové výjimky, ale provoz zasahuje do místních procesů. Faktem je, že dostat se do balíčku FIB označeného v [PREROUTING|Mangle] má označení trasy a jde do jiné směrovací tabulky než main, kde není žádné místní rozhraní. V případě Pravidel směrování se nejprve zkontroluje, zda je paket určen pro lokální proces a teprve ve fázi User PBR jde do zadané směrovací tabulky.

Použití [IP]->[Firewall]->[Mangle action=route]
Tato akce funguje pouze v [Prerouting|Mangle] a umožňuje nasměrovat provoz na zadanou bránu bez použití dalších směrovacích tabulek přímým zadáním adresy 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

účinek route má nižší prioritu než pravidla směrování ([IP]->[Route]->[Rules]). V případě značek trasy vše závisí na poloze pravidel, pokud je pravidlo s action=route v hodnotě více než action=mark-route, pak bude použit (bez ohledu na příznak passtrough), jinak značení trasy.
Na wiki je o této akci velmi málo informací a všechny závěry jsou získány experimentálně, každopádně jsem nenašel možnosti, kdy použití této možnosti dává výhody oproti ostatním.

Dynamické vyvažování založené na PPC

Per Connection Classifier - je flexibilnější analog ECMP. Na rozdíl od ECMP rozděluje provoz podle spojení přísněji (ECMP neví nic o spojeních, ale při spárování s Routing Cache se získá něco podobného).

PCC bere zadaná pole z hlavičky ip, převede je na 32bitovou hodnotu a vydělí jmenovatel. Zbytek dělení se porovná se zadaným zbytek a pokud se shodují, použije se zadaná akce. více. Zní to šíleně, ale funguje to.

Příklad se třemi 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

Příklad dynamické distribuce provozu podle src.address mezi tři kanály:

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

Při značení tras existuje další podmínka: in-interface=br-lan, bez toho pod action=mark-routing odezvový provoz z internetu dostane a v souladu s routovacími tabulkami půjde zpět k poskytovateli.

Přepínání komunikačních kanálů

Check ping je dobrý nástroj, ale kontroluje pouze spojení s nejbližším IP peerem, sítě poskytovatelů se obvykle skládají z velkého počtu routerů a přerušení spojení může nastat mimo nejbližšího peer, a pak existují páteřní telekomunikační operátoři, kteří mohou také mají problémy, obecně kontrolní ping ne vždy zobrazuje aktuální informace o přístupu do globální sítě.
Pokud poskytovatelé a velké korporace mají dynamický směrovací protokol BGP, pak uživatelé v domácnostech a kancelářích musí nezávisle přijít na to, jak kontrolovat přístup k internetu přes konkrétní komunikační kanál.

Obvykle se používají skripty, které prostřednictvím určitého komunikačního kanálu zkontrolují dostupnost ip adresy na internetu a vyberou něco spolehlivého, například google dns: 8.8.8.8. 8.8.4.4. V komunitě Mikrotik je k tomu ale přizpůsoben zajímavější nástroj.

Pár slov o rekurzivním směrování
Rekurzivní směrování je nezbytné při budování Multihop BGP peeringu a do článku o základech statického směrování se dostalo pouze díky mazaným uživatelům MikroTiku, kteří přišli na to, jak používat rekurzivní cesty spárované s kontrolní bránou k přepínání komunikačních kanálů bez dalších skriptů.

Je čas porozumět možnostem rozsahu / cílového rozsahu obecně a tomu, jak je trasa vázána na rozhraní:

1. Trasa vyhledá rozhraní pro odeslání paketu na základě hodnoty jeho rozsahu a všech položek v hlavní tabulce s menšími nebo stejnými hodnotami cílového rozsahu.
2. Z nalezených rozhraní se vybere to, přes které můžete poslat paket na zadanou bránu
3. Pro odeslání paketu na bránu je vybráno rozhraní nalezeného připojeného záznamu

V přítomnosti rekurzivní cesty se vše děje stejně, ale ve dvou fázích:

• 1-3 K připojeným trasám je přidána jedna další trasa, přes kterou lze dosáhnout zadané brány
• 4-6 Nalezení trasy připojené k trase pro „střední“ bránu

Všechny manipulace s rekurzivním vyhledáváním probíhají v RIB a do FIB se přenese pouze konečný výsledek: 0.0.0.0/0 via 10.10.10.1 on ether1.

Příklad použití rekurzivního směrování k přepínání tras

Konfigurace:

/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 zkontrolovat, že pakety budou odesílány do 10.10.10.1:

Check gateway neví nic o rekurzivním směrování a jednoduše posílá ping na 8.8.8.8, který je (na základě hlavní tabulky) přístupný přes bránu 10.10.10.1.

Pokud dojde ke ztrátě komunikace mezi 10.10.10.1 a 8.8.8.8, pak je trasa odpojena, ale pakety (včetně testovacích pingů) do 8.8.8.8 nadále procházejí 10.10.10.1:

Pokud dojde ke ztrátě spojení na ether1, pak nastane nepříjemná situace, když pakety před 8.8.8.8 projdou přes druhého poskytovatele:

To je problém, pokud používáte NetWatch ke spouštění skriptů, když 8.8.8.8 není k dispozici. Pokud je spojení přerušeno, NetWatch bude jednoduše fungovat prostřednictvím záložního komunikačního kanálu a předpokládá, že je vše v pořádku. Vyřešeno přidáním další trasy filtru:

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

Existuje na habré článek, kde je podrobněji rozebrána situace s NetWatch.

A ano, při použití takové rezervace bude adresa 8.8.8.8 napevno připojena k jednomu z poskytovatelů, takže vybrat ji jako zdroj dns není dobrý nápad.

Pár slov o virtuálním směrování a předávání (VRF)

Technologie VRF je navržena tak, aby vytvořila několik virtuálních směrovačů v rámci jednoho fyzického, tuto technologii široce využívají telekomunikační operátoři (obvykle ve spojení s MPLS) k poskytování služeb L3VPN klientům s překrývajícími se adresami podsítě:

VRF v Mikrotiku je ale organizováno na základě směrovacích tabulek a má řadu nevýhod, například místní ip adresy routeru jsou dostupné ze všech VRF, můžete si přečíst více по ссылке.

příklad konfigurace 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

Ze zařízení připojeného k ether2 vidíme, že ping jde na adresu routeru z jiného vrf (a to je problém), zatímco ping nejde na internet:

Pro přístup k internetu musíte zaregistrovat další trasu, která přistupuje k hlavní tabulce (v terminologii vrf se to nazývá ú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

Zde jsou dva způsoby úniku trasy: pomocí směrovací tabulky: 172.17.0.1@main a pomocí názvu rozhraní: 172.17.0.1%wlan1.

A nastavit značení pro zpáteční 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 

Podsítě se stejnou adresou
Organizace přístupu k podsítím se stejnou adresou na stejném routeru pomocí VRF a síťové mapy:

Základní konfigurace:

/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

pravidla firewallu:

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

Pravidla směrování pro zpáteční provoz:

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

Přidání rout přijatých přes dhcp do dané routovací tabulky
VRF může být zajímavé, pokud potřebujete automaticky přidat dynamickou cestu (například z dhcp klienta) do konkrétní směrovací tabulky.

Přidání rozhraní do vrf:

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

Pravidla pro odesílání provozu (odchozího a tranzitního) přes tabulku 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

Další, falešná trasa pro odchozí směrování do práce:

/interface bridge
add name=bare

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

Tato cesta je potřebná pouze k tomu, aby místní odchozí pakety mohly projít dříve rozhodnutím o směrování (2). [OUTPUT|Mangle] a získejte směrovací štítek, pokud jsou na směrovači další aktivní cesty před 0.0.0.0/0 v hlavní tabulce, není to vyžadováno.

Цепоч РєРё connected-in и dynamic-in в [Routing] -> [Filters]

Filtrování směrování (příchozí a odchozí) je nástroj, který se obvykle používá ve spojení s protokoly dynamického směrování (a proto je dostupný pouze po instalaci balíčku Směrování), ale v příchozích filtrech jsou dva zajímavé řetězce:

• connect-in — filtrování připojených cest
• dynamic-in - filtrování dynamických cest přijatých PPP a DCHP

Filtrování umožňuje nejen zahodit trasy, ale také změnit řadu možností: vzdálenost, směrovací značka, komentář, rozsah, cílový rozsah, ...

Jedná se o velmi přesný nástroj a pokud něco umíte bez Směrovacích filtrů (ale ne skriptů), tak Směrovací filtry nepoužívejte, nepleťte sebe a ty, kteří budou router konfigurovat po vás. V kontextu dynamického směrování budou filtry směrování používány mnohem častěji a produktivněji.

Nastavení směrovací značky pro dynamické trasy
Příklad z domácího routeru. Mám nakonfigurovaná dvě VPN připojení a provoz v nich by měl být zabalen v souladu se směrovacími tabulkami. Zároveň chci, aby se trasy vytvářely automaticky při aktivaci rozhraní:

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

Nevím proč, pravděpodobně chyba, ale pokud vytvoříte vrf pro rozhraní ppp, cesta k 0.0.0.0/0 se stále dostane do hlavní tabulky. Jinak by bylo všechno ještě jednodušší.

Deaktivace připojených tras
Někdy je vyžadováno toto:

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

Nástroje pro ladění

RouterOS poskytuje řadu nástrojů pro ladění směrování:

• [Tool]->[Tourch] - umožňuje prohlížet pakety na rozhraních
• /ip route check - umožňuje vidět, na jakou bránu bude paket odeslán, nefunguje se směrovacími tabulkami
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - ping a trasování pomocí zadané směrovací tabulky
• action=log в [IP]->[Firewall] - vynikající nástroj, který vám umožní sledovat cestu paketu podél toku paketů, tato akce je dostupná ve všech řetězcích a tabulkách

Zdroj: www.habr.com