🥇Multivan og routing på Mikrotik RouterOS

Indledning

At tage artiklen op, ud over forfængelighed, blev foranlediget af den deprimerende frekvens af spørgsmål om dette emne i profilgrupperne i det russisktalende telegramsamfund. Artiklen henvender sig til uerfarne Mikrotik RouterOS (herefter benævnt ROS) administratorer. Den beskæftiger sig kun med multivan, med vægt på routing. Som en bonus er der minimalt tilstrækkelige indstillinger til at sikre sikker og bekvem betjening. De, der leder efter afsløring af emnerne køer, belastningsbalancering, vlans, broer, flertrins dyb analyse af kanalens tilstand og lignende - spilder måske ikke tid og kræfter på at læse.

Indledende data

Som testperson blev der valgt en femports Mikrotik-router med ROS-version 6.45.3. Det vil dirigere trafik mellem to lokale netværk (LAN1 og LAN2) og tre udbydere (ISP1, ISP2, ISP3). Kanalen til ISP1 har en statisk "grå" adresse, ISP2 - "hvid", opnået via DHCP, ISP3 - "hvid" med PPPoE-autorisation. Tilslutningsdiagrammet er vist på figuren:

Opgaven er at konfigurere MTK-routeren baseret på skemaet, således at:

Giv automatisk skift til en backup-udbyder. Hovedudbyderen er ISP2, den første reserve er ISP1, den anden reserve er ISP3.
Organiser LAN1-netværksadgang til internettet kun via ISP1.
Giv mulighed for at dirigere trafik fra lokale netværk til internettet gennem den valgte udbyder baseret på adresselisten.
Giv mulighed for at publicere tjenester fra det lokale netværk til internettet (DSTNAT)
Konfigurer et firewallfilter for at give den mindst mulige sikkerhed fra internettet.
Routeren kunne udstede sin egen trafik gennem enhver af de tre udbydere, afhængigt af den valgte kildeadresse.
Sørg for, at svarpakker dirigeres til den kanal, de kom fra (inklusive LAN).

Kommentar. Vi vil konfigurere routeren "fra bunden" for at garantere fraværet af overraskelser i startkonfigurationerne "ud af boksen", der skifter fra version til version. Winbox blev valgt som et konfigurationsværktøj, hvor ændringer vil blive vist visuelt. Selve indstillingerne vil blive indstillet af kommandoer i Winbox-terminalen. Den fysiske forbindelse til konfiguration foretages ved en direkte forbindelse til Ether5-grænsefladen.

En smule ræsonnement om, hvad en multivan er, er det et problem eller er der snedige smarte mennesker omkring vævning af konspirationsnetværk

En nysgerrig og opmærksom administrator, der selv opretter en sådan eller lignende ordning, indser pludselig pludselig, at den allerede fungerer normalt. Ja, ja, uden dine tilpassede rutetabeller og andre ruteregler, som de fleste artikler om dette emne er fulde af. Lad os tjekke?

Kan vi konfigurere adressering på grænseflader og standardgateways? Ja:

På ISP1 blev adressen og gatewayen registreret med afstand=2 и check-gateway=ping.
På ISP2 er standardindstillingen for dhcp-klient - derfor vil afstanden være lig med én.
På ISP3 i pppoe-klientindstillingerne hvornår add-default-route=ja sætte default-rute-distance=3.

Glem ikke at registrere NAT ved udgangen:

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

Som et resultat har brugere af lokale websteder det sjovt med at downloade katte gennem hoved-ISP2-udbyderen, og der er en kanalreservation ved hjælp af mekanismen tjek gateway Se note 1

Opgavens punkt 1 implementeres. Hvor er multivanen med sine mærker? Ingen…

Yderligere. Du skal frigive specifikke klienter fra LAN via ISP1:

/ip firewall mangle tilføj action=rutekæde=prerouting dst-address-list=!BOGONS
passthrough=yes route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip firewall mangle tilføj action=rutekæde=prerouting dst-address-list=!BOGONS
passthrough=ingen rute-dst=100.66.66.1 src-adresse=192.168.88.0/24

Opgavens punkt 2 og 3 er gennemført. Etiketter, stempler, ruteregler, hvor er du?!

Har du brug for at give adgang til din foretrukne OpenVPN-server med adressen 172.17.17.17 for klienter fra internettet? Vær venlig:

/ip skysæt ddns-enabled=ja

Som peer giver vi kunden outputresultatet: ":put [ip cloud få dns-navn]"

Vi registrerer port forwarding fra internettet:

/ip firewall nat tilføje handling=dst-nat kæde=dstnat dst-port=1194
in-interface-list=WAN-protokol=udp til-adresser=172.17.17.17

Punkt 4 er klar.

Vi sætter en firewall og anden sikkerhed op til punkt 5, samtidig er vi glade for, at alt allerede fungerer for brugerne og rækker ud efter en beholder med en yndlingsdrink ...
EN! Tunneler er glemt.

l2tp-klient, konfigureret af google artikel, er steget til din yndlings hollandske VDS? Ja.
l2tp-server med IPsec er steget og klienter efter DNS-navn fra IP Cloud (se ovenfor.) klæber? Ja.
Læner vi os tilbage i stolen og nipper til en drink, og overvejer dovent opgavens punkt 6 og 7. Vi tænker – har vi brug for det? Alligevel fungerer det sådan (c) ... Så hvis det stadig ikke er nødvendigt, så er det det. Multivan implementeret.

Hvad er en multivan? Dette er forbindelsen af flere internetkanaler til en router.

Du behøver ikke læse artiklen yderligere, for hvad kan der være udover et show off af tvivlsom anvendelighed?

For dem, der er tilbage, som er interesserede i opgavens punkt 6 og 7, og også mærker perfektionismens kløe, dykker vi dybere.

Den vigtigste opgave ved at implementere en multivan er den korrekte trafikdirigering. Nemlig: uanset hvilken (eller hvilken) Se. note 3 internetudbyderens kanal(er) ser på standardruten på vores router, den skulle returnere et svar til den nøjagtige kanal pakken kom fra. Opgaven er klar. Hvor er problemet? Faktisk, i et simpelt lokalt netværk er opgaven den samme, men ingen gider med yderligere indstillinger og føler ikke problemer. Forskellen er, at enhver routbar node på internettet er tilgængelig gennem hver af vores kanaler, og ikke gennem en strengt specifik, som i et simpelt LAN. Og "problemet" er, at hvis der kom en anmodning til os om IP-adressen på ISP3, så vil svaret i vores tilfælde gå gennem ISP2-kanalen, da standardgatewayen er rettet dertil. Forlader og vil blive kasseret af udbyderen som forkert. Problemet er blevet identificeret. Hvordan løses det?

Løsningen er opdelt i tre faser:

Forudindstilling. På dette stadium indstilles routerens grundlæggende indstillinger: lokalt netværk, firewall, adresselister, hårnål NAT osv.
Multivan. På dette tidspunkt vil de nødvendige forbindelser blive markeret og sorteret i routingtabeller.
Opretter forbindelse til en internetudbyder. På dette stadium vil grænsefladerne, der giver forbindelse til internettet, blive konfigureret, routing og internetkanalreservationsmekanismen vil blive aktiveret.

1. Forudindstilling

1.1. Vi rydder routerkonfigurationen med kommandoen:

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

enig med "Farligt! Nulstille alligevel? [y/N]:” og efter genstart forbinder vi med Winbox via MAC. På dette stadium er konfigurationen og brugerbasen ryddet.

1.2. Opret en ny bruger:

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

log ind under den og slet standarden:

/user remove admin

Kommentar. Det er fjernelse og ikke deaktivering af standardbrugeren, som forfatteren betragter som sikrere og anbefaler til brug.

1.3. Vi opretter grundlæggende grænsefladelister for at gøre det nemt at arbejde i en firewall, opdagelsesindstillinger og andre MAC-servere:

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

Signeringsgrænseflader 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 udfyld grænsefladelisterne:

/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"

Kommentar. At skrive forståelige kommentarer er værd at bruge tid på dette, plus det letter i høj grad fejlfinding og forståelse af konfigurationen.

Forfatteren anser det for nødvendigt af sikkerhedsmæssige årsager at tilføje ether3-grænsefladen til "WAN"-grænsefladelisten, på trods af at ip-protokollen ikke vil gå igennem den.

Glem ikke, at efter at PPP-grænsefladen er rejst på ether3, skal den også tilføjes til grænsefladelisten "WAN"

1.4. Vi skjuler routeren fra naboskabsdetektion og kontrol fra udbydernetværk 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 opretter det mindste tilstrækkelige sæt af firewall-filterregler til at beskytte routeren:

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

(reglen giver tilladelse til etablerede og relaterede forbindelser, der startes fra både tilsluttede netværk og selve routeren)

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

(ping og ikke kun ping. Alt icmp er tilladt. Meget nyttigt til at finde MTU-problemer)

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

(reglen, der lukker inputkæden, forbyder alt andet, der kommer fra internettet)

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

(reglen tillader etablerede og relaterede forbindelser, der passerer gennem routeren)

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

(reglen nulstiller forbindelser med forbindelse-state=ugyldig, der passerer gennem routeren. Det anbefales kraftigt af Mikrotik, men i nogle sjældne situationer kan det blokere nyttig trafik)

/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

(reglen forbyder pakker, der kommer fra internettet og ikke har bestået dstnat-proceduren, at passere gennem routeren. Dette vil beskytte lokale netværk mod ubudne gæster, der, der er i samme broadcast-domæne med vores eksterne netværk, vil registrere vores eksterne IP'er som en gateway og dermed prøve at "udforske" vores lokale netværk.)

Kommentar. Lad os antage, at netværkene LAN1 og LAN2 er tillid til, og at trafikken mellem dem og fra dem ikke filtreres.

1.6. Opret en liste med en liste over ikke-routable netværk:

/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 netværk, der ikke kan omdirigeres til internettet og vil blive fulgt i overensstemmelse hermed.)

Kommentar. Listen kan ændres, så jeg råder dig til med jævne mellemrum at tjekke relevansen.

1.7. Konfigurer DNS for selve routeren:

/ip dns set servers=1.1.1.1,8.8.8.8

Kommentar. I den nuværende version af ROS har dynamiske servere forrang frem for statiske. Navneopløsningsanmodningen sendes til den første server i rækkefølge på listen. Overgangen til den næste server udføres, når den nuværende ikke er tilgængelig. Timeoutet er stort - mere end 5 sekunder. Retur tilbage, når den "faldne server" genoptages, sker ikke automatisk. I betragtning af denne algoritme og tilstedeværelsen af en multivan, anbefaler forfatteren ikke at bruge servere leveret af udbydere.

1.8. Opsæt et lokalt netværk.
1.8.1. Vi konfigurerer statiske IP-adresser på LAN-grænseflader:

/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 sætter reglerne for ruter til vores lokale netværk gennem 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"

Kommentar. Dette er en af de hurtige og nemme måder at få adgang til LAN-adresser med kilder til eksterne IP-adresser på routergrænseflader, der ikke går gennem 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

Kommentar. Dette giver dig adgang til dine ressourcer (dstnat) via en ekstern IP, mens du er inde i netværket.

2. Faktisk implementeringen af den meget korrekte multivan

For at løse problemet med "at svare, hvor de spurgte fra", vil vi bruge to ROS-værktøjer: forbindelsesmærke и rutemærke. forbindelsesmærke giver dig mulighed for at markere den ønskede forbindelse og derefter arbejde med dette mærke som betingelse for ansøgning rutemærke. Og allerede med rutemærke muligt at arbejde i ip-rute и ruteregler. Vi fandt ud af værktøjerne, nu skal du beslutte, hvilke forbindelser du skal markere - én gang, præcis hvor du skal markere - to.

Med den første er alt enkelt - vi skal markere alle de forbindelser, der kommer til routeren fra internettet via den relevante kanal. I vores tilfælde vil disse være tre etiketter (efter antallet af kanaler): "conn_isp1", "conn_isp2" og "conn_isp3".

Nuancen med den anden er, at indgående forbindelser vil være af to typer: transit og dem, der er beregnet til selve routeren. Tilslutningsmærkemekanismen fungerer i bordet mangle. Overvej pakkens bevægelse på et forenklet diagram, venligt udarbejdet af specialisterne fra mikrotik-trainings.com-ressourcen (ikke reklame):

Efter pilene ser vi, at pakken ankommer kl.indgangsinterface", går gennem kæden"Prerouting” og først derefter er det opdelt i transit og lokal i blokken ”Rutebeslutning". Derfor bruger vi for at slå to fluer med ét smæk Tilslutningsmærke i bordet Mangle Pre-routing kæder Prerouting.

bemærkning. I ROS er "Routing mark"-etiketter angivet som "Tabel" i afsnittet Ip/Ruter/Regler og som "Routing Mark" i andre sektioner. Dette kan skabe en vis forvirring i forståelsen, men i virkeligheden er dette det samme, og det er en analog af rt_tables i iproute2 på linux.

2.1. Vi markerer indgående forbindelser fra hver af udbyderne:

/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

Kommentar. For ikke at markere allerede markerede forbindelser, bruger jeg forbindelsesmærket=no-mark condition i stedet for forbindelsestilstand=ny, fordi jeg synes dette er mere korrekt, samt afvisningen af drop ugyldige forbindelser i inputfilteret.

passthrough=no - fordi i denne implementeringsmetode er re-markering udelukket, og for at fremskynde kan du afbryde opregningen af regler efter den første match.

Man skal huske på, at vi ikke på nogen måde forstyrrer routing endnu. Nu er der kun stadier af forberedelse. Det næste trin i implementeringen vil være behandlingen af transittrafik, der returnerer over den etablerede forbindelse fra destinationen i det lokale netværk. De der. de pakker, der (se diagrammet) passerede gennem routeren undervejs:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” og kom til deres adressat i det lokale netværk.

Vigtigt! I ROS er der ingen logisk opdeling i eksterne og interne grænseflader. Hvis vi sporer stien til svarpakken i henhold til ovenstående diagram, vil den følge den samme logiske vej som anmodningen:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” bare for en anmodning"input interface” var ISP-grænsefladen, og for svaret - LAN

2.2. Vi dirigerer responstransittrafik til de tilsvarende rutetabeller:

/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 arbejder kun med trafik fra det lokale netværk og dst-address-type=!local, der ikke har destinationsadressen på adressen på selve routerens grænseflader.

Det samme for lokale pakker, der kom til routeren undervejs:

“Input Interface”=>”Prerouting”=>”Routingbeslutning”=>”Input”=>”Lokal proces”

Vigtigt! Svaret vil gå på følgende måde:

”Lokal proces”=>”Routingbeslutning”=>”Output”=>”Post Routing”=>”Outputgrænseflade”

2.3. Vi dirigerer svar lokal trafik til de tilsvarende routingtabeller:

/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 stadium kan opgaven med at forberede at sende et svar til den internetkanal, som anmodningen kom fra, anses for løst. Alt er markeret, mærket og klar til at blive rutet.
En fremragende "bivirkning" af denne opsætning er evnen til at arbejde med DSNAT portvideresendelse fra begge (ISP2, ISP3) udbydere på samme tid. Slet ikke, da vi på ISP1 har en adresse, der ikke kan dirigeres. Denne effekt er vigtig, for eksempel for en mailserver med to MX'er, der ser på forskellige internetkanaler.

For at eliminere nuancerne i driften af lokale netværk med eksterne IP-routere bruger vi løsningerne fra afsnit. 1.8.2 og 3.1.2.6.

Derudover kan du bruge et værktøj med markeringer til at løse afsnit 3 i opgaven. Vi implementerer det sådan:

2.4. Vi dirigerer trafik fra lokale kunder fra routinglisterne til de relevante tabeller:

/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 sådan ud:

3. Opret en forbindelse til internetudbyderen og aktiver branded routing

3.1. Opret en forbindelse 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. Konfigurer statisk routing:
3.1.2.1. Tilføj en standard "nødrute":

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

Kommentar. Denne rute gør det muligt for trafik fra lokale processer at passere rutebeslutningsfasen, uanset tilstanden af forbindelserne hos nogen af udbyderne. Nuancen af udgående lokal trafik er, at for at pakken skal bevæge sig i det mindste et sted, skal hovedroutingtabellen have en aktiv rute til standardgatewayen. Hvis ikke, så bliver pakken simpelthen ødelagt.

Som en værktøjsudvidelse tjek gateway For en dybere analyse af kanaltilstanden foreslår jeg at bruge den rekursive rutemetode. Essensen af metoden er, at vi fortæller routeren om at lede efter en sti til dens gateway ikke direkte, men gennem en mellemliggende gateway. 4.2.2.1, 4.2.2.2 og 4.2.2.3 vil blive valgt som sådanne "test"-gateways for henholdsvis ISP1, ISP2 og ISP3.

3.1.2.2. Rute til "verifikations"-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

Kommentar. Vi sænker omfangsværdien til standarden i ROS-målomfang for at bruge 4.2.2.1 som en rekursiv gateway i fremtiden. Jeg understreger: Omfanget af ruten til "test"-adressen skal være mindre end eller lig med målomfanget for den rute, der vil referere til testadressen.

3.1.2.3. Rekursiv standardrute for trafik uden rutemærke:

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

Kommentar. Værdien afstand=2 bruges, fordi ISP1 er erklæret som den første backup i henhold til opgavebetingelserne.

3.1.2.4. Rekursiv standardrute for trafik med rutemærke "to_isp1":

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

Kommentar. Faktisk er vi her endelig begyndt at nyde frugterne af det forberedende arbejde, der blev udført i afsnit 2.

På denne rute vil al trafik, der har mærket ruten "to_isp1" blive dirigeret til den første udbyders gateway, uanset hvilken standard gateway, der i øjeblikket er aktiv for hovedtabellen.

3.1.2.5. Første fallback rekursive standardrute for ISP2- og ISP3-mærket trafik:

/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

Kommentar. Disse ruter er blandt andet nødvendige for at reservere trafik fra lokale netværk, der er medlemmer af adresselisten "to_isp*"'

3.1.2.6. Vi registrerer ruten for routerens lokale trafik til internettet gennem ISP1:

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

Kommentar. I kombination med reglerne fra afsnit 1.8.2 giver det adgang til den ønskede kanal med en given kilde. Dette er afgørende for at bygge tunneler, der specificerer den lokale side-IP-adresse (EoIP, IP-IP, GRE). Da reglerne i ip-rutereglerne udføres fra top til bund, indtil den første match af betingelserne, så bør denne regel være efter reglerne fra paragraf 1.8.2.

3.1.3. Vi registrerer NAT-reglen for udgående trafik:

/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

Kommentar. NATim alt, der går ud, undtagen hvad der kommer ind i IPsec-politikkerne. Jeg prøver ikke at bruge action=masquerade, medmindre det er absolut nødvendigt. Den er langsommere og mere ressourcekrævende end src-nat, fordi den beregner NAT-adressen for hver ny forbindelse.

3.1.4. Vi sender kunder fra listen, som har forbud mod at få adgang gennem andre udbydere, direkte til ISP1-udbyderens 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

Kommentar. action=route har en højere prioritet og anvendes før andre routingregler.

place-before=0 - placerer vores regel først på listen.

3.2. Opret en forbindelse til ISP2.

Da ISP2-udbyderen giver os indstillingerne via DHCP, er det rimeligt at foretage de nødvendige ændringer med et script, der starter, når DHCP-klienten udlø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 scriptet i Winbox-vinduet:

Kommentar. Den første del af scriptet udløses, når lejekontrakten er opnået med succes, den anden - efter lejekontrakten er frigivet.Se note 2

3.3. Vi opretter forbindelse til ISP3-udbyderen.

Da indstillingsudbyderen giver os dynamik, er det rimeligt at lave de nødvendige ændringer med scripts, der starter efter at ppp-grænsefladen er blevet hævet og efter faldet.

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 scriptet i Winbox-vinduet:

Kommentar. Line
/ip firewall mangle sæt [find comment="Connmark in from ISP3"] in-interface=$"interface";
giver dig mulighed for at håndtere omdøbningen af grænsefladen korrekt, da den fungerer med dens kode og ikke visningsnavnet.

3.3.2. Brug nu profilen til at oprette en ppp-forbindelse:

/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 sidste touch, lad os indstille uret:

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

For dem der læser til ende

Den foreslåede måde at implementere en multivan på er forfatterens personlige præference og er ikke den eneste mulige. ROS-værktøjssættet er omfattende og fleksibelt, hvilket på den ene side volder vanskeligheder for begyndere, og på den anden side er årsagen til dets popularitet. Lær, prøv, opdag nye værktøjer og løsninger. For eksempel, som en anvendelse af den erhvervede viden, er det muligt at erstatte værktøjet i denne implementering af multivanen check-gateway med rekursive ruter til netwatch.

noter

check-gateway - en mekanisme, der giver dig mulighed for at deaktivere ruten efter to på hinanden følgende mislykkede kontroller af gatewayen for tilgængelighed. Kontrollen udføres en gang hvert 10. sekund plus svartimeout. I alt ligger den faktiske koblingstid i intervallet 20-30 sekunder. Hvis en sådan skifttiming ikke er tilstrækkelig, er der mulighed for at bruge værktøjet netwatch, hvor kontroltimeren kan indstilles manuelt. check-gateway udløses ikke ved periodisk pakketab på linket.
Vigtig! Deaktivering af en primær rute vil deaktivere alle andre ruter, der henviser til den. Derfor for dem at angive check-gateway=ping ikke nødvendigt.
Det sker, at der opstår en fejl i DHCP-mekanismen, som ligner en klient, der sidder fast i fornyelsestilstanden. I dette tilfælde vil den anden del af scriptet ikke fungere, men det forhindrer ikke trafik i at gå korrekt, da staten sporer den tilsvarende rekursive rute.
ECMP (Equal Cost Multi-Path) - i ROS er det muligt at sætte en rute med flere gateways og samme afstand. I dette tilfælde vil forbindelser blive fordelt på tværs af kanaler ved hjælp af round robin-algoritmen i forhold til antallet af specificerede gateways.

For drivkraften til at skrive artiklen, hjælp til at forme dens struktur og placering af accenter - personlig taknemmelighed til Evgeny @jscar

Kilde: www.habr.com

Multivan og routing på Mikrotik RouterOS