🥇Multivan og ruting på Mikrotik RouterOS

Innledning

Å ta opp artikkelen, i tillegg til forfengelighet, ble foranlediget av den deprimerende frekvensen av spørsmål om dette emnet i profilgruppene til det russisktalende telegramsamfunnet. Artikkelen er rettet mot nybegynnere av Mikrotik RouterOS (heretter kalt ROS)-administratorer. Den omhandler kun multivan, med vekt på ruting. Som en bonus er det minimalt nok innstillinger for å sikre sikker og praktisk drift. De som leter etter avsløring av emnene køer, lastbalansering, vlans, broer, flertrinns dyp analyse av tilstanden til kanalen og lignende - kan ikke kaste bort tid og krefter på å lese.

Innledende data

Som testperson ble en femports Mikrotik-ruter med ROS versjon 6.45.3 valgt. Den vil rute trafikk mellom to lokale nettverk (LAN1 og LAN2) og tre leverandører (ISP1, ISP2, ISP3). Kanalen til ISP1 har en statisk "grå" adresse, ISP2 - "hvit", hentet via DHCP, ISP3 - "hvit" med PPPoE-autorisasjon. Tilkoblingsskjemaet er vist i figuren:

Oppgaven er å konfigurere MTK-ruteren basert på skjemaet slik at:

Gi automatisk bytte til en sikkerhetskopileverandør. Hovedleverandøren er ISP2, den første reserven er ISP1, den andre reserven er ISP3.
Organiser LAN1-nettverkstilgang til Internett kun gjennom ISP1.
Gi muligheten til å rute trafikk fra lokale nettverk til Internett gjennom den valgte leverandøren basert på adresselisten.
Gi mulighet for å publisere tjenester fra det lokale nettverket til Internett (DSTNAT)
Sett opp et brannmurfilter for å gi minimum tilstrekkelig sikkerhet fra Internett.
Ruteren kan sende ut sin egen trafikk gjennom hvilken som helst av de tre leverandørene, avhengig av den valgte kildeadressen.
Sørg for at svarpakker blir rutet til kanalen de kom fra (inkludert LAN).

Merk. Vi vil konfigurere ruteren "fra bunnen av" for å garantere fravær av overraskelser i startkonfigurasjonene "ut av esken" som endres fra versjon til versjon. Winbox ble valgt som et konfigurasjonsverktøy, hvor endringer vil vises visuelt. Selve innstillingene vil bli satt av kommandoer i Winbox-terminalen. Den fysiske tilkoblingen for konfigurasjon gjøres ved en direkte tilkobling til Ether5-grensesnittet.

Litt resonnement om hva en multivan er, er det et problem eller er utspekulerte smarte mennesker rundt veving av konspirasjonsnettverk

En nysgjerrig og oppmerksom administrator, som setter opp et slikt eller lignende opplegg på egen hånd, innser plutselig at det allerede fungerer normalt. Ja, ja, uten dine egendefinerte rutetabeller og andre ruteregler, som de fleste artiklene om dette emnet er fulle av. La oss sjekke?

Kan vi konfigurere adressering på grensesnitt og standard gatewayer? Ja:

På ISP1 ble adressen og gatewayen registrert med avstand=2 и check-gateway=ping.
På ISP2 er standard dhcp-klientinnstilling - følgelig vil avstanden være lik én.
På ISP3 i pppoe-klientinnstillingene når add-default-route=ja sette default-rute-avstand=3.

Ikke glem å registrere NAT ved utgangen:

/ip brannmur nat add action=masquerade chain=srcnat out-interface-list=WAN

Som et resultat har brukere av lokale nettsteder det gøy å laste ned katter gjennom hovedleverandøren av ISP2, og det er en kanalreservasjon ved å bruke mekanismen sjekk gateway Se note 1

Punkt 1 i oppgaven gjennomføres. Hvor er multivanen med sine merker? Nei…

Lengre. Du må frigjøre spesifikke klienter fra LAN via ISP1:

/ip brannmur mangle add action=rutekjede=forruting dst-address-list=!BOGONS
passthrough=yes route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip brannmur mangle add action=rutekjede=forruting dst-address-list=!BOGONS
passthrough=ingen rute-dst=100.66.66.1 src-address=192.168.88.0/24

Oppgavens pkt. 2 og 3 er gjennomført. Etiketter, frimerker, ruteregler, hvor er du?!

Trenger du å gi tilgang til din favoritt OpenVPN-server med adressen 172.17.17.17 for klienter fra Internett? Vær så snill:

/ip cloud set ddns-enabled=ja

Som en peer gir vi kunden resultatet: ":put [ip cloud få dns-navn]"

Vi registrerer portvideresending fra Internett:

/ip brannmur nat add action=dst-nat kjede=dstnat dst-port=1194
in-interface-list=WAN-protokoll=udp til-adresser=172.17.17.17

Vare 4 er klar.

Vi setter opp en brannmur og annen sikkerhet for punkt 5, samtidig er vi glade for at alt allerede fungerer for brukerne og strekker oss etter en beholder med en favorittdrink ...
EN! Tunneler er glemt.

l2tp-klient, konfigurert av Google-artikkel, har steget til din favoritt nederlandske VDS? Ja.
l2tp-server med IPsec har steget og klienter etter DNS-navn fra IP Cloud (se ovenfor.) klamrer seg til? Ja.
Lener vi oss tilbake i stolen og nipper til en drink, vurderer vi dovent punkt 6 og 7 i oppgaven. Vi tenker – trenger vi det? Likevel fungerer det slik (c) ... Så hvis det fortsatt ikke er nødvendig, så er det det. Multivan implementert.

Hva er en multivan? Dette er tilkoblingen av flere Internett-kanaler til én ruter.

Du trenger ikke å lese artikkelen videre, for hva kan det være annet enn å vise frem tvilsom anvendelighet?

For de som blir igjen, som er interessert i punkt 6 og 7 i oppgaven, og også kjenner kløen av perfeksjonisme, dykker vi dypere.

Den viktigste oppgaven med å implementere en multivan er riktig trafikkruting. Nemlig: uavhengig av hvilken (eller hvilken) Se. note 3 ISPens kanal(er) ser på standardruten på ruteren vår, den skal returnere et svar til den nøyaktige kanalen pakken kom fra. Oppgaven er klar. Hvor er problemet? Faktisk, i et enkelt lokalt nettverk, er oppgaven den samme, men ingen plager seg med ytterligere innstillinger og føler ikke problemer. Forskjellen er at enhver rutbar node på Internett er tilgjengelig gjennom hver av våre kanaler, og ikke gjennom en strengt spesifikk en, som i et enkelt LAN. Og "problemet" er at hvis en forespørsel kom til oss om IP-adressen til ISP3, vil svaret i vårt tilfelle gå gjennom ISP2-kanalen, siden standardporten er rettet dit. Forlater og vil bli forkastet av leverandøren som feil. Problemet er identifisert. Hvordan løse det?

Løsningen er delt inn i tre trinn:

Forhåndsinnstilling. På dette stadiet vil de grunnleggende innstillingene til ruteren bli satt: lokalt nettverk, brannmur, adresselister, hårnål NAT, etc.
Multivan. På dette stadiet vil de nødvendige forbindelsene bli merket og sortert i rutetabeller.
Kobler til en ISP. På dette stadiet vil grensesnittene som gir tilkobling til Internett bli konfigurert, ruting og Internett-kanalreservasjonsmekanismen vil bli aktivert.

1. Forhåndsinnstilling

1.1. Vi sletter ruterkonfigurasjonen med kommandoen:

/system reset-configuration skip-backup=yes no-defaults=yes

enig med "Farlig! Tilbakestille likevel? [y/N]:” og etter omstart kobler vi til Winbox via MAC. På dette stadiet slettes konfigurasjonen og brukerbasen.

1.2. Opprett en ny bruker:

/user add group=full name=knight password=ultrasecret comment=”Not horse”

logg inn under den og slett standarden:

/user remove admin

Merk. Det er fjerning og ikke deaktivering av standardbrukeren som forfatteren anser som tryggere og anbefaler bruk.

1.3. Vi lager grunnleggende grensesnittlister for å gjøre det enklere å operere i en brannmur, oppdagelsesinnstillinger og andre MAC-servere:

/interface list add name=WAN comment="For Internet"
/interface list add name=LAN comment="For Local Area"

Signeringsgrensesnitt med kommentarer

/interface ethernet set ether1 comment="to ISP1"
/interface ethernet set ether2 comment="to ISP2"
/interface ethernet set ether3 comment="to ISP3"
/interface ethernet set ether4 comment="to LAN1"
/interface ethernet set ether5 comment="to LAN2"

og fyll ut grensesnittlistene:

/interface list member add interface=ether1 list=WAN comment=ISP1
/interface list member add interface=ether2 list=WAN comment=ISP2 
/interface list member add interface=ether3 list=WAN comment="to ISP3"
/interface list member add interface=ether4 list=LAN  comment="LAN1"
/interface list member add interface=ether5 list=LAN  comment="LAN2"

Merk. Å skrive forståelige kommentarer er verdt tiden brukt på dette, pluss at det i stor grad letter feilsøking og forståelse av konfigurasjonen.

Forfatteren anser det som nødvendig, av sikkerhetsgrunner, å legge til ether3-grensesnittet til "WAN"-grensesnittlisten, til tross for at ip-protokollen ikke vil gå gjennom den.

Ikke glem at etter at PPP-grensesnittet er hevet på ether3, må det også legges til grensesnittlisten "WAN"

1.4. Vi skjuler ruteren fra nabolagsdeteksjon og kontroll fra leverandørnettverk via MAC:

/ip neighbor discovery-settings set discover-interface-list=!WAN
/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN

1.5. Vi oppretter minimum tilstrekkelig sett med brannmurfilterregler for å beskytte ruteren:

/ip firewall filter add action=accept chain=input comment="Related Established Untracked Allow" 
connection-state=established,related,untracked

(regelen gir tillatelse til etablerte og relaterte tilkoblinger som initieres fra både tilkoblede nettverk og ruteren selv)

/ip firewall filter add action=accept chain=input comment="ICMP from ALL" protocol=icmp

(ping og ikke bare ping. All icmp er tillatt. Veldig nyttig for å finne MTU-problemer)

/ip firewall filter add action=drop chain=input comment="All other WAN Drop" in-interface-list=WAN

(regelen som lukker inndatakjeden forbyr alt annet som kommer fra Internett)

/ip firewall filter add action=accept chain=forward 
comment="Established, Related, Untracked allow" 
connection-state=established,related,untracked

(regelen tillater etablerte og relaterte tilkoblinger som går gjennom ruteren)

/ip firewall filter add action=drop chain=forward comment="Invalid drop" connection-state=invalid

(regelen tilbakestiller tilkoblinger med connection-state=ugyldig som går gjennom ruteren. Det anbefales sterkt av Mikrotik, men i noen sjeldne situasjoner kan det blokkere nyttig trafikk)

/ip firewall filter add action=drop chain=forward comment="Drop all from WAN not DSTNATed"  
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

(regelen forbyr pakker som kommer fra Internett og ikke har bestått dstnat-prosedyren å passere gjennom ruteren. Dette vil beskytte lokale nettverk fra inntrengere som, som er i samme kringkastingsdomene med våre eksterne nettverk, vil registrere våre eksterne IP-er som en gateway og dermed prøve å "utforske" våre lokale nettverk.)

Merk. La oss anta at nettverkene LAN1 og LAN2 er klarert og trafikken mellom dem og fra dem ikke filtreres.

1.6. Opprett en liste med en liste over ikke-rutbare nettverk:

/ip firewall address-list
add address=0.0.0.0/8 comment=""This" Network" list=BOGONS
add address=10.0.0.0/8 comment="Private-Use Networks" list=BOGONS
add address=100.64.0.0/10 comment="Shared Address Space. RFC 6598" list=BOGONS
add address=127.0.0.0/8 comment=Loopback list=BOGONS
add address=169.254.0.0/16 comment="Link Local" list=BOGONS
add address=172.16.0.0/12 comment="Private-Use Networks" list=BOGONS
add address=192.0.0.0/24 comment="IETF Protocol Assignments" list=BOGONS
add address=192.0.2.0/24 comment=TEST-NET-1 list=BOGONS
add address=192.168.0.0/16 comment="Private-Use Networks" list=BOGONS
add address=198.18.0.0/15 comment="Network Interconnect Device Benchmark Testing"
 list=BOGONS
add address=198.51.100.0/24 comment=TEST-NET-2 list=BOGONS
add address=203.0.113.0/24 comment=TEST-NET-3 list=BOGONS
add address=224.0.0.0/4 comment=Multicast list=BOGONS
add address=192.88.99.0/24 comment="6to4 Relay Anycast" list=BOGONS
add address=240.0.0.0/4 comment="Reserved for Future Use" list=BOGONS
add address=255.255.255.255 comment="Limited Broadcast" list=BOGONS

(Dette er en liste over adresser og nettverk som ikke kan rutes til Internett og vil bli fulgt deretter.)

Merk. Listen kan endres, så jeg anbefaler deg å sjekke relevansen med jevne mellomrom.

1.7. Sett opp DNS for selve ruteren:

/ip dns set servers=1.1.1.1,8.8.8.8

Merk. I den nåværende versjonen av ROS har dynamiske servere forrang over statiske. Navneoppløsningsforespørselen sendes til den første serveren i rekkefølge i listen. Overgangen til neste server utføres når den nåværende er utilgjengelig. Tidsavbruddet er stort - mer enn 5 sekunder. Retur tilbake, når den "falne serveren" gjenopptas, skjer ikke automatisk. Gitt denne algoritmen og tilstedeværelsen av en multivan, anbefaler forfatteren ikke å bruke servere levert av leverandører.

1.8. Sett opp et lokalt nettverk.
1.8.1. Vi konfigurerer statiske IP-adresser på LAN-grensesnitt:

/ip address add interface=ether4 address=192.168.88.254/24 comment="LAN1 IP"
/ip address add interface=ether5 address=172.16.1.0/23 comment="LAN2 IP"

1.8.2. Vi setter reglene for ruter til våre lokale nettverk gjennom hovedrutingstabellen:

/ip route rule add dst-address=192.168.88.0/24 table=main comment=”to LAN1”
/ip route rule add dst-address=172.16.0.0/23 table=main comment="to LAN2"

Merk. Dette er en av de raske og enkle måtene å få tilgang til LAN-adresser med kilder til eksterne IP-adresser til rutergrensesnitt som ikke går gjennom standardruten.

1.8.3. Aktiver Hairpin NAT for LAN1 og LAN2:

/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN1" 
out-interface=ether4 src-address=192.168.88.0/24 to-addresses=192.168.88.254
/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN2" 
out-interface=ether5 src-address=172.16.0.0/23 to-addresses=172.16.1.0

Merk. Dette lar deg få tilgang til ressursene dine (dstnat) via en ekstern IP mens du er inne i nettverket.

2. Faktisk, implementeringen av den helt riktige multivan

For å løse problemet med å "svare der de spurte fra", vil vi bruke to ROS-verktøy: tilkoblingsmerke и rutemerke. tilkoblingsmerke lar deg markere ønsket forbindelse og deretter jobbe med dette merket som betingelse for å søke rutemerke. Og allerede med rutemerke mulig å jobbe i IP-rute и ruteregler. Vi fant ut verktøyene, nå må du bestemme hvilke tilkoblinger du skal merke - en gang, nøyaktig hvor du skal merke - to.

Med den første er alt enkelt - vi må merke alle tilkoblingene som kommer til ruteren fra Internett via riktig kanal. I vårt tilfelle vil disse være tre etiketter (etter antall kanaler): «conn_isp1», «conn_isp2» og «conn_isp3».

Nyansen med den andre er at innkommende tilkoblinger vil være av to typer: transitt og de som er beregnet på selve ruteren. Tilkoblingsmerkemekanismen fungerer i tabellen mangle. Vurder bevegelsen av pakken på et forenklet diagram, vennligst kompilert av spesialistene på mikrotik-trainings.com-ressursen (ikke reklame):

Etter pilene ser vi at pakken ankommer "innspill grensesnitt", går gjennom kjeden"Forhåndsruting” og først da deles det inn i transitt og lokalt i blokken ”Rutingbeslutning". Derfor, for å slå to fluer i en smekk, bruker vi Tilkoblingsmerke i bordet Mangle forhåndsruting kjeder Forhåndsruting.

bemerkning. I ROS er "Routing mark"-etiketter oppført som "Tabell" i delen Ip/Ruter/Rules, og som "Routing Mark" i andre seksjoner. Dette kan føre til litt forvirring i forståelsen, men faktisk er dette det samme, og er en analog av rt_tables i iproute2 på linux.

2.1. Vi merker innkommende forbindelser fra hver av leverandørene:

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP1" connection-mark=no-mark in-interface=ether1  new-connection-mark=conn_isp1 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP2" connection-mark=no-mark in-interface=ether2  new-connection-mark=conn_isp2 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP3" connection-mark=no-mark in-interface=pppoe-isp3  new-connection-mark=conn_isp3 passthrough=no

Merk. For å ikke markere allerede merkede koblinger bruker jeg tilkoblingsmerke=ingen-merke-betingelsen i stedet for tilkoblingstilstand=ny fordi jeg synes dette er mer riktig, samt avvisning av slipp ugyldige koblinger i inngangsfilteret.

passthrough=no - fordi i denne implementeringsmetoden er re-markering utelukket, og for å øke hastigheten kan du avbryte oppregningen av regler etter den første kampen.

Det bør huskes på at vi ikke forstyrrer ruting på noen måte ennå. Nå er det bare stadier av forberedelse. Neste trinn i implementeringen vil være behandlingen av transittrafikk som returnerer over den etablerte forbindelsen fra destinasjonen i det lokale nettverket. De. de pakkene som (se diagrammet) passerte gjennom ruteren underveis:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” og kom til adressaten i det lokale nettverket.

Viktig! I ROS er det ingen logisk inndeling i eksterne og interne grensesnitt. Hvis vi sporer banen til svarpakken i henhold til diagrammet ovenfor, vil den følge samme logiske vei som forespørselen:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” bare for en forespørsel"Input Interface” var ISP-grensesnittet, og for svaret - LAN

2.2. Vi dirigerer responstrafikk til de tilsvarende rutetabellene:

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP1" connection-mark=conn_isp1 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP2" connection-mark=conn_isp2 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP3" connection-mark=conn_isp3 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp3 passthrough=no

Kommentar. in-interface-list=!WAN - vi jobber kun med trafikk fra det lokale nettverket og dst-address-type=!local som ikke har destinasjonsadressen til adressen til grensesnittene til selve ruteren.

Det samme for lokale pakker som kom til ruteren underveis:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Input”=>”Lokal prosess”

Viktig! Svaret vil gå på følgende måte:

”Local Process”=>”Routing Decision”=>”Output”=>”Post Routing”=>”Output Interface”

2.3. Vi sender svar lokal trafikk til de tilsvarende rutetabellene:

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP1" connection-mark=conn_isp1 dst-address-type=!local 
new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP2" connection-mark=conn_isp2 dst-address-type=!local 
new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP3" connection-mark=conn_isp3 dst-address-type=!local 
new-routing-mark=to_isp3 passthrough=no

På dette stadiet kan oppgaven med å forberede å sende et svar til internettkanalen som forespørselen kom fra anses som løst. Alt er merket, merket og klart til å rutes.
En utmerket "sideeffekt" av dette oppsettet er muligheten til å jobbe med DSNAT-portvideresending fra begge (ISP2, ISP3) leverandørene samtidig. Ikke i det hele tatt, siden vi på ISP1 har en adresse som ikke kan rutes. Denne effekten er viktig, for eksempel for en e-postserver med to MX-er som ser på forskjellige Internett-kanaler.

For å eliminere nyansene i driften av lokale nettverk med eksterne IP-rutere, bruker vi løsningene fra avsnitt. 1.8.2 og 3.1.2.6.

I tillegg kan du bruke et verktøy med markeringer for å løse avsnitt 3 i oppgaven. Vi implementerer det slik:

2.4. Vi dirigerer trafikk fra lokale kunder fra rutelistene til de aktuelle tabellene:

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP1" dst-address-list=!BOGONS new-routing-mark=to_isp1 
passthrough=no src-address-list=Via_ISP1

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP2" dst-address-list=!BOGONS new-routing-mark=to_isp2 
passthrough=no src-address-list=Via_ISP2

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP3" dst-address-list=!BOGONS new-routing-mark=to_isp3 
passthrough=no src-address-list=Via_ISP3

Som et resultat ser det omtrent slik ut:

3. Sett opp en tilkobling til Internett-leverandøren og aktiver merkevareruting

3.1. Sett opp en tilkobling til ISP1:
3.1.1. Konfigurer en statisk IP-adresse:

/ip address add interface=ether1 address=100.66.66.2/30 comment="ISP1 IP"

3.1.2. Sett opp statisk ruting:
3.1.2.1. Legg til en standard "nødrute":

/ip route add comment="Emergency route" distance=254 type=blackhole

Merk. Denne ruten lar trafikk fra lokale prosesser passere rutebeslutningsstadiet, uavhengig av tilstanden til koblingene til noen av leverandørene. Nyansen med utgående lokaltrafikk er at for at pakken skal bevege seg i det minste et sted, må hovedrutingstabellen ha en aktiv rute til standard gateway. Hvis ikke, vil pakken ganske enkelt bli ødelagt.

Som en utvidelse av verktøyet sjekk gateway For en dypere analyse av kanaltilstanden foreslår jeg å bruke den rekursive rutemetoden. Essensen av metoden er at vi ber ruteren om å se etter en vei til gatewayen ikke direkte, men gjennom en mellomgateway. 4.2.2.1, 4.2.2.2 og 4.2.2.3 vil bli valgt som slike "test"-gatewayer for henholdsvis ISP1, ISP2 og ISP3.

3.1.2.2. Rute til "verifiserings"-adressen:

/ip route add check-gateway=ping comment="For recursion via ISP1"  
distance=1 dst-address=4.2.2.1 gateway=100.66.66.1 scope=10

Merk. Vi senker omfangsverdien til standard i ROS-målomfang for å bruke 4.2.2.1 som en rekursiv gateway i fremtiden. Jeg understreker: Omfanget av ruten til "test"-adressen må være mindre enn eller lik målomfanget for ruten som vil referere til testadressen.

3.1.2.3. Rekursiv standardrute for trafikk uten rutemerke:

/ip route add comment="Unmarked via ISP1" distance=2 gateway=4.2.2.1

Merk. Verdien avstand=2 brukes fordi ISP1 er deklarert som den første sikkerhetskopien i henhold til oppgavebetingelsene.

3.1.2.4. Rekursiv standardrute for trafikk med rutemerke "to_isp1":

/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1 
routing-mark=to_isp1

Merk. Faktisk, her begynner vi endelig å nyte fruktene av det forberedende arbeidet som ble utført i paragraf 2.

På denne ruten vil all trafikk som har merkeruten "to_isp1" bli dirigert til gatewayen til den første leverandøren, uavhengig av hvilken standard gateway som for øyeblikket er aktiv for hovedtabellen.

3.1.2.5. Første reserverekursive standardrute for ISP2- og ISP3-merket trafikk:

/ip route add comment="Marked via ISP2 Backup1" distance=2 gateway=4.2.2.1 
routing-mark=to_isp2
/ip route add comment="Marked via ISP3 Backup1" distance=2 gateway=4.2.2.1 
routing-mark=to_isp3

Merk. Disse rutene trengs blant annet for å reservere trafikk fra lokale nettverk som er medlemmer av adresselisten "to_isp*"'

3.1.2.6. Vi registrerer ruten for den lokale trafikken til ruteren til Internett gjennom ISP1:

/ip route rule add comment="From ISP1 IP to Inet" src-address=100.66.66.2 table=to_isp1

Merk. I kombinasjon med reglene fra avsnitt 1.8.2 gir den tilgang til ønsket kanal med en gitt kilde. Dette er kritisk for å bygge tunneler som spesifiserer den lokale IP-adressen (EoIP, IP-IP, GRE). Siden reglene i ip-rutereglene utføres fra topp til bunn, til den første matchen av betingelsene, bør denne regelen være etter reglene fra klausul 1.8.2.

3.1.3. Vi registrerer NAT-regelen for utgående trafikk:

/ip firewall nat add action=src-nat chain=srcnat comment="NAT via ISP1"  
ipsec-policy=out,none out-interface=ether1 to-addresses=100.66.66.2

Merk. NATim alt som går ut, bortsett fra det som kommer inn i IPsec-policyene. Jeg prøver å ikke bruke action=maskerade med mindre det er absolutt nødvendig. Den er tregere og mer ressurskrevende enn src-nat fordi den beregner NAT-adressen for hver ny tilkobling.

3.1.4. Vi sender klienter fra listen som har forbud mot å få tilgang gjennom andre leverandører direkte til ISP1-leverandørens gateway.

/ip firewall mangle add action=route chain=prerouting comment="Address List via ISP1 only" 
dst-address-list=!BOGONS passthrough=no route-dst=100.66.66.1 
src-address-list=Via_only_ISP1 place-before=0

Merk. action=rute har høyere prioritet og brukes før andre rutingsregler.

place-before=0 - plasserer regelen vår først i listen.

3.2. Sett opp en tilkobling til ISP2.

Siden ISP2-leverandøren gir oss innstillingene via DHCP, er det rimelig å gjøre de nødvendige endringene med et script som starter når DHCP-klienten utløses:

/ip dhcp-client
add add-default-route=no disabled=no interface=ether2 script=":if ($bound=1) do={r
    n    /ip route add check-gateway=ping comment="For recursion via ISP2" distance=1 
           dst-address=4.2.2.2/32 gateway=$"gateway-address" scope=10r
    n    /ip route add comment="Unmarked via ISP2" distance=1 gateway=4.2.2.2;r
    n    /ip route add comment="Marked via ISP2 Main" distance=1 gateway=4.2.2.2 
           routing-mark=to_isp2;r
    n    /ip route add comment="Marked via ISP1 Backup1" distance=2 gateway=4.2.2.2 
           routing-mark=to_isp1;r
    n    /ip route add comment="Marked via ISP3 Backup2" distance=3 gateway=4.2.2.2 
           routing-mark=to_isp3;r
    n    /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none 
           out-interface=$"interface" to-addresses=$"lease-address" comment="NAT via ISP2" 
           place-before=1;r
    n    if ([/ip route rule find comment="From ISP2 IP to Inet"] ="") do={r
    n        /ip route rule add comment="From ISP2 IP to Inet" 
               src-address=$"lease-address" table=to_isp2 r
    n    } else={r
    n       /ip route rule set [find comment="From ISP2 IP to Inet"] disabled=no 
              src-address=$"lease-address"r
    n    }      r
    n} else={r
    n   /ip firewall nat remove  [find comment="NAT via ISP2"];r
    n   /ip route remove [find comment="For recursion via ISP2"];r
    n   /ip route remove [find comment="Unmarked via ISP2"];r
    n   /ip route remove [find comment="Marked via ISP2 Main"];r
    n   /ip route remove [find comment="Marked via ISP1 Backup1"];r
    n   /ip route remove [find comment="Marked via ISP3 Backup2"];r
    n   /ip route rule set [find comment="From ISP2 IP to Inet"] disabled=yesr
    n}r
    n" use-peer-dns=no use-peer-ntp=no

Selve skriptet i Winbox-vinduet:

Merk. Den første delen av skriptet utløses når leieavtalen er oppnådd, den andre - etter at leieavtalen er utgitt.Se note 2

3.3. Vi setter opp en forbindelse til ISP3-leverandøren.

Siden innstillingsleverandøren gir oss dynamikk, er det rimelig å gjøre de nødvendige endringene med skript som starter etter at ppp-grensesnittet er hevet og etter fallet.

3.3.1. Først konfigurerer vi profilen:

/ppp profile
add comment="for PPPoE to ISP3" interface-list=WAN name=isp3_client 
on-down="/ip firewall nat remove  [find comment="NAT via ISP3"];r
    n/ip route remove [find comment="For recursion via ISP3"];r
    n/ip route remove [find comment="Unmarked via ISP3"];r
    n/ip route remove [find comment="Marked via ISP3 Main"];r
    n/ip route remove [find comment="Marked via ISP1 Backup2"];r
    n/ip route remove [find comment="Marked via ISP2 Backup2"];r
    n/ip route rule set [find comment="From ISP3 IP to Inet"] disabled=yes;" 
on-up="/ip route add check-gateway=ping comment="For recursion via ISP3" distance=1 
    dst-address=4.2.2.3/32 gateway=$"remote-address" scope=10r
    n/ip route add comment="Unmarked via ISP3" distance=3 gateway=4.2.2.3;r
    n/ip route add comment="Marked via ISP3 Main" distance=1 gateway=4.2.2.3 
    routing-mark=to_isp3;r
    n/ip route add comment="Marked via ISP1 Backup2" distance=3 gateway=4.2.2.3 
    routing-mark=to_isp1;r
    n/ip route add comment="Marked via ISP2 Backup2" distance=3 gateway=4.2.2.3 
    routing-mark=to_isp2;r
    n/ip firewall mangle set [find comment="Connmark in from ISP3"] 
    in-interface=$"interface";r
    n/ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none 
    out-interface=$"interface" to-addresses=$"local-address" comment="NAT via ISP3" 
    place-before=1;r
    nif ([/ip route rule find comment="From ISP3 IP to Inet"] ="") do={r
    n   /ip route rule add comment="From ISP3 IP to Inet" src-address=$"local-address" 
    table=to_isp3 r
    n} else={r
    n   /ip route rule set [find comment="From ISP3 IP to Inet"] disabled=no 
    src-address=$"local-address"r
    n};r
    n"

Selve skriptet i Winbox-vinduet:

Merk. Linje
/ip brannmur mangle set [finn kommentar="Connmark inn fra ISP3"] in-interface=$"grensesnitt";
lar deg håndtere omdøpningen av grensesnittet på riktig måte, siden det fungerer med koden og ikke visningsnavnet.

3.3.2. Nå, bruk profilen, opprett en ppp-tilkobling:

/interface pppoe-client add allow=mschap2 comment="to ISP3" disabled=no 
interface=ether3 name=pppoe-isp3 password=isp3_pass profile=isp3_client user=isp3_client

Som en siste detalj, la oss stille klokken:

/system ntp client set enabled=yes server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org

For de som leser til slutt

Den foreslåtte måten å implementere en multivan er forfatterens personlige preferanse og er ikke den eneste mulige. ROS-verktøysettet er omfattende og fleksibelt, noe som på den ene siden forårsaker vanskeligheter for nybegynnere, og på den annen side er årsaken til populariteten. Lær, prøv, oppdag nye verktøy og løsninger. For eksempel, som en anvendelse av den ervervede kunnskapen, er det mulig å erstatte verktøyet i denne implementeringen av multivanen check-gateway med rekursive ruter til netwatch.

Merknader

check-gateway - en mekanisme som lar deg deaktivere ruten etter to påfølgende mislykkede kontroller av gatewayen for tilgjengelighet. Kontrollen utføres en gang hvert 10. sekund, pluss svartidsavbrudd. Totalt ligger den faktiske koblingstidspunktet i området 20-30 sekunder. Hvis slik byttetiming ikke er tilstrekkelig, er det en mulighet for å bruke verktøyet netwatch, hvor sjekktimeren kan stilles inn manuelt. check-gateway avfyrer ikke på periodisk pakketap på lenken.
Viktig! Deaktivering av en primær rute vil deaktivere alle andre ruter som refererer til den. Derfor, for dem å spesifisere check-gateway=ping ikke nødvendig.
Det skjer at det oppstår en feil i DHCP-mekanismen, som ser ut som en klient som sitter fast i fornyelsestilstanden. I dette tilfellet vil ikke den andre delen av skriptet fungere, men det vil ikke hindre trafikk i å gå riktig, siden staten sporer den tilsvarende rekursive ruten.
ECMP (Equal Cost Multi-Path) - i ROS er det mulig å sette en rute med flere gatewayer og samme avstand. I dette tilfellet vil forbindelser fordeles på tvers av kanaler ved hjelp av round robin-algoritmen, i forhold til antall spesifiserte gatewayer.

For drivkraften til å skrive artikkelen, hjelp til å forme dens struktur og plassering av aksenter - personlig takknemlighet til Evgeny @jscar

Kilde: www.habr.com