🥇Multivan och routing på Mikrotik RouterOS

Inledning

Att ta upp artikeln, förutom fåfänga, föranleddes av den deprimerande frekvensen av frågor om detta ämne i profilgrupperna för den rysktalande telegramgemenskapen. Artikeln riktar sig till nybörjare som administratörer av Mikrotik RouterOS (nedan kallade ROS). Den handlar bara om multivan, med tonvikt på routing. Som en bonus finns det minimalt tillräckliga inställningar för att säkerställa säker och bekväm drift. De som letar efter avslöjande av ämnena köer, lastbalansering, vlans, broar, djupanalys i flera steg av kanalens tillstånd och liknande - får inte slösa tid och ansträngning på att läsa.

Rå data

Som testperson valdes en femports Mikrotik-router med ROS-version 6.45.3. Den kommer att dirigera trafik mellan två lokala nätverk (LAN1 och LAN2) och tre leverantörer (ISP1, ISP2, ISP3). Kanalen till ISP1 har en statisk "grå" adress, ISP2 - "vit", erhållen via DHCP, ISP3 - "vit" med PPPoE-auktorisering. Anslutningsschemat visas i figuren:

Uppgiften är att konfigurera MTK-routern baserat på schemat så att:

Ge automatiskt byte till en backupleverantör. Huvudleverantören är ISP2, den första reserven är ISP1, den andra reserven är ISP3.
Organisera LAN1-nätverksåtkomst till Internet endast via ISP1.
Ge möjligheten att dirigera trafik från lokala nätverk till Internet genom den valda leverantören baserat på adresslistan.
Ge möjligheten att publicera tjänster från det lokala nätverket till Internet (DSTNAT)
Konfigurera ett brandväggsfilter för att ge minsta möjliga säkerhet från Internet.
Routern kan ge ut sin egen trafik genom vilken som helst av de tre leverantörerna, beroende på den valda källadressen.
Se till att svarspaket dirigeras till den kanal som de kom från (inklusive LAN).

Kommentar. Vi kommer att konfigurera routern "från början" för att garantera frånvaron av överraskningar i startkonfigurationerna "out of the box" som ändras från version till version. Winbox valdes som ett konfigurationsverktyg, där ändringar kommer att visas visuellt. Själva inställningarna kommer att ställas in av kommandon i Winbox-terminalen. Den fysiska anslutningen för konfiguration görs genom en direkt anslutning till Ether5-gränssnittet.

Lite resonemang om vad en multivan är, är det ett problem eller är det listiga smarta människor runt att väva konspirationsnätverk

En nyfiken och uppmärksam administratör, som sätter upp ett sådant eller liknande system på egen hand, inser plötsligt att det redan fungerar normalt. Ja, ja, utan dina anpassade rutttabeller och andra ruttregler, som de flesta artiklar om detta ämne är fulla av. Låt oss kolla?

Kan vi konfigurera adressering på gränssnitt och standardgateways? Ja:

På ISP1 registrerades adressen och gatewayen med avstånd=2 и check-gateway=ping.
På ISP2 är standardinställningen för dhcp-klienten - följaktligen kommer avståndet att vara lika med ett.
På ISP3 i pppoe-klientinställningarna när add-default-route=ja sätta default-route-distance=3.

Glöm inte att registrera NAT vid utgången:

/ip brandvägg nat add action=maskerad kedja=srcnat out-interface-list=WAN

Som ett resultat har användare av lokala webbplatser roligt att ladda ner katter via huvudleverantören av ISP2 och det finns en kanalreservation med hjälp av mekanismen kontrollera gateway Se not 1

Punkt 1 i uppgiften genomförs. Var är multivanen med sina märken? Nej…

Ytterligare. Du måste frigöra specifika klienter från LAN via ISP1:

/ip brandvägg mangle add action=ruttkedja=fördirigering dst-address-list=!BOGONS
passthrough=yes route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip brandvägg mangle add action=ruttkedja=fördirigering dst-address-list=!BOGONS
passthrough=ingen rutt-dst=100.66.66.1 src-adress=192.168.88.0/24

Punkterna 2 och 3 i uppgiften har genomförts. Etiketter, stämplar, ruttregler, var är du?!

Behöver du ge åtkomst till din favorit OpenVPN-server med adressen 172.17.17.17 för klienter från Internet? Snälla du:

/ip molnuppsättning ddns-enabled=ja

Som en peer ger vi kunden resultatet: ":put [ip moln få dns-namn]"

Vi registrerar portvidarebefordran från Internet:

/ip brandvägg nat add action=dst-nat kedja=dstnat dst-port=1194
in-interface-list=WAN-protokoll=udp till-adresser=172.17.17.17

Artikel 4 är klar.

Vi sätter upp en brandvägg och annan säkerhet för punkt 5, samtidigt är vi glada att allt redan fungerar för användarna och når en behållare med en favoritdryck ...
A! Tunnlar är bortglömda.

l2tp-klient, konfigurerad av google artikel, har stigit till din favorit holländska VDS? Ja.
l2tp-server med IPsec har stigit och klienter med DNS-namn från IP Cloud (se ovan.) klamrar sig fast? Ja.
När vi lutar oss tillbaka i stolen, smuttar på en drink, överväger vi lättjefullt punkterna 6 och 7 i uppgiften. Vi tänker – behöver vi det? Ändå fungerar det så (c) ... Så om det fortfarande inte behövs, så är det det. Multivan implementerad.

Vad är en multivan? Detta är anslutningen av flera internetkanaler till en router.

Du behöver inte läsa artikeln mer, för vad kan finnas där förutom en uppvisning av tvivelaktig tillämplighet?

För de som är kvar, som är intresserade av punkterna 6 och 7 i uppgiften, och dessutom känner klådan av perfektionism, dyker vi djupare.

Den viktigaste uppgiften med att implementera en multivan är rätt trafikdirigering. Nämligen: oavsett vilken (eller vilken) Se. not 3 ISP:s kanal(er) tittar på standardrutten på vår router, den bör returnera ett svar till den exakta kanalen paketet kom från. Uppgiften är tydlig. Vad är problemet? Faktum är att i ett enkelt lokalt nätverk är uppgiften densamma, men ingen stör sig på ytterligare inställningar och känner inte problem. Skillnaden är att alla routbara noder på Internet är tillgängliga via var och en av våra kanaler, och inte genom en strikt specifik, som i ett enkelt LAN. Och "problemet" är att om en begäran kom till oss om IP-adressen för ISP3, så kommer svaret i vårt fall att gå via ISP2-kanalen, eftersom standardgatewayen är riktad dit. Lämnar och kommer att kasseras av leverantören som felaktiga. Problemet har identifierats. Hur löser man det?

Lösningen är uppdelad i tre steg:

Förinställning. I detta skede kommer de grundläggande inställningarna för routern att ställas in: lokalt nätverk, brandvägg, adresslistor, hårnåls-NAT, etc.
Multivan. I detta skede kommer de nödvändiga anslutningarna att markeras och sorteras i routingtabeller.
Ansluter till en ISP. I detta skede kommer gränssnitten som ger anslutning till Internet att konfigureras, routing och mekanismen för internetkanalreservation kommer att aktiveras.

1. Förinställning

1.1. Vi rensar routerns konfiguration med kommandot:

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

håller med "Farlig! Återställa ändå? [y/N]:” och efter omstart ansluter vi till Winbox via MAC. I detta skede rensas konfigurationen och användarbasen.

1.2. Skapa en ny användare:

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

logga in under den och ta bort standarden:

/user remove admin

Kommentar. Det är borttagningen och inte inaktiveringen av standardanvändaren som författaren anser vara säkrare och rekommenderar för användning.

1.3. Vi skapar grundläggande gränssnittslistor för bekvämligheten att arbeta i en brandvägg, upptäcktsinställningar och andra MAC-servrar:

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

Signeringsgränssnitt 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"

och fyll i gränssnittslistorna:

/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. Att skriva begripliga kommentarer är värt den tid som läggs på detta, plus att det i hög grad underlättar felsökning och förståelse av konfigurationen.

Författaren anser att det av säkerhetsskäl är nödvändigt att lägga till ether3-gränssnittet till "WAN"-gränssnittslistan, trots att ip-protokollet inte kommer att gå igenom det.

Glöm inte att efter att PPP-gränssnittet har höjts på ether3, måste det också läggas till i gränssnittslistan "WAN"

1.4. Vi döljer routern från grannskapsdetektering och kontroll från leverantörsnätverk 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 skapar den minsta tillräckliga uppsättningen av brandväggsfilterregler för att skydda routern:

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

(regeln ger tillstånd för etablerade och relaterade anslutningar som initieras från både anslutna nätverk och själva routern)

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

(ping och inte bara ping. All icmp är tillåten. Mycket användbart för att hitta MTU-problem)

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

(regeln som stänger inmatningskedjan förbjuder allt annat som kommer från Internet)

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

(regeln tillåter etablerade och relaterade anslutningar som passerar genom routern)

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

(regeln återställer anslutningar med connection-state=invalid som passerar genom routern. Det rekommenderas starkt av Mikrotik, men i vissa sällsynta situationer kan det blockera användbar 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

(regeln förbjuder paket som kommer från Internet och inte har klarat dstnat-proceduren att passera via routern. Detta kommer att skydda lokala nätverk från inkräktare som, som är i samma sändningsdomän med våra externa nätverk, kommer att registrera våra externa IP-adresser som en gateway och därmed försöka "utforska" våra lokala nätverk.)

Kommentar. Låt oss anta att nätverken LAN1 och LAN2 är betrodda och att trafiken mellan dem och från dem inte filtreras.

1.6. Skapa en lista med en lista över icke-routbara nätverk:

/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

(Detta är en lista över adresser och nätverk som inte är routbara till Internet och kommer att följas därefter.)

Kommentar. Listan kan komma att ändras, så jag råder dig att regelbundet kontrollera relevansen.

1.7. Konfigurera DNS för själva routern:

/ip dns set servers=1.1.1.1,8.8.8.8

Kommentar. I den nuvarande versionen av ROS har dynamiska servrar företräde framför statiska. Namnupplösningsbegäran skickas till den första servern i ordningen i listan. Övergången till nästa server utförs när den nuvarande inte är tillgänglig. Timeouten är stor - mer än 5 sekunder. Att återvända, när den "fallna servern" återupptas, sker inte automatiskt. Med tanke på denna algoritm och närvaron av en multivan rekommenderar författaren att inte använda servrar som tillhandahålls av leverantörer.

1.8. Konfigurera ett lokalt nätverk.
1.8.1. Vi konfigurerar statiska IP-adresser på LAN-gränssnitt:

/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 ställer in reglerna för rutter till våra lokala nätverk genom huvudrutttabellen:

/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. Detta är ett av de snabba och enkla sätten att komma åt LAN-adresser med källor till externa IP-adresser för routergränssnitt som inte går via standardrutten.

1.8.3. Aktivera Hairpin NAT för LAN1 och 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. Detta gör att du kan komma åt dina resurser (dstnat) via en extern IP medan du är inne i nätverket.

2. Faktiskt, genomförandet av den mycket korrekta multivan

För att lösa problemet med att "svara var de frågade ifrån" kommer vi att använda två ROS-verktyg: anslutningsmärke и ruttmärke. anslutningsmärke låter dig markera önskad anslutning och sedan arbeta med denna markering som villkor för ansökan ruttmärke. Och redan med ruttmärke möjligt att arbeta i ip-rutt и ruttregler. Vi kom på verktygen, nu måste du bestämma vilka anslutningar som ska markeras - en gång, exakt var du ska markera - två.

Med den första är allt enkelt - vi måste markera alla anslutningar som kommer till routern från Internet via lämplig kanal. I vårt fall kommer dessa att vara tre etiketter (efter antalet kanaler): "conn_isp1", "conn_isp2" och "conn_isp3".

Nyansen med den andra är att inkommande anslutningar kommer att vara av två typer: transit och de som är avsedda för själva routern. Anslutningsmarkeringsmekanismen fungerar i tabellen mangrove. Tänk på paketets rörelse på ett förenklat diagram, vänligt sammanställt av specialisterna på mikrotik-trainings.com-resursen (inte reklam):

Efter pilarna ser vi att paketet anländer till "ingångsgränssnitt", går genom kedjan"Fördirigering” och först då delas den in i transit och lokal i blocket ”Beslut om färdväg". Därför använder vi för att slå två flugor i en smäll Anslutningsmärke i bordet Mangle Pre-routing kedjor Fördirigering.

anmärkning. I ROS listas "Rutningsmärke"-etiketter som "Tabell" i avsnittet Ip/Rutter/Regler och som "Ruttmärke" i andra avsnitt. Detta kan skapa en viss förvirring i förståelsen, men i själva verket är detta samma sak, och är en analog av rt_tables i iproute2 på linux.

2.1. Vi markerar inkommande anslutningar från var och en av leverantörerna:

/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. För att inte markera redan markerade anslutningar använder jag anslutningsmarkering=no-mark condition istället för connection-state=new eftersom jag tycker att detta är mer korrekt, samt avvisande av släpp ogiltiga anslutningar i ingångsfiltret.

passthrough=no - för i denna implementeringsmetod är ommärkning utesluten och för att påskynda kan du avbryta uppräkningen av regler efter den första matchningen.

Man bör komma ihåg att vi inte på något sätt stör routing ännu. Nu finns det bara stadier av förberedelser. Nästa steg i implementeringen kommer att vara behandlingen av transittrafik som återvänder över den etablerade anslutningen från destinationen i det lokala nätverket. De där. de paket som (se diagrammet) passerade genom routern längs vägen:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” och kom till sin adressat i det lokala nätverket.

Viktigt! I ROS finns det ingen logisk uppdelning i externa och interna gränssnitt. Om vi spårar sökvägen för svarspaketet enligt diagrammet ovan, kommer det att följa samma logiska väg som begäran:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” bara för en förfrågan"input Interface” var ISP-gränssnittet, och för svaret - LAN

2.2. Vi dirigerar svarstrafiken till motsvarande rutttabeller:

/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 arbetar endast med trafik från det lokala nätverket och dst-address-type=!local som inte har destinationsadressen för adressen till själva routerns gränssnitt.

Samma sak för lokala paket som kom till routern längs vägen:

“Input Interface”=>”Prerouting”=>”Routingbeslut”=>”Input”=>”Lokal process”

Viktigt! Svaret kommer att gå på följande sätt:

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

2.3. Vi riktar svar lokal trafik till motsvarande 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

I detta skede kan uppgiften att förbereda att skicka ett svar till den internetkanal som förfrågan kom från anses vara löst. Allt är märkt, märkt och redo att dirigeras.
En utmärkt "bieffekt" av denna installation är möjligheten att arbeta med DSNAT-portvidarebefordran från båda (ISP2, ISP3) leverantörerna samtidigt. Inte alls, eftersom vi på ISP1 har en adress som inte kan dirigeras. Denna effekt är viktig för till exempel en e-postserver med två MX:er som tittar på olika internetkanaler.

För att eliminera nyanserna i driften av lokala nätverk med externa IP-routrar använder vi lösningarna från stycken. 1.8.2 och 3.1.2.6.

Dessutom kan du använda ett verktyg med markeringar för att lösa punkt 3 i problemet. Vi implementerar det så här:

2.4. Vi dirigerar trafik från lokala kunder från routinglistorna till lämpliga 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 ett resultat ser det ut ungefär så här:

3. Skapa en anslutning till Internetleverantören och aktivera routing av märket

3.1. Konfigurera en anslutning till ISP1:
3.1.1. Konfigurera en statisk IP-adress:

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

3.1.2. Ställ in statisk routing:
3.1.2.1. Lägg till en standard "nödrutt":

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

Kommentar. Denna rutt tillåter trafik från lokala processer att passera ruttbeslutsstadiet, oavsett tillståndet för länkarna hos någon av leverantörerna. Nyansen med utgående lokal trafik är att för att paketet ska kunna flyttas åtminstone någonstans måste huvuddirigeringstabellen ha en aktiv rutt till standardgatewayen. Om inte, kommer paketet helt enkelt att förstöras.

Som en verktygsförlängning kontrollera gateway För en djupare analys av kanaltillståndet föreslår jag att du använder den rekursiva ruttmetoden. Kärnan i metoden är att vi säger åt routern att leta efter en väg till sin gateway inte direkt, utan genom en mellanliggande gateway. 4.2.2.1, 4.2.2.2 och 4.2.2.3 kommer att väljas som sådana "test"-gateways för ISP1, ISP2 respektive ISP3.

3.1.2.2. Väg till "verifieringsadressen":

/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 scope-värdet till standard i ROS target scope för att använda 4.2.2.1 som en rekursiv gateway i framtiden. Jag betonar: omfattningen av rutten till "testadressen" måste vara mindre än eller lika med målomfattningen för rutten som kommer att referera till testadressen.

3.1.2.3. Rekursiv standardrutt för trafik utan ruttmarkering:

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

Kommentar. Värdet avstånd=2 används eftersom ISP1 deklareras som den första säkerhetskopian enligt uppgiftsvillkoren.

3.1.2.4. Rekursiv standardrutt för trafik med ruttmärke "to_isp1":

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

Kommentar. Faktiskt, här börjar vi äntligen njuta av frukterna av det förberedande arbete som utfördes i punkt 2.

På denna rutt kommer all trafik som har markeringen "to_isp1" att dirigeras till den första leverantörens gateway, oavsett vilken standardgateway som för närvarande är aktiv för huvudtabellen.

3.1.2.5. Första reservrekursiv standardrutt för ISP2- och ISP3-taggad 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. Dessa rutter behövs bland annat för att reservera trafik från lokala nätverk som är medlemmar i adresslistan "to_isp*"'

3.1.2.6. Vi registrerar rutten för routerns lokala trafik till Internet via ISP1:

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

Kommentar. I kombination med reglerna från punkt 1.8.2 ger den åtkomst till den önskade kanalen med en given källa. Detta är avgörande för att bygga tunnlar som anger den lokala IP-adressen (EoIP, IP-IP, GRE). Eftersom reglerna i ip-ruttreglerna exekveras från topp till botten, fram till den första matchningen av villkoren, bör denna regel ligga efter reglerna från paragraf 1.8.2.

3.1.3. Vi registrerar NAT-regeln för utgå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 allt som slocknar, förutom det som kommer in i IPsec-policyerna. Jag försöker att inte använda action=maskerad om det inte är absolut nödvändigt. Den är långsammare och mer resurskrävande än src-nat eftersom den beräknar NAT-adressen för varje ny anslutning.

3.1.4. Vi skickar kunder från listan som är förbjudna att komma åt via andra leverantörer direkt till ISP1-leverantö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

Kommentar. action=route har högre prioritet och tillämpas före andra routingregler.

place-before=0 - placerar vår regel först i listan.

3.2. Skapa en anslutning till ISP2.

Eftersom ISP2-leverantören ger oss inställningarna via DHCP är det rimligt att göra nödvändiga ändringar med ett skript som startar när DHCP-klienten triggas:

/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

Själva skriptet i Winbox-fönstret:

Kommentar. Den första delen av skriptet utlöses när hyresavtalet framgångsrikt erhålls, den andra - efter att hyresavtalet släppts.Se not 2

3.3. Vi upprättar en anslutning till ISP3-leverantören.

Eftersom inställningsleverantören ger oss dynamik är det rimligt att göra nödvändiga ändringar med skript som startar efter att ppp-gränssnittet har höjts och efter fallet.

3.3.1. Först konfigurerar 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"

Själva skriptet i Winbox-fönstret:

Kommentar. Linje
/ip brandvägg mangle set [find comment="Connmark in from ISP3"] in-interface=$"interface";
låter dig hantera bytet av gränssnittet korrekt, eftersom det fungerar med dess kod och inte visningsnamnet.

3.3.2. Skapa nu en ppp-anslutning med hjälp av profilen:

/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 sista touch, låt oss ställa klockan:

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

För den som läser till slutet

Det föreslagna sättet att implementera en multivan är författarens personliga preferens och är inte det enda möjliga. ROS-verktygslådan är omfattande och flexibel, vilket å ena sidan orsakar svårigheter för nybörjare, och å andra sidan är orsaken till dess popularitet. Lär dig, prova, upptäck nya verktyg och lösningar. Till exempel, som en tillämpning av den förvärvade kunskapen, är det möjligt att ersätta verktyget i denna implementering av multivanen check-gateway med rekursiva vägar till netwatch.

Anteckningar

check-gateway - en mekanism som gör att du kan avaktivera rutten efter två på varandra följande misslyckade kontroller av gatewayen för tillgänglighet. Kontrollen utförs en gång var 10:e sekund, plus svarstiden. Totalt ligger den faktiska växlingstiden i intervallet 20-30 sekunder. Om en sådan omkopplingstid inte är tillräcklig finns det ett alternativ att använda verktyget netwatch, där kontrolltimern kan ställas in manuellt. check-gateway avfyras inte vid intermittent paketförlust på länken.
Viktig! Om du avaktiverar en primär rutt inaktiveras alla andra rutter som refererar till den. Därför för dem att specificera check-gateway=ping inte nödvändigt.
Det händer att ett fel inträffar i DHCP-mekanismen, som ser ut som en klient som har fastnat i förnyelsetillståndet. I det här fallet kommer den andra delen av skriptet inte att fungera, men det kommer inte att hindra trafiken från att gå korrekt, eftersom staten spårar motsvarande rekursiva rutt.
ECMP (Equal Cost Multi-Path) - i ROS är det möjligt att sätta en rutt med flera gateways och samma avstånd. I det här fallet kommer anslutningar att fördelas över kanaler med hjälp av round robin-algoritmen, i proportion till antalet specificerade gateways.

För drivkraften att skriva artikeln, hjälp med att forma dess struktur och placering av accenter - personlig tacksamhet till Evgeny @jscar

Källa: will.com