🥇Multivan e routing su Mikrotik RouterOS

Introduzione

Intraprendere questo articolo, oltre a un certo ego, è stato spinto dalla sconsolante frequenza delle domande su questo tema nei gruppi tematici della comunità russa di Telegram. L'articolo è rivolto ai neofiti amministratori di Mikrotik RouterOS (di seguito ROS). Viene trattato solo il multi-VLAN, con un focus sulla routing. Come bonus, sono presenti le configurazioni minime necessarie per garantire un lavoro sicuro e comodo. Coloro che cercano un approfondimento 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 soggetto, è stato scelto un router Mikrotik a cinque porte con ROS versione 6.45.3. Sarà utilizzato per instradare il traffico tra due reti locali (LAN1 e LAN2) e tre provider (ISP1, ISP2, ISP3). La connessione a ISP1 ha un indirizzo “grigio” statico, ISP2 — “bianco”, ottenuto tramite DHCP, ISP3 — “bianco” con autorizzazione PPPoE. Lo schema di connessione è mostrato nell'immagine:

L'obiettivo è configurare il router 'MTK' in base allo schema affinché:

Assicurare il passaggio automatico al provider di riserva. Il provider principale è ISP2, il primo di riserva è ISP1, il secondo di riserva è ISP3.
Organizzare l'accesso alla rete LAN1 a Internet solo tramite ISP1.
Prevedere la possibilità di instradare il traffico dalle reti locali a Internet tramite il provider scelto in base all'address-list.
Prevedere la possibilità di pubblicare servizi dalla rete locale a Internet (DSTNAT).
Configurare un filtro del firewall per garantire una sicurezza minima nei confronti di Internet.
Il router potrà generare traffico attraverso uno qualsiasi dei tre provider a seconda dell'indirizzo sorgente scelto.
Assicurare che i pacchetti di risposta vengano instradati attraverso il canale da cui provengono (compresa LAN).

Nota. Configureremo il router 'da zero' per garantire l'assenza di sorprese nelle configurazioni iniziali che cambiano da versione a versione 'out of the box'. Lo strumento di configurazione scelto è Winbox, dove verranno visualizzate in modo chiaro le modifiche. Le configurazioni stesse verranno impostate tramite comandi nel terminale di Winbox. La connessione fisica per la configurazione avviene tramite collegamento diretto con l'interfaccia Ether5.

Riflessioni su cosa sia un multivan, se è un problema o se astuti esperti stiano tessendo una rete di cospirazioni

Un amministratore curioso e attento, configurando autonomamente tale schema o uno simile, si rende conto improvvisamente che funziona già bene. Sì, senza queste vostre tabelle di routing e altre route rules, che affollano la maggior parte degli articoli su questo argomento. Verifichiamo?

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 di default significa che la distanza sarà uguale a uno.
Su ISP3 nelle impostazioni del client PPPoE abbiamo add-default-route=yes impostiamo default-route-distance=3.

Non dimentichiamo di impostare il NAT in uscita:

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

In conclusione, gli utenti delle reti locali possono divertirsi a caricarsi tramite il provider principale ISP2, e c'è anche un backup della connessione tramite il meccanismo check gateway Vedi nota 1

Il punto 1 del compito è stato realizzato. Dov'è il multivan con i suoi etichette? No...

Andiamo oltre. Dobbiamo far uscire 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, route rules, dove siete?!

Dobbiamo dare accesso al nostro amato server OpenVPN con indirizzo 172.17.17.17 per i clienti da Internet? Ecco:

/ip cloud set ddns-enabled=yes

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

Configurando il 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

Il punto 4 è pronto.

Configuriamo il firewall e altre misure di sicurezza per il punto 5, mentre siamo felici che per gli utenti tutto funzioni già e ci tuffiamo in una bevanda passata...
Ah! Dobbiamo anche i tunnel.

Il client L2TP, configurato seguendo l'articolo trovato, è riuscito a connettersi al nostro amato VDS olandese? Sì.
Il server L2TP con IPsec è stato avviato e i clienti si connettono tramite il DNS name da IP Cloud (vedi sopra)? Sì.
Rilassandoci sulla sedia, sorseggiando una bevanda, esaminiamo pigramente i punti 6 e 7 del compito. Pensiamo: ne abbiamo bisogno? Dopotutto, anche così funziona (s)... Dunque, se non ne abbiamo realmente bisogno, finisce qui. Il multivan è stato realizzato.

Cos'è un multivan? È la connessione di più canali Internet a un solo router.

In seguito, non è necessario leggere l'articolo, poiché cosa ci potrebbe essere se non presunzione di applicabilità dubbia?

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

Il compito principale dell'implementazione del multipath è la corretta instradamento del traffico. In particolare: indipendentemente da quale (o da quali) canali del fornitore Guarda nota 3 il percorso predefinito sul nostro router, deve restituire una risposta esattamente al canale da cui è pervenuto il pacchetto. Il compito è chiaro. Ma qual è il problema? Infatti, nella semplice rete locale il compito è lo stesso, ma nessuno si preoccupa di impostazioni aggiuntive e non sente difficoltà. La differenza è che qualsiasi nodo instradabile su Internet è accessibile attraverso ciascuno dei nostri canali, e non attraverso uno specifico, come nella semplice rete locale. E il "problema" è che se riceviamo una richiesta per l'indirizzo IP ISP3, nel nostro caso la risposta andrà attraverso il canale ISP2, poiché lì è diretto il gateway predefinito. Andrà e sarà scartato dal fornitore come non valido. Abbiamo identificato il problema. Come lo risolviamo?

Divideremo la soluzione in tre fasi:

Impostazione preliminare. In questa fase verranno impostate le configurazioni di base del router: rete locale, firewall, liste indirizzi, hairpin NAT, ecc.
Multipath. In questa fase verranno contrassegnate e classificate le connessioni necessarie nelle tabelle di instradamento.
Connessione all'ISP. In questa fase verranno configurate le interfacce che forniscono la connessione a Internet, sarà coinvolto l'instradamento e il meccanismo di riserva dei canali Internet.

1. Impostazione preliminare

1.1. Ripristiniamo la configurazione del router con il comando:

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

acconsentiamo a "Dangerous! Reset anyway? [y/N]:" e, dopo il riavvio, ci colleghiamo tramite Winbox tramite MAC. In questa fase la configurazione e il database degli utenti sono stati ripuliti.

1.2. Creiamo un nuovo utente:

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

ci accediamo e rimuoviamo quello predefinito:

/user remove admin

Nota. Infatti, l'autore considera più sicuro il suo allontanamento anziché la disattivazione del utente predefinito e lo raccomanda.

1.3. Creiamo liste 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"

Aggiungiamo commenti alle 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 compiliamo le liste di 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 comprensibili vale il tempo speso per questo e facilita notevolmente la risoluzione dei problemi e la comprensione della configurazione.

L'autore ritiene necessario, per motivi di sicurezza, aggiungere all'elenco delle interfacce 'WAN' l'interfaccia ether3, nonostante su di essa non circoli il protocollo ip.

Non dimentichiamo che dopo aver attivato l'interfaccia PPP su ether3, sarà necessario aggiungerla all'elenco delle interfacce 'WAN'.

1.4. Nascondiamo il router dalla rilevazione della vicinanza e dalla gestione dalle reti dei provider attraverso il 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. Creiamo un insieme minimo di regole di filtro del firewall per proteggere il router:

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

(questa regola consente le connessioni stabilite e correlate, che sono state iniziate sia dalle reti connesse che dal router stesso)

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

(ping e non solo ping. È consentito tutto l'icmp in ingresso. Molto utile per trovare 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 il resto che proviene da Internet)

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

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

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

(questa regola scarta le connessioni con connection-state=invalid, che passano attraverso il router. È fortemente consigliata da Mikrotik, ma in alcune rare situazioni potrebbe 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

(questa regola vieta ai pacchetti provenienti da Internet di passare attraverso il router se non hanno superato la procedura di dstnat. Questo proteggerà le reti locali dagli aggressori che, trovandosi nello stesso dominio di broadcast delle nostre reti esterne, scriveranno i nostri IP esterni come gateway e tenteranno così di 'esplorare' le nostre reti locali.)

Nota. Consideriamo come condizione che le reti LAN1 e LAN2 siano fidate e che il traffico tra di esse e da esse non sia filtrato.

1.6. Creiamo un elenco con l'inventario 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

(Questa è una lista di indirizzi e reti che non vengono instradati su Internet e, di conseguenza, noi seguiremo anche questo.)

Nota. L'elenco potrebbe cambiare, quindi consiglio di controllare periodicamente la sua attualità.

1.7. Configuriamo il DNS per il router stesso:

/ip dns set servers=1.1.1.1,8.8.8.8

Nota. Nell'attuale versione ROS dinamiche servers hanno la priorità rispetto a quelli staticamente impostati. La richiesta di risoluzione del nome viene inviata al primo server nell'ordine presente nell'elenco. Si passa al server successivo in caso di non disponibilità del server attuale. Il timeout è elevato — superiore a 5 secondi. Il ritorno automatico, una volta che il “server caduto” riprende a funzionare, non avviene. Tenendo conto di questo algoritmo e della presenza di un multiwan, l'autore raccomanda di non utilizzare i 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 per i percorsi 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 modi semplici e veloci per accedere agli indirizzi delle reti locali con sorgenti di indirizzi IP esterni delle interfacce del router, attraverso le quali non viene effettuato un percorso predefinito.

1.8.3. Attiviamo il 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. Questo consente di accedere alle proprie risorse tramite l'IP esterno (dstnat) rimanendo all'interno della rete.

2. Fondamentalmente, l'implementazione di quel corretto multiwan

Per affrontare la questione “rispondere da dove è stato chiesto” utilizzeremo due strumenti ROS: connection mark e routing mark. Il Connection mark consente di contrassegnare la connessione desiderata e successivamente operare con questa etichetta come condizione per l'applicazione routing mark. E poi con routing mark è possibile lavorare in ip route e route rules. Abbiamo capito gli strumenti, ora dobbiamo decidere quali connessioni etichettare — uno, dove esattamente etichettare — due.

Con il primo è tutto semplice — dobbiamo etichettare tutte le connessioni che arrivano al router da Internet tramite il canale corrispondente. Nel nostro caso ci saranno tre etichette (in base al numero di canali): “conn_isp1”, “conn_isp2” e “conn_isp3”.

La questione del secondo è che le connessioni in ingresso saranno di due tipi: transitiva e quelle destinate al router stesso. Il meccanismo della connection mark funziona nella tabella mangle. Consideriamo il movimento del pacchetto in un diagramma semplificato, gentilmente compilato dagli specialisti del sito mikrotik-trainings.com (non è pubblicità):

Seguendo le frecce, vediamo che il pacchetto che arriva all'“input interface”, passa attraverso la catena “Prerouting” e solo dopo viene suddiviso in transito e locale nel blocco “Routing Decision”. Pertanto, per raggiungere due obiettivi, utilizziamo Connection Mark nella tabella Mangle Prerouting catene Prerouting.

Nota. In ROS, i segni "Routing mark" sono indicati nella sezione Ip/Routes/Rules come "Table", mentre nelle altre sezioni come "Routing Mark". Questo può creare un po' di confusione nel comprendere, ma in sostanza è la stessa cosa e rappresenta l'analogo di rt_tables in iproute2 su linux.

2.1. Segniamo le connessioni in entrata 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 contrassegnare le connessioni già contrassegnate utilizzo la condizione connection-mark=no-mark invece di connection-state=new, perché lo considero più corretto, così come il rifiuto di drop invalid per le connessioni nei filtri input.

passthrough=no — perché in questo metodo di implementazione la rimarcamazione è esclusa e per accelerare si può interrompere l'analisi delle regole dopo la prima corrispondenza.

Va tenuto presente che non stiamo ancora intervenendo nella routing. Attualmente sono in fase di preparazione. La fase successiva dell'implementazione sarà la gestione del traffico in transito che ritorna per una connessione stabilita dall'indirizzo destinatario nella rete locale. Cioè, dei pacchetti che (vedi diagramma) sono passati attraverso il router seguendo il percorso:

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

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

"Input Interface"=>"Prerouting"=>"Routing Decision"=>"Forward"=>"Post Routing"=>"Output Interface" semplicemente per la richiesta "Input Interface" l'interfaccia era ISP, mentre per la risposta — LAN

2.2. Direzioniamo il traffico di risposta di ritorno attraverso le rispettive tabelle di routing:

/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 che non ha l'indirizzo di destinazione degli indirizzi delle interfacce del router stesso.

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

"Input Interface"=>"Prerouting"=>"Routing Decision"=>"Input"=>"Local Process"

Importante! La risposta seguirà il seguente percorso:

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

2.3. Direzioniamo il traffico locale di risposta attraverso le rispettive tabelle di routing:

/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

In questa fase, il compito di preparare la risposta per l'invio nel canale Internet da cui è pervenuta la richiesta può considerarsi risolto. Tutto è stato contrassegnato, marcatore e pronto per il routing.
Un efficace "effetto collaterale" di tale impostazione è la possibilità di lavorare con il port forwarding DSNAT da entrambi i provider (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 puntano su canali Internet diversi.

Per risolvere le particolarità del funzionamento delle reti locali con indirizzi IP esterni del router, utilizziamo le soluzioni nei punti 1.8.2 e 3.1.2.6.

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

2.4. Inoltriamo il traffico dai client locali delle liste di instradamento nelle relative tabelle:

/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

In conclusione, questo 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 un 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 una rotta predefinita "di emergenza":

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

Nota. Questa rotta consente al traffico proveniente dai processi locali di passare alla fase di Decisione della Route indipendentemente dallo stato dei canali di qualsiasi provider. La particolarità del traffico locale in uscita è che affinché un pacchetto si muova in qualsiasi direzione, deve esserci una rotta attiva verso il gateway predefinito nella tabella di instradamento principale. Se non c'è, il pacchetto verrà semplicemente distrutto.

Come estensione dello strumento check gateway per un'analisi più approfondita dello stato del canale, propongo di utilizzare il metodo delle rotte ricorsive. Il principio del metodo è che indichiamo al router di cercare la rotta verso il proprio gateway non direttamente, ma attraverso un gateway intermedio. Gli "gateway di controllo" selezionati saranno 4.2.2.1, 4.2.2.2 e 4.2.2.3 rispettivamente per ISP1, ISP2 e ISP3.

3.1.2.2. Rotta verso l'indirizzo "di controllo":

/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. Riduciamo il valore dello scope al valore predefinito nello scope di destinazione di ROS, per poter utilizzare in seguito 4.2.2.1 come gateway ricorsivo. Sottolineo: lo scope della rotta verso l'indirizzo "di controllo" deve essere minore o uguale allo scope di destinazione della rotta che si riferirà al controllo.

3.1.2.3. Rotta ricorsiva di default per il traffico senza marchio di instradamento:

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

Nota. Il valore distance=2 è utilizzato perché ISP1 è dichiarato come il primo di riserva nelle condizioni del compito.

3.1.2.4. Rotta ricorsiva di default per il traffico con marchio di instradamento "to_isp1":

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

Nota. In effetti, qui iniziamo finalmente a sfruttare i frutti di quel lavoro preparatorio che è stato svolto nel punto 2.

Su questo percorso, tutto il traffico che ha il mark route “to_isp1” sarà instradato verso il gateway del primo fornitore indipendentemente da quale gateway sia attualmente attivo come predefinito nella tabella main.

3.1.2.5. Primo percorso ricorsivo di riserva predefinito per il traffico contrassegnato dei fornitori 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. Questi percorsi sono necessari anche per la riserva di traffico dalle reti locali, che consistono nei membri dell'address list “to_isp*”.

3.1.2.6. Configuriamo il percorso per il traffico locale del router su Internet attraverso ISP1:

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

Nota. Combinato con le regole del punto 1.8.2, si garantisce l'uscita verso il canale desiderato con la sorgente specificata. Questo è critico per costruire tunnel in cui 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 abbinamento delle condizioni, questa regola deve essere dopo le regole del punto 1.8.2.

3.1.3. Configuriamo 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. NAT per tutto l'uscente, tranne per ciò che rientra nelle politiche IPsec. Cerco di non utilizzare action=masquerade senza necessità estrema. Funziona più lentamente e consuma più risorse rispetto a src-nat, poiché calcola l'indirizzo per NAT per ogni nuova connessione.

3.1.4. Inviamo i clienti dell'elenco a cui è vietato l'accesso tramite altri fornitori direttamente al gateway del fornitore 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 di altre regole di routing.

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

3.2. Configuriamo la connessione con ISP2.

Poiché il fornitore ISP2 ci fornisce le impostazioni tramite DHCP, è ragionevole apportare le modifiche necessarie tramite uno script che si avvia all'attivazione 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 viene eseguita al termine della richiesta di leasing, la seconda — dopo la liberazione del leasing.Vedi nota 2

3.3. Configuriamo la connessione con il fornitore ISP3.

Poiché il fornitore ci fornisce impostazioni dinamiche, è ragionevole apportare le modifiche necessarie tramite script che si attivano dopo l'attivazione e la disattivazione dell'interfaccia ppp.

3.3.1. Iniziamo a configurare 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. Riga
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
consente di gestire correttamente la rinomina dell'interfaccia, poiché lavora con il suo codice e non con il nome visualizzato.

3.3.2. Ora, utilizzando il profilo, creiamo una 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, configurare l'orologio:

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

Per chi è riuscito a leggere fino in fondo

Il metodo proposto per implementare il mulitvan è una preferenza personale dell'autore e non è l'unico possibile. L'ecosistema ROS è vasto e flessibile, il che da un lato crea difficoltà per i principianti, dall'altro è la ragione della sua popolarità. Studiate, provate, scoprite nuovi strumenti e soluzioni. Ad esempio, in questa implementazione del mulitvan si può sostituire lo strumento Check-gateway con percorsi ricorsivi su Netwatch.

Note

Check-gateway è un meccanismo che consente di disattivare un percorso dopo due controlli consecutivi non riusciti della disponibilità del gateway. Il controllo avviene ogni 10 secondi, più il timeout di risposta. Pertanto, il timing effettivo del commutazione si colloca tra i 20 e i 30 secondi. Se tale timing non è sufficiente, è possibile utilizzare lo strumento Netwatch, dove il timer di controllo può essere impostato manualmente. Il meccanismo Check-gateway non si attiva in caso di perdite periodiche di pacchetti nel canale.
Importante! La disattivazione del percorso principale comporta la disattivazione di tutti gli altri percorsi ad esso riferiti. Pertanto, per loro non è necessario specificare check-gateway=ping non è necessario.
Capita che nel meccanismo di funzionamento del DHCP si verifichi un guasto, che si presenta come un client bloccato nello stato di renew. In questo caso, la seconda parte dello script non verrà eseguita, ma non interferirà con il normale passaggio del traffico, poiché lo stato viene monitorato dal corrispondente percorso ricorsivo.
ECMP (Equal Cost Multi-Path) in ROS è possibile impostare un percorso con più gateway e la stessa distanza. In questo caso, le connessioni verranno distribuite sui canali utilizzando l'algoritmo round robin, in proporzione al numero di gateway specificati.

Per la spinta alla scrittura dell'articolo, l'aiuto nella formazione della sua struttura e nell'impostazione degli accenti — un ringraziamento personale a Evgenij @jscar

Fonte: habr.com