Introduzione
La ripresa dell'articolo, oltre alla vanità, è stata suggerita dalla deprimente frequenza di domande su questo argomento nei gruppi di profili della comunità di telegrammi di lingua russa. L'articolo è rivolto agli amministratori principianti di Mikrotik RouterOS (di seguito denominato ROS). Si occupa solo del multivan, con un'enfasi sull'instradamento. Come bonus, ci sono impostazioni minimamente sufficienti per garantire un funzionamento sicuro e conveniente. Coloro che sono alla ricerca di informazioni sugli argomenti di code, bilanciamento del carico, vlan, bridge, analisi approfondita in più fasi dello stato del canale e simili, potrebbero non perdere tempo e fatica a leggere.
Dati iniziali
Come soggetto del test è stato selezionato un router Mikrotik a cinque porte con versione ROS 6.45.3. Instraderà 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 - "bianco", ottenuto tramite DHCP, ISP3 - "bianco" con autorizzazione PPPoE. Lo schema di collegamento è mostrato in figura:
Il compito è configurare il router MTK in base allo schema in modo che:
- Fornire il passaggio automatico a un provider di backup. Il provider principale è ISP2, la prima riserva è ISP1, la seconda riserva è ISP3.
- Organizzare l'accesso alla rete LAN1 a Internet solo tramite ISP1.
- Fornire la possibilità di instradare il traffico dalle reti locali a Internet attraverso il provider selezionato in base all'elenco di indirizzi.
- Prevedere la possibilità di pubblicare servizi dalla rete locale a Internet (DSTNAT)
- Impostare un filtro firewall per fornire la sicurezza minima sufficiente da Internet.
- Il router potrebbe emettere il proprio traffico attraverso uno qualsiasi dei tre provider, a seconda dell'indirizzo di origine selezionato.
- Assicurarsi che i pacchetti di risposta vengano instradati al canale da cui provengono (inclusa la LAN).
Nota. Configuriamo il router “da zero” in modo da garantire l'assenza di sorprese nelle configurazioni di partenza “out of the box” che cambiano da versione a versione. Winbox è stato scelto come strumento di configurazione, in cui le modifiche verranno visualizzate visivamente. Le impostazioni stesse verranno impostate dai comandi nel terminale Winbox. La connessione fisica per la configurazione viene effettuata tramite una connessione diretta all'interfaccia Ether5.
Un po 'di ragionamento su cosa sia un multivan, è un problema o sono persone astute e intelligenti intorno alla tessitura di reti di cospirazione
Un amministratore curioso e attento, che crea da solo uno schema simile o simile, improvvisamente si rende conto che sta già funzionando normalmente. Sì, sì, senza le tabelle di instradamento personalizzate e altre regole di instradamento, di cui è piena la maggior parte degli articoli su questo argomento. Controlliamo?
Possiamo configurare l'indirizzamento su interfacce e gateway predefiniti? SÌ:
Su ISP1, l'indirizzo e il gateway sono stati registrati distanza=2 и check-gateway=ping.
Su ISP2, l'impostazione predefinita del client dhcp - di conseguenza, la distanza sarà uguale a uno.
Su ISP3 nelle impostazioni del client pppoe quando add-default-route=sì Mettere default-percorso-distanza=3.
Non dimenticare di registrare NAT all'uscita:
/ip firewall nat add action=masquerade chain=srcnat out-interface-list=WAN
Di conseguenza, gli utenti dei siti locali si divertono a scaricare i gatti tramite il principale provider ISP2 e c'è una prenotazione del canale utilizzando il meccanismo controllare il gateway Vedi nota 1
Il punto 1 dell'attività è implementato. Dov'è il multivan con i suoi segni? NO…
Ulteriore. È necessario rilasciare client specifici dalla LAN tramite ISP1:
/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=sì 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 indirizzo src=192.168.88.0/24
Gli elementi 2 e 3 del compito sono stati implementati. Etichette, timbri, regole del percorso, dove sei?!
Hai bisogno di dare accesso al tuo server OpenVPN preferito con l'indirizzo 172.17.17.17 per i client da Internet? Per favore:
/ip cloud set ddns-enabled=sì
Come peer, diamo al cliente il risultato di output: ":put [ip cloud ottieni nome-dns]"
Registriamo il port forwarding da Internet:
/ip firewall nat aggiungi azione=dst-nat chain=dstnat dst-port=1194
in-interface-list=protocollo WAN=udp to-addresses=172.17.17.17
Il punto 4 è pronto.
Abbiamo installato un firewall e altra sicurezza per il punto 5, allo stesso tempo siamo contenti che tutto funzioni già per gli utenti e raggiungiamo un contenitore con una bevanda preferita ...
UN! I tunnel sono dimenticati.
l2tp-client, configurato da google article, è salito al tuo VDS olandese preferito? SÌ.
l2tp-server con IPsec è aumentato e i client per nome DNS da IP Cloud (vedi sopra) si aggrappano? SÌ.
Appoggiandosi allo schienale della nostra sedia, sorseggiando un drink, consideriamo pigramente i punti 6 e 7 del compito. Pensiamo: ne abbiamo bisogno? Tuttavia, funziona così (c) ... Quindi, se non è ancora necessario, è così. Multivan implementato.
Cos'è un multivan? Questa è la connessione di diversi canali Internet a un router.
Non devi leggere ulteriormente l'articolo, perché cosa può esserci oltre a uno sfoggio di dubbia applicabilità?
Per coloro che rimangono, che sono interessati ai punti 6 e 7 del compito, e sentono anche il prurito del perfezionismo, ci immergiamo più a fondo.
Il compito più importante dell'implementazione di un multivan è il corretto instradamento del traffico. Vale a dire: indipendentemente da quale (o quale) vedi. nota 3 i canali dell'ISP guardano il percorso predefinito sul nostro router, dovrebbe restituire una risposta al canale esatto da cui proviene il pacchetto. Il compito è chiaro. Dov'è il problema? In effetti, in una semplice rete locale, il compito è lo stesso, ma nessuno si preoccupa di impostazioni aggiuntive e non si sente nei guai. La differenza è che qualsiasi nodo instradabile su Internet è accessibile attraverso ciascuno dei nostri canali, e non attraverso uno strettamente specifico, come in una semplice LAN. E il "problema" è che se ci è arrivata una richiesta per l'indirizzo IP dell'ISP3, nel nostro caso la risposta passerà attraverso il canale ISP2, poiché il gateway predefinito è diretto lì. Lascia e verrà scartato dal fornitore come errato. Il problema è stato identificato. Come risolverlo?
La soluzione si articola in tre fasi:
- Preimpostazione. A questo punto, verranno configurate le impostazioni di base del router: rete locale, firewall, elenchi di indirizzi, NAT a forcina, ecc.
- Multivan. A questo punto, le connessioni necessarie verranno contrassegnate e ordinate in tabelle di instradamento.
- Connessione a un ISP. In questa fase verranno configurate le interfacce che garantiscono la connessione ad Internet, verrà attivato il meccanismo di routing e di prenotazione dei canali Internet.
1. Preimpostazione
1.1. Cancelliamo la configurazione del router con il comando:
/system reset-configuration skip-backup=yes no-defaults=yesessere d'accordo con "Pericoloso! Resettare comunque? [s/n]:” e, dopo il riavvio, ci connettiamo con Winbox tramite MAC. In questa fase, la configurazione e la base utenti vengono cancellate.
1.2. Crea un nuovo utente:
/user add group=full name=knight password=ultrasecret comment=”Not horse”accedi sotto di esso ed elimina quello predefinito:
/user remove adminNota. È la rimozione e la non disabilitazione dell'utente predefinito che l'autore considera più sicuro e raccomanda l'uso.
1.3. Creiamo elenchi di interfacce di base per la comodità di operare in un firewall, impostazioni di rilevamento e altri server MAC:
/interface list add name=WAN comment="For Internet"
/interface list add name=LAN comment="For Local Area"Interfacce di firma con commenti
/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 compilare gli elenchi 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, inoltre facilita notevolmente la risoluzione dei problemi e la comprensione della configurazione.
L'autore ritiene necessario, per motivi di sicurezza, aggiungere l'interfaccia ether3 all'elenco delle interfacce "WAN", nonostante il protocollo ip non la attraverserà.
Non dimenticare che dopo che l'interfaccia PPP è stata attivata su ether3, dovrà anche essere aggiunta all'elenco delle interfacce "WAN"
1.4. Nascondiamo il router dal rilevamento e dal controllo del vicinato dalle reti dei provider 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=LAN1.5. Creiamo il set minimo sufficiente 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(la regola fornisce l'autorizzazione per le connessioni stabilite e correlate avviate 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. Tutti gli icmp sono ammessi. Molto utile per trovare problemi di MTU)
/ip firewall filter add action=drop chain=input comment="All other WAN Drop" in-interface-list=WAN(la regola che chiude la catena di 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(la regola consente connessioni stabilite e relative che passano attraverso il router)
/ip firewall filter add action=drop chain=forward comment="Invalid drop" connection-state=invalid(la regola reimposta le connessioni con connection-state=invalid passando attraverso il router. È fortemente consigliata da Mikrotik, ma in alcune rare situazioni può bloccare il 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 vieta ai pacchetti che provengono da Internet e non hanno superato la procedura dstnat di passare attraverso il router. Questo proteggerà le reti locali da intrusi che, trovandosi nello stesso dominio di trasmissione con le nostre reti esterne, registreranno i nostri IP esterni come gateway e, quindi, cercare di “esplorare” le nostre reti locali.)
Nota. Supponiamo che le reti LAN1 e LAN2 siano attendibili e che il traffico tra di esse e da esse non sia filtrato.
1.6. Crea un elenco con un elenco di 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 verranno seguiti di conseguenza.)
Nota. L'elenco è soggetto a modifiche, quindi ti consiglio di verificarne periodicamente la pertinenza.
1.7. Configura il DNS per il router stesso:
/ip dns set servers=1.1.1.1,8.8.8.8Nota. Nella versione attuale di ROS, i server dinamici hanno la precedenza su quelli statici. La richiesta di risoluzione dei nomi viene inviata al primo server in ordine nell'elenco. Il passaggio al server successivo viene effettuato quando quello corrente non è disponibile. Il timeout è ampio: più di 5 secondi. Il ritorno indietro, quando il "server caduto" viene ripreso, non avviene automaticamente. Dato questo algoritmo e la presenza di un multivan, l'autore consiglia di non utilizzare i server forniti dai provider.
1.8. Configurare una rete locale.
1.8.1. Configuriamo indirizzi IP statici su interfacce 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. Impostiamo le regole per i percorsi verso le nostre reti locali attraverso 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 LAN con fonti di indirizzi IP esterni di interfacce router che non passano attraverso il percorso predefinito.
1.8.3. Abilita 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.0Nota. Ciò ti consente di accedere alle tue risorse (dstnat) tramite un IP esterno pur essendo all'interno della rete.
2. In realtà, l'implementazione del multivan molto corretto
Per risolvere il problema di "rispondere da dove hanno chiesto", utilizzeremo due strumenti ROS: segno di connessione и segno di instradamento. segno di connessione consente di contrassegnare la connessione desiderata e quindi lavorare con questo contrassegno come condizione per l'applicazione segno di instradamento. E già con segno di instradamento possibile lavorarci dentro percorso ip и regole di percorso. Abbiamo individuato gli strumenti, ora devi decidere quali connessioni contrassegnare - una volta, esattamente dove contrassegnare - due.
Con il primo tutto è semplice: dobbiamo contrassegnare tutte le connessioni che arrivano al router da Internet tramite il canale appropriato. Nel nostro caso, queste saranno tre etichette (in base al numero di canali): "conn_isp1", "conn_isp2" e "conn_isp3".
La sfumatura con il secondo è che le connessioni in entrata saranno di due tipi: di transito e quelle destinate al router stesso. Il meccanismo del segno di connessione funziona nella tabella mancante. Considera il movimento del pacco su un diagramma semplificato, gentilmente compilato dagli specialisti della risorsa mikrotik-trainings.com (non pubblicità):
Seguendo le frecce, vediamo che il pacchetto che arriva a "Interfaccia di ingresso”, passa attraverso la catena “Pre-indirizzamento"e solo allora è diviso in transito e locale nel blocco"Decisione di rotta". Pertanto, per prendere due piccioni con una fava, usiamo Segno di connessione nel tavolo Pre-instradamento Mangle Catene Pre-indirizzamento.
osservazione. In ROS, le etichette "Routing mark" sono elencate come "Table" nella sezione Ip/Routes/Rules e come "Routing Mark" in altre sezioni. Questo può introdurre un po' di confusione nella comprensione, ma, in realtà, questa è la stessa cosa, ed è un analogo di rt_tables in iproute2 su Linux.
2.1. Contrassegniamo le connessioni in entrata da ciascuno dei provider:
/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=noNota. Per non contrassegnare le connessioni già contrassegnate, utilizzo la condizione connection-mark=no-mark invece di connection-state=new perché penso che sia più corretta, così come il rifiuto di eliminare connessioni non valide nel filtro di input.
passthrough=no - perché in questo metodo di implementazione è esclusa la rimarcatura e, per velocizzare, è possibile interrompere l'enumerazione delle regole dopo la prima corrispondenza.
Va tenuto presente che non interferiamo ancora in alcun modo con il routing. Ora ci sono solo fasi di preparazione. La fase successiva dell'implementazione sarà l'elaborazione del traffico di transito che ritorna sulla connessione stabilita dalla destinazione nella rete locale. Quelli. quei pacchetti che (vedi il diagramma) sono passati attraverso il router lungo il percorso:
“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” e sono arrivato al loro destinatario nella rete locale.
Importante! In ROS non esiste una divisione logica in interfacce esterne e interne. Se tracciamo il percorso del pacchetto di risposta secondo lo schema sopra, allora seguirà lo stesso percorso logico della richiesta:
“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” solo per una richiesta"Interfaccia di ingresso" era l'interfaccia ISP e per la risposta - LAN
2.2. Dirigiamo il traffico di transito di risposta alle 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=noCommento. in-interface-list=!WAN - lavoriamo solo con traffico proveniente dalla rete locale e dst-address-type=!local che non ha l'indirizzo di destinazione dell'indirizzo delle interfacce del router stesso.
Lo stesso per i pacchetti locali che sono arrivati al router lungo il percorso:
“Interfaccia di input”=>”Prerouting”=>”Decisione di instradamento”=>”Input”=>”Processo locale”
Importante! La risposta andrà nel modo seguente:
”Processo locale”=>”Decisione di instradamento”=>”Output”=>”Post Routing”=>”Interfaccia di output”
2.3. Dirigiamo il traffico locale di risposta alle tabelle di routing 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=noA questo punto si può considerare risolto il compito di predisporre l'invio di una risposta al canale Internet da cui proveniva la richiesta. Tutto è contrassegnato, etichettato e pronto per essere instradato.
Un eccellente effetto "collaterale" di questa configurazione è la capacità di lavorare con il port forwarding DSNAT da entrambi i provider (ISP2, ISP3) contemporaneamente. Niente affatto, poiché su ISP1 abbiamo un indirizzo non instradabile. Questo effetto è importante, ad esempio, per un server di posta con due MX che controllano diversi canali Internet.
Per eliminare le sfumature del funzionamento delle reti locali con router IP esterni, utilizziamo le soluzioni dei paragrafi. 1.8.2 e 3.1.2.6.
Inoltre, puoi utilizzare uno strumento con segni per risolvere il paragrafo 3 del problema. Lo implementiamo in questo modo:
2.4. Dirigiamo il traffico dai client locali dalle liste di instradamento alle tabelle appropriate:
/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_ISP3Di conseguenza, assomiglia a questo:
3. Configurare una connessione all'ISP e abilitare il routing con marchio
3.1. Configurare una connessione all'ISP1:
3.1.1. Configura un indirizzo IP statico:
/ip address add interface=ether1 address=100.66.66.2/30 comment="ISP1 IP"3.1.2. Imposta il routing statico:
3.1.2.1. Aggiungi un percorso di "emergenza" predefinito:
/ip route add comment="Emergency route" distance=254 type=blackholeNota. Questo instradamento consente al traffico proveniente dai processi locali di superare la fase di decisione dell'instradamento, indipendentemente dallo stato dei collegamenti di uno qualsiasi dei provider. La sfumatura del traffico locale in uscita è che, affinché il pacchetto si sposti almeno da qualche parte, la tabella di instradamento principale deve avere un percorso attivo verso il gateway predefinito. In caso contrario, il pacco verrà semplicemente distrutto.
Come estensione dello strumento controllare il gateway Per un'analisi più approfondita dello stato del canale, suggerisco di utilizzare il metodo del percorso ricorsivo. L'essenza del metodo è che diciamo al router di cercare un percorso per il suo gateway non direttamente, ma attraverso un gateway intermedio. 4.2.2.1, 4.2.2.2 e 4.2.2.3 saranno scelti come tali gateway di "test" 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=10Nota. Abbassiamo il valore dell'ambito al valore predefinito nell'ambito di destinazione ROS per utilizzare 4.2.2.1 come gateway ricorsivo in futuro. Sottolineo: lo scope della route all'indirizzo “test” deve essere minore o uguale allo scope target della route che farà riferimento a quello di test.
3.1.2.3. Percorso predefinito ricorsivo per il traffico senza contrassegno di percorso:
/ip route add comment="Unmarked via ISP1" distance=2 gateway=4.2.2.1Nota. Viene utilizzato il valore distance=2 perché l'ISP1 è dichiarato come primo backup in base alle condizioni dell'attività.
3.1.2.4. Percorso predefinito ricorsivo per il traffico con contrassegno di routing "to_isp1":
/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1
routing-mark=to_isp1Nota. In realtà, qui stiamo finalmente iniziando a godere dei frutti del lavoro preparatorio che è stato svolto nel paragrafo 2.
Su questa route, tutto il traffico che ha il mark route "to_isp1" verrà indirizzato al gateway del primo provider, indipendentemente da quale gateway predefinito sia attualmente attivo per la tabella principale.
3.1.2.5. Prima route predefinita ricorsiva di fallback per il traffico con tag 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_isp3Nota. Questi percorsi sono necessari, tra l'altro, per riservare il traffico dalle reti locali che sono membri dell'elenco di indirizzi "to_isp*"'
3.1.2.6. Registriamo il percorso per il traffico locale del router verso Internet tramite ISP1:
/ip route rule add comment="From ISP1 IP to Inet" src-address=100.66.66.2 table=to_isp1Nota. In combinazione con le regole del paragrafo 1.8.2, fornisce l'accesso al canale desiderato con una data sorgente. Questo è fondamentale per la creazione di tunnel che specificano l'indirizzo IP del lato locale (EoIP, IP-IP, GRE). Poiché le regole nelle regole di route ip vengono eseguite dall'alto verso il basso, fino alla prima corrispondenza delle condizioni, questa regola dovrebbe essere dopo le regole della clausola 1.8.2.
3.1.3. Registriamo 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.2Nota. NATim tutto ciò che esce, tranne ciò che entra nelle politiche IPsec. Cerco di non usare action=masquerade a meno che non sia assolutamente necessario. È più lento e richiede più risorse di src-nat perché calcola l'indirizzo NAT per ogni nuova connessione.
3.1.4. Inviamo i client dell'elenco a cui è vietato l'accesso tramite 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=0Nota. action=route ha una priorità più alta e viene applicato prima di altre regole di instradamento.
place-before=0 - posiziona la nostra regola prima nell'elenco.
3.2. Configurare una connessione a ISP2.
Poiché il provider ISP2 ci fornisce le impostazioni tramite DHCP, è ragionevole apportare le modifiche necessarie con uno script che si avvia quando viene attivato il 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=noLo script stesso nella finestra Winbox:
Nota. La prima parte dello script viene attivata quando il contratto di locazione viene ottenuto con successo, la seconda - dopo il rilascio del contratto di locazione.Vedi nota 2
3.3. Abbiamo impostato una connessione al provider ISP3.
Dato che il provider delle impostazioni ci fornisce dinamiche, è ragionevole apportare le modifiche necessarie con script che iniziano dopo che l'interfaccia ppp è stata sollevata e dopo la caduta.
3.3.1. Per prima cosa 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 Winbox:
Nota. fila
/ip firewall mangle set [find comment="Connmark in from ISP3"] in-interface=$"interface";
consente di gestire correttamente la ridenominazione dell'interfaccia, poiché funziona con il suo codice e non con il nome visualizzato.
3.3.2. Ora, usando il profilo, crea 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_clientCome tocco finale, impostiamo l'orologio:
/system ntp client set enabled=yes server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.orgPer chi legge fino alla fine
Il modo proposto per implementare un multivan è la preferenza personale dell'autore e non è l'unico possibile. Il toolkit ROS è ampio e flessibile, il che, da un lato, causa difficoltà ai principianti e, dall'altro, è la ragione della sua popolarità. Impara, prova, scopri nuovi strumenti e soluzioni. Ad esempio, come applicazione delle conoscenze acquisite, è possibile sostituire lo strumento in questa implementazione del multivan gateway di controllo con percorsi ricorsivi a NetWatch.
Note
- gateway di controllo - un meccanismo che consente di disattivare il percorso dopo due controlli consecutivi non andati a buon fine del gateway per la disponibilità. Il controllo viene eseguito una volta ogni 10 secondi, più il timeout della risposta. In totale, il tempo di commutazione effettivo è compreso tra 20 e 30 secondi. Se tale tempistica di commutazione non è sufficiente, esiste un'opzione per utilizzare lo strumento NetWatch, dove il timer di controllo può essere impostato manualmente. gateway di controllo non si attiva in caso di perdita intermittente di pacchetti sul collegamento.
Importante! La disattivazione di una route primaria disattiverà tutte le altre route che fanno riferimento ad essa. Pertanto, per loro da indicare check-gateway=ping non necessario.
- Succede che si verifichi un errore nel meccanismo DHCP, che sembra un client bloccato nello stato di rinnovo. In questo caso, la seconda parte dello script non funzionerà, ma non impedirà al traffico di camminare correttamente, poiché lo stato tiene traccia del percorso ricorsivo corrispondente.
- ECMP (percorso multiplo a costo uguale) - in ROS è possibile impostare un percorso con più varchi 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 l'impulso a scrivere l'articolo, aiuta a modellarne la struttura e il posizionamento degli accenti: gratitudine personale a Evgeny
Fonte: habr.com