🥇 Grunnleggende om statisk ruting i Mikrotik RouterOS

Ruting er prosessen med å finne den beste veien for å sende pakker over TCP/IP-nettverk. Enhver enhet koblet til et IPv4-nettverk inneholder en prosess og rutingtabeller.

Denne artikkelen er ikke en HOWTO, den beskriver statisk ruting i RouterOS med eksempler, jeg har bevisst utelatt resten av innstillingene (for eksempel srcnat for tilgang til Internett), så å forstå materialet krever et visst nivå av kunnskap om nettverk og RouterOS.

Bytte og ruting

Bytte er prosessen med å utveksle pakker innenfor ett Layer2-segment (Ethernet, ppp, ...). Hvis enheten ser at mottakeren av pakken er på det samme Ethernet-undernettet med den, lærer den mac-adressen ved å bruke arp-protokollen og overfører pakken direkte, utenom ruteren. En ppp (punkt-til-punkt) tilkobling kan bare ha to deltakere og pakken sendes alltid til én adresse 0xff.

Ruting er prosessen med å overføre pakker mellom Layer2-segmenter. Hvis en enhet ønsker å sende en pakke hvis mottaker er utenfor Ethernet-segmentet, ser den inn i rutetabellen og sender pakken til en gateway som vet hvor den skal sende pakken neste (eller kanskje ikke vet, den opprinnelige avsenderen av pakken er ikke klar over dette).

Den enkleste måten å tenke på en ruter på er som en enhet koblet til to eller flere Layer2-segmenter og i stand til å sende pakker mellom dem ved å bestemme den beste ruten fra rutingtabellen.

Hvis du forstår alt, eller du allerede visste det, så les videre. For resten anbefaler jeg på det sterkeste at du gjør deg kjent med en liten, men veldig romslig artikler.

Ruting i RouterOS og PacketFlow

Nesten all funksjonalitet knyttet til statisk ruting er i pakken system. Plastpose ruting legger til støtte for dynamiske rutingalgoritmer (RIP, OSPF, BGP, MME), rutingfiltre og BFD.

Hovedmeny for å sette opp ruting: [IP]->[Route]. Komplekse skjemaer kan kreve at pakker forhåndsmerkes med et rutemerke i: [IP]->[Firewall]->[Mangle] (kjeder PREROUTING и OUTPUT).

Det er tre steder på PacketFlow der beslutninger om IP-pakkeruting tas:

Ruting av pakker mottatt av ruteren. På dette stadiet avgjøres det om pakken skal gå til den lokale prosessen eller sendes videre til nettverket. Transittpakker mottas Utgang Interface
Ruting av lokale utgående pakker. Mottak av utgående pakker Utgang Interface
Ytterligere rutingtrinn for utgående pakker, lar deg endre rutingbeslutningen i [Output|Mangle]

Pakkebanen i blokkene 1, 2 avhenger av reglene i [IP]->[Route]
Pakkebanen i punkt 1, 2 og 3 avhenger av reglene i [IP]->[Route]->[Rules]
Pakkebanen i blokkene 1, 3 kan påvirkes vha [IP]->[Firewall]->[Mangle]

RIB, FIB, Ruting Cache

Rutinginformasjonsbase
Basen der ruter samles inn fra dynamiske rutingprotokoller, ruter fra ppp og dhcp, statiske og tilkoblede ruter. Denne databasen inneholder alle ruter, bortsett fra de som er filtrert av administratoren.

Betinget, det kan vi anta [IP]->[Route] viser RIB.

Informasjonsbase for videresending

Basen der de beste rutene fra RIB er samlet. Alle ruter i FIB er aktive og brukes til å videresende pakker. Hvis ruten blir inaktiv (deaktivert av administratoren (systemet), eller grensesnittet som pakken skal sendes gjennom ikke er aktivt), fjernes ruten fra FIB.

For å ta en rutebeslutning bruker FIB-tabellen følgende informasjon om en IP-pakke:

Kildeadresse
Ankomstadresse
Kildegrensesnitt
Rutemerke
ToS (DSCP)

Å komme inn i FIB-pakken går gjennom følgende stadier:

Er pakken beregnet på en lokal ruterprosess?
Er pakken underlagt systemets eller brukerens PBR-regler?
- Hvis ja, sendes pakken til den angitte rutetabellen
Pakken sendes til hovedbordet

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

Ruting cache
Rutebufringsmekanisme. Ruteren husker hvor pakkene ble sendt og hvis det er lignende (antagelig fra samme forbindelse) lar den dem gå langs samme rute, uten å sjekke inn FIB. Rutebufferen tømmes med jevne mellomrom.

For RouterOS-administratorer laget de ikke verktøy for å vise og administrere ruting-cachen, men når den kan deaktiveres i [IP]->[Settings].

Denne mekanismen ble fjernet fra linux 3.6-kjernen, men RouterOS bruker fortsatt kjerne 3.3.5, kanskje Ruting cahce er en av grunnene.

Legg til rutedialog

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

Subnett som du vil opprette en rute for (standard: 0.0.0.0/0)
Gateway IP eller grensesnitt som pakken skal sendes til (det kan være flere, se ECMP nedenfor)
Gateway-tilgjengelighetssjekk
Record type
Avstand (metrisk) for en rute
Rutingtabell
IP for lokale utgående pakker via denne ruten
Hensikten med Scope og Target Scope er skrevet på slutten av artikkelen.

Ruteflagg

X - Ruten er deaktivert av administratoren (disabled=yes)
A - Ruten brukes til å sende pakker
D - Rute lagt til dynamisk (BGP, OSPF, RIP, MME, PPP, DHCP, Connected)
C - Subnettet er koblet direkte til ruteren
S - Statisk rute
r,b,o,m - Rute lagt til av en av de dynamiske rutingprotokollene
B,U,P - Filtreringsrute (slipper pakker i stedet for å sende)

Hva skal angis i gateway: ip-adresse eller grensesnitt?

Systemet lar deg spesifisere begge deler, samtidig som det ikke banner og gir ikke hint om du har gjort noe galt.

IP adresse
Gateway-adressen må være tilgjengelig over Layer2. For Ethernet betyr dette at ruteren må ha en adresse fra samme subnett på et av de aktive ip-grensesnittene, for ppp at gateway-adressen er spesifisert på et av de aktive grensesnittene som subnettadresse.
Dersom tilgjengelighetsbetingelsen for Layer2 ikke er oppfylt, anses ruten som inaktiv og faller ikke inn i FIB.

grensesnitt
Alt er mer komplisert og oppførselen til ruteren avhenger av typen grensesnitt:

PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) tilkobling forutsetter kun to deltakere og pakken vil alltid bli sendt til gatewayen for overføring, hvis gatewayen oppdager at mottakeren er seg selv, så vil den overføre pakken til sin lokale prosess.
Ethernet antar tilstedeværelsen av mange deltakere og vil sende forespørsler til arp-grensesnittet med adressen til mottakeren av pakken, dette er forventet og ganske normal oppførsel for tilkoblede ruter.
Men når du prøver å bruke grensesnittet som en rute for et eksternt subnett, får du følgende situasjon: ruten er aktiv, ping til gatewayen passerer, men når ikke mottakeren fra det spesifiserte subnettet. Hvis du ser på grensesnittet gjennom en sniffer, vil du se arp-forespørsler med adresser fra et eksternt subnett.

Prøv å spesifisere ip-adressen som gateway når det er mulig. Unntaket er tilkoblede ruter (opprettet automatisk) og PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*) grensesnitt.

OpenVPN inneholder ikke en PPP-header, men du kan bruke OpenVPN-grensesnittnavnet for å lage en rute.

Mer spesifikk rute

Grunnleggende ruteregel. Ruten som beskriver det mindre delnettet (med den største delnettverket) har forrang i pakkens rutingbeslutning. Plasseringen av oppføringene i rutetabellen er ikke relevant for valget – hovedregelen er Mer spesifikk.

Alle ruter fra den angitte ordningen er aktive (ligger i FIB). peke på forskjellige undernett og ikke komme i konflikt med hverandre.

Hvis en av gatewayene blir utilgjengelig, vil den tilknyttede ruten bli ansett som inaktiv (fjernet fra FIB) og pakker vil bli søkt fra de gjenværende rutene.

Ruten med subnett 0.0.0.0/0 er noen ganger gitt spesiell betydning og kalles "Standardrute" eller "Gateway of last resort". Faktisk er det ikke noe magisk med det, og det inkluderer ganske enkelt alle mulige IPv4-adresser, men disse navnene beskriver oppgaven godt - det indikerer gatewayen hvor du kan videresende pakker som det ikke finnes andre, mer nøyaktige ruter for.

Maksimal mulig subnettmaske for IPv4 er /32, denne ruten peker til en spesifikk vert og kan brukes i rutingtabellen.

Å forstå mer spesifikk rute er grunnleggende for enhver TCP/IP-enhet.

Avstand

Avstander (eller beregninger) kreves for administrativ filtrering av ruter til et enkelt subnett tilgjengelig gjennom flere gatewayer. En rute med lavere metrikk anses som en prioritet og vil bli inkludert i FIB. Hvis en rute med en lavere metrikk slutter å være aktiv, vil den bli erstattet av en rute med en høyere metrikk i FIB.

Hvis det er flere ruter til samme subnett med samme metrikk, vil ruteren bare legge til én av dem til FIB-tabellen, styrt av dens interne logikk.

Beregningen kan ha en verdi fra 0 til 255:

0 - Metrisk for tilkoblede ruter. Avstand 0 kan ikke angis av administrator
1-254 - Beregninger tilgjengelig for administratoren for å angi ruter. Beregninger med lavere verdi har høyere prioritet
255 - Metrikk tilgjengelig for administratoren for å angi ruter. I motsetning til 1-254 forblir en rute med en metrikk på 255 alltid inaktiv og faller ikke inn i FIB
spesifikke beregninger. Ruter avledet fra dynamiske rutingprotokoller har standard metriske verdier

sjekk gateway

Check gateway er en MikroTik RoutesOS-utvidelse for å sjekke tilgjengeligheten til gatewayen via icmp eller arp. En gang hvert 10. sekund (kan ikke endres), sendes en forespørsel til gatewayen, hvis svaret ikke mottas to ganger, anses ruten som utilgjengelig og fjernes fra FIB. Hvis sjekkgatewayen er deaktivert, fortsetter sjekkbanen og ruten vil bli aktiv igjen etter en vellykket sjekk.

Check gateway deaktiverer oppføringen der den er konfigurert og alle andre oppføringer (i alle rutingtabeller og ecmp-ruter) med den angitte gatewayen.

Generelt fungerer sjekk gateway fint så lenge det ikke er problemer med pakketap til gatewayen. Check gateway vet ikke hva som skjer med kommunikasjon utenfor den sjekkede gatewayen, dette krever ekstra verktøy: skript, rekursiv ruting, dynamisk ruting protokoller.

De fleste VPN- og tunnelprotokoller inneholder innebygde verktøy for å sjekke tilkoblingsaktivitet, og å aktivere sjekkgateway for dem er en ekstra (men veldig liten) belastning på nettverket og enhetens ytelse.

ECMP-ruter

Equal-Cost Multi-Path - sending av pakker til mottakeren ved å bruke flere gatewayer samtidig ved å bruke Round Robin-algoritmen.

En ECMP-rute opprettes av administratoren ved å spesifisere flere gatewayer for ett subnett (eller automatisk, hvis det er to likeverdige OSPF-ruter).

ECMP brukes for belastningsbalansering mellom to kanaler, i teorien, hvis det er to kanaler i ecmp-ruten, bør den utgående kanalen være forskjellig for hver pakke. Men Ruting cache-mekanismen sender pakker fra tilkoblingen langs ruten som den første pakken tok, som et resultat får vi en slags balansering basert på tilkoblinger (per-tilkobling lasting balansering).

Hvis du deaktiverer Ruting Cache, vil pakkene i ECMP-ruten deles riktig, men det er et problem med NAT. NAT-regelen behandler kun den første pakken fra tilkoblingen (resten behandles automatisk), og det viser seg at pakker med samme kildeadresse forlater forskjellige grensesnitt.

Sjekk at gatewayen ikke fungerer i ECMP-ruter (RouterOS-feil). Men du kan omgå denne begrensningen ved å opprette flere valideringsruter som vil deaktivere oppføringer i ECMP.

Filtrering ved hjelp av ruting

Alternativet Type bestemmer hva som skal gjøres med pakken:

unicast - send til den angitte gatewayen (grensesnitt)
blackhole - kast en pakke
forby, utilgjengelig - kast pakken og send en icmp-melding til avsenderen

Filtrering brukes vanligvis når det er nødvendig å sikre sending av pakker langs feil vei, selvfølgelig kan du filtrere dette gjennom brannmuren.

Et par eksempler

For å konsolidere de grunnleggende tingene om ruting.

Typisk hjemmeruter

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

Statisk rute til 0.0.0.0/0 (standard rute)
Tilkoblet rute på grensesnittet med leverandøren
Tilkoblet rute på LAN-grensesnitt

Typisk hjemmeruter med PPPoE

Statisk rute til standardrute, lagt til automatisk. det er spesifisert i tilkoblingsegenskaper
Tilkoblet rute for PPP-forbindelse
Tilkoblet rute på LAN-grensesnitt

Typisk hjemmeruter med to leverandører og 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

Statisk rute til standardrute gjennom den første leverandøren med metrikk 1 og gateway-tilgjengelighetssjekk
Statisk rute til standardrute gjennom andre leverandør med beregning 2
Sammenkoblede ruter

Trafikk til 0.0.0.0/0 går gjennom 10.10.10.1 mens denne gatewayen er tilgjengelig, ellers bytter den til 10.20.20.1

En slik ordning kan betraktes som en kanalreservasjon, men den er ikke uten ulemper. Hvis det oppstår en pause utenfor leverandørens gateway (for eksempel innenfor operatørens nettverk), vil ikke ruteren din vite om det og vil fortsette å betrakte ruten som aktiv.

Typisk hjemmeruter med to leverandører, redundans og ECMP

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.10.10.1,10.20.20.1 distance=1

Statiske ruter for å sjekke chack gateway
ECMP rute
Sammenkoblede ruter

Ruter som skal sjekkes er blå (fargen på inaktive ruter), men dette forstyrrer ikke sjekkegatewayen. Den nåværende versjonen (6.44) av RoS gir automatisk prioritet til ECMP-ruten, men det er bedre å legge testruter til andre rutingtabeller (alternativ routing-mark)

På Speedtest og andre lignende nettsteder vil det ikke være noen økning i hastighet (ECMP deler trafikk etter tilkoblinger, ikke etter pakker), men p2p-applikasjoner bør laste ned raskere.

Filtrering via ruting

/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

Statisk rute til standardrute
Statisk rute til 192.168.200.0/24 over ipip tunnel
Forbyr statisk rute til 192.168.200.0/24 via ISP-ruter

Et filtreringsalternativ der tunneltrafikk ikke vil gå til leverandørens ruter når ipip-grensesnittet er deaktivert. Slike ordninger er sjelden nødvendig, fordi du kan implementere blokkering gjennom brannmuren.

Rutingsløyfe
Ruting loop - en situasjon når en pakke kjører mellom rutere før ttl utløper. Vanligvis er det resultatet av en konfigurasjonsfeil, i store nettverk behandles det ved implementering av dynamiske rutingprotokoller, i små - med forsiktighet.

Det ser noe slik ut:

Et eksempel (enkleste) på hvordan du får et lignende resultat:

Ruting loop-eksemplet er til ingen praktisk nytte, men det viser at rutere ikke har noen anelse om naboens rutetabell.

Ruting for policygrunnlag og tilleggsrutingstabeller

Ved valg av rute bruker ruteren kun ett felt fra pakkehodet (Dst. Address) – dette er grunnleggende ruting. Ruting basert på andre forhold, for eksempel kildeadresse, type trafikk (ToS), balansering uten ECMP, tilhører Policy Base Routing (PBR) og bruker ekstra rutingtabeller.

Mer spesifikk rute er hovedrutevalgsregelen i rutetabellen.

Som standard legges alle rutingsregler til i hovedtabellen. Administratoren kan opprette et vilkårlig antall ekstra rutingtabeller og rute pakker til dem. Regler i forskjellige tabeller er ikke i konflikt med hverandre. Hvis pakken ikke finner en passende regel i den angitte tabellen, vil den gå til hovedtabellen.

Eksempel med distribusjon via brannmur:

192.168.100.10 -> 8.8.8.8
1. Trafikk fra 192.168.100.10 blir merket via-isp1 в [Prerouting|Mangle]
2. På Ruting-stadiet i tabellen via-isp1 søker etter en rute til 8.8.8.8
3. Rute funnet, trafikk sendes til gateway 10.10.10.1
192.168.200.20 -> 8.8.8.8
1. Trafikk fra 192.168.200.20 blir merket via-isp2 в [Prerouting|Mangle]
2. På Ruting-stadiet i tabellen via-isp2 søker etter en rute til 8.8.8.8
3. Rute funnet, trafikk sendes til gateway 10.20.20.1
Hvis en av gatewayene (10.10.10.1 eller 10.20.20.1) blir utilgjengelig, vil pakken gå til bordet main og vil se etter en passende rute dit

Terminologiproblemer

RouterOS har visse terminologiproblemer.
Når man jobber med regler i [IP]->[Routes] rutetabellen er indikert, selv om det er skrevet at etiketten:

В [IP]->[Routes]->[Rule] alt er riktig, i etiketttilstanden i tabellhandlingen:

Hvordan sende en pakke til en bestemt rutetabell

RouterOS tilbyr flere verktøy:

Regler i [IP]->[Routes]->[Rules]
Rutemarkører (action=mark-routing) inn [IP]->[Firewall]->[Mangle]
VRF utvidelse

Regler [IP]->[Route]->[Rules]
Regler behandles sekvensielt, hvis pakken samsvarer med betingelsene i regelen, går den ikke videre.

Rutingsregler lar deg utvide mulighetene for ruting, og stole ikke bare på mottakeradressen, men også på kildeadressen og grensesnittet som pakken ble mottatt på.

Regler består av betingelser og en handling:

Forhold. Gjenta praktisk talt listen over tegn som pakken sjekkes med i FIB, bare ToS mangler.
Aktivitet
- oppslag - send en pakke til en tabell
- oppslag kun i tabell - lås pakken i tabellen, hvis ruten ikke blir funnet, vil pakken ikke gå til hovedtabellen
- slipp - slipp en pakke
- utilgjengelig - kast pakken med avsendervarsel

I FIB behandles trafikk til lokale prosesser utenom reglene [IP]->[Route]->[Rules]:

merking [IP]->[Firewall]->[Mangle]
Rutingetiketter lar deg angi gatewayen for en pakke ved å bruke nesten alle brannmurtilstander:

Praktisk talt fordi ikke alle gir mening, og noen kan fungere ustabilt.

Det er to måter å merke en pakke på:

Sett umiddelbart rutemerke
Sett først tilkoblingsmerke, deretter basert på tilkoblingsmerke å legge rutemerke

I en artikkel om brannmurer skrev jeg at det andre alternativet er å foretrekke. reduserer belastningen på cpuen, når det gjelder merking av ruter - dette er ikke helt sant. Disse merkingsmetodene er ikke alltid likeverdige og brukes vanligvis til å løse ulike problemer.

Eksempler på bruk

La oss gå videre til eksemplene på bruk av Policy Base Routing, de er mye lettere å vise hvorfor alt dette er nødvendig.

MultiWAN og retur utgående (Output) trafikk
Et vanlig problem med en MultiWAN-konfigurasjon: Mikrotik er kun tilgjengelig fra Internett gjennom en "aktiv" leverandør.

Ruteren bryr seg ikke om hvilken ip forespørselen kom til, når den genererer et svar, vil den se etter en rute i rutetabellen der ruten gjennom isp1 er aktiv. Videre vil en slik pakke mest sannsynlig bli filtrert underveis til mottakeren.

Et annet interessant poeng. Hvis en "enkel" kilde-nat er konfigurert på ether1-grensesnittet: /ip fi nat add out-interface=ether1 action=masquerade pakken vil gå online med src. adresse=10.10.10.100, noe som gjør ting enda verre.

Det er flere måter å fikse problemet på, men enhver av dem vil kreve ytterligere rutingtabeller:

/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

Bruk [IP]->[Route]->[Rules]
Spesifiser rutingtabellen som skal brukes for pakker med spesifisert kilde-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

Du kan bruke action=lookup, men for lokal utgående trafikk utelukker dette alternativet fullstendig tilkoblinger fra feil grensesnitt.

Systemet genererer en svarpakke med Src. Adresse: 10.20.20.200
Rutingbeslutningen(2) trinn sjekker [IP]->[Routes]->[Rules] og pakken sendes til rutetabellen over-isp2
I henhold til rutetabellen må pakken sendes til gatewayen 10.20.20.1 via ether2-grensesnittet

Denne metoden krever ikke en fungerende Connection Tracker, i motsetning til å bruke Mangle-tabellen.

Bruk [IP]->[Firewall]->[Mangle]
Forbindelsen starter med en innkommende pakke, så vi merker den (action=mark-connection), for utgående pakker fra en merket tilkobling, sett ruteetiketten (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

Hvis flere IP-er er konfigurert på ett grensesnitt, kan du legge til betingelsen dst-address for å være sikker.

En pakke åpner forbindelsen på ether2-grensesnittet. Pakken går inn [INPUT|Mangle] som sier å merke alle pakker fra tilkoblingen som fra-isp2
Systemet genererer en svarpakke med Src. Adresse: 10.20.20.200
På Routing Decision(2)-stadiet sendes pakken, i samsvar med rutingtabellen, til gatewayen 10.20.20.1 via ether1-grensesnittet. Du kan bekrefte dette ved å logge inn pakkene [OUTPUT|Filter]
På scenen [OUTPUT|Mangle] tilkoblingsetiketten er sjekket fra-isp2 og pakken mottar en ruteetikett over-isp2
Ruting Adjument(3)-trinnet sjekker for tilstedeværelsen av en rutingetikett og sender den til den aktuelle rutingtabellen
I henhold til rutetabellen må pakken sendes til gatewayen 10.20.20.1 via ether2-grensesnittet

MultiWAN og retur dst-nat trafikk

Et eksempel er mer komplisert, hva du skal gjøre hvis det er en server (for eksempel web) bak ruteren på et privat subnett og du må gi tilgang til den gjennom noen av leverandørene.

/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

Essensen av problemet vil være den samme, løsningen ligner på Firewall Mangle-alternativet, bare andre kjeder vil bli brukt:

/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 viser ikke NAT, men jeg tror alt er klart.

MultiWAN og utgående tilkoblinger

Du kan bruke PBR-funksjonene til å opprette flere vpn (SSTP i eksemplet) tilkoblinger fra forskjellige rutergrensesnitt.

Ytterligere rutetabeller:

/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

Pakkemerker:

/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

Enkle NAT-regler, ellers vil pakken forlate grensesnittet med feil Src. adresse:

/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

Analyse:

Ruteren lager tre SSTP-prosesser
I rutebeslutningsstadiet (2) velges en rute for disse prosessene basert på hovedrutingstabellen. Fra samme rute mottar pakken Src. Adresse bundet til ether1-grensesnittet
В [Output|Mangle] pakker fra forskjellige tilkoblinger mottar forskjellige etiketter
Pakker kommer inn i tabellene som tilsvarer etikettene i rutejusteringsstadiet og mottar en ny rute for å sende pakker
Men pakker har fortsatt Src. Adresse fra ether1, på scenen [Nat|Srcnat] adressen erstattes i henhold til grensesnittet

Interessant nok vil du se følgende tilkoblingstabell på ruteren:

Connection Tracker fungerer tidligere [Mangle] и [Srcnat], så alle forbindelser kommer fra samme adresse, hvis du ser nærmere, så inn Replay Dst. Address det vil være adresser etter NAT:

På VPN-serveren (jeg har en på testbenken) kan du se at alle tilkoblinger kommer fra de riktige adressene:

Vent litt
Det er en enklere måte, du kan ganske enkelt spesifisere en spesifikk gateway for hver av adressene:

/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 slike ruter vil påvirke ikke bare utgående, men også transitttrafikk. I tillegg, hvis du ikke trenger trafikk til vpn-serveren for å gå gjennom upassende kommunikasjonskanaler, må du legge til 6 flere regler for å [IP]->[Routes]с type=blackhole. I forrige versjon - 3 regler i [IP]->[Route]->[Rules].

Fordeling av brukerforbindelser etter kommunikasjonskanaler

Enkle hverdagslige oppgaver. Igjen, ytterligere rutetabeller vil være nødvendig:

/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

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

Hvis bruk action=lookup, så når en av kanalene er deaktivert, vil trafikken gå til hovedtabellen og gå gjennom arbeidskanalen. Om dette er nødvendig eller ikke avhenger av oppgaven.

Ved å bruke merkingene i [IP]->[Firewall]->[Mangle]
Et enkelt eksempel med lister over ip-adresser. I prinsippet kan nesten alle forhold brukes. Det eneste forbeholdet til layer7, selv når det er paret med tilkoblingsetiketter, kan det virke som om alt fungerer som det skal, men noe av trafikken vil fortsatt gå feil vei.

/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åse" brukere i én rutetabell gjennom [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

Enten gjennom [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 proff dst-address-type=!local
Tilleggstilstand dst-address-type=!local det er nødvendig at trafikk fra brukere når de lokale prosessene til ruteren (dns, winbox, ssh, ...). Hvis flere lokale undernett er koblet til ruteren, er det nødvendig å sikre at trafikken mellom dem ikke går til Internett, for eksempel ved å bruke dst-address-table.

I eksemplet bruker [IP]->[Route]->[Rules] det er ingen slike unntak, men trafikken når lokale prosesser. Faktum er at å komme inn i FIB-pakken merket inn [PREROUTING|Mangle] har en ruteetikett og går inn i en annen rutetabell enn main, der det ikke er noe lokalt grensesnitt. Når det gjelder rutingregler, sjekkes det først om pakken er beregnet på en lokal prosess, og først på bruker-PBR-stadiet går den til den angitte rutingtabellen.

Hjelp [IP]->[Firewall]->[Mangle action=route]
Denne handlingen fungerer bare i [Prerouting|Mangle] og lar deg dirigere trafikk til den angitte gatewayen uten å bruke ytterligere rutingtabeller, ved å spesifisere gatewayadressen direkte:

/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 lavere prioritet enn rutingsregler ([IP]->[Route]->[Rules]). Ved rutemerker avhenger alt av reglenes plassering, dersom regelen med action=route verdt mer enn action=mark-route, så vil den bli brukt (uavhengig av flagget passtrough), ellers markerer ruten.
Det er veldig lite informasjon på wikien om denne handlingen, og alle konklusjoner er oppnådd eksperimentelt, i alle fall, jeg fant ikke alternativer når bruk av dette alternativet gir fordeler fremfor andre.

PPC-basert dynamisk balansering

Per Connection Classifier - er en mer fleksibel analog av ECMP. I motsetning til ECMP, deler den trafikk etter tilkoblinger strengere (ECMP vet ingenting om tilkoblinger, men når den pares med Routing Cache, oppnås noe lignende).

PCC tar angitte felter fra ip-headeren, konverterer dem til en 32-bits verdi, og deler med nevner. Resten av divisjonen sammenlignes med spesifisert rest og hvis de samsvarer, brukes den angitte handlingen. Mer. Høres sprøtt ut, men det fungerer.

Eksempel 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

Et eksempel på dynamisk distribusjon av trafikk etter src.address mellom 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

Ved merking av ruter er det en tilleggsbetingelse: in-interface=br-lan, uten den under action=mark-routing responstrafikk fra Internett vil komme inn og vil i henhold til rutetabellene gå tilbake til leverandøren.

Bytte kommunikasjonskanaler

Sjekk ping er et godt verktøy, men det sjekker kun forbindelsen med nærmeste IP-peer, leverandørnettverk består vanligvis av et stort antall rutere og det kan oppstå et tilkoblingsbrudd utenfor nærmeste peer, og så er det ryggrad teleoperatører som evt. har problemer, generelt viser ikke sjekk ping alltid oppdatert informasjon om tilgang til det globale nettverket.
Hvis leverandører og store selskaper har BGP dynamisk ruting-protokoll, må hjemme- og kontorbrukere uavhengig finne ut hvordan de skal sjekke Internett-tilgang gjennom en bestemt kommunikasjonskanal.

Vanligvis brukes skript som gjennom en bestemt kommunikasjonskanal sjekker tilgjengeligheten til en ip-adresse på Internett, samtidig som man velger noe pålitelig, for eksempel google dns: 8.8.8.8. 8.8.4.4. Men i Mikrotik-miljøet er et mer interessant verktøy tilpasset dette.

Noen få ord om rekursiv ruting
Rekursiv ruting er nødvendig når man bygger Multihop BGP-peering og kom inn i artikkelen om det grunnleggende om statisk ruting kun på grunn av utspekulerte MikroTik-brukere som fant ut hvordan de skulle bruke rekursive ruter sammenkoblet med check gateway for å bytte kommunikasjonskanaler uten ekstra skript.

Det er på tide å forstå alternativene for omfang/målomfang i generelle termer og hvordan ruten er bundet til grensesnittet:

Ruten slår opp et grensesnitt for å sende pakken basert på omfangsverdien og alle oppføringer i hovedtabellen med mindre enn eller like målomfangsverdier
Fra de funnet grensesnittene velges den som du kan sende en pakke til den angitte gatewayen gjennom
Grensesnittet til den funnet tilkoblede oppføringen er valgt for å sende pakken til gatewayen

I nærvær av en rekursiv rute, skjer alt det samme, men i to stadier:

1-3 En ekstra rute legges til de tilkoblede rutene, som den angitte gatewayen kan nås gjennom
4-6 Finne rutetilkoblet rute for den "mellomliggende" gatewayen

Alle manipulasjoner med det rekursive søket skjer i RIB, og bare det endelige resultatet overføres til FIB: 0.0.0.0/0 via 10.10.10.1 on ether1.

Et eksempel på bruk av rekursiv ruting for å bytte rute

Konfigurasjon:

/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 sjekke at pakker sendes til 10.10.10.1:

Check gateway vet ingenting om rekursiv ruting og sender ganske enkelt ping til 8.8.8.8, som (basert på hovedtabellen) er tilgjengelig gjennom gateway 10.10.10.1.

Hvis det er et tap av kommunikasjon mellom 10.10.10.1 og 8.8.8.8, kobles ruten fra, men pakker (inkludert testpinger) til 8.8.8.8 fortsetter å gå gjennom 10.10.10.1:

Hvis koblingen til ether1 går tapt, oppstår det en ubehagelig situasjon når pakker før 8.8.8.8 går gjennom den andre leverandøren:

Dette er et problem hvis du bruker NetWatch til å kjøre skript når 8.8.8.8 ikke er tilgjengelig. Hvis koblingen er brutt, vil NetWatch ganske enkelt jobbe gjennom backup-kommunikasjonskanalen og anta at alt er i orden. Løst ved å legge til en ekstra filterrute:

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

Det er på habré artikkel, hvor situasjonen med NetWatch vurderes nærmere.

Og ja, når du bruker en slik reservasjon, vil adressen 8.8.8.8 være fastkoblet til en av leverandørene, så å velge den som en dns-kilde er ikke en god idé.

Noen få ord om virtuell ruting og videresending (VRF)

VRF-teknologi er designet for å lage flere virtuelle rutere innenfor én fysisk, denne teknologien er mye brukt av telekomoperatører (vanligvis i forbindelse med MPLS) for å tilby L3VPN-tjenester til klienter med overlappende subnettadresser:

Men VRF i Mikrotik er organisert på grunnlag av rutingstabeller og har en rekke ulemper, for eksempel er lokale ip-adresser til ruteren tilgjengelig fra alle VRF-er, du kan lese mer по ссылке.

vrf-konfigurasjonseksempel:

/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

Fra enheten koblet til ether2 ser vi at ping går til ruteradressen fra en annen vrf (og dette er et problem), mens ping ikke går til Internett:

For å få tilgang til Internett må du registrere en ekstra rute som får tilgang til hovedtabellen (i vrf-terminologi kalles dette rutelekkasje):

/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

Her er to måter å lekke rute på: ved å bruke rutetabellen: 172.17.0.1@main og bruker grensesnittnavn: 172.17.0.1%wlan1.

Og sett opp merking for returtrafikk inn [PREROUTING|Mangle]:

/ip firewall mangle
add chain=prerouting in-interface=ether1 action=mark-connection new-connection-mark=from-vrf1 passthrough=no
add chain=prerouting connection-mark=from-vrf1 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf1 passthrough=no 
add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=from-vrf2 passthrough=no
add chain=prerouting connection-mark=from-vrf2 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf2 passthrough=no

Subnett med samme adresse
Organisering av tilgang til subnett med samme adressering på samme ruter ved hjelp av VRF og netmap:

Grunnleggende konfigurasjon:

/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

brannmurregler:

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

Ruteregler for returtrafikk:

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

Legge til ruter mottatt via dhcp til en gitt rutetabell
VRF kan være interessant hvis du trenger å automatisk legge til en dynamisk rute (for eksempel fra en dhcp-klient) til en bestemt rutetabell.

Legger til grensesnitt til vrf:

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

Regler for å sende trafikk (utgående og transitt) gjennom tabellen 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

Ytterligere, falsk rute for utgående ruting til jobb:

/interface bridge
add name=bare

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

Denne ruten er kun nødvendig slik at lokale utgående pakker kan passere gjennom rutebeslutningen (2) før [OUTPUT|Mangle] og få rutingetiketten, hvis det er andre aktive ruter på ruteren før 0.0.0.0/0 i hovedtabellen, er det ikke nødvendig.

kjede `connected-in` и `dynamic-in` в `[Routing] -> [Filters]`

Rutefiltrering (innkommende og utgående) er et verktøy som vanligvis brukes sammen med dynamiske rutingprotokoller (og derfor kun tilgjengelig etter installasjon av pakken) ruting), men det er to interessante kjeder i de innkommende filtrene:

koblet inn — filtrering av tilkoblede ruter
dynamic-in - filtrering av dynamiske ruter mottatt av PPP og DCHP

Filtrering lar deg ikke bare forkaste ruter, men også endre en rekke alternativer: avstand, rutemerke, kommentar, omfang, målomfang, ...

Dette er et veldig presist verktøy og hvis du kan gjøre noe uten rutingfiltre (men ikke skript), så ikke bruk rutingfiltre, ikke forvirre deg selv og de som skal konfigurere ruteren etter deg. I sammenheng med dynamisk ruting vil rutingfiltre bli brukt mye hyppigere og mer produktivt.

Sette rutemerke for dynamiske ruter
Et eksempel fra en hjemmeruter. Jeg har konfigurert to VPN-tilkoblinger, og trafikken i dem skal pakkes inn i samsvar med rutetabellene. Samtidig vil jeg at rutene skal opprettes automatisk når grensesnittet aktiveres:

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

Jeg vet ikke hvorfor, sannsynligvis en feil, men hvis du oppretter en vrf for ppp-grensesnittet, vil ruten til 0.0.0.0/0 fortsatt komme inn i hovedtabellen. Ellers ville alt blitt enda enklere.

Deaktiverer tilkoblede ruter
Noen ganger er dette nødvendig:

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

Feilsøkingsverktøy

RouterOS tilbyr en rekke verktøy for feilsøking av ruting:

[Tool]->[Tourch] - lar deg se pakker på grensesnitt
/ip route check - lar deg se hvilken gateway pakken skal sendes til, fungerer ikke med rutingtabeller
/ping routing-table=<name> и /tool traceroute routing-table=<name> - ping og spor ved å bruke den angitte rutetabellen
action=log в [IP]->[Firewall] - et utmerket verktøy som lar deg spore banen til en pakke langs pakkeflyten, denne handlingen er tilgjengelig i alle kjeder og tabeller

Kilde: www.habr.com

Grunnleggende om statisk ruting i Mikrotik RouterOS