🥇Multicast e routing su Mikrotik RouterOS

Introduzione

L'articolo è stato motivato non solo dall'orgoglio, ma anche dalla deludente frequenza di domande su questo argomento nei gruppi tematici della comunità Telegram di lingua russa. L'articolo è rivolto ai principianti amministratori di Mikrotik RouterOS (d'ora in poi ROS). Viene trattato esclusivamente il multivan, con un focus sul routing. Come bonus, sono presenti le impostazioni minime necessarie per garantire un lavoro sicuro e confortevole. Coloro che cercano approfondimenti su code, bilanciamento del carico, VLAN, bridge, analisi approfondita dello stato del canale e simili possono risparmiare tempo e fatica nella lettura.

Dati di origine

Come oggetto di prova, è stato scelto un router a cinque porte Mikrotik con ROS versione 6.45.3. Esso gestirà il traffico tra due reti locali (LAN1 e LAN2) e tre provider (ISP1, ISP2, ISP3). Il canale verso ISP1 ha un indirizzo statico 'grigio', ISP2 ha un indirizzo 'bianco', ottenuto tramite DHCP, e ISP3 ha un indirizzo 'bianco' con autenticazione PPPoE. Lo schema di connessione è mostrato nell'immagine:

L'obiettivo è configurare il router 'MTK' sulla base dello schema in modo che:

Garantire il passaggio automatico a un fornitore di riserva. Il fornitore principale è ISP2, il primo riserva è ISP1, il secondo riserva è ISP3.
Organizzare l'accesso della rete LAN1 a Internet solo tramite ISP1.
Prevedere la possibilità di instradare il traffico dalle reti locali a Internet attraverso il fornitore scelto in base a un address-list.
Prevedere la possibilità di pubblicare servizi dalla rete locale su Internet (DSTNAT).
Configurare il filtro del firewall per garantire una sicurezza minima adeguata da parte di Internet.
Il router dovrebbe rilasciare il proprio traffico tramite uno dei tre fornitori in base all'indirizzo sorgente selezionato.
Garantire l'instradamento dei pacchetti di risposta nel canale da cui sono provenuti (inclusa la LAN).

Nota. Configureremo il router "da zero" per garantire l'assenza di sorprese nelle configurazioni di partenza "pronte all'uso" che cambiano da versione a versione. Il nostro strumento di configurazione sarà Winbox, dove le modifiche saranno visualizzate chiaramente. Le impostazioni stesse saranno inserite tramite comandi nel terminale di Winbox. La connessione fisica per la configurazione avviene tramite un collegamento diretto con l'interfaccia Ether5.

Alcune riflessioni su cos'è un multivan, se è un problema o se astuti ingegneri stanno tessendo reti di cospirazioni.

Un amministratore curioso e attento, mentre configura autonomamente uno schema del genere o simile, potrebbe improvvisamente rendersi conto che funziona già normalmente. Sì, senza quei vostri tavoli di routing e altre regole di percorso, che affollano la maggior parte degli articoli su questo tema. Controlliamo?

Possiamo configurare l'indirizzamento sulle interfacce e i gateway predefiniti? Sì:

Su ISP1 abbiamo scritto l'indirizzo e il gateway con distance=2 e check-gateway=ping.
Su ISP2 la configurazione del client DHCP per impostazione predefinita — di conseguenza la distanza sarà pari a uno.
Su ISP3 nelle impostazioni del client PPPoE con add-default-route=yes impostiamo default-route-distance=3.

Non dimentichiamo di configurare il NAT in uscita:

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

In conclusione, gli utenti delle reti locali si connettono felicemente tramite il provider principale ISP2 e c'è un'allocazione della larghezza di banda utilizzando il meccanismo. controlla gateway Vedi nota 1

Punto 1 del compito è stato realizzato. Dove sono le etichette del multipunto? No…

Proseguiamo. È necessario escludere specifici clienti dalla LAN tramite 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

I punti 2 e 3 del compito sono stati realizzati. Etichette, marchi, regole di routing, dove siete?!

Serve dare accesso al nostro amato server OpenVPN all'indirizzo 172.17.17.17 per i clienti di Internet? Ecco:

/ip cloud set ddns-enabled=yes

Ai clienti, come peer, forniamo il risultato dell'output: “:put [ip cloud get dns-name]”

Configurazione del port forwarding da 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

Punto 4 completato.

Configuriamo il firewall e altre misure di sicurezza per il punto 5, mentre ci rallegriamo che gli utenti hanno già tutto funzionante e ci tendiamo verso il contenitore della nostra bevanda preferita…
Ah! Abbiamo anche dimenticato i tunnel.

Il client L2TP, configurato seguendo un articolo trovato su Google, è riuscito a collegarsi al nostro amato VDS olandese? Sì.
Il server L2TP con IPsec è attivato e i clienti si connettono tramite nome DNS da IP Cloud (vedi sopra)? Sì.
Riposandoci sulla sedia, sorseggiando una bevanda, esaminiamo pigramente i punti 6 e 7 del compito. Pensiamo: ne abbiamo davvero bisogno? Tutto funziona già... Quindi, se non ci serve, è tutto qui. Il Multivan è implementato.

Cos'è il Multivan? È la connessione di più canali Internet a un unico router.

A questo punto, non c'è bisogno di leggere l'articolo, perché cosa ci potrebbe essere se non un'esibizione di poco valore pratico?

Con coloro che sono rimasti e sono interessati ai punti 6 e 7 del compito, e avvertono il prurito del perfezionismo, ci immergiamo più a fondo.

La principale sfida nell'attuazione del multivan è la corretta gestione del traffico. In particolare, indipendentemente da quale (o quali) canale(i) del provider osservi la rotta predefinita sul nostro router, deve restituire la risposta esattamente al canale da cui è arrivato il pacchetto. Il compito è chiaro. Ma qual è il problema? Infatti, in una semplice rete locale il problema è lo stesso, ma nessuno si preoccupa di impostazioni aggiuntive e non ci sono complicazioni. La differenza sta nel fatto che qualsiasi nodo instradabile in Internet è accessibile attraverso ciascuno dei nostri canali, non attraverso uno specifico come in una rete locale semplice. E il problema è che se riceviamo una richiesta all'indirizzo IP ISP3, nel nostro caso la risposta verrà inviata attraverso il canale ISP2, poiché quello è il gateway predefinito. Verrà inviata e scartata dal provider come non valida. Abbiamo identificato il problema. Come lo risolviamo?

Dividiamo la soluzione in tre fasi:

Impostazione preliminare. In questa fase saranno impostate le configurazioni di base del router: rete locale, firewall, liste degli indirizzi, hairpin NAT, ecc.
Multivan. In questa fase, le connessioni necessarie verranno contrassegnate e ordinate in tabelle di routing.
Connessione all'ISP. In questa fase verranno configurate le interfacce per garantire la connessione a Internet, attivata la routing e il meccanismo di backup delle connessioni Internet.

1. Configurazione preliminare

1.1. Pulisci la configurazione del router con il comando:

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

accettiamo “Pericoloso! Ripristinare comunque? [y/N]:” e, dopo il riavvio, ci connettiamo tramite Winbox usando il MAC. In questa fase, la configurazione e il database degli utenti sono stati puliti.

1.2. Creiamo un nuovo utente:

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

ci accediamo come tale e rimuoviamo quello predefinito:

/user remove admin

Nota. L'autore considera più sicuro eliminare piuttosto che disabilitare l'utente predefinito e lo raccomanda.

1.3. Creiamo elenchi di interfacce di base per facilitare l'operazione nel firewall, nelle impostazioni di discovery e in altri server MAC:

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

Annotiamo con commenti le interfacce

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

e completiamo gli elenchi delle interfacce:

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

Nota. Scrivere commenti chiari vale il tempo speso e facilita notevolmente il troubleshooting e la comprensione della configurazione.

L'autore ritiene necessario, per motivi di sicurezza, aggiungere l'interfaccia ether3 nella lista interfacce "WAN", anche se su di essa non passerà il protocollo ip.

Non dimentichiamo che, dopo aver attivato l'interfaccia PPP su ether3, dovrà essere aggiunta anche alla lista interfacce "WAN".

1.4. Nascondere il router da rilevamenti di vicinato e gestione dalle reti dei fornitori tramite 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. Creare un insieme minimo di regole del firewall per proteggere il router:

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

(la regola consente connessioni stabilite e correlate, iniziate sia dalle reti collegate che dal router stesso)

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

(ping e non solo ping. Tutto l'icmp in ingresso è consentito. È molto utile per identificare problemi con l'MTU)

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

(la regola di chiusura della catena input vieta tutto ciò che proviene da Internet)

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

(la regola consente connessioni stabilite e correlate che passano attraverso il router)

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

(la regola resetta le connessioni con connection-state=invalid che attraversano il router. È fortemente raccomandata da Mikrotik, ma in alcune situazioni rare può bloccare traffico utile)

/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 regola impedisce ai pacchetti provenienti da Internet di passare attraverso il router se non hanno seguito la procedura dstnat. Questo proteggerà le reti locali da attaccanti che, trovandosi nello stesso dominio di broadcast delle nostre reti esterne, registreranno i nostri IP esterni come gateway e cercheranno di 'esplorare' le nostre reti locali.)

Nota. Consideriamo che le reti LAN1 e LAN2 siano fidate e che il traffico tra di esse e verso di esse non venga filtrato.

1.6. Creiamo un elenco delle reti non instradabili:

/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

(Questo è un elenco di indirizzi e reti che non sono instradabili su Internet e, di conseguenza, anche noi ci atterremo a questo.)

Nota. L'elenco potrebbe cambiare, quindi consiglio di controllare periodicamente l'aggiornamento.

1.7. Configuriamo il DNS per il router stesso:

/ip dns set servers=1.1.1.1,8.8.8.8

Nota. Nella versione attuale di ROS, i dinamici server hanno la priorità rispetto a quelli staticamente configurati. La richiesta di risoluzione del nome viene inviata al primo server nell'ordine dell'elenco. Si passa al server successivo in caso di mancata disponibilità dell'attuale. Il timeout è ampio — oltre 5 secondi. Il ritorno automatico non avviene quando il 'server caduto' riprende a funzionare. Tenendo conto di questo algoritmo e della presenza di un multilink, l'autore consiglia di non utilizzare server forniti dai provider.

1.8. Configuriamo la rete locale.
1.8.1. Configuriamo indirizzi IP statici sulle interfacce delle reti locali:

/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. Impostiamo le regole di routing verso le nostre reti locali tramite la tabella di routing principale:

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

Nota. Questo è uno dei metodi semplici e veloci per accedere agli indirizzi delle reti locali con fonti di indirizzi IP esterni delle interfacce del router, attraverso le quali non passa il percorso predefinito.

1.8.3. Attiviamo Hairpin NAT per LAN1 e 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

Nota. Ciò consente di accedere alle proprie risorse tramite l'IP esterno (dstnat) rimanendo all'interno della rete.

2. In effetti, l'implementazione del corretto multilink

Per risolvere il compito di 'rispondere da dove è stata fatta la richiesta', utilizzeremo due strumenti ROS: marcatura di connessione e marcatura di routing. Marcatura di connessione consente di contrassegnare la connessione desiderata e successivamente lavorare con questo contrassegno come condizione per l'applicazione marcatura di routing. E già con marcatura di routing è possibile lavorare in ip route e regole di routing. Abbiamo chiarito gli strumenti, ora dobbiamo decidere quali connessioni etichettare — prima, dove etichettare — secondo.

Con la prima è semplice: dobbiamo contrassegnare tutte le connessioni che arrivano al router da Internet attraverso il canale appropriato. Nel nostro caso, saranno tre contrassegni (in base al numero di canali): “conn_isp1”, “conn_isp2” e “conn_isp3”.

Il punto cruciale del secondo è che le connessioni in entrata saranno di due tipi: transitorie e quelle destinate al router stesso. Il meccanismo di marcatura della connessione funziona nella tabella mangle. Consideriamo il movimento del pacchetto in un diagramma semplificato, gentilmente fornito dagli esperti del sito mikrotik-trainings.com (non è pubblicità):

Seguendo le frecce, vediamo che il pacchetto, che arriva all'“interfaccia di input”, passa attraverso la catena “Prerouting” e solo dopo viene suddiviso in transitorio e locale nel blocco “Decisione di Routing”. Pertanto, per colpire due piccioni con una fava, utilizziamo Marcatura di Connessione nella tabella Mangle Prerouting catene Prerouting.

Nota. In ROS, le etichette “Routing mark” sono indicate nella sezione Ip/Routes/Rules come “Table”, mentre nelle altre sezioni come “Routing Mark”. Questo potrebbe generare un po' di confusione, ma in sostanza sono la stessa cosa e corrispondono a rt_tables in iproute2 su Linux.

2.1. Etichettiamo le connessioni in ingresso da ciascun fornitore:

/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

Nota. Per non etichettare nuovamente le connessioni già etichettate, utilizzo la condizione connection-mark=no-mark invece di connection-state=new perché la ritengo più corretta, così come l'abbandono delle connessioni drop invalid nel filtro input.

passthrough=no — perché in questo modo di implementazione l'ritagging è escluso e per velocizzare si può interrompere la verifica delle regole dopo la prima corrispondenza.

È importante notare che al momento non interferiamo con la routazione. Attualmente siamo solo nelle fasi di preparazione. Il prossimo passo sarà l'elaborazione del traffico transitivo che ritorna attraverso una connessione stabilita dall'indirizzo nella rete locale. Cioè, i pacchetti che (vedi diagramma) hanno attraversato il router lungo il percorso:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” e sono arrivati al loro destinatario nella rete locale.

Attenzione! In ROS non c'è una divisione logica tra interfacce esterne e interne. Se seguiamo il percorso del pacchetto di risposta nel diagramma fornito, questo seguirà lo stesso percorso logico della richiesta:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” solo per la richiesta “Interfaccia di Input” c'era l'interfaccia ISP, mentre per la risposta — LAN

2.2. Inviamo il traffico di transito di risposta secondo le tabelle di instradamento corrispondenti:

/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

Nota. in-interface-list=!WAN — lavoriamo solo con il traffico dalla rete locale e dst-address-type=!local non avente come indirizzo di destinazione gli indirizzi delle interfacce del router stesso.

Lo stesso vale per i pacchetti locali che sono arrivati al router attraverso il percorso:

“Interfaccia di Input”=>”Prerouting”=>”Decisione di Instradamento”=>”Input”=>”Elaborazione Locale”

Attenzione! La risposta seguirà il seguente percorso:

”Elaborazione Locale”=>”Decisione di Instradamento”=>”Output”=>”Post Routing”=>”Interfaccia di Output”

2.3. Inviamo il traffico locale di risposta secondo le tabelle di instradamento corrispondenti:

/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

A questo punto, il compito di preparare l'invio della risposta nel canale Internet da cui è arrivata la richiesta può considerarsi risolto. Tutto è etichettato, marcato e pronto per essere instradato.
Un ottimo "effetto collaterale" di questa configurazione è la possibilità di utilizzare la traduzione dei porti DSNAT da entrambi i fornitori (ISP2, ISP3) contemporaneamente. Non su tutti, poiché su ISP1 abbiamo un indirizzo non instradabile. Questo effetto è importante, ad esempio, per un server di posta con due MX che si collegano a diversi canali Internet.

Per affrontare le particolarità del lavoro delle reti locali con indirizzi IP esterni del router, utilizziamo soluzioni dai punti 1.8.2 e 3.1.2.6.

Inoltre, possiamo utilizzare uno strumento con etichette anche per risolvere il punto 3 del problema. Procediamo in questo modo:

2.4. Inviamo il traffico dei clienti locali dalle liste di instradamento alle tabelle corrispondenti:

/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

Alla fine, appare approssimativamente così:

3. Configuriamo la connessione a ISP e attiviamo l'instradamento per marchi

3.1. Configuriamo la connessione a ISP1:
3.1.1. Configuriamo l'indirizzo IP statico:

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

3.1.2. Configuriamo l'instradamento statico:
3.1.2.1. Aggiungiamo il percorso "di emergenza" predefinito:

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

Nota. Questo percorso consente al traffico dei processi locali di superare la fase di Decisione del Percorso indipendentemente dallo stato dei canali di qualsiasi fornitore. Un aspetto dell'uscita del traffico locale è che, affinché un pacchetto possa muoversi, nella tabella di routing principale deve esistere un percorso attivo verso il gateway predefinito. Se non c'è, il pacchetto verrà semplicemente eliminato.

Come estensione dello strumento controlla gateway per un'analisi più approfondita dello stato del canale, propongo di utilizzare il metodo dei percorsi ricorsivi. L'idea del metodo è che indichiamo al router di cercare un percorso verso il proprio gateway non direttamente, ma attraverso un gateway intermedio. A tali gateway “di verifica” saranno scelti 4.2.2.1, 4.2.2.2 e 4.2.2.3 rispettivamente per ISP1, ISP2 e ISP3.

3.1.2.2. Percorso verso l'indirizzo “di verifica”:

/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

Nota. Abbassiamo il valore dello scope a quello predefinito nello scope di destinazione di ROS, per utilizzare successivamente 4.2.2.1 come gateway ricorsivo. Sottolineo: lo scope del percorso verso l'indirizzo “di verifica” deve essere minore o uguale allo scope di destinazione di quel percorso che farà riferimento a quello di verifica.

3.1.2.3. Rotta ricorsiva predefinita per il traffico senza routing mark:

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

Nota. Il valore di distance=2 è usato perché ISP1 è stato dichiarato come primo provider di riserva nelle specifiche.

3.1.2.4. Rotta ricorsiva predefinita per il traffico con routing mark “to_isp1”:

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

Nota. Qui finalmente iniziamo a beneficiare del lavoro preparatorio svolto nel punto 2.

Su questa rotta, tutto il traffico che ha il mark route “to_isp1” sarà diretto al gateway del primo provider indipendentemente dal gateway predefinito attualmente attivo per la tabella principale.

3.1.2.5. Prima rotta ricorsiva di riserva predefinita per il traffico marcato dai provider ISP2 e 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

Nota. Queste rotte sono necessarie anche per riservare il traffico dalle reti locali costituite dai membri della address list “to_isp*””,

3.1.2.6. Scriviamo la rotta per il traffico locale del router verso internet attraverso ISP1:

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

Nota. In combinazione con le regole di cui al punto 1.8.2, viene garantito l'accesso al canale desiderato con la sorgente specificata. Questo è fondamentale per la creazione di tunnel, dove viene impostato l'indirizzo IP del lato locale (EoIP, IP-IP, GRE). Poiché le regole in ip route rules vengono eseguite dall'alto verso il basso, fino al primo soddisfacimento dei criteri, questa regola deve essere posizionata dopo le regole del punto 1.8.2.

3.1.3. Definiamo la regola NAT per il traffico in uscita:

/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

Nota. NATizza tutto l'uscente, eccetto ciò che rientra nelle politiche IPsec. Cerco di non usare action=masquerade senza necessità estrema. Funziona più lentamente e richiede più risorse rispetto a src-nat, poiché calcola l'indirizzo per NAT per ogni nuova connessione.

3.1.4. Inviamo i clienti dalla lista a cui è vietato uscire attraverso altri provider direttamente al gateway del provider 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

Nota. action=route ha una priorità più alta e viene applicata prima delle altre regole di routing.

place-before=0 — posiziona la nostra regola per prima nella lista.

3.2. Configuriamo la connessione a ISP2.

Poiché il provider ISP2 ci fornisce le impostazioni tramite DHCP, è ragionevole apportare le necessarie modifiche con uno script che si avvia al verificarsi del cliente 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

Lo script stesso nella finestra di Winbox:

Nota. La prima parte dello script si attiva al ricevimento della locazione, la seconda dopo il rilascio della locazione.Vedi nota 2

3.3. Configurazione della connessione al provider ISP3.

Poiché il provider delle configurazioni ci fornisce dinamiche, è sensato apportare le modifiche necessarie tramite script che si avviano dopo l'innalzamento e dopo il calo dell'interfaccia ppp.

3.3.1. Prima configuriamo il profilo:

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

Lo script stesso nella finestra di Winbox:

Nota. Stringa
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
permette di gestire correttamente il rinominamento dell'interfaccia, poiché lavora con il suo codice e non con il nome visualizzato.

3.3.2. Ora, utilizzando il profilo, creiamo la connessione 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

Come ultimo tocco, configuriamo l'ora:

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

Per chi è arrivato fino alla fine

Il metodo proposto di implementazione del multipath è una preferenza personale dell'autore e non è l'unica possibilità. Gli strumenti di ROS sono ampi e flessibili, il che da un lato presenta difficoltà per i principianti, dall'altro è la ragione della loro popolarità. Studiate, provate e scoprite nuovi strumenti e soluzioni. Ad esempio, nella realizzazione presentata del multipath, si può sostituire lo strumento Check-gateway con rotte ricorsive su Netwatch.

Note

Check-gateway — meccanismo che consente di disattivare il percorso dopo due controlli consecutivi non riusciti del gateway per l'accessibilità. Il controllo viene effettuato ogni 10 secondi, più il timeout della risposta. Pertanto, il tempo effettivo di commutazione è compreso tra 20 e 30 secondi. Se questo tempo di commutazione non è sufficiente, c'è la possibilità di utilizzare uno strumento Netwatch, dove il timer di controllo può essere impostato manualmente. Meccanismo Check-gateway non si attiva in caso di perdite di pacchetti periodiche nel canale.
Importante! La disattivazione del percorso principale comporta la disattivazione di tutti gli altri percorsi che vi si riferiscono. Pertanto, per loro non è necessario specificare check-gateway=ping non è necessario.
Può capitare che nel funzionamento del DHCP si verifichi un malfunzionamento, che appare come un client bloccato nello stato di rinnovo. In tal caso, la seconda parte dello script non funzionerà, ma non interferirà con il traffico corretto, poiché lo stato monitora il relativo percorso ricorsivo.
ECMP (Equal Cost Multi-Path) — in ROS è possibile impostare un percorso con più gateway e la stessa distanza. In tal caso, le connessioni saranno distribuite sui canali utilizzando l'algoritmo round robin, proporzionalmente al numero di gateway specificati.

Un ringraziamento personale ad Evgeny per l'ispirazione nell'articolo, il supporto nella creazione della sua struttura e nella definizione degli accenti. @jscar

Fonte: habr.com