🥇Multi-WAN et routage sur Mikrotik RouterOS

Introduction

L'article a été motivé non seulement par vanité, mais aussi par la fréquence décourageante de questions sur ce sujet dans les groupes spécialisés de la communauté russophone sur Telegram. L'article est destiné aux administrateurs débutants de Mikrotik RouterOS (ci-après ROS). Il traite uniquement du multicast, en mettant l'accent sur le routage. En bonus, des configurations minimales suffisantes sont incluses pour assurer un fonctionnement sûr et pratique. Ceux qui recherchent des sujets sur les files d'attente, l'équilibrage de charge, les VLAN, les ponts, l'analyse approfondie de l'état du canal, etc. peuvent s'abstenir de lire.

Données d'origine

Pour cette expérience, un routeur Mikrotik à cinq ports avec ROS version 6.45.3 a été choisi. Il va router le trafic entre deux réseaux locaux (LAN1 et LAN2) et trois fournisseurs (ISP1, ISP2, ISP3). Le lien vers ISP1 a une adresse “grise” statique, ISP2 a une adresse “publique” obtenue par DHCP, et ISP3 dispose d’une adresse “publique” avec une authentification PPPoE. Le schéma de connexion est présenté sur l'image :

La tâche consiste à configurer le routeur « MTK » selon le schéma afin de :

Garantir le basculement automatique vers le fournisseur de secours. Le fournisseur principal est ISP2, le premier secours est ISP1, le second secours est ISP3.
Organiser la sortie du réseau LAN1 vers Internet uniquement via ISP1.
Prévoir la possibilité de router le trafic des réseaux locaux vers Internet via un fournisseur choisi sur la base d'une liste d'adresses.
Prévoir la possibilité de publier des services depuis le réseau local sur Internet (DSTNAT).
Configurer un filtre de pare-feu pour assurer une sécurité minimale contre Internet.
Le routeur doit pouvoir émettre son propre trafic via l'un des trois fournisseurs en fonction de l'adresse source sélectionnée.
Assurer le routage des paquets de réponse vers le canal d'où ils proviennent (y compris LAN).

Remarque. Nous allons configurer le routeur « à partir de zéro » afin de garantir l'absence de surprises dans les configurations de démarrage variant d'une version à l'autre. Winbox a été choisi comme outil de configuration, où les changements seront clairement affichés. Les paramètres eux-mêmes seront définis par des commandes dans le terminal Winbox. La connexion physique pour la configuration se fait par connexion directe à l'interface Ether5.

Quelques réflexions sur ce qu'est un multiwan, est-ce un problème ou des malins qui tissent des réseaux de complots ?

Un administrateur curieux et attentif, en configurant lui-même un tel schéma ou un similaire, se rend soudain compte que cela fonctionne déjà correctement. Oui, sans ces tableaux de routage personnalisés et autres règles de routage, que la plupart des articles sur ce sujet débordent. Vérifions ?

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

Sur ISP1, nous avons indiqué l'adresse et la passerelle avec distance=2 et check-gateway=ping.
Sur ISP2, la configuration du client DHCP par défaut - par conséquent, la distance sera égale à un.
Sur ISP3, dans les paramètres du client PPPoE à add-default-route=yes nous fixons default-route-distance=3.

N'oublions pas de configurer le NAT à la sortie :

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

Au final, les utilisateurs des réseaux locaux peuvent accéder avec des chats via le fournisseur principal ISP2 et il y a une redondance du canal grâce au mécanisme check gateway Voir note 1

Le point 1 de la tâche est réalisé. Où est donc le multiwan avec ses étiquettes ? Non…

Ensuite. Nous devons faire sortir des clients spécifiques du LAN via ISP1 :

/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

Les points 2 et 3 de la tâche sont réalisés. Étiquettes, marques, règles de routage, où êtes-vous ?!

Faut-il donner accès au serveur OpenVPN préféré avec l'adresse 172.17.17.17 pour les clients de l'Internet ? Voici comment :

/ip cloud set ddns-enabled=yes

Aux clients, en tant qu'ami, nous donnons le résultat de la sortie : ":put [ip cloud get dns-name]”

Nous configurerons le redirection de port depuis Internet :

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

Le point 4 est prêt.

Nous configurons le pare-feu et autres sécurités pour le point 5, tout en réjouissant que les utilisateurs ont déjà tout fonctionnel et en nous penchant vers le récipient avec notre boisson préférée…
Ah ! Nous avons oublié les tunnels.

Le client L2TP, configuré selon un article trouvé sur Google, a-t-il atteint notre VDS néerlandais préféré ? Oui.
Le serveur L2TP avec IPsec a démarré et les clients par DNS-Name d'IP Cloud (voir ci-dessus) se connectent ? Oui.
Affalé sur le dossier de la chaise, sirotant notre boisson, nous contemplons paresseusement les points 6 et 7 de la tâche. Nous réfléchissons - en avons-nous vraiment besoin ? Tout fonctionne déjà (avec)… Ainsi, si cela n'est pas nécessaire, alors tout est dit. Multiwan réalisé.

Qu'est-ce que le multiwan ? C'est la connexion de plusieurs canaux Internet à un seul routeur.

Ensuite, l'article peut ne pas être lu, car que reste-t-il à part des frime qui suscite un doute sur son applicabilité ?

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

La tâche la plus importante de la mise en œuvre du multilan est un routage correct du trafic. C'est-à-dire : peu importe à quel (ou quels) fournisseur de services (voir note 3) le routeur pointe par défaut, il doit renvoyer la réponse au même canal d'où le paquet est venu. La tâche est claire. Mais où est le problème ? Car dans un réseau local simple, la tâche est la même, mais personne ne se complique la vie avec des réglages supplémentaires et aucun problème n’est ressenti. La différence est que chaque nœud routable sur Internet est accessible via chacun de nos canaux, et non via un canal spécifique comme dans un réseau local simple. Et le « problème » est que si nous recevons une requête pour l'adresse IP ISP3, dans notre cas la réponse sera envoyée par le canal ISP2, puisque c'est là que le routeur par défaut est dirigé. Elle sera envoyée et rejetée par le fournisseur comme incorrecte. Nous avons identifié le problème. Comment le résoudre ?

Divisons la solution 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, NAT hairpin, etc.
Multilan. À ce stade, les connexions nécessaires seront marquées et triées dans les tables de routage.
Connexion à l’ISP. À ce stade, les interfaces permettant la connexion à Internet seront configurées, le routage et le mécanisme de redondance des canaux Internet seront activés.

1. Préconfiguration

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

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

nous acceptons “Dangerous! Reset anyway? [y/N]:” et, après le redémarrage, nous nous connectons avec Winbox via MAC. À ce stade, la configuration et la base d’utilisateurs sont effacées.

1.2. Nous créons un nouvel utilisateur :

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

nous nous connectons avec celui-ci et supprimons l'utilisateur par défaut :

/user remove admin

Remarque. C'est précisément la suppression et non la désactivation de l'utilisateur par défaut que l'auteur considère comme plus sûr et recommande.

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

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

Nous annotons les interfaces

/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 remplissons 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 passé et facilite considérablement le dépannage et la compréhension de la configuration.

L'auteur estime qu'il est nécessaire, pour des raisons de sécurité, d'ajouter l'interface ether3 à la liste d'interface "WAN", même si le protocole IP ne passera pas par celle-ci.

N'oublions pas qu'après activation de l'interface PPP sur ether3, il faudra également l'ajouter à la liste d'interface "WAN".

1.4. Cacher le routeur des réseaux des fournisseurs pour empêcher la découverte et la gestion par adresse 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. Créer un ensemble minimal 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 permet les connexions établies et connues, initiées à la fois par les 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 plus que le ping. Tout l'icmp entrant est autorisé. Très utile pour détecter des problèmes de 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 le reste provenant d'Internet)

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

(la règle permet les connexions établies et connues qui passent à travers le routeur)

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

(la règle réinitialise les connexions avec connection-state=invalid qui passent à travers le routeur. Elle est fortement recommandée par Mikrotik, mais dans certaines situations rares, elle peut bloquer du 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 le passage à travers le routeur des paquets provenant d'Internet n'ayant pas subi le processus de dstnat. Cela protégera les réseaux locaux des attaquants qui, se trouvant dans un même domaine de diffusion que nos réseaux externes, utiliseraient nos IP externes comme passerelle et tenteraient ainsi d'explorer nos réseaux locaux.)

Remarque. Supposons que les réseaux LAN1 et LAN2 soient de confiance et que le trafic entre eux et depuis eux ne soit pas filtré.

1.6. Créer une liste des 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

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

Remarque. La liste peut changer, je recommande donc de vérifier périodiquement son exactitude.

1.7. Configurer le 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 dynamiques serveurs ont la priorité sur les adresses définies 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 fait en cas d'indisponibilité du serveur actuel. Le délai d'attente est long — plus de 5 secondes. Le retour en arrière, lors de la reprise du 'serveur tombé', ne se fait pas automatiquement. En tenant compte de cet algorithme et de la présence d'un multiprouter, l'auteur recommande de ne pas utiliser les serveurs fournis par les fournisseurs.

1.8. Configurons le réseau local.
1.8.1. Configurer les adresses IP statiques sur les interfaces des réseaux locaux :

/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. Définir les règles de routage 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 simples et rapides d'accéder aux adresses des réseaux locaux avec des sources d'adresses IP externes des interfaces du routeur, à travers lesquelles aucun routage par défaut n'est effectué.

1.8.3. Activer le 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 d'accéder à ses ressources (dstnat) via l'IP externe, tout en étant à l'intérieur du réseau.

2. En réalité, la mise en œuvre de ce multirouter correct

Pour résoudre la tâche 'répondre d'où l'on a demandé', nous allons utiliser deux outils ROS : marque de connexion et marque de routage. Marque de connexion permet de marquer la connexion souhaitée et de travailler par la suite avec cette marque comme condition pour son application marque de routage. Et déjà avec marque de routage il est possible de travailler dans ip route et règles de routage. Nous avons compris les outils, maintenant il faut décider quelles connexions marquer — première chose, où précisément faire ces marques — deuxième.

Pour la première, c'est simple : nous devons marquer toutes les connexions qui arrivent au routeur d'Internet via le canal correspondant. Dans notre cas, il y aura trois marques (pour le nombre de canaux) : 'conn_isp1', 'conn_isp2' et 'conn_isp3'.

Le point délicat concernant le second est que les connexions entrantes seront de deux types : transitaires et celles qui sont destinées au routeur lui-même. Le mécanisme de marque de connexion fonctionne dans la table mangle. Considérons le mouvement d'un paquet sur un diagramme simplifié, gracieusement réalisé par les spécialistes du site mikrotik-trainings.com (pas de publicité) :

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 ensuite se divise en transitaires et locaux dans le bloc 'Décision de routage. Donc, pour frapper deux oiseaux d'une pierre, utilisons la Marque de connexion dans la table Mangle Préroutage chaînes 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 prêter à confusion dans la compréhension, mais, en substance, il s'agit de la même chose, et c'est l'analogue des rt_tables dans iproute2 sur Linux.

2.1. Nous marquons les connexions entrantes de chaque fournisseur :

/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. Pour éviter de marquer des connexions déjà marquées, j'utilise la condition connection-mark=no-mark au lieu de connection-state=new, car je considère que c'est plus correct, tout comme le rejet des connexions invalides dans le filtre d'entrée.

passthrough=no — parce que dans cette méthode de mise en œuvre, le re-marquage est exclu et pour accélérer, nous pouvons interrompre la recherche de règles après la première correspondance.

Il faut garder à l'esprit que nous n'intervenons pour le moment pas dans le routage. Nous en sommes actuellement à la phase de préparation. La prochaine étape de mise en œuvre sera le traitement du trafic transit qui revient par une connexion établie de l'adresse à l'intérieur du réseau local. C'est-à-dire les paquets qui (voir le diagramme) ont passé le routeur sur le chemin :

« Input Interface »=>« Prerouting »=>« Routing Decision »=>« Forward »=>« Post Routing »=>« Output Interface » et ont atteint leur destinataire dans le réseau local.

Attention ! Dans ROS, il n'y a pas de division logique entre les interfaces externes et internes. Si l'on suit le chemin du paquet de réponse selon le diagramme fourni, il suivra le même chemin logique que la requête :

« Input Interface »=>« Prerouting »=>« Routing Decision »=>« Forward »=>« Post Routing »=>« Output Interface » simplement pour la requête «Input Interface» l'interface ISP, tandis que pour la réponse — LAN

2.2. Nous dirigeons le trafic transit de réponse correspondant aux tables de routage :

/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 ne travaillons qu'avec le trafic provenant du réseau local et dst-address-type=!local n'ayant pas d'adresse destination des interfaces du routeur lui-même.

La même chose pour les paquets locaux qui sont arrivés au routeur par le chemin :

« Input Interface »=>« Prerouting »=>« Routing Decision »=>« Input »=>« Local Process »

Attention ! La réponse suivra le chemin suivant :

« Local Process »=>« Routing Decision »=>« Output »=>« Post Routing »=>« Output Interface »

2.3. Nous dirigeons le trafic local de réponse par 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éparation à l'envoi de la réponse par le canal Internet d'où la requête est venue peut être considérée comme résolue. Tout est marqué, marqué et prêt à être routé.
Un excellent effet « secondaire » de cette configuration est la possibilité de faire du port forwarding DSNAT avec les deux fournisseurs (ISP2, ISP3) simultanément. Ce n'est pas le cas pour tous, car chez ISP1, nous avons une adresse non routable. Cet effet est important, par exemple, pour un serveur de messagerie avec deux MX, qui se connectent à différentes canaux Internet.

Pour résoudre les spécificités des réseaux locaux avec des IP externes des routeurs, nous utilisons des solutions des sections 1.8.2 et 3.1.2.6.

De plus, il est possible d'utiliser un outil avec des marquages pour traiter le point 3 de la tâche. Nous l'implémentons ainsi :

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

Au final, cela ressemble à peu près à ceci :

3. Nous configurons la connexion à ISP et mettons en place le routage par marquage

3.1. Nous configurons la connexion à ISP1 :
3.1.1. Nous configurons l'adresse IP statique :

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

3.1.2. Nous paramétrons le routage statique :
3.1.2.1. Nous ajoutons un itinéraire de secours par défaut :

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

Remarque. Cet itinéraire permet au trafic provenant des processus locaux de passer l'étape de décision de routage, indépendamment de l'état des canaux de l'un des fournisseurs. La spécificité du trafic local sortant est que pour qu'un paquet se déplace, un itinéraire actif vers la passerelle par défaut doit être présent dans la table de routage principale. S'il n'est pas là, le paquet sera simplement détruit.

En tant qu'extension de l'outil check gateway pour une analyse plus approfondie de l'état du canal, je propose d'utiliser la méthode des itinéraires récursifs. L'idée de la méthode est que nous indiquons au routeur de rechercher un chemin vers sa passerelle, non pas directement mais via une passerelle intermédiaire. Les passerelles « vérificatrices » choisies seront 4.2.2.1, 4.2.2.2 et 4.2.2.3 respectivement pour ISP1, ISP2 et ISP3.

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

/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. Nous réduisons la valeur de portée à celle par défaut dans la portée cible de ROS, afin d'utiliser par la suite 4.2.2.1 comme passerelle récursive. Je souligne : la portée de l'itinéraire vers l'adresse « vérificatrice » doit être inférieure ou égale à la portée cible de l'itinéraire qui fera référence à la vérificatrice.

3.1.2.3. Itinéraire récursif par défaut pour le trafic sans marque de routage :

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

Remarque. La valeur distance=2 est utilisée parce qu'ISP1 a été désigné comme premier secours dans les conditions de la tâche.

3.1.2.4. Itinéraire récursif 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. Enfin, nous commençons ici à bénéficier des fruits de cette préparation réalisée au point 2.

Tout le trafic ayant la marque de route "to_isp1" sera dirigé vers la passerelle du premier fournisseur, quel que soit le pont d'accès par défaut actuellement actif pour la table principale.

3.1.2.5. Première route de secours récursive par défaut pour le trafic marqué 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 la sauvegarde du trafic provenant des réseaux locaux qui se trouvent dans la liste d'adresses "to_isp*".

3.1.2.6. Nous définissons la route pour le trafic local du routeur vers Internet via ISP1 :

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

Remarque. Combiné avec les règles du point 1.8.2, cela garantit la sortie dans le canal requis avec la source spécifiée. Ceci est critique pour la création de tunnels où l'adresse IP du côté local est configurée (EoIP, IP-IP, GRE). Étant donné que les règles dans les règles de routage IP sont exécutées de haut en bas, jusqu'à la première correspondance des conditions, cette règle doit être après les règles du point 1.8.2.

3.1.3. Nous définissons une 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 pour tout le trafic sortant, sauf pour celui qui entre dans les politiques IPsec. J'essaie d'éviter d'utiliser action=masquerade sauf en cas de nécessité extrême. Cela fonctionne plus lentement et consomme plus de ressources que src-nat, car il calcule l'adresse pour NAT pour chaque nouvelle connexion.

3.1.4. Nous dirigeons les clients de la liste, à qui l'accès est interdit via les autres fournisseurs, directement vers 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=route a une priorité plus élevée et s'applique avant les autres règles de routage.

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

3.2. Configuration de la connexion à ISP2.

Étant donné que le fournisseur ISP2 nous fournit les paramètres via DHCP, il est raisonnable d'apporter les modifications nécessaires avec un script qui se déclenche lorsque le client DHCP s'active :

/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

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

Remarque. La première partie du script s'active lors de l'obtention réussie de la location, la seconde après la libération de la location.Voir la note 2

3.3. Configuration de la connexion avec le fournisseur ISP3.

Étant donné que le fournisseur nous fournit des paramètres dynamiques, il est raisonnable d'apporter les modifications nécessaires avec des scripts qui démarrent après le démarrage et l'arrêt de l'interface PPP.

3.3.1. D'abord, configurons le 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"

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

Remarque. Chaîne
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
permet de gérer correctement le renommage de l'interface, car il fonctionne avec son code et non avec son nom affiché.

3.3.2. Maintenant, en utilisant le profil, créons 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

Pour finir, configurons l'heure :

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

Pour ceux qui ont lu jusqu'à la fin

La méthode de mise en œuvre du multi-WAN proposée est une préférence personnelle de l'auteur et n'est pas la seule possible. Les outils de ROS sont vastes et flexibles, ce qui d'une part complique la tâche pour les débutants, d'autre part est la raison de sa popularité. Explorez, essayez, découvrez de nouveaux outils et solutions. Par exemple, dans cette mise en œuvre du multi-WAN, on peut remplacer l'outil Check-gateway avec des routes récursives par Netwatch.

Notes

Check-gateway — un mécanisme qui permet de désactiver une route après deux vérifications consécutives infructueuses de la disponibilité du passerelle. La vérification est effectuée toutes les 10 secondes, plus le délai d'attente de réponse. En tout, le temps de commutation réel se situe entre 20 et 30 secondes. Si ce timing de commutation n'est pas suffisant — il y a une option d'utiliser l'outil Netwatch, où le minuteur de vérification peut être défini manuellement. Le mécanisme Check-gateway ne s'active pas lors de pertes de paquets périodiques dans le canal.
Important ! La désactivation de la route principale entraîne la désactivation de toutes les autres routes qui y font référence. Il n'est donc pas nécessaire de spécifier check-gateway=ping .
Il arrive qu'il y ait un échec dans le fonctionnement de DHCP, qui apparaît comme un client bloqué dans l'état renew. Dans ce cas, la seconde partie du script ne fonctionnera pas, mais cela ne gênera pas le trafic, car l'état est suivi par la route récursive correspondante.
ECMP (Equal Cost Multi-Path) — dans ROS, il est possible de définir une route avec plusieurs passerelles ayant la même distance. Dans ce cas, les connexions seront réparties sur les canaux, en utilisant l'algorithme round robin, proportionnellement au nombre de passerelles spécifiées.

Pour le coup de pouce à la rédaction de l'article, l'aide à la structuration et à la mise en avant des points importants — un remerciement personnel à Yevgeny @jscar

Source : habr.com

MultiWAN et routage sur Mikrotik RouterOS