🥇Multivan und Routing auf Mikrotik RouterOS

Einführung

Die Motivation für diesen Artikel, abgesehen von Eitelkeit, war die besorgniserregende Häufigkeit von Fragen zu diesem Thema in den themenspezifischen Gruppen der russischsprachigen Telegram-Community. Der Artikel richtet sich an Anfänger im Umgang mit Mikrotik RouterOS (im Folgenden ROS). Er behandelt ausschließlich Multinetze mit einem Fokus auf Routing. Als Bonus gibt es minimale, aber ausreichende Einstellungen für einen sicheren und komfortablen Betrieb. Diejenigen, die nach Themen zu Queues, Lastverteilung, VLANs, Bridges, mehrstufiger tiefgreifender Analyse des Kanalzustands und ähnlichem suchen, sollten ihre Zeit und Energie nicht für das Lesen aufwenden.

Stammdaten

Als Testgerät wurde ein fünfportiger Mikrotik-Router der ROS-Version 6.45.3 ausgewählt. Er wird den Verkehr zwischen zwei lokalen Netzwerken (LAN1 und LAN2) und drei Anbietern (ISP1, ISP2, ISP3) routen. Der Kanal zu ISP1 hat eine statische „graue“ Adresse, ISP2 eine „weiße“, die über DHCP bezogen wird, ISP3 hat eine „weiße“ Adresse mit PPPoE-Authentifizierung. Das Anschlussdiagramm ist im Bild dargestellt:

Die Aufgabe ist es, den Router „MTK“ gemäß dem Diagramm so zu konfigurieren, dass:

Ein automatisches Umschalten auf den Backup-Anbieter gewährleistet wird. Der Hauptanbieter ist ISP2, der erste Backup ist ISP1, der zweite Backup ist ISP3.
Netzwerk LAN1 hat nur über ISP1 Zugang zum Internet.
Es soll die Möglichkeit bestehen, den Verkehr von den lokalen Netzwerken über den gewählten Anbieter basierend auf der address-list ins Internet zu routen.
Es soll die Möglichkeit bestehen, Dienste aus dem lokalen Netzwerk ins Internet zu publizieren (DSTNAT).
Ein Firewall-Filter soll eingerichtet werden, um eine minimale Sicherheit aus dem Internet zu gewährleisten.
Der Router soll eigenen Verkehr über einen der drei Anbieter basierend auf der gewählten Quelladresse freigeben können.
Die Routing von Antwortpaketen soll über den Kanal erfolgen, von dem sie gekommen sind (einschließlich LAN).

Anmerkung. Wir werden den Router „von Grund auf neu“ konfigurieren, um Überraschungen bei den sich von Version zu Version ändernden Startkonfigurationen „out of the box“ zu vermeiden. Als Konfigurationstool wurde Winbox gewählt, in dem die Änderungen übersichtlich angezeigt werden. Die Einstellungen selbst werden über Befehle im Winbox-Terminal vorgenommen. Die physische Verbindung für die Konfiguration erfolgt über eine direkte Verbindung mit der Schnittstelle Ether5.

Einige Überlegungen dazu, was ein Multivan ist, ob es ein Problem darstellt oder ob schlaue Köpfe um uns herum Verschwörungstheorien spinnen.

Ein neugieriger und aufmerksamer Admin, der solch eine oder ähnliche Konfiguration eigenständig einrichtet, stellt plötzlich fest, dass es auch ohne diese benutzerdefinierten Routing-Tabellen und anderen Routing-Regeln, die in vielen Artikeln zu diesem Thema vorkommen, gut funktioniert. Überprüfen wir das?

Können wir die Adressierung an den Schnittstellen und die Standard-Gateways einrichten? Ja:

Wir haben die Adresse und das Gateway auf ISP1 eingetragen mit distance=2 und check-gateway=ping.
Bei ISP2 beträgt die Standardkonfiguration des DHCP-Clients — entsprechend ist der Abstand gleich eins.
Bei ISP3 in den PPPoE-Client-Einstellungen bei add-default-route=yes setzen wir default-route-distance=3.

NAT für den Ausgang nicht vergessen:

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

Insgesamt laden die Benutzer in den lokalen Netzen die Katzen fröhlich über den Hauptanbieter ISP2 und es gibt eine Kanalreservierung mithilfe des Mechanismus check gateway Siehe Anmerkung 1

Punkt 1 der Aufgabenstellung ist umgesetzt. Wo bleibt der Multivan mit seinen Labels? Nein…

Weiter. Wir müssen bestimmte Clients aus dem LAN über ISP1 herauslassen:

/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

Die Punkte 2 und 3 der Aufgabenstellung sind umgesetzt. Labels, Markierungen, Routing-Regeln, wo seid ihr?!

Müssen wir den Zugang zu unserem geliebten OpenVPN-Server mit der Adresse 172.17.17.17 für Clients aus dem Internet bereitstellen? Bitte sehr:

/ip cloud set ddns-enabled=yes

Den Clients geben wir als Peer das Ergebnis der Ausgabe: ":put [ip cloud get dns-name]”

Wir richten die Portweiterleitung aus dem Internet ein:

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

Punkt 4 ist bereit.

Wir konfigurieren die Firewall und die gesamte Sicherheit für Punkt 5, während wir uns freuen, dass bei den Benutzern bereits alles funktioniert und wir uns nach einem Getränk sehnen…
Oh! Die Tunnel haben wir auch vergessen.

Der L2TP-Client, der gemäß einem gefundenen Artikel eingerichtet wurde, hat sich mit unserem geliebten niederländischen VDS verbunden? Ja.
Der L2TP-Server mit IPsec ist aktiv, und die Clients verbinden sich über den DNS-Namen aus der IP-Cloud (siehe oben). Ja.
Zurückgelehnt im Stuhl, mit einem Schluck aus dem Getränk, betrachten wir träge die Punkte 6 und 7 der Aufgabe. Denken wir — brauchen wir das wirklich? Es läuft schließlich so schon (mit)… Falls es das also nicht braucht, ist es das. Der Multivan ist implementiert.

Was ist ein Multivan? Das ist die Verbindung mehrerer Internetkanäle zu einem Router.

Den Rest des Artikels kann man sich sparen, denn was außer fraglicher Anwendbarkeit könnte es dort noch geben?

Mit denen, die geblieben sind, die an den Punkten 6 und 7 der Aufgaben interessiert sind und den Perfektionismus verspüren, tauchen wir tiefer ein.

Die wichtigste Aufgabe bei der Implementierung von Multivan ist die korrekte Routenführung des Traffics. Das bedeutet: Unabhängig davon, auf welchen (oder welche) Quellen der Standardroute unseres Routers verweist, muss die Antwort genau über den Kanal zurückgegeben werden, von dem das Paket kam. Die Aufgabe ist klar. Wo liegt das Problem? Denn in einem einfachen lokalen Netzwerk ist die Aufgabe die gleiche, aber niemand macht sich mit zusätzlichen Einstellungen den Kopf darüber, und es gibt keine Schwierigkeiten. Der Unterschied liegt darin, dass jeder routierbare Knoten im Internet über jeden unserer Kanäle zugänglich ist und nicht nur über einen bestimmten, wie in einem einfachen lokalen Netzwerk. Und das Problem besteht darin, dass, wenn eine Anfrage an die IP-Adresse ISP3 gerichtet wird, die Antwort in unserem Fall über den Kanal ISP2 gesendet wird, da dort das Standardgateway verweist. Es wird gesendet und vom Provider als ungültig abgelehnt. Das Problem ist erkannt. Wie lässt sich das lösen?

Die Lösung werden wir in drei Phasen unterteilen:

Vorbereitungseinstellungen. In dieser Phase werden die grundlegenden Einstellungen des Routers festgelegt: lokales Netzwerk, Firewall, Adresslisten, Hairpin NAT usw.
Multivan. In dieser Phase werden die benötigten Verbindungen markiert und nach Routing-Tabellen sortiert.
Verbindung zu ISP. In dieser Phase werden die Schnittstellen konfiguriert, die die Internetverbindung sicherstellen, Routing aktiviert und der Mechanismus für die Backup-Kanäle im Internet aktiviert.

1. Vorbereitungseinstellungen

1.1. Wir löschen die Konfiguration des Routers mit dem Befehl:

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

wir stimmen zu mit “Dangerous! Reset anyway? [y/N]:” und verbinden uns nach dem Neustart über MAC mit Winbox. In dieser Phase sind die Konfiguration und die Benutzerdatenbank gelöscht.

1.2. Wir erstellen einen neuen Benutzer:

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

wir loggen uns mit ihm ein und löschen den Standardbenutzer:

/user remove admin

Anmerkung. Die Autorin betrachtet das Löschen und nicht das Deaktivieren des Standardbenutzers als sicherer und empfiehlt dies zur Anwendung.

1.3. Wir erstellen grundlegende Interface-Listen zur vereinfachten Handhabung in der Firewall, den Discovery-Einstellungen und anderen MAC-Servern:

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

Wir kommentieren die Schnittstellen

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

und fügen die Schnittstellenlisten hinzu:

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

Anmerkung. Es lohnt sich, verständliche Kommentare zu schreiben, die die aufgewendete Zeit rechtfertigen und das Troubleshooting sowie das Verständnis der Konfiguration erheblich erleichtern.

Der Autor hält es für notwendig, aus Sicherheitsgründen das Interface ether3 zur Interface-Liste „WAN“ hinzuzufügen, obwohl über es kein IP-Protokoll laufen wird.

Wir vergessen nicht, dass, nachdem das PPP-Interface auf ether3 hochgefahren wurde, es ebenfalls in die Interface-Liste „WAN“ aufgenommen werden muss.

1.4. Den Router vor Entdeckung durch Nachbarknoten und Verwaltung aus den Anbieternetzen über MAC verstecken:

/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. Erstellen eines minimalen Satzes von Firewall-Regeln zum Schutz des Routers:

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

(Die Regel erlaubt Verbindungen, die etabliert und verwandt sind, und die sowohl aus den verbundenen Netzwerken als auch vom Router selbst initiiert werden)

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

(Ping und nicht nur Ping. Vollständiger ICMP-Verkehr ist eingehend erlaubt. Sehr nützlich zur Problemlösung bei MTU)

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

(Die schließende Regel für die Eingabekette verbietet alles andere, was aus dem Internet kommt)

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

(Die Regel erlaubt etablierte und verwandte Verbindungen, die durch den Router hindurchgehen)

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

(Die Regel setzt die Verbindungen mit connection-state=invalid, die durch den Router hindurchgehen, zurück. Sie wird von Mikrotik dringend empfohlen, kann jedoch in einigen seltenen Fällen nützlichen Verkehr blockieren)

/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

(Die Regel verbietet Paketen, die aus dem Internet kommen und nicht das dstnat-Verfahren durchlaufen haben, durch den Router hindurchzugehen. Dies schützt lokale Netzwerke vor Angreifern, die sich im selben Broadcast-Domain wie unsere externen Netzwerke befinden, indem sie unsere externen IP-Adressen als Gateways eintragen und somit versuchen, unsere lokalen Netzwerke zu „erkunden“.)

Anmerkung. Nehmen wir an, dass die Netzwerke LAN1 und LAN2 vertrauenswürdig sind und der Verkehr zwischen ihnen und von ihnen nicht gefiltert wird.

1.6. Erstellen einer Liste mit nicht routierbaren Netzwerken:

/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

(Dies ist eine Liste von Adressen und Netzwerken, die nicht ins Internet geroutet werden, und entsprechend werden auch wir dies befolgen.)

Anmerkung. Die Liste kann sich ändern, deshalb rate ich, sie regelmäßig auf Aktualität zu überprüfen.

1.7. DNS für den Router selbst konfigurieren:

/ip dns set servers=1.1.1.1,8.8.8.8

Anmerkung. In der aktuellen ROS-Version sind dynamische Server haben Vorrang vor statisch zugewiesenen. Die Anfrage zur Namensauflösung wird an den ersten Server in der Reihenfolge der Liste gesendet. Der Wechsel zum nächsten Server erfolgt bei Nichterreichbarkeit des aktuellen. Die Zeitüberschreitung ist groß – über 5 Sekunden. Ein Rückfall, bei Wiederaufnahme des „gestürzten Servers“, erfolgt nicht automatisch. Unter Berücksichtigung dieses Algorithmus und der Verfügbarkeit von Multivan empfiehlt der Autor, keine Server zu verwenden, die von Anbietern bereitgestellt werden.

1.8. Lokales Netzwerk einrichten.
1.8.1. Statische IP-Adressen auf den Schnittstellen der lokalen Netzwerke konfigurieren:

/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. Regeln für Routen zu unseren lokalen Netzwerken über die Haupt-Routing-Tabelle festlegen:

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

Anmerkung. Dies ist eine der einfachen und schnellen Möglichkeiten, um auf die Adressen der lokalen Netzwerke mit Quellen von externen IP-Adressen der Router-Schnittstellen zuzugreifen, über die kein Standardroute läuft.

1.8.3. Hairpin NAT für LAN1 und LAN2 aktivieren:

/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

Anmerkung. Dies ermöglicht den Zugriff auf eigene Ressourcen (dstnat) über die externe IP, während man sich im Netzwerk befindet.

2. Tatsächlich die Implementierung des korrekten Multivan

Um die Aufgabe „dorthin antworten, wo gefragt wurde“ zu lösen, verwenden wir zwei ROS-Tools: connection mark und routing mark. Connection mark ermöglicht es, die gewünschte Verbindung zu kennzeichnen und diese Markierung später als Bedingung für die Anwendung zu verwenden. routing mark. Und bereits mit routing mark kann man arbeiten in ip route und route rules. Mit den Werkzeugen sind wir vertraut, jetzt müssen wir entscheiden, welche Verbindungen wir kennzeichnen – erstens, wo genau wir kennzeichnen – zweitens.

Mit dem ersten ist alles einfach – wir müssen alle Verbindungen kennzeichnen, die von Internet über den entsprechenden Kanal zum Router kommen. In unserem Fall werden es drei Markierungen sein (nach der Anzahl der Kanäle): „conn_isp1“, „conn_isp2“ und „conn_isp3“.

Der Hinweis beim zweiten besteht darin, dass eingehende Verbindungen zwei Arten sein werden: Transit- und solche, die für den Router selbst bestimmt sind. Der Mechanismus connection mark funktioniert in der Tabelle mangle. Betrachten wir die Paketbewegung in einem vereinfachten Diagramm, das freundlicherweise von den Spezialisten der Ressource mikrotik-trainings.com erstellt wurde (keine Werbung):

Folgt man den Pfeilen, sehen wir, dass das Paket, das am "input interface", ankommt, den „Prerouting"-Pfad durchläuft und erst dann im Block „Routing Decision" in Transit- und lokale Pakete unterteilt wird. Daher, um zwei Fliegen mit einer Klappe zu schlagen, verwenden wir Connection Mark in der Tabelle Mangle Prerouting Chain Prerouting.

Hinweis. In ROS sind die „Routing-Markierungen“ im Abschnitt Ip/Routes/Rules als „Tabelle“ angegeben, während sie in den anderen Abschnitten als „Routing-Markierung“ erscheinen. Das kann zu Verwirrung führen, aber im Grunde genommen ist es dasselbe und entspricht rt_tables in iproute2 auf Linux.

2.1. Wir kennzeichnen eingehende Verbindungen von jedem der Anbieter:

/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

Anmerkung. Um bereits gekennzeichnete Verbindungen nicht erneut zu kennzeichnen, verwende ich die Bedingung connection-mark=no-mark anstelle von connection-state=new, da ich das für korrekter halte, ebenso wie den Verzicht auf das Drop invalid von Verbindungen im Input-Filter.

passthrough=no — weil bei dieser Implementierungsweise die Neu-Kennzeichnung ausgeschlossen ist und der Regelabgleich zur Geschwindigkeit nach der ersten Übereinstimmung abgebrochen werden kann.

Es sollte beachtet werden, dass wir bisher nicht in die Routing-Logik eingreifen. Wir befinden uns aktuell nur in der Vorbereitungsphase. Der nächste Schritt in der Implementierung wird die Verarbeitung von Transitdatenverkehr sein, die über eine etablierte Verbindung vom Empfänger im lokalen Netzwerk zurückfließen. D.h. die Pakete, die (siehe Diagramm) durch den Router auf dem Weg:

„Input Interface“=>„Prerouting“=>„Routing Decision“=>„Forward“=>„Post Routing“=>„Output Interface“ und ihr Ziel im lokalen Netzwerk erreichen.

Wichtig! In ROS gibt es keine logische Trennung zwischen externen und internen Schnittstellen. Wenn man den Weg des Antwortpakets anhand des angegebenen Diagramms verfolgt, durchläuft es denselben logischen Pfad wie die Anfrage:

„Input Interface“=>„Prerouting“=>„Routing Decision“=>„Forward“=>„Post Routing“=>„Output Interface“ einfach für die Anfrage „Input Interface“ war die Schnittstelle ISP, und für die Antwort — LAN.

2.2. Wir leiten den antwortenden Transitverkehr über die entsprechenden Routing-Tabellen:

/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

Anmerkung. in-interface-list=!WAN — wir arbeiten nur mit dem Verkehr aus dem lokalen Netzwerk und dst-address-type=!local, der keine Zieladresse der Schnittstellen des Routers selbst hat.

Das Gleiche gilt für lokale Pakete, die am Router auf dem Weg angekommen sind:

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

Wichtig! Die Antwort wird folgendem Pfad folgen:

„Local Process“=>„Routing Decision“=>„Output“=>„Post Routing“=>„Output Interface“

2.3. Wir leiten den antwortenden lokalen Verkehr über die entsprechenden Routing-Tabellen:

/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 dieser Phase kann die Aufgabe der Vorbereitung für die Rücksendung der Antwort über den Kanal ins Internet, von dem die Anfrage kam, als gelöst betrachtet werden. Alles ist gekennzeichnet, markiert und bereit zum Routing.
Ein hervorragender „Nebeneffekt“ dieser Einstellung ist die Möglichkeit, DSNAT-Portweiterleitungen von beiden Anbietern (ISP2, ISP3) gleichzeitig zu nutzen. Nicht bei allen, da wir bei ISP1 keine routierbare Adresse haben. Dieser Effekt ist wichtig, zum Beispiel für einen Mailserver mit zwei MX, die in verschiedene Internetkanäle schauen.

Um die Problematik der lokalen Netzwerke mit externen IPs des Routers zu beseitigen, nutzen wir Lösungen aus den Punkten 1.8.2 und 3.1.2.6.

Außerdem kann ein Werkzeug mit Markierungen aktiviert werden, um Punkt 3 der Aufgabe zu lösen. Wir setzen dies so um:

2.4. Wir leiten den Datenverkehr von den lokalen Clients aus den Routing-Listen in die entsprechenden Tabellen:

/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

So sieht das Ergebnis ungefähr aus:

3. Wir konfigurieren die Verbindung zu ISP und aktivieren die Routing nach Markierungen.

3.1. Wir konfigurieren die Verbindung zu ISP1:
3.1.1. Wir konfigurieren die statische IP-Adresse:

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

3.1.2. Wir konfigurieren das statische Routing:
3.1.2.1. Wir fügen eine „Notfall“-Standardroute hinzu:

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

Anmerkung. Diese Route ermöglicht es dem Datenverkehr von lokalen Prozessen, die Route Decision unabhängig vom Zustand der Kanäle eines der Anbieter zu durchlaufen. Der Knackpunkt beim ausgehenden lokalen Datenverkehr ist, dass eine aktive Route zum Standardgateway in der Haupt-Routingtabelle vorhanden sein muss, damit ein Paket irgendwohin weitergeleitet wird. Gibt es diese nicht, wird das Paket einfach verworfen.

Als Erweiterung des Werkzeugs check gateway für eine tiefere Analyse des Kanalzustands schlage ich vor, die Methode der rekursiven Routen zu verwenden. Der Kern dieser Methode besteht darin, dass wir dem Router anweisen, den Weg zu seinem Gateway nicht direkt, sondern über ein Zwischen-Gateway zu suchen. Als solche „Überprüfungs“-Gateways werden 4.2.2.1, 4.2.2.2 und 4.2.2.3 für ISP1, ISP2 und ISP3 ausgewählt.

3.1.2.2. Route zur „Überprüfungs“-Adresse:

/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

Anmerkung. Wir reduzieren den Scope-Wert auf den Standardwert in der ROS-Zielscope, um 4.2.2.1 später als rekursives Gateway zu verwenden. Ich betone: Der Scope der Route zur „Überprüfungs“-Adresse muss kleiner oder gleich dem Ziel-Scope der Route sein, die auf die Überprüfung verweist.

3.1.2.3. Rekursive Standardroute für Datenverkehr ohne Routingmarke:

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

Anmerkung. Der Wert distance=2 wird verwendet, da ISP1 laut Aufgabenstellung als erster Backup angegeben ist.

3.1.2.4. Rekursive Standardroute für Datenverkehr mit Routingmarke „to_isp1“:

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

Anmerkung. Eigentlich beginnen wir hier endlich, die Früchte der vorbereitenden Arbeit zu nutzen, die in Punkt 2 geleistet wurde.

Auf dieser Route wird der gesamte Verkehr, der das Markierungsroute “to_isp1” hat, unabhängig davon, welches Gateway gerade als Standardgateway für die Haupttabelle aktiv ist, zum Gateway des ersten Anbieters geleitet.

3.1.2.5. Die erste Backup-rekursiv-Standardroute für markierten Verkehr der Anbieter ISP2 und 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

Anmerkung. Diese Routen sind auch erforderlich, um den Verkehr von lokalen Netzwerken zu reservieren, die Mitglieder der Adressenliste “to_isp*” sind.

3.1.2.6. Wir konfigurieren die Route für den lokalen Routerverkehr zum Internet über ISP1:

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

Anmerkung. In Kombination mit den Regeln aus Punkt 1.8.2 wird der Zugang zum gewünschten Kanal mit festgelegt. Dies ist kritisch für den Aufbau von Tunneln, in denen die IP-Adresse der lokalen Seite festgelegt wird (EoIP, IP-IP, GRE). Da die Regeln in ip route rules von oben nach unten ausgeführt werden, bis zur ersten Übereinstimmung der Bedingungen, muss diese Regel nach den Regeln aus Punkt 1.8.2 stehen.

3.1.3. Wir erstellen eine NAT-Regel für den ausgehenden Verkehr:

/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

Anmerkung. NATt alle ausgehenden Verbindungen, außer denjenigen, die unter die IPsec-Richtlinien fallen. Ich versuche, action=masquerade nicht ohne zwingenden Grund zu verwenden. Es arbeitet langsamer und ist ressourcenintensiver als src-nat, da für jede neue Verbindung die Adresse für NAT berechnet wird.

3.1.4. Wir senden die Kunden aus der Liste, denen der Zugang über die anderen Anbieter verboten ist, sofort zum Gateway des Anbieters 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

Anmerkung. action=route hat eine höhere Priorität und wird vor den anderen Routing-Regeln angewendet.

place-before=0 — platziert unsere Regel an erster Stelle in der Liste.

3.2. Wir konfigurieren die Verbindung zu ISP2.

Da der Anbieter ISP2 uns die Konfiguration über DHCP zur Verfügung stellt, ist es sinnvoll, die erforderlichen Änderungen mit einem Skript vorzunehmen, das beim Auslösen des DHCP-Clients gestartet wird:

/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

Das Skript im Winbox-Fenster:

Anmerkung. Der erste Teil des Skripts wird ausgeführt, wenn die Miete erfolgreich erhalten wurde, der zweite — nach der Freigabe der Miete.Siehe Hinweis 2

3.3. Wir konfigurieren die Verbindung zum Anbieter ISP3.

Da der Anbieter uns dynamische Einstellungen zur Verfügung stellt, ist es sinnvoll, die erforderlichen Änderungen mit Skripten vorzunehmen, die nach dem Hoch- und Herunterfahren der PPP-Schnittstelle gestartet werden.

3.3.1. Zuerst konfigurieren wir das Profil:

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

Das Skript im Winbox-Fenster:

Anmerkung. Zeichenkette
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
ermöglicht die korrekte Verarbeitung der Umbenennung der Benutzeroberfläche, da sie mit ihrem Code und nicht mit dem angezeigten Namen arbeitet.

3.3.2. Nun erstellen wir unter Verwendung des Profils eine ppp-Verbindung:

/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

Als letzten Schliff konfigurieren wir die Uhr:

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

Für diejenigen, die bis zum Ende gelesen haben

Die vorgeschlagene Implementierung des Multivans ist eine persönliche Präferenz des Autors und stellt nicht die einzige Möglichkeit dar. Die ROS-Toolchain ist umfangreich und flexibel, was einerseits für Anfänger komplex ist, andererseits jedoch der Grund für ihre Beliebtheit. Lernen Sie, experimentieren Sie, entdecken Sie neue Werkzeuge und Lösungen für sich. Beispielsweise kann in dieser Implementierung des Multivans das Werkzeug Check-gateway mit rekursiven Routen durch Netwatch.

Anmerkungen

Check-gateway — ein Mechanismus, der es ermöglicht, eine Route nach zwei aufeinanderfolgenden fehlgeschlagenen Überprüfungen des Gateways auf Erreichbarkeit zu deaktivieren. Die Überprüfung erfolgt alle 10 Sekunden, plus Timeout für die Antwort. Insgesamt liegt der tatsächliche Timingwechsel im Bereich von 20 bis 30 Sekunden. Wenn dieser Timingwechsel nicht ausreichend ist, kann das Werkzeug Netwatch, wo der Überprüfungs-Timer manuell festgelegt werden kann. Der Mechanismus Check-gateway greift nicht bei sporadischen Paketverlusten im Kanal.
Wichtig! Die Deaktivierung der Hauptroute führt zur Deaktivierung aller anderen Routen, die auf sie verweisen. Daher ist es für sie nicht notwendig, check-gateway=ping anzugeben.
Es kommt vor, dass es im Mechanismus der DHCP-Arbeit zu einem Fehler kommt, der wie ein Client aussieht, der im Zustand renew hängt. In diesem Fall wird der zweite Teil des Skripts nicht ausgeführt, aber der Verkehr kann trotzdem ordnungsgemäß weiterfließen, da der Zustand die entsprechende rekursive Route überwacht.
ECMP (Equal Cost Multi-Path) — in ROS gibt es die Möglichkeit, eine Route mit mehreren Gateways und gleicher Distanz festzulegen. In diesem Fall werden die Verbindungen mit Hilfe des Round-Robin-Algorithmus proportional zur Anzahl der angegebenen Gateways auf die Kanäle verteilt.

Für den Anstoß zum Schreiben des Artikels, die Hilfe bei der Strukturierung und dem Setzen von Akzenten — mein persönlicher Dank gilt Jewgenij @jscar

Quelle: habr.com