Multivan und Routing auf Mikrotik RouterOS

Mit Korrekturen und Ergänzungen vom 02/11/2020

Einführung


Neben der Eitelkeit veranlasste mich die bedrückende Häufigkeit von Fragen zu diesem Thema in den relevanten Gruppen der russischsprachigen Telegrammgemeinschaft, den Artikel aufzugreifen. Dieser Artikel richtet sich an unerfahrene Administratoren von Mikrotik RouterOS (im Folgenden: ROS). Es wird nur ein Multivan betrachtet, wobei der Schwerpunkt auf dem Routing liegt. Der Bonus beinhaltet minimal ausreichende Einstellungen, um einen sicheren und bequemen Betrieb zu gewährleisten. Diejenigen, die nach Offenlegung dieser Warteschlangen, Lastausgleich, VLAN, Brücken, mehrstufiger eingehender Analyse des Zustands des Kanals und dergleichen suchen, können keine Zeit und Mühe mit dem Lesen verschwenden.

Ausgangsdaten


Als Testperson wurde ein Mikrotik-Router mit fünf Ports und ROS Version 6.45+ ausgewählt. Der Datenverkehr wird zwischen zwei lokalen Netzwerken (LAN1 und LAN2) und drei Anbietern (ISP1, ISP2, ISP3) weitergeleitet. Der Kanal zu ISP1 hat eine statische "graue" Adresse, ISP2 ist "weiß", die über DHCP empfangen wird, ISP3 ist "weiß" mit PPPoE-Authentifizierung. Das Anschlussdiagramm ist in der Abbildung dargestellt:



Die Aufgabe besteht darin, den MTK-Router basierend auf dem Schema so zu konfigurieren, dass:

  1. Stellen Sie eine automatische Umschaltung auf den Sicherungsanbieter bereit. Der Hauptanbieter ist ISP2, die erste Reserve ist ISP1, die zweite Reserve ist ISP3.
  2. So organisieren Sie den LAN1-Zugang zum Internet nur über ISP1.
  3. Bieten Sie die Möglichkeit, Datenverkehr von lokalen Netzwerken über den ausgewählten Anbieter basierend auf der Adressliste zum Internet weiterzuleiten.
  4. Bereitstellung der Möglichkeit, Dienste von einem lokalen Netzwerk ins Internet zu veröffentlichen (DSTNAT)
  5. Konfigurieren Sie einen Firewall-Filter, um die minimale Sicherheit im Internet zu gewährleisten.
  6. Der Router kann abhängig von der ausgewählten Quelladresse seinen eigenen Datenverkehr über einen der drei Anbieter ausgeben.
  7. Stellen Sie das Routing von Antwortpaketen an den Kanal bereit, von dem sie stammen (einschließlich LAN).

Bemerkung. Wir werden den Router "von Grund auf neu" konfigurieren, um sicherzustellen, dass die Startkonfigurationen "out of the box" von Version zu Version nicht überraschend sind. Als Konfigurationstool wurde Winbox ausgewählt, in dem die Änderungen visuell angezeigt werden. Die Einstellungen selbst werden durch Befehle im Winbox-Terminal festgelegt. Die physische Verbindung für die Konfiguration erfolgt über eine direkte Verbindung zur Ether5-Schnittstelle.

Eine kleine Diskussion darüber, was ein Multivan ist, ob es sich um ein Problem handelt oder um listige, kluge Leute, die Netzwerke von Verschwörungen verweben


Ein neugieriger und aufmerksamer Administrator, der ein solches oder ein solches Schema selbst erstellt, merkt plötzlich, dass es normal funktioniert. Ja, ja, ohne diese Ihre benutzerdefinierten Routing-Tabellen und andere Routenregeln, die die meisten Artikel zu diesem Thema enthalten. Probieren Sie es aus?

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

Die Adresse und das Gateway mit der Entfernung = 2 und dem Check-Gateway = Ping wurden auf ISP1 registriert .
Auf ISP2 ist die Standard-DHCP-Einstellung des Clients entsprechend, dass der Abstand gleich eins ist.
Auf ISP3 in den pppoe-Einstellungen des Clients mit add-default-route = yes setze default-route-distance = 3 .

Vergessen Sie nicht, NAT für die Ausgabe zu registrieren:

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

Infolgedessen wird LAN-Benutzern über den Haupt-ISP2-Anbieter ein Siegelspaß geladen, und der Kanal wird mithilfe des Check-Gateway- Mechanismus reserviert . Siehe Hinweis 1

Punkt 1 der Aufgabe ist implementiert. Wo ist der Multivan mit seinen Tags? Nein…

Weiter. Sie müssen bestimmte Clients über ISP1 aus dem LAN freigeben:

/ 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 = keine Route-dst = 100.66.66.1 src-Adresse = 192.168.88.0 / 24

Die Punkte 2 und 3 der Aufgabe sind implementiert. Tags, Briefmarken, Routenregeln, wo bist du ?!

Müssen Sie Clients aus dem Internet Zugriff auf Ihren bevorzugten OpenVPN-Server mit der Adresse 172.17.17.17 gewähren? Bitte:

/ ip cloud set ddns-enabled = yes

Wir geben den Kunden das Ausgabeergebnis als Fest: " : put [ip cloud get dns-name] "

Wir registrieren die Portweiterleitung aus dem Internet:

/ ip firewall nat add action = dst-nat chain = dstnat dst-port = 1194 \
In-Interface-Liste = WAN-Protokoll = udp to-Adressen = 172.17.17.17

Punkt 4 ist fertig.

Wir haben eine Firewall und andere Sicherheitsvorkehrungen für Punkt 5 eingerichtet. Gleichzeitig sind wir froh, dass alles für die Benutzer funktioniert und wir nach einem Behälter mit einem Lieblingsgetränk greifen ...
Ah! Die Tunnel sind immer noch vergessen.

Der gemäß dem gegoogelten Artikel konfigurierte l2tp-Client stieg auf den geliebten niederländischen VDS? Ja
l2tp-Server mit IPSec stieg und Clients nach DNS-Namen aus IP Cloud (siehe oben) haften? Ja
Wir lehnen uns zurück, nehmen einen Schluck von dem Getränk und untersuchen müßig die Punkte 6 und 7 des Problems. Wir denken - brauchen wir es? Alles funktioniert so ... Wenn es also nicht nötig ist, dann ist das alles. Multivan implementiert.

Was ist ein Multivan? Dies ist die Verbindung mehrerer Internetkanäle mit einem Router.

Sie können den Artikel nicht weiter lesen, denn was kann da sein, abgesehen von einem Beweis zweifelhafter Anwendbarkeit?

Mit denen, die bleiben, die an den Punkten 6 und 7 der Aufgabe interessiert sind und auch den Juckreiz des Perfektionismus spüren, tauchen wir tiefer ein.

Die wichtigste Aufgabe bei der Implementierung von Multivans ist die korrekte Weiterleitung des Datenverkehrs. Nämlich: Unabhängig davon, welcher (oder welcher) Siehe Anmerkung 3, die Kanäle des Anbieters sehen sich die Standardroute auf unserem Router an, sie sollten die Antwort genau an den Kanal zurückgeben, von dem das Paket stammt. Die Aufgabe ist klar. Wo ist das Problem? In einem einfachen lokalen Netzwerk ist die Aufgabe zwar dieselbe, aber niemand stört sich an zusätzlichen Einstellungen und hat keine Probleme. Der Unterschied besteht darin, dass auf jeden gerouteten Knoten im Internet über jeden unserer Kanäle zugegriffen werden kann und nicht über einen streng spezifischen wie in einem einfachen LAN. Das „Problem“ ist jedoch, dass wenn wir eine Anfrage nach der IP-Adresse von ISP3 erhalten haben, die Antwort in unserem Fall über den ISP2-Kanal erfolgt, da das Standard-Gateway dorthin geleitet wird. Es wird verlassen und vom Anbieter als falsch verworfen. Wir haben uns für das Problem entschieden. Wie kann man es lösen?

Die Lösung ist in drei Stufen unterteilt:

  1. Vorkonfiguration Zu diesem Zeitpunkt werden die Grundeinstellungen des Routers festgelegt: lokales Netzwerk, Firewall, Adresslisten, Haarnadel-NAT usw.
  2. Multivan. Zu diesem Zeitpunkt werden die erforderlichen Verbindungen markiert und gemäß den Routing-Tabellen sortiert.
  3. Verbindung zum ISP. In dieser Phase werden die Schnittstellen, die die Internetverbindung bereitstellen, konfiguriert, das Routing und der Mechanismus für die Reservierung von Internetkanälen werden einbezogen.

Bemerkung. Drei verschiedene Arten der Verbindung zum ISP wurden speziell ausgewählt, um zu zeigen, dass das Einrichten von Multivans mit dynamischen Adressen nicht unlösbar ist, und um eine der Lösungsoptionen zu demonstrieren.
Wichtig! Um die Kanäle gemäß dem Algorithmus zu wechseln, der unter Verwendung der Kosten für Entfernungsrouten angegeben wurde , wird der Check-Gateway- Mechanismus verwendet . Siehe Anmerkung 1
Die im Artikel angegebenen Skripte haben nichts mit Kanalreservierung zu tun.

1. Voreinstellung


1.1. Wir löschen die Routerkonfiguration mit dem Befehl:

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

stimme zu “ Gefährlich! Trotzdem zurücksetzen? [ j / N]: ”und nach dem Neustart stellen wir über MAC eine Verbindung zu Winbox her. In dieser Phase werden die Konfiguration und die Benutzerbasis gelöscht.

1.2. Erstellen Sie einen neuen Benutzer:

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

Melden Sie sich darunter an und löschen Sie die Standardeinstellung:

 /user remove admin 

Bemerkung. Es ist das Entfernen und nicht das Trennen des Standardbenutzers, das der Autor als sicherer erachtet und zur Verwendung empfiehlt.

1.3. Wir erstellen grundlegende Schnittstellenlisten, um den Betrieb in einer Firewall, Erkennungseinstellungen und anderen MAC-Servern zu vereinfachen:

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

Wir signieren Schnittstellen mit Kommentaren

 /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üllen Sie die Schnittstellenlisten aus:

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

Bemerkung. Das Schreiben klarer Kommentare ist die dafür aufgewendete Zeit wert und erleichtert die Fehlerbehebung und das Verständnis der Konfiguration erheblich.

Der Autor hält es aus Sicherheitsgründen für erforderlich, die ether3-Schnittstelle zur Schnittstellenliste „WAN“ hinzuzufügen, obwohl das IP-Protokoll diese nicht durchläuft.

Vergessen Sie nicht, dass die PPP-Schnittstelle, nachdem sie auf ether3 erstellt wurde, auch zur Liste der WAN-Schnittstellen hinzugefügt werden muss

1.4. Wir verbergen den Router vor der Erkennung und Steuerung von Näherungsfunktionen in den Netzwerken von Anbietern durch MAC:

 /ip neighbor discovery-settings set discover-interface-list=!WAN /tool mac-server set allowed-interface-list=LAN /tool mac-server mac-winbox set allowed-interface-list=LAN 

1.5. Wir erstellen einen Mindestsatz an Firewall-Filterregeln, um den Router zu schützen:

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

(Die Regel bietet Berechtigungen für hergestellte und verwandte Verbindungen, die sowohl von 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. Alle icmp dürfen eingeben. Es ist sehr nützlich, um Probleme mit MTU zu finden.)

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

(Die Regel, die die Eingabekette schließt, 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 hergestellte und verwandte Verbindungen, die über den Router verlaufen.)

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

(Die Regel trennt Verbindungen mit dem Verbindungsstatus = ungültig über den Router. Sie wird von Mikrotik dringend empfohlen, kann jedoch in einigen seltenen Situationen 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 verbietet Pakete, die aus dem Internet stammen und die dstnat-Prozedur nicht über den Router durchlaufen haben. Dies schützt lokale Netzwerke vor Eindringlingen, die sich in derselben Broadcast-Domäne wie unsere externen Netzwerke befinden, unsere externen IP-Adressen als Gateway registrieren und es daher versuchen Erkunden Sie unsere lokalen Netzwerke.)

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

1.6. Erstellen Sie eine Liste mit einer Liste nicht routbarer Netzwerke:

 /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 an das Internet weitergeleitet werden. Dementsprechend werden wir dies auch befolgen.)

Bemerkung. Die Liste kann sich ändern, daher empfehle ich Ihnen, die Relevanz regelmäßig zu überprüfen.

1.7. Konfigurieren Sie DNS für den Router selbst:

 /ip dns set servers=1.1.1.1,8.8.8.8 

Bemerkung. In der aktuellen Version von ROS haben dynamische Server Vorrang vor statisch definierten. Eine Namensauflösungsanforderung wird an den ersten Server in der Reihenfolge in der Liste gesendet. Der Übergang zum nächsten Server erfolgt, wenn der aktuelle nicht verfügbar ist. Große Zeitüberschreitung - mehr als 5 Sekunden. Die Rückkehr zurück, wenn der "heruntergefallene Server" wieder aufgenommen wird, erfolgt nicht automatisch. Angesichts dieses Algorithmus und des Vorhandenseins eines Multivans empfiehlt der Autor, keine von Anbietern herausgegebenen Server zu verwenden.

1.8. Konfigurieren Sie das lokale Netzwerk.
1.8.1. Konfigurieren Sie statische IP-Adressen auf LAN-Schnittstellen:

 /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 legen die Regeln für Routen zu unseren lokalen Netzwerken über die Hauptrouting-Tabelle fest:

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

Bemerkung. Dies ist eine der einfachsten und schnellsten Möglichkeiten, auf lokale Netzwerkadressen mit externen IP-Adressen von Router-Schnittstellen zuzugreifen, über die die Standardroute nicht verläuft.

1.8.3. Aktivieren Sie bei Bedarf 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 

Bemerkung. Auf diese Weise können Benutzer von LAN1 und LAN2 über eine externe IP-Adresse (dstnat) auf Server zugreifen, die sich mit Benutzern im selben Netzwerksegment befinden.

2. Eigentlich die Implementierung der richtigen Multivans


Um das Problem der Beantwortung von Fragen zu lösen, verwenden wir zwei ROS-Tools: Verbindungsmarkierung und Routingmarkierung . Mit der Verbindungsmarke können Sie die gewünschte Verbindung markieren und mit dieser Bezeichnung als Bedingung für das Anbringen der Routing-Marke weiterarbeiten. Und bereits mit Routing Mark ist es möglich, in IP-Route und Routenregeln zu arbeiten. Wir haben die Werkzeuge herausgefunden, jetzt müssen wir entscheiden, welche Verbindungen markiert werden sollen - eine, wo genau - zwei.

Mit dem ersten ist alles einfach - wir müssen alle Verbindungen, die vom Internet über den entsprechenden Kanal zum Router kommen, markieren. In unserem Fall sind dies drei Bezeichnungen (entsprechend der Anzahl der Kanäle): "conn_isp1", "conn_isp2" und "conn_isp3".

Die Nuance mit der zweiten ist, dass es zwei Arten von eingehenden Verbindungen gibt: Transit und solche, die für den Router selbst bestimmt sind. Der Verbindungsmarkierungsmechanismus funktioniert in der Mangeltabelle . Betrachten Sie die Bewegung des Pakets in einem vereinfachten Diagramm, das freundlicherweise von den Spezialisten der Ressource mikrotik-trainings.com (keine Werbung) zusammengestellt wurde:



Wenn wir den Pfeilen folgen , sehen wir, dass das Paket, das an der „ Eingabeschnittstelleankommt, die Kette „ Preroutingdurchläuft und erst dann im Block „ Routing Decision “ in Transit und Local unterteilt wird. Um zwei Fliegen mit einer Klappe zu schlagen , verwenden Sie daher das Verbindungszeichen in der Mangle Prerouting- Tabelle der Prerouting- Kette.

Bemerkung . In ROS werden die Bezeichnungen "Routing-Marke" im Abschnitt "IP / Routen / Regeln" als "Tabelle" und in den übrigen Abschnitten als "Routing-Marke" angegeben. Dies kann zu Verwirrung beim Verständnis führen, aber tatsächlich ist es ein und dasselbe und das Analogon von rt_tables in iproute2 unter Linux.

2.1. Wir markieren 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 

Bemerkung.
Diejenigen Leser, die versuchen, buchstäblich und in der Lesereihenfolge die im Artikel vorgeschlagene Einstellung zu wiederholen, werden bei der Eingabe des dritten Befehls auf den Fehler "Eingabe stimmt mit keinem Wert der Schnittstelle überein" stoßen. Dies ist auf das Fehlen der Schnittstelle „pppoe-isp3“ zurückzuführen, die in Abschnitt 3.3.2 konfiguriert wird. An dieser Stelle können Sie "ether3" anstelle von "pppoe-isp3" eingeben. Nach Abschluss von Abschnitt 3.3.2 sollten Sie zurückgehen und den aktuellen Namen der Schnittstelle eingeben.

Um bereits markierte Verbindungen nicht zu markieren, verwende ich die Bedingung Verbindungsmarke = keine Markierung anstelle von Verbindungsstatus = neu.

Passthrough = Nein - da bei dieser Implementierungsmethode eine erneute Markierung ausgeschlossen ist und Sie zur Beschleunigung die Aufzählung von Regeln nach dem ersten Spiel unterbrechen können.

Es sollte bedacht werden, dass wir das Routing immer noch nicht stören. Jetzt gibt es nur noch Vorbereitungsstufen. Die nächste Implementierungsstufe ist die Verarbeitung des Transitverkehrs, der über eine feste Verbindung vom Adressaten im lokalen Netzwerk zurückgegeben wird. Das heißt, die Pakete, die (siehe Abbildung) auf dem Weg durch den Router gingen:

"Input Interface" => "Prerouting" => "Routing Decision" => "Forward" => "Post Routing" => "Output Interface" und kam zu ihrem Ziel im lokalen Netzwerk.

Wichtig! In ROS gibt es keine logische Unterteilung in externe und interne Schnittstellen. Wenn wir den Pfad des Antwortpakets im folgenden Diagramm verfolgen, folgt es demselben logischen Pfad wie die Anforderung:

"Input Interface" => "Prerouting" => "Routing Decision" => "Forward" => "Post Routing" => "Output Interface" Nur für die Anfrage " Input Interface " gab es eine ISP-Schnittstelle und für die Antwort war es LAN

2.2. Wir leiten den Rücktransitverkehr an die entsprechenden Routing-Tabellen weiter:

 /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 

Bemerkung. in-interface-list =! WAN - Wir arbeiten nur mit Datenverkehr aus dem lokalen Netzwerk und dst-address-type =! local ohne die Zieladresse der Schnittstellenadressen des Routers.


Das Gleiche gilt für lokale Pakete, die unterwegs zum Router kamen:

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

Wichtig! Die Antwort geht auf folgendem Weg:

"Lokaler Prozess" => "Routing-Entscheidung" => "Ausgabe" => "Post-Routing" => "Ausgabeschnittstelle"

2.3. Wir leiten den lokalen Antwortverkehr an 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, eine Antwort an den Internetkanal zu senden, von dem die Anforderung stammt, als gelöst betrachtet werden. Alles ist markiert, markiert und bereit zur Route.
Ein hervorragender Nebeneffekt dieser Konfiguration ist die Möglichkeit, DSNAT-Ports von beiden Anbietern (ISP2, ISP3) gleichzeitig weiterzuleiten. Überhaupt nicht, da wir auf ISP1 keine routingfähige Adresse haben. Dieser Effekt ist beispielsweise für einen Mailserver mit zwei MXs wichtig, die unterschiedliche Internetkanäle betrachten.

Um die Nuancen der Arbeit lokaler Netzwerke mit externen IP-Routern zu beseitigen, verwenden wir die Lösungen aus den Absätzen. 1.8.2 und 3.1.2.6.

Darüber hinaus können Sie das Werkzeug mit Markierungen verwenden und Absatz 3 des Problems lösen. Wir implementieren es so:

2.4. Wir leiten den Datenverkehr von lokalen Clients von Routing-Listen zu den 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 

Infolgedessen sieht es ungefähr so ​​aus (das Bild ist anklickbar):



3. Konfigurieren Sie die ISP-Konnektivität und aktivieren Sie das markenbasierte Routing


3.1. Konfigurieren Sie die Verbindung zu ISP1:
3.1.1. Konfigurieren Sie eine statische IP-Adresse:

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

3.1.2. Konfigurieren Sie das statische Routing:
3.1.2.1. Fügen Sie eine Standard-Notfallroute hinzu:

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

Bemerkung. Diese Route ermöglicht es dem Verkehr von lokalen Prozessen, die Phase der Routenentscheidung zu durchlaufen, unabhängig vom Status der Kanäle eines der Anbieter. Die Nuance des ausgehenden lokalen Datenverkehrs besteht darin, dass das aktive Routing zum Standard-Gateway in der Hauptrouting-Tabelle vorhanden sein muss, damit sich das Paket zumindest irgendwohin bewegt. Wenn nicht, wird das Paket einfach zerstört.

Als Erweiterung des Check-Gateway- Tools für eine eingehendere Analyse des Kanalstatus schlage ich die Verwendung der rekursiven Routenmethode vor. Das Wesentliche der Methode ist, dass wir den Router anweisen, nicht direkt, sondern über ein Zwischen-Gateway nach dem Pfad zu seinem Gateway zu suchen. Als solche "Test" -Gateways werden 4.2.2.1, 4.2.2.2 und 4.2.2.3 für ISP1, ISP2 bzw. ISP3 ausgewählt.

3.1.2.2. Route zur Verifizierungsadresse:

 /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 

Bemerkung. Der Bereichswert wird im ROS-Zielbereich auf den Standardwert reduziert, um weitere 4.2.2.1 als rekursives Gateway zu verwenden. Ich betone: Der Umfang der Route zur Verifizierungsadresse sollte kleiner oder gleich dem Zielbereich der Route sein, die auf die Verifizierung verweist.

3.1.2.3. Die standardmäßige rekursive Route für Verkehr ohne Routing-Markierung:

 /ip route add check-gateway=ping comment="Unmarked via ISP1" \ distance=2 gateway=4.2.2.1 

Bemerkung. Der Wert distance = 2 wird verwendet, da ISP1 unter den Bedingungen der Aufgabe als erster Standby-Wert deklariert wird.

3.1.2.4. Die standardmäßige rekursive Route für den Verkehr mit der Routing-Markierung "to_isp1":

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

Bemerkung. Eigentlich fangen wir hier endlich an, die Früchte der in Absatz 2 durchgeführten Vorarbeiten zu verwenden.

Auf dieser Route wird der gesamte Datenverkehr mit der Markierungsroute "to_isp1" an das Gateway des ersten Anbieters geleitet, unabhängig davon, welches Standardgateway für die Haupttabelle derzeit aktiv ist.

3.1.2.5. Die erste rekursive Standard-Fallback-Route für beschrifteten Datenverkehr von ISP2- und ISP3-Anbietern:

 /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 

Bemerkung. Diese Routen werden auch benötigt, um Datenverkehr von lokalen Netzwerken zu reservieren, die Mitglieder der Adressliste "to_isp *" sind. '

3.1.2.6. Wir schreiben die Route für den lokalen Router-Verkehr zum Internet über ISP1:

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

Bemerkung. In Kombination mit den Regeln aus Abschnitt 1.8.2 wird ein Ausgang zum gewünschten Kanal mit einer bestimmten Quelle bereitgestellt. Dies ist entscheidend für den Bau von Tunneln, in denen die IP-Adresse der lokalen Seite (EoIP, IP-IP, GRE) angegeben ist. Da die Regeln in IP-Routenregeln von oben nach unten ausgeführt werden, bis diese Bedingungen zum ersten Mal übereinstimmen, sollte diese Regel den Regeln in Abschnitt 1.8.2 entsprechen.

3.1.3. Wir schreiben die NAT-Regel für 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 

Bemerkung. NAT ist alles, was dazu gehört, außer dass es in IPSec-Richtlinien fällt. Ich versuche, action = masquerade nicht zu verwenden, es sei denn, dies ist absolut notwendig. Es ist langsamer und ressourcenintensiver als src-nat, da für jede neue Verbindung eine Adresse für NAT berechnet wird.

3.1.4. Wir senden Clients aus der Liste, denen das Verlassen über andere Anbieter untersagt ist, direkt an das ISP1-Provider-Gateway.

 /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 

Bemerkung. action = route hat eine höhere Priorität und wird früher als andere Routing-Regeln angewendet.

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

3.2. Wir konfigurieren die Verbindung zu ISP2.

Da der ISP2-Anbieter uns die Einstellungen über DHCP mitteilt, 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 remove [ find gateway=\"4.2.2.2\" ]; /ip route remove \ [ find where dst-address ~\"4.2.2.2\" ]\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=10\r\ \n /ip route add check-gateway=ping 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\"\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 remove [ find gateway=\"4.2.2.2\" ]; /ip route remove \ [ find where dst-address ~\"4.2.2.2\" ]\r\ \n /ip firewall nat remove [find comment=\"NAT via ISP2\"]\r\ \n /ip route rule remove [find comment=\"From ISP2 IP to Inet\"]\r\ \n}\r\ \n" use-peer-dns=no use-peer-ntp=no 

Das Skript selbst im Winbox-Fenster (anklickbar):


Bemerkung. Der erste Teil des Skripts wird ausgelöst, wenn der Mietvertrag erfolgreich empfangen wurde, der zweite - nachdem der Mietvertrag freigegeben wurde. Siehe Anmerkung 2

3.3. Wir konfigurieren die Verbindung zum ISP3-Provider.

Da der Konfigurationsanbieter uns Dynamik verleiht, ist es sinnvoll, die erforderlichen Änderungen mit Skripten vorzunehmen, die nach dem Anstieg und nach dem Abfall der ppp-Schnittstelle beginnen.

Bemerkung. Die ppp-Schnittstelle kann anstelle einer IP-Adresse als Gateway angegeben werden. In diesem Fall kann die rekursive Route jedoch nicht aktiviert werden. Daher erhalten wir die IP-Adresse der Anbieterseite in die Variable und verwenden sie auf die gleiche Weise wie für die anderen Anbieter

3.3.1. Konfigurieren Sie zunächst das Profil:

 /ppp profile add comment="for PPPoE to ISP3" interface-list=WAN name=isp3_client \ on-down="/ip route remove [ find gateway=\"4.2.2.3\" ]\r\ \n/ip route remove [ find where dst-address ~\"4.2.2.3\" ]\r\ \n/ip firewall nat remove [find comment=\"NAT via ISP3\"]\r\ \n/ip route rule remove [find comment=\"From ISP3 IP to Inet\"]" \ on-up="/ip route remove [ find gateway=\"4.2.2.3\" ]; /ip route remove \ [ find where dst-address ~\"4.2.2.3\" ]\r\ \n/ip route add check-gateway=ping comment=\"For recursion via ISP3\" distance=1 \ dst-address=4.2.2.3/32 gateway=\$\"remote-address\" scope=10\r\ \n/ip route add check-gateway=ping 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\"\r\ \n/ip route rule add comment=\"From ISP3 IP to Inet\" \ src-address=\$\"local-address\" table=to_isp3 " 

Das Skript selbst im Winbox-Fenster (anklickbar):


Bemerkung. String
/ ip firewall mangle set [find comment = "Verbindung von ISP3 verbinden"] in-interface = $ "interface";
Ermöglicht es Ihnen, die Umbenennung der Schnittstelle korrekt zu verarbeiten, da sie mit ihrem Code und nicht mit dem Anzeigenamen funktioniert.

3.3.2. Erstellen Sie nun mithilfe 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 


Bemerkung. Einige Anbieter "vergessen", den Parameter "Remote-Adresse" anzugeben. In diesem Fall funktioniert das Konfigurationsskript bei Verbindung nicht ordnungsgemäß, und im Protokoll wird der folgende Fehler angezeigt:
pppoe, ppp, info pppoe-isp3: Die Remote-Adresse konnte mit xxx.xxx.xxx.xxx nicht ermittelt werden
Um dieses Problem zu lösen, müssen Sie die Adresse im ppp-Profil (ein beliebiger Dummy) manuell festlegen:
 /ppp profile set isp3_client remote-address=169.254.69.96 

String
/ ip firewall mangle set [find comment = "Verbindung von ISP3 verbinden"] in-interface = $ "interface";
Ermöglicht es Ihnen, die Umbenennung der Schnittstelle korrekt zu verarbeiten, da sie mit ihrem Code und nicht mit dem Anzeigenamen funktioniert.

Stellen Sie als letzten Schliff die Uhr ein:

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


Die vorgeschlagene Methode zur Implementierung von Multivans ist die persönliche Präferenz des Autors und nicht die einzig mögliche. Das ROS-Toolkit ist umfangreich und flexibel, was zum einen Anfängern Schwierigkeiten bereitet, zum anderen den Grund für die Beliebtheit. Entdecken, versuchen, entdecken Sie neue Tools und Lösungen. Als Anwendung des gewonnenen Wissens ist es beispielsweise bei dieser Implementierung des Multivans möglich , das Check-Gateway- Tool durch rekursive Routen mit Netwatch zu ersetzen .

Anmerkungen


  1. Check-gateway — , . 10 , . , 20-30 . — Netwatch , .
    Check-gateway .

    Wichtig! , . check-gateway=ping .
  2. Es kommt vor, dass ein Fehler im DHP-Betriebsmechanismus auftritt, der aussieht, als ob ein Client in einem Erneuerungszustand hängt. In diesem Fall funktioniert der zweite Teil des Skripts nicht, aber der Verkehr wird nicht beeinträchtigt, wenn er korrekt läuft, da der Status die entsprechende rekursive Route überwacht.
  3. ECMP (Equal Cost Multi-Path) - ROS kann eine Route mit mehreren Gateways und derselben Entfernung angeben. In diesem Fall werden die Verbindungen mithilfe des Round-Robin-Algorithmus proportional zur Anzahl der angegebenen Gateways auf die Kanäle verteilt.

Wenn Sie den Anstoß zum Schreiben des Artikels geben möchten , helfen Sie bei der Gestaltung seiner Struktur und bei der Hervorhebung - persönlicher Dank an Eugene @jscar

Source: https://habr.com/ru/post/de463813/


All Articles