Grunderna i statisk routing i Mikrotik RouterOS

Routing är processen att hitta den bästa vägen för att överföra paket över TCP/IP-nätverk. Alla enheter som är anslutna till ett IPv4-nätverk innehåller en process och routingtabeller.

Den här artikeln är inte en HOWTO, den beskriver statisk routing i RouterOS med exempel, jag har medvetet utelämnat resten av inställningarna (till exempel srcnat för åtkomst till Internet), så att förstå materialet kräver en viss nivå av kunskap om nätverk och RouterOS.

Växling och routing

Switching är processen att utbyta paket inom ett Layer2-segment (Ethernet, ppp, ...). Om enheten ser att mottagaren av paketet är på samma Ethernet-undernät som den, lär den sig mac-adressen med hjälp av arp-protokollet och överför paketet direkt, förbi routern. En ppp (punkt-till-punkt) anslutning kan bara ha två deltagare och paketet skickas alltid till en adress 0xff.

Routing är processen att överföra paket mellan Layer2-segment. Om en enhet vill skicka ett paket vars mottagare är utanför Ethernet-segmentet tittar den i dess routingtabell och skickar paketet till en gateway som vet vart paketet ska skickas härnäst (eller kanske inte vet, den ursprungliga avsändaren av paketet är inte medveten om detta).

Det enklaste sättet att tänka på en router är som en enhet ansluten till två eller flera Layer2-segment och som kan skicka paket mellan dem genom att bestämma den bästa rutten från routingtabellen.

Om du förstår allt, eller om du redan visste det, läs då vidare. För övrigt rekommenderar jag starkt att du bekantar dig med en liten, men mycket rymlig artiklar.

Routing i RouterOS och PacketFlow

Nästan all funktionalitet relaterad till statisk routing finns i paketet system. Plastpåse routing lägger till stöd för dynamiska routingalgoritmer (RIP, OSPF, BGP, MME), routingfilter och BFD.

Huvudmeny för att ställa in routing: [IP]->[Route]. Komplexa scheman kan kräva att paket är förmärkta med ett routingmärke i: [IP]->[Firewall]->[Mangle] (kedjor PREROUTING и OUTPUT).

Det finns tre platser på PacketFlow där beslut om IP-paketdirigering tas:

1. Routingpaket som tas emot av routern. I detta skede avgörs om paketet ska gå till den lokala processen eller skickas vidare till nätverket. Transitpaket tar emot Utgångsgränssnitt
2. Dirigera lokala utgående paket. Utgående paket tar emot Utgångsgränssnitt
3. Ytterligare routingsteg för utgående paket, låter dig ändra routingbeslutet i [Output|Mangle]

• Paketvägen i block 1, 2 beror på reglerna i [IP]->[Route]
• Paketvägen i punkterna 1, 2 och 3 beror på reglerna i [IP]->[Route]->[Rules]
• Paketvägen i block 1, 3 kan påverkas med hjälp av [IP]->[Firewall]->[Mangle]

RIB, FIB, Routing Cache

Routing Information Base
Basen där rutter samlas in från dynamiska routingprotokoll, rutter från ppp och dhcp, statiska och anslutna rutter. Denna databas innehåller alla rutter, förutom de som filtrerats av administratören.

Villkorligt, det kan vi anta [IP]->[Route] visar RIB.

Informationsbas för vidarebefordran

Basen där de bästa rutterna från RIB samlas. Alla rutter i FIB är aktiva och används för att vidarebefordra paket. Om rutten blir inaktiv (inaktiverad av administratören (systemet), eller gränssnittet genom vilket paketet ska skickas inte är aktivt), tas rutten bort från FIB.

För att fatta ett routingbeslut använder FIB-tabellen följande information om ett IP-paket:

• Käll adress
• Destinations adress
• källgränssnitt
• Ruttmärke
• ToS (DSCP)

Att komma in i FIB-paketet går igenom följande steg:

• Är paketet avsett för en lokal routerprocess?
• Är paketet föremål för systemets eller användarens PBR-regler?
  • Om ja, skickas paketet till den angivna routingtabellen
• Paketet skickas till huvudbordet

Villkorligt, det kan vi anta [IP]->[Route Active=yes] visar FIB.

Routing cache
Rutcachningsmekanism. Routern kommer ihåg var paketen skickades och om det finns liknande (förmodligen från samma anslutning) låter den dem gå längs samma rutt, utan att checka in FIB. Ruttens cache rensas med jämna mellanrum.

För RouterOS-administratörer skapade de inte verktyg för att visa och hantera routingcachen, men när den kan inaktiveras i [IP]->[Settings].

Denna mekanism togs bort från linux 3.6-kärnan, men RouterOS använder fortfarande kärnan 3.3.5, kanske är Routing cahce en av anledningarna.

Dialogrutan Lägg till rutt

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

1. Subnät som du vill skapa en rutt för (standard: 0.0.0.0/0)
2. Gateway IP eller gränssnitt som paketet kommer att skickas till (det kan finnas flera, se ECMP nedan)
3. Gateway tillgänglighetskontroll
4. Inspelningstyp
5. Avstånd (metriskt) för en rutt
6. Routningstabell
7. IP för lokala utgående paket via denna rutt
8. Syftet med Scope och Target Scope skrivs i slutet av artikeln.

Ruttflaggor

• X - Rutten har inaktiverats av administratören (disabled=yes)
• A - Rutten används för att skicka paket
• D - Rutt läggs till dynamiskt (BGP, OSPF, RIP, MME, PPP, DHCP, ansluten)
• C - Subnätet är anslutet direkt till routern
• S - Statisk väg
• r,b,o,m - Rutt läggs till av ett av de dynamiska routingprotokollen
• B,U,P - Filtreringsväg (släpper paket istället för att sända)

Vad ska man ange i gateway: ip-adress eller gränssnitt?

Systemet låter dig specificera båda, samtidigt som det inte svär och inte ger tips om du gjort något fel.

IP-adress
Gatewayadressen måste vara tillgänglig via Layer2. För Ethernet innebär detta att routern måste ha en adress från samma subnät på ett av de aktiva ip-gränssnitten, för ppp att gatewayadressen anges på ett av de aktiva gränssnitten som subnätadress.
Om tillgänglighetsvillkoret för Layer2 inte är uppfyllt anses rutten vara inaktiv och faller inte in i FIB.

gränssnitt
Allt är mer komplicerat och routerns beteende beror på typen av gränssnitt:

• PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) anslutning förutsätter endast två deltagare och paketet kommer alltid att skickas till gatewayen för överföring, om gatewayen upptäcker att mottagaren är sig själv, så kommer den att överföra paketet till dess lokala process.
  
• Ethernet förutsätter närvaron av många deltagare och kommer att skicka förfrågningar till arp-gränssnittet med adressen till mottagaren av paketet, detta är förväntat och ganska normalt beteende för anslutna rutter.
  Men när du försöker använda gränssnittet som en rutt för ett fjärrundernät får du följande situation: rutten är aktiv, ping till gatewayen passerar, men når inte mottagaren från det angivna undernätet. Om du tittar på gränssnittet genom en sniffer kommer du att se arp-förfrågningar med adresser från ett fjärrundernät.
  

Försök att ange ip-adressen som gateway när det är möjligt. Undantaget är anslutna rutter (skapas automatiskt) och PPP-gränssnitt (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*).

OpenVPN innehåller ingen PPP-rubrik, men du kan använda OpenVPN-gränssnittsnamnet för att skapa en rutt.

Mer specifik väg

Grundläggande routingregel. Rutten som beskriver det mindre delnätet (med den största delnätsmasken) har företräde i paketets routingbeslut. Positionen för posterna i routingtabellen är inte relevant för valet - huvudregeln är Mer specifik.

Alla rutter från det angivna schemat är aktiva (finns i FIB). peka på olika undernät och inte komma i konflikt med varandra.

Om en av gatewayerna blir otillgänglig kommer den associerade rutten att anses vara inaktiv (borttagen från FIB) och paket kommer att sökas från de återstående vägarna.

Rutten med subnät 0.0.0.0/0 ges ibland speciell betydelse och kallas "Default Route" eller "Gateway of last resort". I själva verket finns det inget magiskt med det och det inkluderar helt enkelt alla möjliga IPv4-adresser, men dessa namn beskriver dess uppgift väl - det indikerar porten dit man ska vidarebefordra paket som det inte finns några andra, mer exakta rutter för.

Den maximala möjliga nätmasken för IPv4 är /32, denna rutt pekar på en specifik värd och kan användas i routingtabellen.

Att förstå mer specifik rutt är grundläggande för alla TCP/IP-enheter.

Distans

Avstånd (eller mätvärden) krävs för administrativ filtrering av rutter till ett enda subnät som är tillgängligt via flera gateways. En rutt med lägre måttenhet anses vara en prioritet och kommer att ingå i FIB. Om en rutt med en lägre måttenhet upphör att vara aktiv kommer den att ersättas av en rutt med en högre måttenhet i FIB.

Om det finns flera rutter till samma subnät med samma mått, kommer routern att lägga till endast en av dem till FIB-tabellen, styrd av dess interna logik.

Mätvärdet kan ha ett värde från 0 till 255:

• 0 - Metrisk för anslutna rutter. Avstånd 0 kan inte ställas in av administratören
• 1-254 - Statistik tillgängliga för administratören för att ställa in rutter. Mätvärden med ett lägre värde har högre prioritet
• 255 - Mätvärde tillgängligt för administratören för att ställa in rutter. Till skillnad från 1-254 förblir en rutt med måttet 255 alltid inaktiv och faller inte in i FIB
• specifika mätvärden. Rutter härledda från dynamiska routingprotokoll har standardvärden

kontrollera gateway

Check gateway är en MikroTik RoutesOS-tillägg för att kontrollera tillgängligheten för gatewayen via icmp eller arp. En gång var tionde sekund (kan inte ändras) skickas en begäran till gatewayen, om svaret inte tas emot två gånger anses rutten vara otillgänglig och tas bort från FIB. Om check gateway har inaktiverats fortsätter kontrollrutten och rutten kommer att bli aktiv igen efter en lyckad kontroll.

Check gateway inaktiverar posten där den är konfigurerad och alla andra poster (i alla routingtabeller och ecmp-rutter) med den angivna gatewayen.

I allmänhet fungerar check gateway bra så länge det inte finns några problem med paketförlust till gatewayen. Check gateway vet inte vad som händer med kommunikation utanför den kontrollerade gatewayen, detta kräver ytterligare verktyg: skript, rekursiv routing, dynamiska routingprotokoll.

De flesta VPN- och tunnelprotokoll innehåller inbyggda verktyg för att kontrollera anslutningsaktivitet, att aktivera check gateway för dem är en extra (men mycket liten) belastning på nätverket och enhetens prestanda.

ECMP rutter

Equal-Cost Multi-Path - skicka paket till mottagaren med hjälp av flera gateways samtidigt med hjälp av Round Robin-algoritmen.

En ECMP-rutt skapas av administratören genom att ange flera gateways för ett subnät (eller automatiskt, om det finns två likvärdiga OSPF-rutter).

ECMP används för lastbalansering mellan två kanaler, i teorin, om det finns två kanaler i ecmp-rutten, så bör den utgående kanalen vara olika för varje paket. Men Routing-cache-mekanismen skickar paket från anslutningen längs den rutt som det första paketet tog, som ett resultat får vi en sorts balansering baserad på anslutningar (lastbalansering per anslutning).

Om du inaktiverar Routing Cache kommer paketen i ECMP-rutten att delas korrekt, men det finns ett problem med NAT. NAT-regeln bearbetar endast det första paketet från anslutningen (resten bearbetas automatiskt), och det visar sig att paket med samma källadress lämnar olika gränssnitt.

Kontrollera att gatewayen inte fungerar i ECMP-rutter (RouterOS-bugg). Men du kan komma runt denna begränsning genom att skapa ytterligare valideringsvägar som kommer att inaktivera poster i ECMP.

Filtrering med hjälp av Routing

Alternativet Typ bestämmer vad som ska göras med paketet:

• unicast - skicka till angiven gateway (gränssnitt)
• blackhole - kassera ett paket
• förbjuda, oåtkomlig - kassera paketet och skicka ett icmp-meddelande till avsändaren

Filtrering används vanligtvis när det är nödvändigt att säkra sändningen av paket åt fel håll, naturligtvis kan du filtrera detta genom brandväggen.

Ett par exempel

Att konsolidera de grundläggande sakerna om routing.

Typisk hemmarouter

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

1. Statisk rutt till 0.0.0.0/0 (standardrutt)
2. Ansluten rutt på gränssnittet med leverantören
3. Ansluten rutt på LAN-gränssnitt

Typisk hemmarouter med PPPoE

1. Statisk rutt till standardrutt, läggs till automatiskt. det anges i anslutningsegenskaper
2. Ansluten rutt för PPP-anslutning
3. Ansluten rutt på LAN-gränssnitt

Typisk hemrouter med två leverantörer och redundans

/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. Statisk rutt till standardrutt genom den första leverantören med mätvärde 1 och kontroll av gateway-tillgänglighet
2. Statisk rutt till standardrutt genom andra leverantör med mätvärde 2
3. Anslutna rutter

Trafik till 0.0.0.0/0 går genom 10.10.10.1 medan denna gateway är tillgänglig, annars växlar den till 10.20.20.1

Ett sådant system kan betraktas som en kanalreservation, men det är inte utan nackdelar. Om ett avbrott inträffar utanför leverantörens gateway (till exempel inom operatörens nätverk), kommer din router inte att veta om det och kommer att fortsätta att betrakta rutten som aktiv.

Typisk hemmarouter med två leverantörer, redundans och 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. Statiska rutter för att kontrollera chack gateway
2. ECMP-rutt
3. Anslutna rutter

Rutter att kontrollera är blå (färgen på inaktiva rutter), men detta stör inte check-gatewayen. Den nuvarande versionen (6.44) av RoS ger automatisk prioritet till ECMP-rutten, men det är bättre att lägga till testrutter till andra rutttabeller (alternativ routing-mark)

På Speedtest och andra liknande sajter kommer det inte att ske någon hastighetsökning (ECMP delar upp trafiken efter anslutningar, inte efter paket), men p2p-applikationer bör laddas ner snabbare.

Filtrering via routing

/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. Statisk rutt till standardrutt
2. Statisk väg till 192.168.200.0/24 över ipip-tunneln
3. Förbjuder statisk rutt till 192.168.200.0/24 via ISP-router

Ett filtreringsalternativ där tunneltrafik inte går till leverantörens router när ipip-gränssnittet är inaktiverat. Sådana system krävs sällan, eftersom du kan implementera blockering genom brandväggen.

Routing loop
Routing loop - en situation när ett paket körs mellan routrar innan ttl löper ut. Vanligtvis är det resultatet av ett konfigurationsfel, i stora nätverk behandlas det genom implementering av dynamiska routingprotokoll, i små - med försiktighet.

Det ser ut så här:

Ett exempel (enklast) på hur man får ett liknande resultat:

Routing loop-exemplet är till ingen praktisk användning, men det visar att routrar inte har någon aning om sin grannes routingtabell.

Policy Bas routing och ytterligare routing tabeller

När du väljer en rutt använder routern endast ett fält från pakethuvudet (Dst. Address) - detta är grundläggande routing. Routing baserad på andra villkor, såsom källadress, typ av trafik (ToS), balansering utan ECMP, tillhör Policy Base Routing (PBR) och använder ytterligare routingtabeller.

Mer specifik väg är huvudregeln för val av rutt i rutttabellen.

Som standard läggs alla routingregler till i huvudtabellen. Administratören kan skapa ett godtyckligt antal ytterligare dirigeringstabeller och dirigera paket till dem. Regler i olika tabeller står inte i konflikt med varandra. Om paketet inte hittar en lämplig regel i den angivna tabellen, kommer det att gå till huvudtabellen.

Exempel med distribution via brandvägg:

• 192.168.100.10 -> 8.8.8.8
  1. Trafik från 192.168.100.10 märks via-isp1 в [Prerouting|Mangle]
  2. Vid Routing-stadiet i tabellen via-isp1 söker efter en rutt till 8.8.8.8
  3. Rutten hittad, trafik skickas till gateway 10.10.10.1
• 192.168.200.20 -> 8.8.8.8
  1. Trafik från 192.168.200.20 märks via-isp2 в [Prerouting|Mangle]
  2. Vid Routing-stadiet i tabellen via-isp2 söker efter en rutt till 8.8.8.8
  3. Rutten hittad, trafik skickas till gateway 10.20.20.1
• Om en av gatewayerna (10.10.10.1 eller 10.20.20.1) blir otillgänglig, kommer paketet att gå till bordet huvudsakliga och ska leta efter en lämplig väg dit

Terminologifrågor

RouterOS har vissa terminologiproblem.
När man arbetar med regler i [IP]->[Routes] routingtabellen anges, även om det står skrivet att etiketten:

В [IP]->[Routes]->[Rule] allt är korrekt, i etiketttillståndet i tabellåtgärden:

Hur man skickar ett paket till en specifik routingtabell

RouterOS tillhandahåller flera verktyg:

• Regler i [IP]->[Routes]->[Rules]
• Ruttmarkörer (action=mark-routing) i [IP]->[Firewall]->[Mangle]
• VRF-förlängning

Regler [IP]->[Route]->[Rules]
Regler bearbetas sekventiellt, om paketet matchar regelns villkor passerar det inte vidare.

Routingregler tillåter dig att utöka möjligheterna till routing, inte bara beroende på mottagaradressen utan också på källadressen och gränssnittet som paketet togs emot på.

Regler består av villkor och en åtgärd:

• Betingelser. Upprepa praktiskt taget listan över tecken med vilka paketet kontrolleras i FIB, endast ToS saknas.
• Aktivitet
  • lookup - skicka ett paket till en tabell
  • slå endast upp i tabell - lås paketet i tabellen, om rutten inte hittas kommer paketet inte att gå till huvudtabellen
  • släpp - släpp ett paket
  • oåtkomlig – kassera paketet med avsändarmeddelande

I FIB bearbetas trafik till lokala processer utan att reglerna [IP]->[Route]->[Rules]:

märkning [IP]->[Firewall]->[Mangle]
Routingetiketter låter dig ställa in gatewayen för ett paket med nästan alla brandväggsvillkor:

Praktiskt taget eftersom inte alla är vettiga, och vissa kan fungera instabilt.

Det finns två sätt att märka ett paket:

• Lägg omedelbart ruttmärke
• Sätt först anslutningsmärke, sedan baserat på anslutningsmärke att lägga ruttmärke

I en artikel om brandväggar skrev jag att det andra alternativet är att föredra. minskar belastningen på cpu, när det gäller att markera rutter - detta är inte helt sant. Dessa märkningsmetoder är inte alltid likvärdiga och används vanligtvis för att lösa olika problem.

Exempel på användning

Låt oss gå vidare till exemplen på att använda Policy Base Routing, de är mycket lättare att visa varför allt detta behövs.

MultiWAN och retur utgående (utgångs) trafik
Ett vanligt problem med en MultiWAN-konfiguration: Mikrotik är endast tillgängligt från Internet via en "aktiv" leverantör.

Routern bryr sig inte om vilken ip förfrågan kom till, när den genererar ett svar kommer den att leta efter en rutt i routingtabellen där rutten genom isp1 är aktiv. Vidare kommer ett sådant paket troligen att filtreras längs vägen till mottagaren.

En annan intressant punkt. Om en "enkel" käll-nat är konfigurerad på ether1-gränssnittet: /ip fi nat add out-interface=ether1 action=masquerade paketet kommer att gå online med src. adress=10.10.10.100, vilket gör saken ännu värre.

Det finns flera sätt att lösa problemet, men vilket som helst av dem kräver ytterligare routingtabeller:

/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

Använd [IP]->[Route]->[Rules]
Ange routningstabellen som ska användas för paket med angiven käll-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

Kan använda action=lookup, men för lokal utgående trafik utesluter detta alternativ helt anslutningar från fel gränssnitt.

• Systemet genererar ett svarspaket med Src. Adress: 10.20.20.200
• Stegkontroller för routingbeslut(2). [IP]->[Routes]->[Rules] och paketet skickas till routingtabellen över-isp2
• Enligt routingtabellen måste paketet skickas till gatewayen 10.20.20.1 via ether2-gränssnittet

Denna metod kräver inte en fungerande Connection Tracker, till skillnad från att använda Mangle-tabellen.

Använd [IP]->[Firewall]->[Mangle]
Anslutningen börjar med ett inkommande paket, så vi markerar det (action=mark-connection), för utgående paket från en markerad anslutning, ställ in routingetiketten (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

Om flera ips är konfigurerade på ett gränssnitt kan du lägga till villkoret dst-address För att vara säker.

• Ett paket öppnar anslutningen på ether2-gränssnittet. Paketet går in [INPUT|Mangle] som säger att alla paket från anslutningen ska markeras som från-isp2
• Systemet genererar ett svarspaket med Src. Adress: 10.20.20.200
• I steget för routingbeslut(2) skickas paketet, i enlighet med routingtabellen, till gatewayen 10.20.20.1 via ether1-gränssnittet. Du kan verifiera detta genom att logga in paketen [OUTPUT|Filter]
• På scenen [OUTPUT|Mangle] anslutningsetiketten är markerad från-isp2 och paketet får en ruttetikett över-isp2
• Steget Routing Adjument(3) kontrollerar förekomsten av en routingetikett och skickar den till lämplig routingtabell
• Enligt routingtabellen måste paketet skickas till gatewayen 10.20.20.1 via ether2-gränssnittet

MultiWAN och retur dst-nat-trafik

Ett exempel är mer komplicerat, vad du ska göra om det finns en server (till exempel webb) bakom routern på ett privat subnät och du behöver ge tillgång till den via någon av leverantörerna.

/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

Kärnan i problemet kommer att vara densamma, lösningen liknar Firewall Mangle-alternativet, endast andra kedjor kommer att användas:

/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

Diagrammet visar inte NAT, men jag tror att allt är klart.

MultiWAN och utgående anslutningar

Du kan använda PBR-funktionerna för att skapa flera vpn-anslutningar (SSTP i exemplet) från olika routergränssnitt.

Ytterligare rutttabeller:

/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

Paketmärkningar:

/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

Enkla NAT-regler, annars kommer paketet att lämna gränssnittet med fel Src. adress:

/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

parsning:

• Routern skapar tre SSTP-processer
• I steget för routingbeslut (2) väljs en rutt för dessa processer baserat på huvuddirigeringstabellen. Från samma rutt tar paketet emot Src. Adress bunden till ether1-gränssnittet
• В [Output|Mangle] paket från olika anslutningar får olika etiketter
• Paket går in i tabellerna som motsvarar etiketterna vid routingjusteringsstadiet och får en ny rutt för att skicka paket
• Men paketen har fortfarande Src. Adress från ether1, på scen [Nat|Srcnat] adressen ersätts enligt gränssnittet

Intressant nog kommer du att se följande anslutningstabell på routern:

Connection Tracker fungerar tidigare [Mangle] и [Srcnat], så alla anslutningar kommer från samma adress, om du tittar mer i detalj, så in Replay Dst. Address det kommer att finnas adresser efter NAT:

På VPN-servern (jag har en på testbänken) kan du se att alla anslutningar kommer från rätt adresser:

Vänta lite
Det finns ett enklare sätt, du kan helt enkelt ange en specifik gateway för var och en av adresserna:

/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

Men sådana rutter kommer att påverka inte bara utgående utan även transittrafik. Plus, om du inte behöver trafik till vpn-servern för att gå igenom olämpliga kommunikationskanaler, måste du lägga till ytterligare 6 regler för att [IP]->[Routes]с type=blackhole. I den tidigare versionen - 3 regler i [IP]->[Route]->[Rules].

Fördelning av användaranslutningar efter kommunikationskanaler

Enkla, vardagliga sysslor. Återigen kommer ytterligare routingtabeller att behövas:

/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

med användning av [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

Vid användning action=lookup, när en av kanalerna är inaktiverad, kommer trafiken att gå till huvudtabellen och gå genom arbetskanalen. Om detta är nödvändigt eller inte beror på uppgiften.

Använda markeringarna i [IP]->[Firewall]->[Mangle]
Ett enkelt exempel med listor över ip-adresser. I princip kan nästan alla villkor användas. Den enda varningen för lager7, även när det är ihopkopplat med anslutningsetiketter, kan det verka som att allt fungerar korrekt, men en del av trafiken kommer fortfarande att gå åt fel håll.

/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

Du kan "låsa" användare i en routingtabell [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

Antingen genom [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 proffs dst-address-type=!local
Ytterligare skick dst-address-type=!local det är nödvändigt att trafik från användare når routerns lokala processer (dns, winbox, ssh, ...). Om flera lokala subnät är anslutna till routern är det nödvändigt att se till att trafiken mellan dem inte går till Internet, t.ex. dst-address-table.

I exemplet använder [IP]->[Route]->[Rules] det finns inga sådana undantag, men trafiken når lokala processer. Faktum är att komma in i FIB-paketet markerat [PREROUTING|Mangle] har en ruttetikett och går in i en annan routingtabell än main, där det inte finns något lokalt gränssnitt. När det gäller routingregler kontrolleras först om paketet är avsett för en lokal process och först i User PBR-stadiet går det till den specificerade routingtabellen.

med användning av [IP]->[Firewall]->[Mangle action=route]
Denna åtgärd fungerar bara i [Prerouting|Mangle] och låter dig dirigera trafik till den angivna gatewayen utan att använda ytterligare routingtabeller, ange gatewayadressen direkt:

/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

effekt route har lägre prioritet än routingregler ([IP]->[Route]->[Rules]). När det gäller vägmärken beror allt på reglernas placering, om regeln med action=route värt mer än action=mark-route, då kommer den att användas (oavsett flagga passtrough), annars markerar rutten.
Det finns väldigt lite information på wikin om denna åtgärd och alla slutsatser erhålls experimentellt, i alla fall, jag hittade inte alternativ när jag använder det här alternativet ger fördelar framför andra.

PPC-baserad dynamisk balansering

Per Connection Classifier - är en mer flexibel analog till ECMP. Till skillnad från ECMP delar den upp trafik efter anslutningar mer strikt (ECMP vet ingenting om anslutningar, men när den paras ihop med Routing Cache erhålls något liknande).

PCC tar angivna fält från ip-huvudet, konverterar dem till ett 32-bitars värde och dividerar med nämnare. Resten av divisionen jämförs med den angivna återstoden och om de matchar, tillämpas den angivna åtgärden. Mer. Låter galet, men det fungerar.

Exempel med tre adresser:

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

Ett exempel på dynamisk distribution av trafik efter src.address mellan tre kanaler:

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

Vid markering av rutter finns ett ytterligare villkor: in-interface=br-lan, utan den under action=mark-routing svarstrafik från Internet kommer att få och, i enlighet med routingtabellerna, gå tillbaka till leverantören.

Byta kommunikationskanaler

Check ping är ett bra verktyg, men det kontrollerar bara anslutningen till närmaste IP-peer, leverantörsnätverk består oftast av ett stort antal routrar och ett anslutningsavbrott kan inträffa utanför närmaste peer, och sedan finns det telekomoperatörer i stamnätet som kan också har problem, i allmänhet visar check ping inte alltid uppdaterad information om åtkomst till det globala nätverket.
Om leverantörer och stora företag har BGPs dynamiska routingprotokoll, måste hem- och kontorsanvändare självständigt ta reda på hur man kontrollerar internetåtkomst via en specifik kommunikationskanal.

Vanligtvis används skript som genom en viss kommunikationskanal kontrollerar tillgängligheten av en ip-adress på Internet, samtidigt som man väljer något pålitligt, till exempel google dns: 8.8.8.8. 8.8.4.4. Men i Mikrotik-gemenskapen har ett mer intressant verktyg anpassats för detta.

Några ord om rekursiv routing
Rekursiv routing är nödvändigt när man bygger Multihop BGP-peering och kom in i artikeln om grunderna för statisk routing endast på grund av listiga MikroTik-användare som kom på hur man använder rekursiva rutter parade med check-gateway för att byta kommunikationskanaler utan ytterligare skript.

Det är dags att förstå alternativen för omfattning/målomfång i allmänna termer och hur rutten är bunden till gränssnittet:

1. Rutten letar upp ett gränssnitt för att skicka paketet baserat på dess scope-värde och alla poster i huvudtabellen med mindre än eller lika mål-scope-värden
2. Från de hittade gränssnitten väljs den genom vilken du kan skicka ett paket till den angivna gatewayen
3. Gränssnittet för den hittade anslutna posten väljs för att skicka paketet till gatewayen

I närvaro av en rekursiv rutt händer allt på samma sätt, men i två steg:

• 1-3 Ytterligare en rutt läggs till de anslutna rutterna, genom vilken den angivna gatewayen kan nås
• 4-6 Hitta den ruttanslutna rutten för den "mellanliggande" gatewayen

Alla manipulationer med den rekursiva sökningen sker i RIB, och endast det slutliga resultatet överförs till FIB: 0.0.0.0/0 via 10.10.10.1 on ether1.

Ett exempel på att använda rekursiv routing för att byta rutter

Konfiguration:

/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

Du kan kontrollera att paket kommer att skickas till 10.10.10.1:

Check gateway vet ingenting om rekursiv routing och skickar helt enkelt ping till 8.8.8.8, som (baserat på huvudtabellen) är tillgänglig via gateway 10.10.10.1.

Om det uppstår kommunikationsbortfall mellan 10.10.10.1 och 8.8.8.8, kopplas rutten från, men paket (inklusive testpingningar) till 8.8.8.8 fortsätter att gå till 10.10.10.1:

Om länken till ether1 går förlorad, uppstår en obehaglig situation när paket före 8.8.8.8 går via den andra leverantören:

Detta är ett problem om du använder NetWatch för att köra skript när 8.8.8.8 inte är tillgängligt. Om länken bryts kommer NetWatch helt enkelt att arbeta genom backupkommunikationskanalen och anta att allt är bra. Lösas genom att lägga till en extra filterväg:

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

Det finns på habré artikel, där situationen med NetWatch övervägs mer i detalj.

Och ja, när du använder en sådan reservation kommer adressen 8.8.8.8 att kopplas till en av leverantörerna, så att välja den som en dns-källa är inte en bra idé.

Några ord om Virtual Routing and Forwarding (VRF)

VRF-tekniken är utformad för att skapa flera virtuella routrar inom en fysisk, denna teknik används i stor utsträckning av telekomoperatörer (vanligtvis i kombination med MPLS) för att tillhandahålla L3VPN-tjänster till klienter med överlappande subnätadresser:

Men VRF i Mikrotik är organiserat utifrån routingtabeller och har ett antal nackdelar, till exempel finns lokala ip-adresser till routern tillgängliga från alla VRF:er, du kan läsa mer по ссылке.

vrf-konfigurationsexempel:

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

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

Från enheten som är ansluten till ether2 ser vi att ping går till routeradressen från en annan vrf (och detta är ett problem), medan ping inte går till internet:

För att komma åt Internet måste du registrera en extra rutt som kommer åt huvudtabellen (i vrf-terminologi kallas detta ruttläckage):

/ip route
add distance=1 gateway=172.17.0.1@main routing-mark=vrf1
add distance=1 gateway=172.17.0.1%wlan1 routing-mark=vrf2

Här är två sätt att läcka rutt: med hjälp av rutttabellen: 172.17.0.1@main och använder gränssnittsnamn: 172.17.0.1%wlan1.

Och sätt upp markering för returtrafik in [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 

Subnät med samma adress
Organisering av åtkomst till subnät med samma adressering på samma router med hjälp av VRF och nätkarta:

Grundläggande konfiguration:

/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

brandväggsregler:

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

Rutningsregler för returtrafik:

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

Lägga till rutter som tas emot via dhcp till en given rutttabell
VRF kan vara intressant om du automatiskt behöver lägga till en dynamisk rutt (till exempel från en dhcp-klient) till en specifik routingtabell.

Lägger till gränssnitt till vrf:

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

Regler för att skicka trafik (utgående och transit) genom tabellen över-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

Ytterligare, falsk rutt för utgående rutt till jobbet:

/interface bridge
add name=bare

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

Denna rutt behövs bara så att lokala utgående paket kan passera genom routingbeslutet (2) innan [OUTPUT|Mangle] och få routingetiketten, om det finns andra aktiva rutter på routern före 0.0.0.0/0 i huvudtabellen, krävs det inte.

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

Ruttfiltrering (inkommande och utgående) är ett verktyg som vanligtvis används i kombination med dynamiska routingprotokoll (och därför endast tillgängligt efter installation av paketet routing), men det finns två intressanta kedjor i de inkommande filtren:

• inkopplad — filtrering av anslutna rutter
• dynamic-in - filtrering av dynamiska rutter som tas emot av PPP och DCHP

Filtrering låter dig inte bara förkasta rutter, utan också att ändra ett antal alternativ: avstånd, ruttmarkering, kommentar, omfattning, målomfattning, ...

Detta är ett mycket exakt verktyg och om du kan göra något utan routingfilter (men inte skript), använd då inte routingfilter, förvirra inte dig själv och de som ska konfigurera routern efter dig. I samband med dynamisk routing kommer routingfilter att användas mycket oftare och mer produktivt.

Ställa in ruttmarkeringen för dynamiska rutter
Ett exempel från en hemmarouter. Jag har två VPN-anslutningar konfigurerade och trafiken i dem ska lindas i enlighet med routingtabellerna. Samtidigt vill jag att rutterna ska skapas automatiskt när gränssnittet aktiveras:

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

Jag vet inte varför, förmodligen en bugg, men om du skapar en vrf för ppp-gränssnittet, kommer vägen till 0.0.0.0/0 fortfarande att hamna i huvudtabellen. Annars skulle allt bli ännu lättare.

Inaktivera anslutna rutter
Ibland krävs detta:

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

Felsökningsverktyg

RouterOS tillhandahåller ett antal verktyg för att felsöka routing:

• [Tool]->[Tourch] - låter dig se paket på gränssnitt
• /ip route check - låter dig se vilken gateway paketet kommer att skickas till, fungerar inte med routingtabeller
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - pinga och spåra med den angivna routingtabellen
• action=log в [IP]->[Firewall] - ett utmärkt verktyg som låter dig spåra ett pakets väg längs paketflödet, denna åtgärd är tillgänglig i alla kedjor och tabeller

Källa: will.com