🥇Multipath och routing på Mikrotik RouterOS

Introduktion

Att ta itu med artikeln, förutom fåfänga, drevs av den nedslående frekvensen av frågor kring detta ämne i profilerade grupper inom det ryskspråkiga Telegram-samhället. Artikeln riktar sig till nybörjare inom Mikrotik RouterOS (hädanefter ROS). Den behandlar endast multipath-routing med fokus på routning. Som bonus finns det minimalt tillräckliga inställningar för att säkerställa säker och bekväm användning. De som söker djupgående analyser av köer, belastningsbalansering, VLAN, bryggor, flerstegs djupanalys av kanalens tillstånd och liknande - kan spara tid och ansträngning på att läsa.

Ursprungliga data

Som försöksobjekt valdes en femportar Mikrotik-router med ROS version 6.45.3. Den kommer att ruttla trafik mellan två lokala nätverk (LAN1 och LAN2) och tre internetleverantörer (ISP1, ISP2, ISP3). Kanalen till ISP1 har en statisk "grå" adress, ISP2 - en "vit" adress som erhålls via DHCP, ISP3 - en "vit" adress med PPPoE-autentisering. Anslutningsskeman visas i bilden:

Uppgiften är att konfigurera routern "MTK" utifrån schemat så att:

Automatisk växling till reservleverantören är möjlig. Huvudleverantören är ISP2, första reservleverantören är ISP1, andra reservleverantören är ISP3.
Möjliggöra att nätverket LAN1 får tillgång till internet endast genom ISP1.
Möjliggöra att routa trafik från lokala nätverk till internet genom vald internetleverantör baserat på address-list.
Möjliggöra publicering av tjänster från det lokala nätverket till internet (DSTNAT).
Konfigurera brandväggens filter för att säkerställa minimalt nödvändig säkerhet mot internet.
Routern ska kunna släppa ut sin egen trafik genom en av de tre leverantörerna beroende på vald källadress.
Säkerställa routning av svarspaket tillbaka till den kanal de kom från (inklusive LAN).

Anmärkning. Vi kommer att konfigurera routern "från grunden" för att garantera att det inte uppstår några överraskningar i de föränderliga startkonfigurationerna "ur lådan" mellan versioner. Som verktyg för konfiguration valdes Winbox, där ändringarna kommer att visas tydligt. Själva inställningarna kommer att anges med kommandon i Winbox-terminalen. Den fysiska anslutningen för konfigurationen görs genom en direkt anslutning till gränssnittet Ether5.

Lite reflektioner över vad en multivan är, om det är ett problem eller om kloka personer väver konspirationsnät omkring det.

En nyfiken och uppmärksam administratör, när han själv konfigurerar ett sådant eller liknande schema, inser plötsligt att det fungerar fint som det är. Ja, utan alla dessa användartabeller för routing och andra route rules som de flesta artiklar i ämnet kryllar av. Ska vi kolla?

Kan vi konfigurera adressering på gränssnitten och standardgateway? Ja:

På ISP1 har vi angett adress och gateway med distance=2 och check-gateway=ping.
På ISP2 är konfigurationen av DHCP-klienten som standard — därför kommer distance att vara en.
På ISP3 i inställningarna för PPPoE-klienten vid add-default-route=yes sätter vi default-route-distance=3.

Kom ihåg att ange NAT vid utgång:

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

Slutligen, användarna på lokala nätverk laddar glatt genom huvudleverantören ISP2 och det finns redundans i kanalen genom mekanismen check gateway Se kommentar 1

Punkt 1 av uppgiften är genomförd. Var är multivan med sina etiketter? Nej...

Vidare. Vi behöver släppa specifika klienter från LAN genom ISP1:

/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=yes route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=no route-dst=100.66.66.1 src-address=192.168.88.0/24

Punkterna 2 och 3 av uppgiften är genomförda. Etiketter, märken, route rules, var är ni?!

Ska vi ge åtkomst till den älskade OpenVPN-servern med adress 172.17.17.17 för kunder från Internet? Varsågod:

/ip cloud set ddns-enabled=yes

Ge klienterna som peer resultatet av utskriften: “:put [ip cloud get dns-name]”

Vi anger portforwarding från internet:

/ip firewall nat add action=dst-nat chain=dstnat dst-port=1194
in-interface-list=WAN protocol=udp to-addresses=172.17.17.17

Punkt 4 är klar.

Vi konfigurerar brandväggen och annan säkerhet för punkt 5, samtidigt som vi gläder oss åt att användarna redan har allt som fungerar och vi sträcker oss mot behållaren med vår favoritdryck...
A! Vi har glömt tunnlarna.

Är l2tp-klienten, konfigurerad enligt den googlade artikeln, uppe på den älskade holländska VDS? Ja.
Är l2tp-servern med IPsec uppe och klienterna kopplar via DNS-namn från IP Cloud (se ovan)? Ja.
Lutande tillbaka i stolen, sippar på drycken, betraktar vi slösa på punkterna 6 och 7 av uppgiften. Tänker — behövs det ens? Allt fungerar ju (s)... Så om det verkligen inte behövs, så är det här allt. Multivan är implementerad.

Vad är en multivan? Det är anslutningen av flera Internetkanaler till en router.

Vidare behöver vi inte läsa artikeln, eftersom vad kan det finnas där förutom pretentiöst skryt med tveksam tillämpning?

Med dem som stannade, som är intresserade av punkterna 6 och 7 i uppgiften, samt känner en klåda av perfektionism, dyker vi djupare.

Den viktigaste uppgiften i genomförandet av multisite är korrekt trafikdirigering. Det handlar om att oavsett vilken (eller vilka) kanaler från leverantören som standardrutten tittar på på vår router, ska den alltid returnera svaret till den kanal där paketet kom från. Uppgiften är tydlig. Var ligger problemet? I ett enkelt lokalt nätverk är uppgiften densamma, men ingen bryr sig om extra inställningar och några problem uppstår inte. Skillnaden är att varje routable nod på Internet är tillgänglig via var och en av våra kanaler, och inte via en specifik, som i ett enkelt lokalt nätverk. Och ”problemet” är att om vi får en förfrågan till IP-adressen ISP3, så kommer i vårt fall svaret att skickas via kanalen ISP2, eftersom dit standardgateway är riktad. Det kommer att försvinna och kastas bort av leverantören som felaktigt. Problemet är identifierat. Hur löser vi det?

Vi kommer att dela upp lösningen i tre steg:

Förberedande inställning. I detta steg kommer grundläggande inställningar för routern att anges: lokalt nätverk, brandvägg, adresslistor, hairpin NAT och mer.
Multisite. I detta steg kommer nödvändiga anslutningar att märkas och sorteras i routingtavlor.
Anslutning till ISP. I detta steg kommer gränssnitten som säkerställer anslutning till Internet att konfigureras, routingkomponenten att aktiveras och mekanismen för reservkanaler att inrättas.

1. Förberedande inställning

1.1. Rensa routerns konfiguration med kommandot:

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

vi accepterar "Dangerous! Reset anyway? [y/N]:" och efter omstart ansluter vi med Winbox via MAC. Vid denna tidpunkt har konfigurationen och användardatabasen rensats.

1.2. Skapa en ny användare:

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

logga in som den och ta bort den standardanvändare:

/user remove admin

Anmärkning. Just att ta bort och inte inaktivera den standardanvändaren anser författaren vara säkrare och rekommenderas.

1.3. Skapa grundläggande interface-listor för att underlätta hanteringen i brandväggen, i inställningarna för discovery och andra MAC-servrar:

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

Vi undertecknar gränssnitten 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 fyller i interface-listorna:

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

Anmärkning. Att skriva förståeliga kommentarer är värt den tid som spenderas på det plus underlättar felsökning och förståelse av konfigurationen.

För att säkerställa säkerheten anser författaren att man bör lägga till gränssnittet ether3 i interface list "WAN", trots att det inte kommer att köra IP-protokollet.

Kom ihåg att efter att PPP-gränssnittet har aktiverats på ether3, måste det också läggas till i interface list "WAN".

1.4. Döljer routern från att upptäckas av grannskap och hantering från leverantörens nä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. Skapar ett minimalt antal brandväggsregler för att skydda routern:

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

(regeln tillåter etablerade och relaterade anslutningar, oavsett om de initierades från de anslutna nätverken eller av routern själv)

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

(ping och inte bara ping. All ICMP är tillåten inåt. Mycket användbart för att hitta problem med MTU)

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

(det stängande inputregeln 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. Den rekommenderas starkt av Mikrotik, men i vissa sällsynta fall kan den blockera 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

(regeln förhindrar paket som kommer från Internet och inte har genomgått dstnat-processen från att passera genom routern. Detta skyddar lokala nätverk från angripare som, för att ligga i samma broadcasthuvud som våra externa nätverk, anger våra externa IP-numer som gateway och därmed försöker "utforska" våra lokala nätverk.)

Anmärkning. Vi accepterar att nätverken LAN1 och LAN2 är betrodda och att trafik mellan dem och från dem inte filtreras.

1.6. Skapar en lista med 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

(Det här är en lista över adresser och nätverk som inte routas till Internet och som vi också kommer att följa.)

Anmärkning. Listan kan ändras, därför rekommenderar jag att periodiskt kontrollera att den är aktuell.

1.7. Konfigurerar DNS för routern själv:

/ip dns set servers=1.1.1.1,8.8.8.8

Anmärkning. I den aktuella versionen av ROS är dynamiska servrar har prioritet framför statiskt angivna. Förfrågan om namnöversättning skickas till den första servern i ordning i listan. Överföring till nästa server sker vid otillgänglighet av den aktuella. Timeout är lång — mer än 5 sekunder. Återgång, vid återupptagen drift av den "kraschade servern", sker automatiskt inte. Med tanke på denna algoritm och tillgången till multipath, rekommenderar författaren att inte använda servrar som tillhandahålls av leverantörerna.

1.8. Ställer in det lokala nätverket.
1.8.1. Konfigurerar statiska IP-adresser på gränssnitten för lokala nätverk:

/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. Ställer in ruttregler för våra lokala nätverk genom den huvudsakliga routingtabellen:

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

Anmärkning. Detta är ett av de enkla och snabba sätten att få tillgång till adresser för lokala nätverk med externa IP-adresser från routern, genom vilka det inte finns någon standardrutt.

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

Anmärkning. Detta möjliggör åtkomst via extern IP till sina resurser (dstnat) medan man är inuti nätverket.

2. Egentligen implementeringen av just den korrekta multipath

För att lösa uppgiften "att svara därifrån man ombads" kommer vi att använda två verktyg från ROS: connection mark och routing mark. Connection mark möjliggör märkning av den nödvändiga anslutningen och vidare arbete med denna etikett, som ett villkor för tillämpning routing mark. Och redan med routing mark kan man arbeta i ip route och route rules. Vi har gått igenom verktygen, nu måste vi lösa vilka anslutningar som ska märkas — först, var exakt ska vi märka — två.

Med det första är allt enkelt — vi måste märka alla anslutningar som kommer till routern från internet via den matchande kanalen. I vårt fall kommer det att vara tre etiketter (i antal kanaler): "conn_isp1", "conn_isp2" och "conn_isp3".

Nyansen med det andra är att inkommande anslutningar kommer att vara av två typer: transit och de som avses för själva routern. Mechanismen för connection mark fungerar i tabellen mangle. Låt oss titta på paketets rörelse i ett förenklat diagram, vänligt sammansatt av specialister från resursen mikrotik-trainings.com (inte reklam):

Genom att följa pilarna ser vi att paketet, som kommer in i "input interface", går igenom kedjan "Prerouting" och delas sedan upp i transit och lokal i blocket "Routing Decision". Därför, för att döda två flugor i en smäll, involverar vi Connection Mark i tabellen Mangle Prerouting kedjor Prerouting.

Anmärkning. I ROS markeras "Routing mark" i avsnittet Ip/Routes/Rules som "Table", medan i övriga avsnitt används termen "Routing Mark". Detta kan skapa viss förvirring, men i grunden är det samma sak och motsvarar rt_tables i iproute2 på linux.

2.1. Vi markerar inkommande anslutningar från varje leverantör:

/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

Anmärkning. För att undvika att märka redan märkta anslutningar använder jag villkoret connection-mark=no-mark istället för connection-state=new, eftersom jag anser att det är mer korrekt, liksom att undvika drop invalid anslutningar i input-filtret.

passthrough=no — eftersom denna implementering inte tillåter ommärkning och för att snabba upp processen kan vi avbryta genomgången av regler efter den första träff.

Det är viktigt att notera att vi för närvarande inte ingriper i routingen. Just nu är vi endast i förberedelsestadiet. Nästa steg i implementeringen kommer att vara att hantera transittrafik som returneras via etablerad anslutning från värden i det lokala nätverket. D.v.s. de paket som (se diagram) har passerat genom routern enligt vägen:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” och nått sin destination i det lokala nätverket.

Viktigt! I ROS finns det ingen logisk indelning mellan externa och interna gränssnitt. Om vi följer vägen för det svarande paketet enligt diagrammet så kommer det att följa samma logiska väg som förfrågan:

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

2.2. Vi dirigerar svarande transittrafik enligt motsvarande routingtabeller:

/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

Anmärkning. in-interface-list=!WAN — vi arbetar endast med trafik från det lokala nätverket och dst-address-type=!local utan destination till gränssnittens egna adresser.

Samma sak gäller för lokala paket som har kommit till routern via vägen:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Input”=>”Local Process”

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

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

2.3. Vi dirigerar svarande lokal trafik enligt 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 vi anse att förberedelsen för att svara på den kanal från vilken förfrågan kom är slutförd. Allt är markerat, omarkerat och redo för routing.
En utmärkt "biverkning" av denna inställning är möjligheten att köra DNSAT-portöppning från båda (ISP2, ISP3) leverantörerna samtidigt. Inte hos alla, eftersom vi har en icke-routbar adress hos ISP1. Denna effekt är viktig, till exempel för en e-postserver med två MX-poster som pekar på olika internetkanaler.

För att åtgärda nyanserna kring lokala nätverksarbeten med externa IP-adresser på routern använder vi lösningar från punkterna 1.8.2 och 3.1.2.6.

Dessutom kan vi använda verktyget med märkningar även för att lösa punkt 3 av uppgiften. Vi genomför det så här:

2.4. Vi dirigerar trafik från lokala klienter enligt routinglistor till de motsvarande tabellerna:

/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

Det här ser ungefär ut så här:

3. Vi konfigurerar anslutningen till ISP och använder märkbaserad routing.

3.1. Vi konfigurerar anslutningen till ISP1:
3.1.1. Vi konfigurerar en statisk IP-adress:

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

3.1.2. Vi ställer in statisk routing:
3.1.2.1. Vi lägger till en "nödrutt" som standard:

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

Anmärkning. Denna rutt gör det möjligt för trafik från lokala processer att gå igenom Route Decision-steget oavsett tillståndet för kanalerna hos någon av leverantörerna. Poängen med utgående lokal trafik är att för att ett paket ska kunna skickas någonstans måste det finnas en aktiv rutt till standardgatewayen i huvudroutingtabellen. Om det inte finns någon aktiv rutt kommer paketet helt enkelt att förstöras.

Som en utvidgning av verktyget check gateway för en djupare analys av kanalens tillstånd föreslår jag att använda metoden för rekursiva rutter. Metoden går ut på att vi instruerar routern att söka efter en väg till sin gateway inte direkt, utan via en mellanliggande gateway. De "kontroll-gateways" som väljs är 4.2.2.1, 4.2.2.2 och 4.2.2.3, respektive för ISP1, ISP2 och ISP3.

3.1.2.2. Rutt till "kontroll"-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

Anmärkning. Vi sänker värdet på scope till standardvärdet i ROS target scope, för att använda 4.2.2.1 som rekursiv gateway i framtiden. Jag understryker: scope för rutten till "kontroll"-adressen måste vara mindre än eller lika med target scope för den rutt som kommer att referera till kontrollen.

3.1.2.3. Standard rekursiv rutt för trafik utan routingmarkering:

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

Anmärkning. Värdet distance=2 används eftersom ISP1 enligt uppgift anges som den första reserv.

3.1.2.4. Standard rekursiv rutt för trafik med routingmarkeringen "to_isp1":

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

Anmärkning. Här börjar vi äntligen dra nytta av resultaten från det förberedande arbete som genomfördes i punkt 2.

Genom denna rutt kommer all trafik med markering "to_isp1" att dirigeras till den första leverantörens gateway oavsett vilken gateway som för närvarande är aktiv som standard för huvudtabellen.

3.1.2.5. Den första reservrekursiva rutt som standard för markerad trafik från ISP2 och ISP3:

/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

Anmärkning. Dessa rutter behövs bland annat för att reservera trafik från lokala nätverk, som består av medlemmar i address list "to_isp*".

3.1.2.6. Vi skriver rutt för lokal trafik från routern till internet via ISP1:

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

Anmärkning. I kombination med reglerna från punkt 1.8.2, säkerställs att utgången går till rätt kanal med angiven källa. Detta är kritiskt för att bygga tunnlar där lokal sida IP-adressen anges (EoIP, IP-IP, GRE). Eftersom reglerna i ip route rules utförs uppifrån och ner, tills första matchande villkor, så ska denna regel placeras efter reglerna från punkt 1.8.2.

3.1.3. Vi skriver en NAT-regel 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

Anmärkning. NATar all utgående trafik, förutom det som hamnar under IPsec-policyer. Jag försöker undvika action=masquerade utan ett verkligt behov. Det fungerar långsammare och är mer resurskrävande än src-nat, eftersom det beräknar adressen för NAT för varje ny anslutning.

3.1.4. Vi skickar kunder från listan som inte får ut via andra leverantörer direkt till ISP1:s 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

Anmärkning. 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. Vi konfigurerar anslutningen till ISP2.

Eftersom ISP2 tillhandahåller inställningarna via DHCP, är det rimligt att göra nödvändiga ändringar med ett skript som startar när DHCP-klienten aktiveras:

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

Anmärkning. Den första delen av skriptet utförs vid framgångsrik hyra, den andra — efter att hyra har avslutats.Se anmärkning 2

3.3. Vi konfigurerar anslutningen till ISP3.

Eftersom leverantören tillhandahåller dynamiska inställningar, är det rimligt att göra nödvändiga ändringar med skript som startar efter att gränssnittet ppp har aktiverats och avaktiverats.

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:

Anmärkning. Sträng
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
möjliggör korrekt hantering av namnändringar i gränssnittet eftersom det arbetar med dess kod och inte det visade namnet.

3.3.2. Nu, med hjälp av profilen, skapar vi en PPP-anslutning:

/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 sista steg ska vi ställa in klockan:

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

För dem som har läst till slutet

Den föreslagna metoden för implementering av multipath är ett personligt val av författaren och är inte den enda möjliga. ROS-verktygen är omfattande och flexibla, vilket å ena sidan orsakar svårigheter för nybörjare, å andra sidan är anledningen till populariteten. Fördjupa dig, testa och upptäck nya verktyg och lösningar. Till exempel kan man i denna multipath-implementering byta ut verktyget Check-gateway med rekursiva rutter till Netwatch.

Anteckningar

Check-gateway är en mekanism som gör det möjligt att inaktivera en rutt efter två på varandra följande misslyckade kontroller av gatewayens tillgänglighet. Kontroll görs var 10:e sekund plus svarstidsgräns. Totalt ligger den faktiska tidsperioden för växling mellan 20-30 sekunder. Om denna växlingstid är otillräcklig finns det en möjlighet att använda verktyget Netwatch, där kontrolltimern kan ställas in manuellt. Mekanismen Check-gateway aktiveras inte vid periodiska paketförluster i kanalen.
Viktigt! Inaktivering av huvudrutten medför inaktivering av alla andra rutter som hänvisar till den. Därför är det inte nödvändigt att ange check-gateway=ping .
Det kan hända att det uppstår ett fel i DHCP:s funktion som ser ut som om klienten fastnat i tillståndet renew. I sådana fall kommer den andra delen av skriptet inte att köras, men det hindrar inte trafiken från att flöda, eftersom tillståndet övervakas av den motsvarande rekursiva rutten.
ECMP (Equal Cost Multi-Path) — i ROS finns möjligheten att ställa in en rutt med flera gateways och samma distance. I så fall kommer anslutningarna att fördelas över kanalerna med hjälp av en round robin-algoritm, proportionellt mot antalet angivna gateways.

För drivkraften bakom att skriva artikeln, hjälpen vid utformningen av dess struktur och i placeringen av viktiga punkter — ett personligt tack till Evgeny @jscar

Källa: habr.com