🧝🏽 👨🏾‍🤝‍👨🏻 👨🏼‍🚒 Multivan et routage sur Mikrotik RouterOS 🍩 👨🏻‍💼 💚

Avec corrections et ajouts du 02/11/2020

Présentation

Outre la vanité, la fréquence déprimante des questions sur ce sujet dans les groupes concernés de la communauté des télégrammes russophones m'a incité à reprendre l'article. Cet article est destiné aux administrateurs novices de Mikrotik RouterOS (ci-après ROS). Il ne considère qu'un multivan, avec un accent sur le routage. Le bonus comprend des paramètres minimalement suffisants pour assurer un fonctionnement sûr et pratique. Ceux qui recherchent la divulgation de ces files d'attente, l'équilibrage de charge, le vlan, les ponts, l'analyse approfondie en plusieurs étapes de l'état du canal et similaires - ne peuvent pas perdre de temps et d'efforts pour lire.

Données source

En tant que sujet de test, un routeur Mikrotik à cinq ports avec ROS version 6.45+ a été sélectionné. Il acheminera le trafic entre deux réseaux locaux (LAN1 et LAN2) et trois fournisseurs (ISP1, ISP2, ISP3). Le canal vers ISP1 a une adresse statique «grise», ISP2 est «blanc» reçu via DHCP, ISP3 est «blanc» avec authentification PPPoE. Le schéma de connexion est illustré dans la figure:

La tâche consiste à configurer le routeur MTK en fonction du schéma afin que:

Fournit une commutation automatique vers le fournisseur de sauvegarde. Le principal fournisseur est ISP2, la première réserve est ISP1, la deuxième réserve est ISP3.
Pour organiser l'accès LAN1 à Internet uniquement via ISP1.
Permet d'acheminer le trafic des réseaux locaux vers Internet via le fournisseur sélectionné en fonction de la liste d'adresses.
Fournir la possibilité de publier des services d'un réseau local sur Internet (DSTNAT)
Configurez un filtre pare-feu pour fournir la sécurité minimale suffisante à partir d'Internet.
Le routeur peut émettre son propre trafic via l'un des trois fournisseurs, en fonction de l'adresse source sélectionnée.
Fournissez le routage des paquets de réponse vers le canal d'où ils proviennent (y compris le LAN).

Remarque. Nous allons configurer le routeur «à partir de zéro» afin de garantir qu'il n'y a pas de surprise à démarrer des configurations «prêtes à l'emploi» changeant de version en version. Winbox a été choisi comme outil de configuration, où les modifications seront affichées visuellement. Les paramètres eux-mêmes seront définis par des commandes dans le terminal Winbox. La connexion physique pour la configuration se fait via une connexion directe à l'interface Ether5.

Une petite discussion sur ce qu'est un multivan, que ce soit un problème ou que des gens astucieux et astucieux tissent des réseaux de conspirations

Un administrateur curieux et attentif, mettant en place tel ou tel schéma par lui-même, se rend soudain compte qu'il fonctionne normalement. Oui, oui, sans ces tables de routage personnalisées et autres règles de routage, qui regorgent de la plupart des articles sur ce sujet. Vérifiez-le?

Peut-on configurer l'adressage sur les interfaces et les passerelles par défaut? Oui:

L'adresse et la passerelle avec distance = 2 et check-gateway = ping ont été enregistrées sur ISP1 .
Sur ISP2, le paramètre DHCP par défaut pour le client est la distance, respectivement, égale à un.
Sur ISP3 dans les paramètres pppoe du client avec add-default-route = yes set default-route-distance = 3 .

N'oubliez pas d'enregistrer NAT pour la sortie:

/ ip firewall nat add action = chaîne de mascarade = srcnat out-interface-list = WAN

En conséquence, les utilisateurs des réseaux locaux ont du plaisir à charger les scellés via le fournisseur principal ISP2 et il y a une réservation du canal à l'aide du mécanisme de passerelle de vérification ^.

Le point 1 de la tâche est mis en œuvre. Où est le multivan avec ses étiquettes? Non ...

Plus loin. Vous devez libérer des clients spécifiques du LAN via ISP1:

/ ip firewall mangle add action = route chain = préroutage dst-address-list =! BOGONS \
passthrough = oui route-dst = 100.66.66.1 src-address-list = Via_ISP1
/ ip firewall mangle add action = route chain = préroutage dst-address-list =! BOGONS \
passthrough = no route-dst = 100.66.66.1 src-address = 192.168.88.0 / 24

Les points 2 et 3 de la tâche sont mis en œuvre. Tags, tampons, règles de parcours, où êtes-vous?!

Besoin de donner accès à votre serveur OpenVPN préféré avec l'adresse 172.17.17.17 pour les clients Internet? SVP:

/ ip cloud set ddns-enabled = yes

Nous donnons le résultat de sortie aux clients comme un festin: " : put [ip cloud get dns-name] "

Nous enregistrons la redirection de port depuis Internet:

/ ip firewall nat add action = dst-nat chain = dstnat dst-port = 1194 \
in-interface-list = protocole WAN = adresses udp = 172.17.17.17

Le point 4 est prêt.

Nous avons mis en place un pare-feu et d'autres éléments de sécurité pour le point 5, en même temps, nous sommes heureux que tout fonctionne pour les utilisateurs et atteignons un conteneur avec une boisson préférée ...
Ah! Les tunnels sont encore oubliés.

Le client l2tp configuré selon l'article googlé est passé au VDS néerlandais bien-aimé? Oui
l2tp-server avec IPsec rose et les clients par nom DNS depuis IP Cloud (voir ci-dessus) s'accrochent? Oui
En nous penchant en arrière, en buvant une gorgée de boisson, nous examinons paresseusement les points 6 et 7 du problème. Nous pensons - en avons-nous besoin? Tout fonctionne comme ça (s) ... Donc si ce n'est pas nécessaire, alors c'est tout. Multivan implémenté.

Qu'est-ce qu'un multivan? Il s'agit de la connexion de plusieurs canaux Internet à un routeur.

Vous ne pouvez pas lire l'article plus loin, car que peut-il y avoir en plus d'une démonstration d'applicabilité douteuse?

Avec ceux qui restent, qui sont intéressés par les points 6 et 7 de la tâche, et ressentent également les démangeaisons du perfectionnisme, nous plongeons plus profondément.

La tâche la plus importante de la mise en œuvre de multivans est le routage correct du trafic. A savoir: quel que soit (ou lequel) ^{Voir la note 3,} le ou les canaux du fournisseur regardent la route par défaut sur notre routeur, il devrait retourner la réponse exactement au canal d'où provient le paquet. La tâche est claire. Où est le problème? En effet, dans un simple réseau local, la tâche est la même, mais personne ne dérange avec des paramètres supplémentaires et ne ressent aucun problème. La différence est que tout nœud routé sur Internet est accessible via chacun de nos canaux, et non via un canal strictement spécifique, comme dans un simple LAN. Mais le «problème» est que si nous recevons une demande d'adresse IP d'ISP3, alors dans notre cas la réponse passera par le canal ISP2, puisque la passerelle par défaut y est dirigée. Il partira et sera rejeté par le fournisseur comme étant incorrect. Nous avons décidé du problème. Comment le résoudre?

La solution est divisée en trois étapes:

Préconfiguration À ce stade, les paramètres de base du routeur seront définis: réseau local, pare-feu, listes d'adresses, épingle à cheveux NAT, etc.
Multivan. À ce stade, les connexions nécessaires seront marquées et triées en fonction des tables de routage.
Connexion au FAI. A ce stade, les interfaces fournissant la connexion Internet seront configurées, le routage et le mécanisme de réservation des canaux Internet seront impliqués.

Remarque. Trois types différents de connexion au FAI ont été choisis spécifiquement pour montrer qu'il n'y a rien d'insoluble dans la configuration de multivans avec des adresses dynamiques et démontrer l'une des options de la solution.
Important! Pour commuter les canaux selon l'algorithme spécifié en utilisant le coût des itinéraires à distance , le mécanisme de passerelle de vérification est utilisé . ^{Voir note 1}
Les scripts donnés dans l'article n'ont rien à voir avec la réservation de chaîne.

1. Préréglage

1.1. Nous effaçons la configuration du routeur avec la commande:

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

d'accord avec " Dangereux! Réinitialiser quand même? [y / N]: ”et, après le redémarrage, nous nous connectons à Winbox via MAC. À ce stade, la configuration et la base d'utilisateurs sont effacées.

1.2. Créez un nouvel utilisateur:

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

connectez-vous en dessous et supprimez la valeur par défaut:

 /user remove admin

Remarque. C'est la suppression et non la déconnexion de l'utilisateur par défaut que l'auteur considère plus sûr et recommande d'utiliser.

1.3. Nous créons des listes d'interfaces de base pour la commodité de fonctionner dans un pare-feu, des paramètres de découverte et d'autres serveurs MAC:

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

Nous signons des interfaces avec des commentaires

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

et remplissez les listes d'interfaces:

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

Remarque. Écrire des commentaires clairs vaut le temps consacré à cela, ce qui facilite grandement le dépannage et la compréhension de la configuration.

L'auteur considère qu'il est nécessaire, pour des raisons de sécurité, d'ajouter l'interface ether3 à la liste d'interfaces «WAN», malgré le fait que le protocole ip ne le traversera pas.

N'oubliez pas qu'une fois l'interface PPP augmentée sur ether3, elle devra également être ajoutée à la liste des interfaces «WAN»

1.4. Nous cachons le routeur de la détection de proximité et du contrôle des réseaux des fournisseurs par 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. Nous créons un ensemble minimum suffisant de règles de filtrage du pare-feu pour protéger le routeur:

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

(la règle autorise les connexions établies et connexes initiées à la fois à partir des réseaux connectés et par le routeur lui-même)

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

(ping et pas seulement ping. Tout icmp est autorisé à entrer. Il est très utile pour trouver des problèmes avec MTU)

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

(la règle de fermeture de la chaîne d'entrée interdit tout ce qui arrive d'Internet)

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

(la règle autorise les connexions établies et connexes qui transitent par le routeur)

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

(la règle supprime les connexions, avec connection-state = invalide, passant par le routeur. Elle est fortement recommandée par Mikrotik, mais dans certaines situations rares, elle peut bloquer le trafic utile)

 /ip firewall filter add action=drop chain=forward \ comment="Drop all from WAN not DSTNATed" connection-nat-state=!dstnat \ connection-state=new in-interface-list=WAN

(la règle interdit les paquets qui transitent par Internet et qui n'ont pas suivi la procédure dstnat via le routeur. Cela protégera les réseaux locaux des intrus qui, étant dans le même domaine de diffusion avec nos réseaux externes, enregistreront nos adresses IP externes en tant que passerelle et, par conséquent, essaieront «Explorez» nos réseaux locaux.)

Remarque. Supposons que LAN1 et LAN2 sont des réseaux de confiance et que le trafic entre eux et à partir d'eux ne soit pas filtré.

1.6. Créez une liste avec une liste de réseaux non routables:

 /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

(Il s'agit d'une liste d'adresses et de réseaux qui ne sont pas acheminés vers Internet et, par conséquent, nous suivrons également cela.)

Remarque. La liste peut changer, je vous conseille donc de vérifier périodiquement la pertinence.

1.7. Configurez DNS pour le routeur lui-même:

 /ip dns set servers=1.1.1.1,8.8.8.8

Remarque. Dans la version actuelle de ROS, les serveurs dynamiques ont priorité sur ceux définis statiquement. Une demande de résolution de nom est envoyée au premier serveur dans l'ordre de la liste. La transition vers le serveur suivant se produit lorsque le serveur actuel n'est pas disponible. Big timeout - plus de 5 secondes. Le retour lorsque le «serveur tombé en panne» est repris ne se produit pas automatiquement. Compte tenu de cet algorithme et de la présence d'un multivan, l'auteur recommande de ne pas utiliser de serveurs émis par des fournisseurs.

1.8. Configurez le réseau local.
1.8.1. Configurez les adresses IP statiques sur les interfaces LAN:

 /ip address add interface=ether4 address=192.168.88.254/24 comment="LAN1 IP" /ip address add interface=ether5 address=172.16.1.0/23 comment="LAN2 IP"

1.8.2. Nous définissons les règles pour les itinéraires vers nos réseaux locaux via la table de routage principale:

 /ip route rule add dst-address=192.168.88.0/24 table=main comment="to LAN1" /ip route rule add dst-address=172.16.0.0/23 table=main comment="to LAN2"

Remarque. C'est l'un des moyens les plus simples et les plus rapides d'accéder aux adresses de réseau local avec des adresses IP externes des interfaces de routeur par lesquelles la route par défaut ne passe pas.

1.8.3. Si nécessaire, activez Hairpin NAT pour LAN1 et 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

Remarque. Cela permet aux utilisateurs de LAN1 et LAN2 d'accéder via une IP externe (dstnat) à des serveurs situés avec des utilisateurs sur le même segment de réseau.

2. En fait, la mise en œuvre des multivans corrects

Pour résoudre le problème de «répondre d'où ils l'ont demandé», nous utiliserons deux outils ROS: la marque de connexion et la marque de routage . La marque de connexion vous permet de marquer la connexion souhaitée et de continuer à travailler avec cette étiquette comme condition pour appliquer la marque de routage . Et déjà avec la marque de routage, il est possible de travailler sur les routes IP et les règles de route . Nous avons compris les outils, maintenant nous devons décider quelles connexions marquer - un, où exactement marquer - deux.

Avec le premier, tout est simple - nous devons marquer toutes les connexions qui arrivent au routeur depuis Internet via le canal approprié. Dans notre cas, il s'agira de trois labels (selon le nombre de canaux): "conn_isp1", "conn_isp2" et "conn_isp3".

La nuance avec la seconde est que les connexions entrantes seront de deux types: transit et celles qui sont destinées au routeur lui-même. Le mécanisme de marque de connexion fonctionne dans la table mangle . Considérez le déplacement du colis sur un schéma simplifié, aimablement collecté par les spécialistes de la ressource mikrotik-trainings.com (non publicitaire):

En suivant les flèches, nous voyons que le paquet arrivant à « l'interface d'entrée » passe par la chaîne « Préroutage » et seulement alors il est divisé en transit et local dans le bloc « Décision de routage ». Par conséquent, pour tuer deux oiseaux avec une pierre, utilisez la marque de connexion dans la table de pré - routage Mangle de la chaîne de pré - routage .

Remarque . Dans ROS, les étiquettes «Routing mark» sont indiquées dans la section Ip / Routes / Rules comme «Table», et dans les autres sections comme «Routing Mark». Cela peut entraîner une certaine confusion dans la compréhension, mais, en fait, c'est la même chose, et c'est l'analogue de rt_tables dans iproute2 sur linux.

2.1. Nous marquons les connexions entrantes de chacun des fournisseurs:

 /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

Remarque.
Les lecteurs qui tentent de répéter littéralement et dans l'ordre de lecture le paramètre suggéré dans l'article, lors de la saisie de la troisième commande, ils rencontreront l'erreur: "l'entrée ne correspond à aucune valeur d'interface". Cela est dû à l'absence de l'interface «pppoe-isp3», qui sera configurée dans la section 3.3.2. À ce stade, vous pouvez entrer «ether3» au lieu de «pppoe-isp3». Après avoir terminé le paragraphe 3.3.2, vous devez revenir en arrière et mettre le nom actuel de l'interface.

Afin de ne pas marquer les connexions déjà marquées, j'utilise la condition connection-mark = no-mark au lieu de connection-state = new.

passthrough = no - car dans cette méthode d'implémentation, le re-marquage est exclu, et pour accélérer, vous pouvez interrompre l'énumération des règles après la première correspondance.

Il convient de garder à l'esprit que nous n'interférons toujours pas avec le routage. Maintenant, il n'y a que des étapes de préparation. La prochaine étape de mise en œuvre sera le traitement du trafic de transit, qui est retourné via une connexion régulière du destinataire dans le réseau local. C'est-à-dire ces paquets qui (voir schéma) ont traversé le routeur en cours de route:

"Input Interface" => "Prerouting" => "Routing Decision" => "Forward" => "Post Routing" => "Output Interface" et arrivé à destination sur le réseau local.

Important! Dans ROS, il n'y a pas de division logique entre les interfaces externes et internes. Si nous suivons le chemin du paquet de réponse dans le diagramme ci-dessous, il suivra le même chemin logique que la demande:

"Input Interface" => "Prerouting" => "Routing Decision" => "Forward" => "Post Routing" => "Output Interface" juste pour la requête " Input Interface " il y avait une interface ISP, et pour la réponse - LAN

2.2. Nous dirigeons le trafic de retour vers les tables de routage correspondantes:

 /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

Remarque. in-interface-list =! WAN - nous travaillons uniquement avec le trafic provenant du réseau local et dst-address-type =! local sans l'adresse de destination des adresses d'interface du routeur lui-même.

La même chose pour les paquets locaux qui sont arrivés au routeur en cours de route:

"Interface d'entrée" => "Préroutage" => "Décision de routage" => "Entrée" => "Processus local"

Important! La réponse ira dans le sens suivant:

"Processus local" => "Décision de routage" => "Sortie" => "Post-routage" => "Interface de sortie"

2.3. Nous dirigeons le trafic local de réponse vers les tables de routage correspondantes:

 /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

À ce stade, la tâche de préparer l'envoi d'une réponse au canal Internet d'où provient la demande peut être considérée comme résolue. Tout est balisé, balisé et prêt à être acheminé.
Un excellent effet «secondaire» de cette configuration est la possibilité de transférer des ports DSNAT à partir des deux fournisseurs (ISP2, ISP3) en même temps. Pas du tout, car sur ISP1, nous n'avons pas d'adresse routable. Cet effet est important, par exemple, pour un serveur de messagerie avec deux MX qui regardent différents canaux Internet.

Pour éliminer les nuances du fonctionnement des réseaux locaux avec des routeurs IP externes, nous utilisons les solutions des paragraphes. 1.8.2 et 3.1.2.6.

De plus, vous pouvez utiliser l'outil avec des marquages et pour résoudre le paragraphe 3 du problème. Nous l'implémentons comme ceci:

2.4. Nous dirigeons le trafic des clients locaux des listes de routage vers les tables correspondantes:

 /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

En conséquence, cela ressemble à ceci (l'image est cliquable):

3. Configurer la connectivité ISP et activer le routage basé sur la marque

3.1. Configurez la connexion à ISP1:
3.1.1. Configurez une adresse IP statique:

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

3.1.2. Configurer le routage statique:
3.1.2.1. Ajoutez un itinéraire d'urgence par défaut:

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

Remarque. Cette route permet au trafic provenant des processus locaux de passer par l'étape Route Decision, quel que soit l'état des canaux de l'un des fournisseurs. La nuance du trafic local sortant est que pour que le paquet se déplace au moins quelque part, le routage actif vers la passerelle par défaut doit être présent dans la table de routage principale. Sinon, le colis sera simplement détruit.

En tant qu'extension de l'outil de passerelle de contrôle pour une analyse plus approfondie de l'état du canal, je propose d'utiliser la méthode de l'itinéraire récursif. L'essence de la méthode est que nous demandons au routeur de rechercher le chemin vers sa passerelle non pas directement, mais via une passerelle intermédiaire. En tant que telles passerelles de «test», 4.2.2.1, 4.2.2.2 et 4.2.2.3 seront sélectionnées respectivement pour ISP1, ISP2 et ISP3.

3.1.2.2. Itinéraire vers l'adresse de «vérification»:

 /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

Remarque. La valeur d'étendue est réduite par défaut dans l'étendue cible ROS, afin d'utiliser davantage 4.2.2.1 comme passerelle récursive. Je souligne: la portée de la route vers l'adresse de «vérification» doit être inférieure ou égale à la portée cible de la route qui référencera la vérification.

3.1.2.3. Route récursive par défaut pour le trafic sans marque de routage:

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

Remarque. La valeur distance = 2 est utilisée car ISP1 est déclaré comme le premier en attente selon les termes de la tâche.

3.1.2.4. Route récursive par défaut pour le trafic avec la marque de routage "to_isp1":

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

Remarque. En fait, nous commençons enfin ici à utiliser les fruits des travaux préparatoires menés au paragraphe 2.

Sur cette route, tout le trafic qui a marqué la route «to_isp1» sera dirigé vers la passerelle du premier fournisseur, quelle que soit la passerelle par défaut pour la table principale actuellement active.

3.1.2.5. La première route récursive par défaut de secours pour le trafic étiqueté des fournisseurs ISP2 et 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

Remarque. Ces routes sont également nécessaires pour réserver le trafic provenant des réseaux locaux, qui sont membres de la liste d'adresses «to_isp *» »

3.1.2.6. Nous écrivons l'itinéraire pour le trafic du routeur local vers Internet via ISP1:

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

Remarque. En combinaison avec les règles de la clause 1.8.2, une sortie vers le canal souhaité avec une source donnée est fournie. Ceci est essentiel pour la construction de tunnels dans lesquels l'adresse IP du côté local (EoIP, IP-IP, GRE) est spécifiée. Étant donné que les règles des règles de routage ip sont exécutées de haut en bas, jusqu'à ce que les conditions correspondent pour la première fois, cette règle doit être postérieure aux règles du paragraphe 1.8.2.

3.1.3. Nous écrivons la règle NAT pour le trafic sortant:

 /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

Remarque. NAT est tout ce qui va, sauf qu'il tombe dans les politiques IPsec. J'essaie de ne pas utiliser action = masquerade à moins que cela ne soit absolument nécessaire. Il est plus lent et plus gourmand en ressources que src-nat car il calcule une adresse pour NAT pour chaque nouvelle connexion.

3.1.4. Nous envoyons les clients de la liste auxquels il est interdit de quitter via d'autres fournisseurs directement à la passerelle du fournisseur 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

Remarque. action = la route a une priorité plus élevée et est appliquée plus tôt que les autres règles de routage.

place-before = 0 - place notre règle en premier dans la liste.

3.2. Nous configurons la connexion à ISP2.

Étant donné que le fournisseur ISP2 nous donne les paramètres via DHCP, il est raisonnable d'effectuer les modifications nécessaires avec un script qui démarre lorsque le client DHCP est déclenché:

 /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

Le script lui-même dans la fenêtre Winbox (cliquable):

Remarque. La première partie du script est déclenchée lorsque le bail est reçu avec succès, la seconde - après la libération du bail. ^{Voir note 2}

3.3. Nous configurons la connexion au fournisseur ISP3.

Puisque le fournisseur de configuration nous donne de la dynamique, il est raisonnable de faire les changements nécessaires avec des scripts qui démarrent après la montée et la chute de l'interface ppp.

Remarque. L'interface ppp peut être spécifiée comme passerelle au lieu d'une adresse IP. Cependant, dans ce cas, la route récursive ne peut pas être activée. Par conséquent, nous obtenons l'adresse IP du côté fournisseur dans la variable et nous l'utilisons plus loin de la même manière que pour les autres fournisseurs

3.3.1. Tout d'abord, configurez le 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 "

Le script lui-même dans la fenêtre Winbox (cliquable):

Remarque. String
/ ip firewall mangle set [find comment = "Connmark in from ISP3"] in-interface = $ "interface";
Vous permet de traiter correctement le changement de nom de l'interface, car il fonctionne avec son code et non le nom d'affichage.

3.3.2. Maintenant, en utilisant le profil, créez une connexion ppp:

 /interface pppoe-client add allow=mschap2 comment="to ISP3" disabled=no \ interface=ether3 name=pppoe-isp3 password=isp3_pass profile=isp3_client \ user=isp3_client

Remarque. Certains fournisseurs "oublient" de donner le paramètre "remote-address". Dans ce cas, une fois connecté, le script de configuration ne fonctionnera pas correctement et dans le journal, vous verrez l'erreur suivante:
pppoe, ppp, info pppoe-isp3: impossible de déterminer l'adresse distante, en utilisant xxx.xxx.xxx.xxx
Pour résoudre ce problème, vous devez définir manuellement l'adresse dans le profil ppp (n'importe quel mannequin):

 /ppp profile set isp3_client remote-address=169.254.69.96

String
/ ip firewall mangle set [find comment = "Connmark in from ISP3"] in-interface = $ "interface";
Vous permet de traiter correctement le changement de nom de l'interface, car il fonctionne avec son code et non le nom d'affichage.

En touche finale, réglez l'horloge:

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

Pour ceux qui lisent jusqu'au bout

La méthode proposée pour implémenter les multivans est la préférence personnelle de l'auteur et n'est pas la seule possible. La boîte à outils ROS est vaste et flexible, ce qui, d'une part, cause des difficultés aux débutants, d'autre part - la raison de la popularité. Explorez, essayez, découvrez de nouveaux outils et solutions. Par exemple, en application des connaissances acquises, il est possible dans cette implémentation du multivan de remplacer l'outil check-gateway par des routes récursives avec Netwatch .

Remarques

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

! , . check-gateway=ping .
Il arrive qu'une défaillance se produise dans le mécanisme d'opération DHP, qui ressemble à un client suspendu dans un état de renouvellement. Dans ce cas, la deuxième partie du script ne fonctionnera pas, mais le trafic ne fera pas de mal à marcher correctement, car l'état surveille l'itinéraire récursif correspondant.
ECMP (Equal Cost Multi-Path) - ROS a la possibilité de spécifier un itinéraire avec plusieurs passerelles et la même distance. Dans ce cas, les connexions seront réparties sur les canaux à l'aide de l'algorithme round robin, proportionnellement au nombre de passerelles spécifié.

Pour que l'élan pour écrire l'article aide à façonner sa structure et à mettre l'accent - merci personnel à Eugene @jscar

Multivan et routage sur Mikrotik RouterOS