🥇Multivan i enrutament a Mikrotik RouterOS

Introducció

Reprendre l'article, a més de la vanitat, va ser motivat per la freqüència depriment de preguntes sobre aquest tema als grups de perfil de la comunitat de telegrames de parla russa. L'article està dirigit als administradors novells de Mikrotik RouterOS (d'ara endavant ROS). Tracta només del multivan, amb èmfasi en l'encaminament. Com a avantatge, hi ha configuracions mínimes suficients per garantir un funcionament segur i còmode. Aquells que busquen la divulgació dels temes de cues, equilibri de càrrega, vlans, ponts, anàlisi profunda en diverses etapes de l'estat del canal i similars, no poden perdre temps i esforç de lectura.

Dades primeres

Com a subjecte de prova, es va seleccionar un encaminador Mikrotik de cinc ports amb la versió ROS 6.45.3. Encaminarà el trànsit entre dues xarxes locals (LAN1 i LAN2) i tres proveïdors (ISP1, ISP2, ISP3). El canal a ISP1 té una adreça "grisa" estàtica, ISP2 - "blanca", obtinguda mitjançant DHCP, ISP3 - "blanca" amb autorització PPPoE. L'esquema de connexió es mostra a la figura:

La tasca és configurar l'encaminador MTK en funció de l'esquema de manera que:

Proporcioneu el canvi automàtic a un proveïdor de còpia de seguretat. El proveïdor principal és ISP2, la primera reserva és ISP1, la segona reserva és ISP3.
Organitzeu l'accés a la xarxa LAN1 a Internet només mitjançant ISP1.
Proporcioneu la possibilitat d'encaminar el trànsit des de les xarxes locals a Internet a través del proveïdor seleccionat en funció de la llista d'adreces.
Preveure la possibilitat de publicar serveis des de la xarxa local a Internet (DSTNAT)
Configureu un filtre de tallafoc per proporcionar la seguretat mínima suficient des d'Internet.
L'encaminador podria emetre el seu propi trànsit a través de qualsevol dels tres proveïdors, depenent de l'adreça d'origen seleccionada.
Assegureu-vos que els paquets de resposta s'encaminen al canal del qual provenen (inclosa la LAN).

Observació Configurarem el router “des de zero” per tal de garantir l'absència de sorpreses en les configuracions d'arrencada “des de la caixa” que canvien de versió en versió. Winbox es va triar com a eina de configuració, on es mostraran visualment els canvis. La configuració en si s'establirà mitjançant ordres al terminal Winbox. La connexió física per a la configuració es fa mitjançant una connexió directa a la interfície Ether5.

Una mica de raonament sobre què és un multivan, és un problema o són persones intel·ligents astutes al voltant de teixir xarxes de conspiració

Un administrador curiós i atent, que estableix un esquema tal o semblant pel seu compte, de sobte s'adona que ja funciona amb normalitat. Sí, sí, sense les vostres taules d'encaminament personalitzades i altres regles de ruta, de les quals estan plens la majoria d'articles sobre aquest tema. Comprovem?

Podem configurar l'adreçament en interfícies i passarel·les per defecte? Sí:

A l'ISP1, es van registrar l'adreça i la passarel·la distància = 2 и check-gateway=ping.
A ISP2, la configuració predeterminada del client dhcp; en conseqüència, la distància serà igual a un.
A ISP3 a la configuració del client pppoe quan add-default-route=sí posar default-route-distance=3.

No oblideu registrar NAT a la sortida:

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

Com a resultat, els usuaris de llocs locals es diverteixen baixant gats a través del proveïdor principal ISP2 i hi ha una reserva de canal mitjançant el mecanisme comproveu la passarel·la Vegeu la nota 1

S'implementa el punt 1 de la tasca. On és el multivan amb les seves marques? No…

Més lluny. Heu d'alliberar clients específics de la LAN mitjançant 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

S'han implementat els ítems 2 i 3 de la tasca. Etiquetes, segells, regles de ruta, on ets?!

Necessites donar accés al teu servidor OpenVPN preferit amb l'adreça 172.17.17.17 per als clients d'Internet? Si us plau:

/ip cloud set ddns-enabled=yes

Com a igual, donem al client el resultat de sortida: ":put [núvol IP obtenir nom-DNS]"

Registrem el reenviament de ports des d'Internet:

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

L'article 4 està llest.

Hem configurat un tallafoc i altres seguretat per al punt 5, alhora que ens alegrem que tot ja funcioni per als usuaris i aconseguim un recipient amb una beguda preferida...
A! Els túnels s'obliden.

l2tp-client, configurat per l'article de Google, s'ha convertit en el vostre VDS holandès favorit? Sí.
El servidor l2tp amb IPsec ha augmentat i els clients per nom DNS d'IP Cloud (vegeu més amunt). Sí.
Inclinats enrere a la nostra cadira, prenent una copa, considerem amb mandra els punts 6 i 7 de la tasca. Pensem: ho necessitem? Tot i així, funciona així (c)... Així que, si encara no cal, ja està. Multivan implementat.

Què és un multivan? Aquesta és la connexió de diversos canals d'Internet a un encaminador.

No cal que llegiu més l'article, perquè què hi pot haver a més d'una mostra d'aplicabilitat dubtosa?

Per als que queden, que estan interessats en els punts 6 i 7 de la tasca, i també senten la picor del perfeccionisme, aprofundim.

La tasca més important d'implementar un multivan és l'encaminament correcte del trànsit. És a dir: independentment de quin (o quin) Vegeu. nota 3 els canals de l'ISP miren la ruta predeterminada del nostre encaminador, hauria de retornar una resposta al canal exacte del qual prové el paquet. La tasca és clara. On és el problema? De fet, en una xarxa local senzilla, la tasca és la mateixa, però ningú es molesta amb configuracions addicionals i no té problemes. La diferència és que qualsevol node encaminable d'Internet és accessible a través de cadascun dels nostres canals, i no a través d'un de estrictament específic, com en una simple LAN. I el "problema" és que si ens arriba una sol·licitud per a l'adreça IP d'ISP3, en el nostre cas la resposta passarà pel canal ISP2, ja que la passarel·la predeterminada s'adreça allà. Surt i serà descartat pel proveïdor com a incorrecte. S'ha identificat el problema. Com solucionar-ho?

La solució es divideix en tres etapes:

Preconfiguració. En aquesta fase, s'establiran la configuració bàsica de l'encaminador: xarxa local, tallafoc, llistes d'adreces, NAT de forquilla, etc.
Multivan. En aquesta fase, les connexions necessàries seran marcades i ordenades en taules d'encaminament.
Connexió a un ISP. En aquesta fase es configuraran les interfícies que proporcionen connexió a Internet, l'encaminament i s'activarà el mecanisme de reserva de canals d'Internet.

1. Preconfiguració

1.1. Netegem la configuració de l'encaminador amb l'ordre:

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

estar d'acord amb "Perillós! Restablir de totes maneres? [y/N]:” i, després de reiniciar, ens connectem amb Winbox via MAC. En aquesta etapa, la configuració i la base d'usuaris s'esborren.

1.2. Crea un usuari nou:

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

inicieu sessió a sota i suprimiu el predeterminat:

/user remove admin

Observació És l'eliminació i no desactivació de l'usuari predeterminat que l'autor considera més segur i recomana per al seu ús.

1.3. Creem llistes d'interfícies bàsiques per a la comoditat d'operar en un tallafoc, configuracions de descobriment i altres servidors MAC:

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

Interfícies de signatura amb comentaris

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

i ompliu les llistes d'interfícies:

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

Observació Escriure comentaris comprensibles val la pena el temps dedicat a això, a més, facilita molt la resolució de problemes i la comprensió de la configuració.

L'autor considera necessari, per motius de seguretat, afegir la interfície ether3 a la llista d'interfícies "WAN", malgrat que el protocol ip no la passarà.

No oblideu que després que la interfície PPP s'aixequi a ether3, també s'haurà d'afegir a la llista d'interfícies "WAN"

1.4. Ocultem l'encaminador de la detecció i control del barri des de les xarxes de proveïdors mitjançant 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. Creem el conjunt mínim suficient de regles de filtre de tallafoc per protegir l'encaminador:

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

(la regla proporciona permís per a connexions establertes i relacionades que s'inicien tant des de xarxes connectades com del propi encaminador)

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

(ping i no només ping. Tots els icmp estan permesos. Molt útil per trobar problemes de MTU)

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

(la regla que tanca la cadena d'entrada prohibeix tot el que ve d'Internet)

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

(la regla permet connexions establertes i relacionades que passen pel router)

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

(la regla restableix les connexions amb connection-state=invalid passant per l'encaminador. És molt recomanable per Mikrotik, però en algunes situacions rares pot bloquejar el trànsit útil)

/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

(la norma prohibeix que els paquets que provenen d'Internet i no hagin passat el procediment dstnat passin pel router. Això protegirà les xarxes locals d'intrusos que, al trobar-se al mateix domini de broadcast amb les nostres xarxes externes, registraran les nostres IPs externes com a passarel·la i, per tant, intentar "explorar" les nostres xarxes locals.)

Observació Suposem que les xarxes LAN1 i LAN2 són de confiança i el trànsit entre elles i des d'elles no es filtra.

1.6. Creeu una llista amb una llista de xarxes no encaminables:

/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

(Aquesta és una llista d'adreces i xarxes que no es poden encaminar a Internet i se seguirà en conseqüència.)

Observació La llista està subjecta a canvis, així que us recomano que comproveu periòdicament la rellevància.

1.7. Configureu el DNS per al propi encaminador:

/ip dns set servers=1.1.1.1,8.8.8.8

Observació A la versió actual de ROS, els servidors dinàmics tenen prioritat sobre els estàtics. La sol·licitud de resolució de noms s'envia al primer servidor per ordre de la llista. La transició al següent servidor es realitza quan l'actual no està disponible. El temps d'espera és gran: més de 5 segons. La tornada, quan es reprèn el "servidor caigut", no es produeix automàticament. Tenint en compte aquest algorisme i la presència d'un multivan, l'autor recomana no utilitzar servidors proporcionats pels proveïdors.

1.8. Configura una xarxa local.
1.8.1. Configuram adreces IP estàtiques en interfícies LAN:

/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. Establem les regles per a les rutes a les nostres xarxes locals mitjançant la taula d'encaminament principal:

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

Observació Aquesta és una de les maneres ràpides i senzilles d'accedir a adreces LAN amb fonts d'adreces IP externes d'interfícies d'encaminador que no passen per la ruta predeterminada.

1.8.3. Habilita Hairpin NAT per a LAN1 i 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

Observació Això us permet accedir als vostres recursos (dstnat) mitjançant una IP externa mentre esteu dins de la xarxa.

2. En realitat, la implementació del multivan molt correcte

Per resoldre el problema de "respondre d'on han preguntat", utilitzarem dues eines ROS: marca de connexió и marca de ruta. marca de connexió us permet marcar la connexió desitjada i després treballar amb aquesta marca com a condició per a la sol·licitud marca de ruta. I ja amb marca de ruta possible treballar-hi ruta IP и regles de ruta. Hem descobert les eines, ara heu de decidir quines connexions marcar, una vegada, exactament on marcar, dues.

Amb el primer, tot és senzill: hem de marcar totes les connexions que arriben al router des d'Internet a través del canal adequat. En el nostre cas, seran tres etiquetes (segons el nombre de canals): “conn_isp1”, “conn_isp2” i “conn_isp3”.

El matís amb el segon és que les connexions entrants seran de dos tipus: de trànsit i les que estan destinades al propi encaminador. El mecanisme de marca de connexió funciona a la taula mangle. Considereu el moviment del paquet en un diagrama simplificat, compilat amablement pels especialistes del recurs mikrotik-trainings.com (no publicitat):

Seguint les fletxes, veiem que el paquet arriba a “interfície d'entrada”, passa per la cadena “Enrutament previ" i només llavors es divideix en trànsit i local al bloc "Decisió de ruta". Per tant, per matar dos ocells d'un tret, fem servir Marca de connexió a la taula Mangle Pre-routing cadenes Enrutament previ.

Nota:. A ROS, les etiquetes "Marca d'encaminament" es mostren com a "Taula" a la secció Ip/Rutes/Regles, i com a "Marca d'encaminament" en altres seccions. Això pot introduir certa confusió en la comprensió, però, de fet, això és el mateix i és un anàleg de rt_tables a iproute2 a Linux.

2.1. Marquem les connexions entrants de cadascun dels proveïdors:

/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

Observació Per no marcar les connexions ja marcades, faig servir la condició connection-mark=no-mark en lloc de connection-state=new perquè crec que això és més correcte, així com el rebuig de les connexions no vàlides al filtre d'entrada.

passthrough=no - perquè en aquest mètode d'implementació, el remarcat està exclòs i, per accelerar, podeu interrompre l'enumeració de regles després de la primera coincidència.

Cal tenir en compte que encara no interferim de cap manera amb l'encaminament. Ara només queden etapes de preparació. La següent fase d'implementació serà el processament del trànsit de trànsit que retorna per la connexió establerta des de la destinació a la xarxa local. Aquells. aquells paquets que (vegeu el diagrama) van passar pel router pel camí:

"Interfície d'entrada"=>"Prerouting"=>"Decisió d'encaminament"=>"Forward"=>"Post Routing"=>"Interfície de sortida" i va arribar al seu destinatari a la xarxa local.

¡Important! A ROS, no hi ha una divisió lògica en interfícies externes i internes. Si tracem el camí del paquet de resposta segons el diagrama anterior, seguirà el mateix camí lògic que la sol·licitud:

"Interfície d'entrada"=>"Prerouting"=>"Decisió d'encaminament"=>"Forward"=>"Post Routing"=>"Interfície de sortida" només per una petició"Interfície d'entrada” era la interfície de l'ISP, i per a la resposta - LAN

2.2. Dirigim el trànsit de trànsit de resposta a les taules d'encaminament corresponents:

/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

Comenta. in-interface-list=!WAN: només treballem amb trànsit de la xarxa local i dst-address-type=!local que no té l'adreça de destinació de l'adreça de les interfícies del propi router.

El mateix per als paquets locals que van arribar al router durant el camí:

"Interfície d'entrada" => "Prerouting" => "Decisió d'encaminament" => "Entrada" => "Procés local"

¡Important! La resposta serà de la següent manera:

"Procés local"=>"Decisió d'encaminament"=>"Sortida"=>"Enrutament posterior"=>"Interfície de sortida"

2.3. Dirigim el trànsit local de resposta a les taules d'encaminament corresponents:

/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

En aquesta fase, es pot considerar resolta la tasca de preparar l'enviament d'una resposta al canal d'Internet des del qual prové la sol·licitud. Tot està marcat, etiquetat i llest per ser encaminat.
Un excel·lent efecte "colateral" d'aquesta configuració és la capacitat de treballar amb el reenviament de ports DSNAT dels dos proveïdors (ISP2, ISP3) alhora. En absolut, ja que a ISP1 tenim una adreça no encaminable. Aquest efecte és important, per exemple, per a un servidor de correu amb dos MX que miren diferents canals d'Internet.

Per eliminar els matisos del funcionament de les xarxes locals amb encaminadors IP externs, utilitzem les solucions dels paràgrafs. 1.8.2 i 3.1.2.6.

A més, podeu utilitzar una eina amb marques per resoldre el paràgraf 3 del problema. Ho implementem així:

2.4. Dirigem el trànsit dels clients locals des de les llistes d'encaminament a les taules adequades:

/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

Com a resultat, sembla una cosa així:

3. Configureu una connexió amb l'ISP i activeu l'encaminament de marca

3.1. Configura una connexió a ISP1:
3.1.1. Configura una adreça IP estàtica:

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

3.1.2. Configura l'encaminament estàtic:
3.1.2.1. Afegeix una ruta "d'emergència" predeterminada:

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

Observació Aquesta ruta permet que el trànsit dels processos locals passi l'etapa de decisió de ruta, independentment de l'estat dels enllaços de qualsevol dels proveïdors. El matís del trànsit local de sortida és que perquè el paquet es mogui almenys a algun lloc, la taula d'encaminament principal ha de tenir una ruta activa a la passarel·la predeterminada. Si no, el paquet simplement es destruirà.

Com a extensió d'eina comproveu la passarel·la Per a una anàlisi més profunda de l'estat del canal, suggereixo utilitzar el mètode de ruta recursiva. L'essència del mètode és que li diem a l'encaminador que busqui un camí cap a la seva passarel·la no directament, sinó a través d'una passarel·la intermèdia. 4.2.2.1, 4.2.2.2 i 4.2.2.3 es seleccionaran com a passarel·les de "prova" per a ISP1, ISP2 i ISP3 respectivament.

3.1.2.2. Ruta a l'adreça de "verificació":

/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

Observació Reduïm el valor de l'abast al valor predeterminat de l'àmbit objectiu de ROS per tal d'utilitzar 4.2.2.1 com a passarel·la recursiva en el futur. Destaco: l'abast de la ruta fins a l'adreça de "prova" ha de ser inferior o igual a l'abast objectiu de la ruta que farà referència a la de prova.

3.1.2.3. Ruta predeterminada recursiva per al trànsit sense marca d'encaminament:

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

Observació El valor de distància=2 s'utilitza perquè ISP1 es declara com la primera còpia de seguretat segons les condicions de la tasca.

3.1.2.4. Ruta predeterminada recursiva per al trànsit amb la marca d'encaminament "to_isp1":

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

Observació De fet, aquí per fi comencem a gaudir dels fruits del treball preparatori que es va dur a terme al paràgraf 2.

En aquesta ruta, tot el trànsit que tingui la ruta marcada "to_isp1" es dirigirà a la passarel·la del primer proveïdor, independentment de quina passarel·la predeterminada estigui activa actualment per a la taula principal.

3.1.2.5. Primera ruta predeterminada recursiva alternativa per al trànsit etiquetat ISP2 i 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

Observació Aquestes rutes són necessàries, entre altres coses, per reservar trànsit de xarxes locals que són membres de la llista d'adreces “to_isp*”'

3.1.2.6. Registrem la ruta per al trànsit local de l'encaminador a Internet a través de l'ISP1:

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

Observació En combinació amb les regles del paràgraf 1.8.2, proporciona accés al canal desitjat amb una font determinada. Això és fonamental per construir túnels que especifiquen l'adreça IP del costat local (EoIP, IP-IP, GRE). Com que les regles de les regles de ruta IP s'executen de dalt a baix, fins a la primera coincidència de les condicions, aquesta regla hauria d'estar després de les regles de la clàusula 1.8.2.

3.1.3. Registrem la regla NAT per al trànsit de sortida:

/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

Observació NATim tot el que surt, excepte el que entra a les polítiques IPsec. Intento no utilitzar action=masquerade tret que sigui absolutament necessari. És més lent i requereix més recursos que src-nat perquè calcula l'adreça NAT per a cada connexió nova.

3.1.4. Enviem clients de la llista que tenen prohibit accedir a través d'altres proveïdors directament a la passarel·la del proveïdor ISP1.

/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

Observació action=route té una prioritat més alta i s'aplica abans que altres regles d'encaminament.

place-before=0 - col·loca la nostra regla en primer lloc a la llista.

3.2. Configureu una connexió a ISP2.

Com que el proveïdor ISP2 ens proporciona la configuració mitjançant DHCP, és raonable fer els canvis necessaris amb un script que s'inicia quan s'activa el client DHCP:

/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

El propi script a la finestra de Winbox:

Observació La primera part de l'script s'activa quan s'obté el contracte d'arrendament amb èxit, la segona, després de l'alliberament del contracte.Vegeu la nota 2

3.3. Hem establert una connexió amb el proveïdor ISP3.

Com que el proveïdor de configuració ens proporciona dinàmica, és raonable fer els canvis necessaris amb scripts que s'inicien després que la interfície ppp s'hagi plantejat i després de la caiguda.

3.3.1. Primer configurem el perfil:

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

El propi script a la finestra de Winbox:

Observació Cadena
/ip firewall mangle set [find comment="Connmark in from ISP3"] in-interface=$"interfície";
permet gestionar correctament el canvi de nom de la interfície, ja que funciona amb el seu codi i no amb el nom de visualització.

3.3.2. Ara, utilitzant el perfil, creeu una connexió ppp:

/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

Com a toc final, posem el rellotge:

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

Per als que llegiu fins al final

La manera proposada d'implementar un multivan és la preferència personal de l'autor i no és l'única possible. El conjunt d'eines ROS és ampli i flexible, cosa que, d'una banda, causa dificultats per als principiants i, d'altra banda, és el motiu de la seva popularitat. Aprèn, prova, descobreix noves eines i solucions. Per exemple, com a aplicació dels coneixements adquirits, és possible substituir l'eina en aquesta implementació del multivan comprova la passarel·la amb rutes recursives a netwatch.

Notes

comprova la passarel·la - un mecanisme que permet desactivar la ruta després de dues comprovacions consecutives infructuoses de la disponibilitat de la passarel·la. La comprovació es realitza una vegada cada 10 segons, més el temps d'espera de resposta. En total, el temps de commutació real es troba entre 20 i 30 segons. Si aquest temps de canvi no és suficient, hi ha una opció per utilitzar l'eina netwatch, on el temporitzador de comprovació es pot configurar manualment. comprova la passarel·la no dispara amb la pèrdua intermitent de paquets a l'enllaç.
Important! La desactivació d'una ruta principal desactivarà totes les altres rutes que hi fan referència. Per tant, perquè ho indiquin check-gateway=ping innecessari.
Succeeix que es produeix un error en el mecanisme DHCP, que sembla un client encallat en l'estat de renovació. En aquest cas, la segona part de l'script no funcionarà, però no impedirà que el trànsit circuli correctament, ja que l'estat fa un seguiment de la ruta recursiva corresponent.
ECMP (Equal Cost Multi-Path) - a ROS és possible establir una ruta amb diverses passarel·les i la mateixa distància. En aquest cas, les connexions es distribuiran entre canals mitjançant l'algoritme round robin, en proporció al nombre de passarel·les especificades.

Per a l'impuls per escriure l'article, ajudeu a configurar-ne l'estructura i la col·locació dels accents: agraïment personal a Evgeny @jscar

Font: www.habr.com