🥇Multiview und Routing auf Mikrotik RouterOS

Einführung

Die Motivation für diesen Artikel, abgesehen von Eitelkeit, war die bedauerlich hohe Anzahl an Fragen zu diesem Thema in den Fachgruppen der russischsprachigen Telegram-Community. Der Artikel richtet sich an angehende Administratoren von Mikrotik RouterOS (im Folgenden ROS). Es wird sich ausschließlich mit dem Multipath beschäftigt, wobei der Fokus auf der Routing-Technologie liegt. Als Bonus gibt es minimal notwendige Einstellungen für eine sichere und benutzerfreundliche Nutzung. Wer sich mit den Themen Warteschlangen, Lastverteilung, VLANs, Bridges, mehrstufiger Tiefenanalyse des Kanalstatus usw. befassen möchte, sollte sich die Zeit und Mühe für das Lesen sparen.

Rohdaten

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

Die Aufgabe besteht darin, den Router “MTK” gemäß dem Diagramm so einzurichten, dass:

Stellen Sie die automatische Umschaltung auf den Backup-Anbieter sicher. Hauptanbieter ist ISP2, erster Backup ist ISP1, zweiter Backup ist ISP3.
Organisieren Sie den Zugang von LAN1 zum Internet ausschließlich über ISP1.
Stellen Sie die Möglichkeit bereit, den Datenverkehr aus lokalen Netzwerken über den ausgewählten Anbieter basierend auf der Adressliste ins Internet zu routen.
Stellen Sie die Möglichkeit zur Veröffentlichung von Diensten aus dem lokalen Netzwerk im Internet (DSTNAT) sicher.
Konfigurieren Sie den Firewall-Filter, um ein Minimum an Sicherheit gegenüber dem Internet zu gewährleisten.
Der Router sollte in der Lage sein, eigenen Datenverkehr über jeden der drei Anbieter abhängig von der ausgewählten Quelladresse auszugeben.
Sorgen Sie für die Rückleitung von Antwortpaketen an den Kanal, aus dem sie gekommen sind (einschließlich LAN).

Hinweis. Wir konfigurieren den Router „von Grund auf“, um Überraschungen bei den wechselnden Startkonfigurationen von Version zu Version zu vermeiden. Als Konfigurationstool haben wir Winbox ausgewählt, in dem die Änderungen anschaulich dargestellt werden. Die Einstellungen werden über Befehle im Winbox-Terminal vorgenommen. Die physische Verbindung zur Konfiguration erfolgt über eine direkte Verbindung mit dem Ether5-Schnittstelle.

Einige Überlegungen dazu, was ein Multi-WAN ist, ob es ein Problem darstellt oder ob schlauere Köpfe sich in Verschwörungsnetzen verstricken.

Ein neugieriger und aufmerksamer Administrator, der ein solches oder ähnliches Setup selbst konfiguriert, wird plötzlich feststellen, dass es auch so gut funktioniert. Ja, ohne diese benutzerdefinierten Routing-Tabellen und anderen Routing-Regeln, die die meisten Artikel zu diesem Thema füllen. Überprüfen wir das?

Können wir die Adressierung an den Schnittstellen und die Standardgateways konfigurieren? Ja:

Auf ISP1 haben wir die Adresse und das Gateway mit distance=2 und check-gateway=ping.
Auf ISP2 wird der DHCP-Client standardmäßig konfiguriert – entsprechend wird die Distance gleich Eins sein.
Auf ISP3 in den PPPoE-Client-Einstellungen bei add-default-route=yes stellen wir default-route-distance=3.

Vergessen Sie nicht, NAT für den Ausgang zu konfigurieren:

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

Insgesamt laden die Benutzer der lokalen Server fröhlich über den Hauptanbieter ISP2, und es gibt eine Kanalreserve dank des Mechanismus. Gateway überprüfen Siehe Fußnote 1

Aufgabe Punkt 1 wurde umgesetzt. Wo ist der Multivan mit seinen Tags? Nein...

Weiter. Es ist notwendig, bestimmte Clients aus dem LAN über ISP1 zu leiten:

/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

Punkte 2 und 3 der Aufgabe wurden umgesetzt. Tags, Markierungen, Routenregeln, wo seid ihr?!

Müssen wir den Zugang zum beliebten OpenVPN-Server mit der Adresse 172.17.17.17 für Clients aus dem Internet bereitstellen? Hier ist er:

/ip cloud set ddns-enabled=yes

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

Portweiterleitung aus dem Internet eintragen:

/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 fertig.

Wir konfigurieren die Firewall und andere Sicherheitsvorkehrungen für Punkt 5 und freuen uns gleichzeitig darüber, dass alles bei den Benutzern bereits funktioniert, während wir uns dem Behälter mit dem Lieblingsgetränk nähern...
Ach, die Tunnel haben wir auch vergessen.

Der L2TP-Client, der nach einem gefundenen Artikel konfiguriert wurde, konnte sich mit dem bevorzugten niederländischen VDS verbinden? Ja.
Der L2TP-Server mit IPsec wurde hochgefahren, und die Clients verbinden sich über den DNS-Namen aus der IP-Cloud (siehe oben)? Ja.
Lehnen Sie sich zurück und nippen Sie an Ihrem Getränk, während Sie in aller Ruhe die Punkte 6 und 7 der Aufgabe betrachten. Fragen Sie sich – benötigen wir das wirklich? Es funktioniert doch alles auch so (sc)… Wenn es also nicht nötig ist, dann war es das. Multivan ist implementiert.

Was ist Multivan? Es ist die Verbindung mehrerer Internetkanäle zu einem einzigen Router.

Den Artikel müssen Sie nicht weiter lesen, denn was gibt es dort außer fragwürdiger Prahlerei und geringer Anwendbarkeit?

Mit denen, die geblieben sind und an den Punkten 6 und 7 der Aufgabe interessiert sind und das Bedürfnis nach Perfektion verspüren, gehen wir tiefer.

Eine der wichtigsten Herausforderungen bei der Implementierung von Multivan ist die korrekte Verkehrsrouting. Das bedeutet: Unabhängig davon, über welchen (oder welche) Kanal(e) der Anbieter den Standardroute auf unserem Router anzeigt, muss die Antwort genau über den Kanal zurückgegeben werden, von dem das Paket gesendet wurde. Die Aufgabe ist klar. Wo liegt das Problem? In einem einfachen lokalen Netzwerk ist die Aufgabe die gleiche, aber niemand stört sich an zusätzlichen Einstellungen und verspürt keine Schwierigkeiten. Der Unterschied besteht darin, dass jeder routierbare Knoten im Internet über jeden unserer Kanäle zugänglich ist, und nicht nur über einen bestimmten, wie es in einem einfachen Netzwerk der Fall ist. Das „Problem“ liegt darin, dass, wenn eine Anfrage an die IP-Adresse ISP3 gerichtet wird, die Antwort in unserem Fall über den Kanal ISP2 gesendet wird, da dieser der Standardgateway ist. Sie wird verworfen, weil der Anbieter sie als ungültig ansieht. Wir haben das Problem identifiziert. Wie lösen wir es?

Wir unterteilen die Lösung in drei Phasen:

Vorbereitung. In dieser Phase werden die grundlegenden Einstellungen des Routers konfiguriert: lokales Netzwerk, Firewall, Adresslisten, Hairpin NAT usw.
Multivan. In diesem Schritt werden die erforderlichen Verbindungen gekennzeichnet und nach Routing-Tabellen sortiert.
Verbindung zum ISP. In diesem Schritt werden die Schnittstellen konfiguriert, die die Internetverbindung herstellen, sowie die Routing- und Backup-Mechanismen für Internetverbindungen aktiviert.

1. Vorbereitende Einrichtung

1.1. Wir löschen die Router-Konfiguration 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. Zu diesem Zeitpunkt 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 melden uns bei ihm an und entfernen den Standardbenutzer:

/user remove admin

Hinweis. Die Autorin betrachtet das Entfernen des Standardbenutzers, und nicht dessen Deaktivierung, als sicherer und empfiehlt dies.

1.3. Wir erstellen grundlegende Interface-Listen zur Vereinfachung der Bedienung im Firewall, der 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 Schnittlisten 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"

Hinweis. Es lohnt sich, verständliche Kommentare zu schreiben; die Zeit dafür ist gut investiert und erleichtert die Fehlersuche sowie das Verständnis der Konfiguration erheblich.

Der Autor hält es für notwendig, aus Sicherheitsgründen die Schnittstelle 'WAN' mit ether3 in die Schnittstellenliste aufzunehmen, obwohl kein IP-Protokoll darüber laufen wird.

Vergessen Sie nicht, dass, nachdem die PPP-Schnittstelle auf ether3 aktiviert wurde, diese ebenfalls in die Schnittstellenliste 'WAN' aufgenommen werden muss.

1.4. Den Router vor Erkennung durch Nachbarschaft und Verwaltung aus den Netzwerken der Anbieter durch MAC-Adressen verbergen:

/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 Sie eine minimal ausreichende Sammlung 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

(Diese Regel erlaubt die Verbindungen, 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. Sämtlicher ICMP-Verkehr ist eingehend erlaubt. Dies ist sehr nützlich zur Erkennung von MTU-Problemen.)

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

(Die schließende Regel für die Eingangsverkettung verbietet alles andere, was aus dem Internet ankommt.)

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

(Diese Regel erlaubt etablierte und verwandte Verbindungen, die den Router durchlaufen.)

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

(Diese Regel setzt Verbindungen mit connection-state=invalid zurück, die den Router durchlaufen. Sie wird von Mikrotik dringend empfohlen, kann jedoch in einigen seltenen Fällen nützlichen Datenverkehr 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 verhindert, dass Pakete, die aus dem Internet kommen und das Verfahren der dstnat nicht durchlaufen haben, den Router passieren. Dies schützt lokale Netzwerke vor Angreifern, die sich im selben Broadcast-Domain wie unsere externen Netzwerke befinden und unsere externen IPs als Gateways verwenden, um unsere lokalen Netzwerke zu „erkunden“.)

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

1.6. Wir erstellen eine 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 der wir auch folgen werden.)

Hinweis. Die Liste kann sich ändern, daher empfehle ich, die Aktualität regelmäßig zu überprüfen.

1.7. Wir konfigurieren DNS für den Router selbst:

/ip dns set servers=1.1.1.1,8.8.8.8

Hinweis. In der aktuellen Version von ROS sind dynamische Server haben Vorrang vor statisch festgelegten. Die Namensauflösungsanfrage wird an den ersten Server in der Reihenfolge der Liste gesendet. Bei Nichterreichbarkeit des aktuellen Servers wird zum nächsten Server gewechselt. Die Timeout-Zeit ist groß — mehr als 5 Sekunden. Ein Rückwechsel, nachdem der "ausgefallene Server" wieder in Betrieb genommen wurde, erfolgt automatisch nicht. Unter Berücksichtigung dieses Algorithmus und der Verfügbarkeit des Multihoming wird empfohlen, keine von den Anbietern bereitgestellten Server zu nutzen.

1.8. Wir konfigurieren das lokale Netzwerk.
1.8.1. Wir konfigurieren statische IP-Adressen an den Schnittstellen der lokalen Netzwerke:

/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. Wir setzen Routenregeln für unsere lokalen Netzwerke über die Haupt-Routingtabelle:

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

Hinweis. Dies ist eine der einfachen und schnellen Methoden, um auf die Adressen der lokalen Netzwerke von externen IP-Adressen der Router-Schnittstellen zuzugreifen, durch die keine Standardroute läuft.

1.8.3. Wir aktivieren Hairpin NAT für LAN1 und 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

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

2. Tatsächlich die korrekte Implementierung des Multihoming.

Um die Aufgabe "antworten, woher gefragt wurde" zu lösen, verwenden wir zwei ROS-Tools: Verbindungsmarkierung und Routing-Markierung. Verbindungsetikett ermöglicht das Markieren der gewünschten Verbindung und späteres Arbeiten mit diesem Etikett als Bedingung für die Anwendung Routing-Markierung. Und schon mit Routing-Markierung kann gearbeitet werden in ip route und Routing-Regeln. Nachdem wir die Werkzeuge geklärt haben, müssen wir nun entscheiden, welche Verbindungen markiert werden sollen — erstens, wo genau markiert werden soll — zweitens.

Beim ersten Punkt ist es einfach — wir müssen alle Verbindungen markieren, die am Router von Internet über den entsprechenden Kanal eintreffen. In unserem Fall werden das drei Etiketten sein (entsprechend der Anzahl der Kanäle): “conn_isp1”, “conn_isp2” und “conn_isp3”.

Die Nuance beim zweiten Punkt besteht darin, dass eingehende Verbindungen zwei Arten haben: Transitverbindungen und solche, die für den Router selbst gedacht sind. Der Mechanismus der Verbindungsmarkierung funktioniert in der Tabelle mangle. Betrachten wir die Paketanalyse anhand eines vereinfachten Diagramms, das von Experten der Webseite mikrotik-trainings.com bereitgestellt wurde (keine Werbung):

Folgt man den Pfeilen, sieht man, dass das Paket, das im “Eingangsinterface” ankommt, über die Kette “Prerouting” geht und erst danach im Block “Routing-Entscheidung” in Transit- und lokale Pakete aufgeteilt wird. Daher nutzen wir, um zwei Fliegen mit einer Klappe zu schlagen, Verbindungsmarkierung in der Tabelle Mangle Prerouting Ketten Prerouting.

Hinweis. In ROS werden die „Routing-Marken“ im Abschnitt Ip/Routes/Rules als „Tabelle“ aufgeführt, während sie in anderen Abschnitten als „Routing-Marke“ bezeichnet werden. Das kann zu etwas 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

Hinweis. Um nicht bereits gekennzeichnete Verbindungen zu markieren, 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 die Kennzeichnung ungültiger Verbindungen im Input-Filter.

passthrough=no – da diese Implementierungsweise eine Neumarkierung ausschließt und zur Beschleunigung die Regelverarbeitung nach der ersten Übereinstimmung unterbrochen werden kann.

Es ist zu beachten, dass wir bisher noch nicht in die Routing-Prozesse eingreifen. Derzeit sind nur die Vorbereitungsphasen im Gange. Der nächste Schritt der Implementierung wird die Verarbeitung des Transitverkehrs sein, der über eine bestehende Verbindung vom Empfänger im lokalen Netzwerk zurückkommt. Also die Pakete, die (siehe Diagramm) den Router auf dem Weg durchlaufen haben:

„Input Interface“=>„Prerouting“=>„Routing Decision“=>„Forward“=>„Post Routing“=>„Output Interface“ und an ihren Empfänger im lokalen Netzwerk gelangt sind.

Wichtig! In ROS gibt es keine logische Trennung zwischen externen und internen Schnittstellen. Wenn man den Pfad der Antwortpakete in dem gegebenen Diagramm verfolgt, wird er denselben logischen Weg wie die Anfrage durchlaufen:

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

2.2. Leiten Sie den Antwort-Transitverkehr gemäß den 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

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

Das Gleiche gilt für lokale Pakete, die zum Router folgendermaßen gekommen sind:

“Eingangsschnittstelle”=>”Prerouting”=>”Routing-Entscheidung”=>”Eingang”=>”Lokaler Prozess”

Wichtig! Die Antwort wird den folgenden Weg nehmen:

”Lokaler Prozess”=>”Routing-Entscheidung”=>”Ausgang”=>”Post-Routing”=>”Ausgangsschnittstelle”

2.3. Leiten Sie den lokalen Antwortverkehr gemäß den 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 diesem Schritt kann die Aufgabe, die Antwort über den Kanal ins Internet zu senden, von dem die Anfrage kam, als gelöst angesehen werden. Alles ist markiert, gekennzeichnet und bereit zum Routen.
Ein hervorragender „Neben“effekt dieser Konfiguration ist die Möglichkeit, DSNAT-Portweiterleitungen gleichzeitig von beiden (ISP2, ISP3) Anbietern zu nutzen. Bei allen Anbietern ist dies jedoch nicht möglich, da wir bei ISP1 eine nicht routierbare Adresse haben. Dieser Effekt ist beispielsweise wichtig für einen Mailserver mit zwei MX, die auf unterschiedliche Internetkanäle zeigen.

Zur Behebung der Besonderheiten des Betriebs lokaler Netzwerke mit externen IPs des Routers verwenden wir Lösungen aus den Punkten 1.8.2 und 3.1.2.6.

Außerdem kann ein Werkzeug mit Markierungen zur Lösung des dritten Punktes der Aufgabenstellung eingesetzt werden. Wir setzen dies so um:

2.4. Wir leiten den Verkehr von 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

Insgesamt sieht das etwa so aus:

3. Wir konfigurieren die Verbindung zu ISP und aktivieren die Routing-Logik.

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 richten die statische Routing ein:
3.1.2.1. Wir fügen die „Notfall“-Standardroute hinzu:

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

Hinweis. Dieser Pfad ermöglicht es, dass der Datenverkehr von lokalen Prozessen die Route Decision unabhängig vom Status der Verbindungen eines der Anbieter durchläuft. Der entscheidende Punkt beim ausgehenden lokalen Datenverkehr ist, dass ein aktiver Pfad zum Standardgateway in der Haupt-Routingtabelle vorhanden sein muss, damit ein Paket irgendwohin weitergeleitet werden kann. Fehlt dieser, wird das Paket einfach verworfen.

Als Erweiterung des Werkzeugs Gateway überprüfen für eine tiefere Analyse des Verbindungsstatus schlage ich vor, die Methode der rekursiven Routen zu verwenden. Bei dieser Methode weisen wir den Router an, den Weg zu seinem Gateway nicht direkt, sondern über ein Zwischen-Gateway zu suchen. Die „Überprüfungs“-Gateways sind 4.2.2.1, 4.2.2.2 und 4.2.2.3 für ISP1, ISP2 und ISP3.

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

Hinweis. Den Scope-Wert senken wir auf den Standardwert im ROS Zielscope, um in Zukunft 4.2.2.1 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. Standardrekursiver Pfad fürTraffic ohne Routing-Markierung:

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

Hinweis. Der Wert distance=2 wird verwendet, da ISP1 gemäß den Vorgaben als erster Backup angegeben ist.

3.1.2.4. Standardrekursiver Pfad für Traffic mit Routing-Markierung „to_isp1“:

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

Hinweis. Hier beginnen wir endlich, die Früchte der Vorarbeiten aus Punkt 2 zu nutzen.

Über diesen Pfad wird aller Traffic mit der Markierung Route „to_isp1“ an das Gateway des ersten Providers geleitet, unabhängig davon, welches Gateway derzeit als Standard für die Haupttabelle aktiv ist.

3.1.2.5. Erster Backup-Rekursiver Pfad für markierten Traffic der Provider 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

Hinweis. Diese Routen sind notwendig, um Traffic von lokalen Netzwerken, die aus Mitgliedern der Adressliste „to_isp*“ bestehen, zu reservieren.

3.1.2.6. Definieren des Pfades für den lokalen Traffic des Routers ins Internet über ISP1:

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

Hinweis. In Kombination mit den Regeln aus Punkt 1.8.2 wird der Zugang zum benötigten Kanal mit der angegebenen Quelle gewährleistet. Dies ist entscheidend für den Aufbau von Tunneln, in denen die IP-Adresse der lokalen Seite (EoIP, IP-IP, GRE) festgelegt wird. Da die Regeln in den IP-Routenregeln von oben nach unten ausgeführt werden, bis das erste Übereinstimmungskriterium erreicht ist, muss diese Regel nach den Regeln aus Punkt 1.8.2 stehen.

3.1.3. Schreiben Sie 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

Hinweis. NAT für sämtlichen ausgehenden Verkehr, außer dem, der in die IPsec-Richtlinien fällt. Ich vermeide es, action=masquerade ohne zwingenden Grund zu verwenden. Es arbeitet langsamer und ist ressourcenintensiver als src-nat, da es für jede neue Verbindung die Adresse für NAT berechnet.

3.1.4. Leiten Sie Kunden aus der Liste, denen der Zugang über andere Anbieter verboten ist, sofort zum Gateway des Providers 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

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

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

3.2. Konfigurieren Sie die Verbindung zu ISP2.

Da der Anbieter ISP2 die Einstellungen über DHCP bereitstellt, ist es sinnvoll, die erforderlichen Änderungen mit einem Skript vorzunehmen, das beim Start des DHCP-Clients ausgeführt 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 selbst im Winbox-Fenster:

Hinweis. Der erste Teil des Skripts wird bei erfolgreichem Empfang der Mietdaten aktiviert, der zweite Teil nach der Freigabe der Mietdaten.Siehe Hinweis 2

3.3. Konfigurieren Sie die Verbindung zum Anbieter ISP3.

Da der Einstellungsanbieter uns dynamische Daten liefert, ist es sinnvoll, die notwendigen Änderungen mit Skripten vorzunehmen, die nach dem Starten und Herunterfahren der ppp-Schnittstelle ausgeführt 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 selbst im Winbox-Fenster:

Hinweis. Zeichenfolge
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
dies ermöglicht die korrekte Verarbeitung der Umbenennung von Schnittstellen, da es mit deren 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 Uhren:

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

Für die, die bis zum Ende gelesen haben

Die vorgeschlagene Implementierung des MultiWAN ist eine persönliche Präferenz des Autors und nicht die einzig mögliche. Die Werkzeugpalette von ROS ist umfangreich und flexibel, was einerseits Schwierigkeiten für Anfänger verursacht, andererseits aber auch zur Popularität beiträgt. Lernen Sie, experimentieren Sie, entdecken Sie neue Werkzeuge und Lösungen. Beispielsweise kann in dieser Implementierung des MultiWAN das Werkzeug Check-gateway mit rekursiven Routen durch Netwatch.

Hinweise

Check-gateway — ein Mechanismus, der es ermöglicht, die Route nach zwei aufeinanderfolgenden erfolglosen Erreichbarkeitsprüfungen des Gateways zu deaktivieren. Die Prüfung erfolgt alle 10 Sekunden, plus Timeout der Antwort. Insgesamt liegt der tatsächliche Umschaltzeitpunkt im Bereich von 20-30 Sekunden. Wenn dieser Umschaltzeitpunkt nicht ausreicht, gibt es die Möglichkeit, ein Tool zu verwenden. Netwatch, bei dem der Prüfintervall manuell eingestellt werden kann. Der Mechanismus Check-gateway wird bei sporadischen Paketverlusten im Kanal nicht aktiviert.
Wichtig! Die Deaktivierung der Hauptroute führt zur Deaktivierung aller anderen Routen, die darauf verweisen. Daher ist es nicht erforderlich, für sie check-gateway=ping anzugeben.
Es kann vorkommen, dass im Mechanismus von DHCP ein Fehler auftritt, der aussieht, als ob der Client im Zustand renew hängt. In diesem Fall wird der zweite Teil des Skripts nicht ausgeführt, aber der ordnungsgemäße Datenverkehr wird nicht gestört, da der Status die entsprechende rekursive Route verfolgt.
ECMP (Equal Cost Multi-Path) In ROS besteht die Möglichkeit, eine Route mit mehreren Gateways und der gleichen Distanz festzulegen. In diesem Fall werden die Verbindungen über die Kanäle verteilt, wobei der Round-Robin-Algorithmus proportional zur Anzahl der angegebenen Gateways verwendet wird.

Für den Anstoß zur Erstellung des Artikels, die Unterstützung bei der Strukturierung und der Setzung von Schwerpunkten – ein persönlicher Dank an Jewgeni. @jscar

Quelle: habr.com