Principes de base du routage statique dans Mikrotik RouterOS

Le routage est le processus de recherche du meilleur chemin pour transmettre des paquets sur des réseaux TCP/IP. Tout appareil connecté à un réseau IPv4 contient un processus et des tables de routage.

Cet article n'est pas un HOWTO, il décrit le routage statique dans RouterOS avec des exemples, j'ai délibérément omis le reste des paramètres (par exemple, srcnat pour accéder à Internet), donc comprendre le matériel nécessite un certain niveau de connaissance des réseaux et de RouterOS.

Commutation et routage

La commutation est le processus d'échange de paquets au sein d'un segment Layer2 (Ethernet, ppp, ...). Si l'appareil voit que le destinataire du paquet se trouve sur le même sous-réseau Ethernet avec lui, il apprend l'adresse mac à l'aide du protocole arp et transmet le paquet directement, en contournant le routeur. Une connexion ppp (point à point) ne peut avoir que deux participants et le paquet est toujours envoyé à une adresse 0xff.

Le routage est le processus de transfert de paquets entre les segments Layer2. Si un appareil veut envoyer un paquet dont le destinataire est en dehors du segment Ethernet, il consulte sa table de routage et transmet le paquet à la passerelle, qui sait où envoyer le paquet ensuite (ou peut ne pas savoir, l'expéditeur d'origine du paquet n'en est pas conscient).

La façon la plus simple de considérer un routeur est comme un périphérique connecté à deux segments de couche 2 ou plus et capable de transmettre des paquets entre eux en déterminant le meilleur itinéraire à partir de la table de routage.

Si vous comprenez tout, ou si vous le saviez déjà, alors lisez la suite. Pour le reste, je vous recommande vivement de vous familiariser avec un petit, mais très volumineux article.

Routage dans RouterOS et PacketFlow

Presque toutes les fonctionnalités liées au routage statique sont dans le package combustion propre. Sac plastique routage ajoute la prise en charge des algorithmes de routage dynamique (RIP, OSPF, BGP, MME), des filtres de routage et de BFD.

Menu principal de configuration du routage : [IP]->[Route]. Des schémas complexes peuvent nécessiter que les paquets soient pré-étiquetés avec une marque de routage dans : [IP]->[Firewall]->[Mangle] (Chaînes PREROUTING и OUTPUT).

Il y a trois endroits sur PacketFlow où les décisions de routage des paquets IP sont prises :

1. Routage des paquets reçus par le routeur. A ce stade, il est décidé si le paquet ira au processus local ou sera envoyé plus loin sur le réseau. Les colis de transit reçoivent Interface de sortie
2. Routage des paquets sortants locaux. Les paquets sortants reçoivent Interface de sortie
3. Étape de routage supplémentaire pour les paquets sortants, vous permet de modifier la décision de routage dans [Output|Mangle]

• Le chemin de paquet dans les blocs 1, 2 dépend des règles dans [IP]->[Route]
• Le chemin du paquet aux points 1, 2 et 3 dépend des règles en [IP]->[Route]->[Rules]
• Le chemin du paquet dans les blocs 1, 3 peut être influencé en utilisant [IP]->[Firewall]->[Mangle]

RIB, FIB, cache de routage

Base d'informations de routage
La base dans laquelle sont collectées les routes des protocoles de routage dynamique, les routes de ppp et dhcp, les routes statiques et connectées. Cette base de données contient toutes les routes, sauf celles filtrées par l'administrateur.

Conditionnellement, on peut supposer que [IP]->[Route] affiche RIB.

Base d'informations de transfert

La base dans laquelle les meilleurs itinéraires de RIB sont collectés. Toutes les routes du FIB sont actives et sont utilisées pour transférer les paquets. Si la route devient inactive (désactivée par l'administrateur (système) ou si l'interface par laquelle le paquet doit être envoyé n'est pas active), la route est supprimée du FIB.

Pour prendre une décision de routage, la table FIB utilise les informations suivantes sur un paquet IP :

• Adresse source
• Adresse de destination
• interfaces sources
• Marque de routage
• Conditions d'utilisation (DSCP)

L'entrée dans le package FIB passe par les étapes suivantes :

• Le package est-il destiné à un processus de routeur local ?
• Le paquet est-il soumis aux règles PBR du système ou de l'utilisateur ?
  • Si oui, alors le paquet est envoyé à la table de routage spécifiée
• Le paquet est envoyé à la table principale

Conditionnellement, on peut supposer que [IP]->[Route Active=yes] affiche FIB.

Cache de routage
Mécanisme de mise en cache des routes. Le routeur se souvient où les paquets ont été envoyés et s'il y en a des similaires (vraisemblablement de la même connexion), il les laisse suivre le même itinéraire, sans vérifier dans le FIB. Le cache de route est périodiquement vidé.

Pour les administrateurs RouterOS, ils n'ont pas créé d'outils pour afficher et gérer le cache de routage, mais lorsqu'il peut être désactivé dans [IP]->[Settings].

Ce mécanisme a été supprimé du noyau linux 3.6, mais RouterOS utilise toujours le noyau 3.3.5, peut-être que Routing cahce est l'une des raisons.

Boîte de dialogue Ajouter un itinéraire

[IP]->[Route]->[+]

1. Sous-réseau pour lequel vous souhaitez créer une route (par défaut : 0.0.0.0/0)
2. Passerelle IP ou interface à laquelle le paquet sera envoyé (il peut y en avoir plusieurs, voir ECMP ci-dessous)
3. Vérification de la disponibilité de la passerelle
4. Type d'enregistrement
5. Distance (métrique) pour un itinéraire
6. Table de routage
7. IP pour les paquets sortants locaux via cette route
8. Le but de la portée et de la portée cible est écrit à la fin de l'article.

Indicateurs d'itinéraire

• X - La route est désactivée par l'administrateur (disabled=yes)
• A - La route est utilisée pour envoyer des paquets
• D - Route ajoutée dynamiquement (BGP, OSPF, RIP, MME, PPP, DHCP, Connecté)
• C - Le sous-réseau est connecté directement au routeur
• S - Route statique
• r,b,o,m - Route ajoutée par l'un des protocoles de routage dynamique
• B,U,P - Route de filtrage (abandonne les paquets au lieu de les transmettre)

Que spécifier dans la passerelle : adresse IP ou interface ?

Le système vous permet de spécifier les deux, alors qu'il ne jure pas et ne donne pas d'indices si vous avez fait quelque chose de mal.

Adresse IP
L'adresse de la passerelle doit être accessible sur Layer2. Pour Ethernet, cela signifie que le routeur doit avoir une adresse du même sous-réseau sur l'une des interfaces ip actives, pour ppp, que l'adresse de la passerelle est spécifiée sur l'une des interfaces actives comme adresse de sous-réseau.
Si la condition d'accessibilité pour la couche 2 n'est pas remplie, la route est considérée comme inactive et ne tombe pas dans le FIB.

Interface
Tout est plus compliqué et le comportement du routeur dépend du type d'interface :

• La connexion PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) ne suppose que deux participants et le paquet sera toujours envoyé à la passerelle pour transmission, si la passerelle détecte que le destinataire est lui-même, alors il transférera le paquet à son processus local.
  
• Ethernet suppose la présence de nombreux participants et enverra des requêtes à l'interface arp avec l'adresse du destinataire du paquet, c'est un comportement attendu et tout à fait normal pour les routes connectées.
  Mais lorsque vous essayez d'utiliser l'interface comme route pour un sous-réseau distant, vous obtenez la situation suivante : la route est active, le ping vers la passerelle passe, mais n'atteint pas le destinataire du sous-réseau spécifié. Si vous regardez l'interface via un renifleur, vous verrez des requêtes arp avec des adresses d'un sous-réseau distant.
  

Essayez de spécifier l'adresse IP comme passerelle dans la mesure du possible. L'exception concerne les routes connectées (créées automatiquement) et les interfaces PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*).

OpenVPN ne contient pas d'en-tête PPP, mais vous pouvez utiliser le nom de l'interface OpenVPN pour créer une route.

Itinéraire plus spécifique

Règle de routage de base. La route qui décrit le sous-réseau le plus petit (avec le plus grand masque de sous-réseau) est prioritaire dans la décision de routage du paquet. La position des entrées dans la table de routage n'est pas pertinente pour le choix - la règle principale est plus spécifique.

Toutes les routes du schéma spécifié sont actives (situées dans FIB). pointent vers des sous-réseaux différents et n'entrent pas en conflit les uns avec les autres.

Si l'une des passerelles devient indisponible, la route associée sera considérée comme inactive (supprimée du FIB) et les paquets seront recherchés à partir des routes restantes.

La route avec le sous-réseau 0.0.0.0/0 a parfois une signification particulière et est appelée "route par défaut" ou "passerelle de dernier recours". En fait, il n'y a rien de magique à ce sujet et il inclut simplement toutes les adresses IPv4 possibles, mais ces noms décrivent bien sa tâche - il indique la passerelle où transférer les paquets pour lesquels il n'y a pas d'autres routes plus précises.

Le masque de sous-réseau maximum possible pour IPv4 est /32, cette route pointe vers un hôte spécifique et peut être utilisée dans la table de routage.

Comprendre une route plus spécifique est fondamental pour tout périphérique TCP/IP.

Tarifs Distance

Les distances (ou métriques) sont requises pour le filtrage administratif des routes vers un seul sous-réseau accessible via plusieurs passerelles. Une route avec une métrique inférieure est considérée comme prioritaire et sera incluse dans le FIB. Si une route avec une métrique inférieure cesse d'être active, elle sera remplacée par une route avec une métrique supérieure dans le FIB.

S'il existe plusieurs routes vers le même sous-réseau avec la même métrique, le routeur n'en ajoutera qu'une seule à la table FIB, guidé par sa logique interne.

La métrique peut prendre une valeur comprise entre 0 et 255 :

• 0 - Métrique pour les routes connectées. La distance 0 ne peut pas être définie par l'administrateur
• 1-254 - Métriques disponibles pour l'administrateur pour la configuration des itinéraires. Les métriques avec une valeur inférieure ont une priorité plus élevée
• 255 - Métrique disponible pour l'administrateur pour la définition des itinéraires. Contrairement à 1-254, une route avec une métrique de 255 reste toujours inactive et ne tombe pas dans le FIB
• métriques spécifiques. Les routes dérivées des protocoles de routage dynamique ont des valeurs métriques standard

vérifier la passerelle

Check gateway est une extension MikroTik RoutesOS permettant de vérifier la disponibilité de la passerelle via icmp ou arp. Une fois toutes les 10 secondes (non modifiable), une requête est envoyée à la passerelle, si la réponse n'est pas reçue deux fois, la route est considérée comme indisponible et est supprimée du FIB. Si la vérification de la passerelle a été désactivée, la vérification de la route se poursuit et la route redevient active après une vérification réussie.

Vérifier la passerelle désactive l'entrée dans laquelle elle est configurée et toutes les autres entrées (dans toutes les tables de routage et routes ecmp) avec la passerelle spécifiée.

En général, la vérification de la passerelle fonctionne correctement tant qu'il n'y a pas de problèmes de perte de paquets vers la passerelle. La passerelle de vérification ne sait pas ce qui se passe avec la communication en dehors de la passerelle vérifiée, cela nécessite des outils supplémentaires : scripts, routage récursif, protocoles de routage dynamique.

La plupart des protocoles VPN et de tunnel contiennent des outils intégrés pour vérifier l'activité de connexion, l'activation de la passerelle de vérification pour eux est une charge supplémentaire (mais très faible) sur les performances du réseau et de l'appareil.

Itinéraires ECMP

Multi-chemin à coût égal - envoi de paquets au destinataire à l'aide de plusieurs passerelles simultanément à l'aide de l'algorithme Round Robin.

Une route ECMP est créée par l'administrateur en spécifiant plusieurs passerelles pour un sous-réseau (ou automatiquement, s'il existe deux routes OSPF équivalentes).

ECMP est utilisé pour l'équilibrage de charge entre deux canaux, en théorie, s'il y a deux canaux dans la route ecmp, alors pour chaque paquet, le canal sortant doit être différent. Mais le mécanisme de cache de routage envoie les paquets de la connexion le long de la route empruntée par le premier paquet. Par conséquent, nous obtenons une sorte d'équilibrage basé sur les connexions (équilibrage de charge par connexion).

Si vous désactivez le cache de routage, les paquets de la route ECMP seront partagés correctement, mais il y a un problème avec NAT. La règle NAT ne traite que le premier paquet de la connexion (les autres sont traités automatiquement), et il s'avère que les paquets avec la même adresse source quittent des interfaces différentes.

Vérifier que la passerelle ne fonctionne pas dans les routes ECMP (bogue RouterOS). Mais vous pouvez contourner cette limitation en créant des itinéraires de validation supplémentaires qui désactiveront les entrées dans ECMP.

Filtrage par Routage

L'option Type détermine ce qu'il faut faire du package :

• unicast - envoyer à la passerelle spécifiée (interface)
• trou noir - jeter un paquet
• interdire, inaccessible - rejeter le paquet et envoyer un message icmp à l'expéditeur

Le filtrage est généralement utilisé lorsqu'il est nécessaire de sécuriser l'envoi de paquets sur le mauvais chemin, bien sûr, vous pouvez filtrer cela à travers le pare-feu.

Quelques exemples

Consolider les éléments de base du routage.

Routeur domestique typique

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1

1. Route statique vers 0.0.0.0/0 (route par défaut)
2. Route connectée sur l'interface avec le fournisseur
3. Route connectée sur l'interface LAN

Routeur domestique typique avec PPPoE

1. Route statique vers la route par défaut, ajoutée automatiquement. il est spécifié dans les propriétés de connexion
2. Route connectée pour la connexion PPP
3. Route connectée sur l'interface LAN

Routeur domestique typique avec deux fournisseurs et redondance

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

1. Route statique vers la route par défaut via le premier fournisseur avec métrique 1 et vérification de la disponibilité de la passerelle
2. Route statique vers la route par défaut via le deuxième fournisseur avec la métrique 2
3. Itinéraires connectés

Le trafic vers 0.0.0.0/0 passe par 10.10.10.1 tant que cette passerelle est disponible, sinon il bascule vers 10.20.20.1

Un tel schéma peut être considéré comme une réservation de canal, mais il n'est pas sans inconvénients. Si une coupure se produit en dehors de la passerelle du fournisseur (par exemple, à l'intérieur du réseau de l'opérateur), votre routeur ne le saura pas et continuera à considérer la route comme active.

Routeur domestique typique avec deux fournisseurs, redondance et ECMP

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.10.10.1,10.20.20.1 distance=1

1. Routes statiques pour vérifier la passerelle chack
2. Itinéraire ECMP
3. Itinéraires connectés

Les routes à vérifier sont bleues (la couleur des routes inactives), mais cela n'interfère pas avec la passerelle de vérification. La version actuelle (6.44) de RoS donne automatiquement la priorité à la route ECMP, mais il est préférable d'ajouter des routes de test à d'autres tables de routage (option routing-mark)

Sur Speedtest et d'autres sites similaires, il n'y aura pas d'augmentation de la vitesse (ECMP divise le trafic par connexions, pas par paquets), mais les applications p2p devraient se télécharger plus rapidement.

Filtrage par routage

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1
add dst-address=192.168.200.0/24 gateway=10.30.30.1 distance=1
add dst-address=192.168.200.0/24 gateway=10.10.10.1 distance=2 type=blackhole

1. Route statique vers route par défaut
2. Route statique vers 192.168.200.0/24 via le tunnel ipip
3. Interdire la route statique vers 192.168.200.0/24 via le routeur ISP

Une option de filtrage dans laquelle le trafic du tunnel n'ira pas au routeur du fournisseur lorsque l'interface ipip est désactivée. De tels régimes sont rarement nécessaires, parce que vous pouvez implémenter le blocage via le pare-feu.

Boucle de routage
Boucle de routage - une situation dans laquelle un paquet s'exécute entre les routeurs avant l'expiration du ttl. C'est généralement le résultat d'une erreur de configuration, dans les grands réseaux, il est traité par la mise en œuvre de protocoles de routage dynamique, dans les petits - avec précaution.

Cela ressemble à ceci:

Un exemple (le plus simple) de la façon d'obtenir un résultat similaire :

L'exemple de la boucle de routage n'est d'aucune utilité pratique, mais il montre que les routeurs n'ont aucune idée de la table de routage de leur voisin.

Routage de base de stratégie et tables de routage supplémentaires

Lors du choix d'une route, le routeur n'utilise qu'un seul champ de l'en-tête de paquet (adresse Dst.) - c'est le routage de base. Le routage basé sur d'autres conditions, telles que l'adresse source, le type de trafic (ToS), l'équilibrage sans ECMP, appartient au Policy Base Routing (PBR) et utilise des tables de routage supplémentaires.

Itinéraire plus spécifique est la principale règle de sélection de route dans la table de routage.

Par défaut, toutes les règles de routage sont ajoutées à la table principale. L'administrateur peut créer un nombre arbitraire de tables de routage supplémentaires et y acheminer des paquets. Les règles des différentes tables n'entrent pas en conflit les unes avec les autres. Si le package ne trouve pas de règle appropriée dans la table spécifiée, il ira à la table principale.

Exemple avec diffusion via Firewall :

• 192.168.100.10 -> 8.8.8.8
  1. Le trafic provenant de 192.168.100.10 est étiqueté via-isp1 в [Prerouting|Mangle]
  2. A l'étape Routage dans la table via-isp1 recherche une route vers 8.8.8.8
  3. Route trouvée, le trafic est envoyé à la passerelle 10.10.10.1
• 192.168.200.20 -> 8.8.8.8
  1. Le trafic provenant de 192.168.200.20 est étiqueté via-isp2 в [Prerouting|Mangle]
  2. A l'étape Routage dans la table via-isp2 recherche une route vers 8.8.8.8
  3. Route trouvée, le trafic est envoyé à la passerelle 10.20.20.1
• Si l'une des passerelles (10.10.10.1 ou 10.20.20.1) devient indisponible, le paquet ira à la table principal et cherchera un itinéraire approprié là-bas

Problèmes de terminologie

RouterOS a certains problèmes de terminologie.
Lorsque vous travaillez avec des règles dans [IP]->[Routes] la table de routage est indiquée, bien qu'il soit écrit que l'étiquette :

В [IP]->[Routes]->[Rule] tout est correct, dans la condition d'étiquette dans l'action de table :

Comment envoyer un paquet à une table de routage spécifique

RouterOS fournit plusieurs outils :

• Règles en [IP]->[Routes]->[Rules]
• Marqueurs de route (action=mark-routing) Dans [IP]->[Firewall]->[Mangle]
• VRF

Règles [IP]->[Route]->[Rules]
Les règles sont traitées séquentiellement, si le paquet correspond aux conditions de la règle, il ne passe pas plus loin.

Les règles de routage vous permettent d'étendre les possibilités de routage, en s'appuyant non seulement sur l'adresse du destinataire, mais également sur l'adresse et l'interface source sur lesquelles le paquet a été reçu.

Les règles consistent en des conditions et une action :

• Conditions. Répétez pratiquement la liste des signes par lesquels le colis est vérifié dans le FIB, seul le ToS manque.
• Activité
  • lookup - envoie un paquet à une table
  • recherche uniquement dans la table - verrouille le paquet dans la table, si la route n'est pas trouvée, le paquet n'ira pas à la table principale
  • drop - déposer un paquet
  • inaccessible - rejeter le paquet avec notification de l'expéditeur

Dans FIB, le trafic vers les processus locaux est traité en contournant les règles [IP]->[Route]->[Rules]:

marquage [IP]->[Firewall]->[Mangle]
Les étiquettes de routage vous permettent de définir la passerelle pour un paquet en utilisant presque toutes les conditions de pare-feu :

Pratiquement, car tous n'ont pas de sens et certains peuvent fonctionner de manière instable.

Il existe deux manières d'étiqueter un colis :

• Mettre tout de suite marque de routage
• Mettre en premier marque de connexion, puis basé sur marque de connexion définir marque de routage

Dans un article sur les pare-feu, j'ai écrit que la deuxième option est préférable. réduit la charge sur le processeur, dans le cas du marquage des itinéraires - ce n'est pas tout à fait vrai. Ces méthodes de marquage ne sont pas toujours équivalentes et sont généralement utilisées pour résoudre divers problèmes.

Exemples d'utilisation

Passons aux exemples d'utilisation du routage de base de stratégie, ils sont beaucoup plus faciles à montrer pourquoi tout cela est nécessaire.

MultiWAN et retour du trafic sortant (sortie)
Un problème courant avec une configuration MultiWAN : Mikrotik n'est disponible sur Internet que par l'intermédiaire d'un fournisseur "actif".

Le routeur ne se soucie pas de l'adresse IP à laquelle la demande est parvenue, lors de la génération d'une réponse, il recherchera une route dans la table de routage où la route via isp1 est active. De plus, un tel paquet sera très probablement filtré en cours de route vers le destinataire.

Un autre point intéressant. Si un nat source "simple" est configuré sur l'interface ether1 : /ip fi nat add out-interface=ether1 action=masquerade le paquet sera mis en ligne avec src. address=10.10.10.100, ce qui rend les choses encore pires.

Il existe plusieurs façons de résoudre le problème, mais chacune d'entre elles nécessitera des tables de routage supplémentaires :

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping distance=2
add dst-address=0.0.0.0/0 gateway=10.10.10.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 routing-mark=over-isp2

l'utilisation de [IP]->[Route]->[Rules]
Spécifiez la table de routage qui sera utilisée pour les paquets avec l'adresse IP source spécifiée.

/ip route rule
add src-address=10.10.10.100/32 action=lookup-only-in-table table=over-isp1
add src-address=10.20.20.200/32 action=lookup-only-in-table table=over-isp2

Peut utiliser action=lookup, mais pour le trafic sortant local, cette option exclut complètement les connexions de la mauvaise interface.

• Le système génère un paquet de réponse avec Src. Adresse : 10.20.20.200
• L'étape Décision de routage(2) vérifie [IP]->[Routes]->[Rules] et le paquet est envoyé à la table de routage sur-isp2
• Selon la table de routage, le paquet doit être envoyé à la passerelle 10.20.20.1 via l'interface ether2

Cette méthode ne nécessite pas de suivi de connexion fonctionnel, contrairement à l'utilisation de la table Mangle.

l'utilisation de [IP]->[Firewall]->[Mangle]
La connexion commence par un paquet entrant, nous le marquons donc (action=mark-connection), pour les paquets sortants d'une connexion marquée, définissez l'étiquette de routage (action=mark-routing).

/ip firewall mangle
#Маркировка входящих соединений
add chain=input in-interface=ether1 connection-state=new action=mark-connection new-connection-mark=from-isp1
add chain=input in-interface=ether2 connection-state=new action=mark-connection new-connection-mark=from-isp2
#Маркировка исходящих пакетов на основе соединений
add chain=output connection-mark=from-isp1 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=output connection-mark=from-isp2 action=mark-routing new-routing-mark=over-isp2 passthrough=no

Si plusieurs ips sont configurés sur une interface, vous pouvez ajouter à la condition dst-address être sûr.

• Un paquet ouvre la connexion sur l'interface ether2. Le colis entre dans [INPUT|Mangle] qui dit de marquer tous les paquets de la connexion comme depuis-isp2
• Le système génère un paquet de réponse avec Src. Adresse : 10.20.20.200
• A l'étape Routing Decision(2), le paquet, conformément à la table de routage, est envoyé à la passerelle 10.20.20.1 via l'interface ether1. Vous pouvez le vérifier en enregistrant les packages dans [OUTPUT|Filter]
• À l'étape [OUTPUT|Mangle] l'étiquette de connexion est cochée depuis-isp2 et le paquet reçoit une étiquette de route sur-isp2
• L'étape Routing Adjustment(3) vérifie la présence d'une étiquette de routage et l'envoie à la table de routage appropriée.
• Selon la table de routage, le paquet doit être envoyé à la passerelle 10.20.20.1 via l'interface ether2

Trafic multiWAN et retour dst-nat

Un exemple est plus compliqué, que faire s'il y a un serveur (par exemple, Web) derrière le routeur sur un sous-réseau privé et que vous devez en fournir l'accès via l'un des fournisseurs.

/ip firewall nat
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether1 action=dst-nat to-address=192.168.100.100
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether2 action=dst-nat to-address=192.168.100.100

L'essence du problème sera la même, la solution est similaire à l'option Firewall Mangle, seules les autres chaînes seront utilisées :

/ip firewall mangle
add chain=prerouting connection-state=new in-interface=ether1 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp1
add chain=prerouting connection-state=new in-interface=ether2 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp2
add chain=prerouting connection-mark=web-input-isp1 in-interface=ether3 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting connection-mark=web-input-isp2 in-interface=ether3 action=mark-routing new-routing-mark=over-isp2 passthrough=no

Le diagramme ne montre pas NAT, mais je pense que tout est clair.

MultiWAN et connexions sortantes

Vous pouvez utiliser les fonctionnalités PBR pour créer plusieurs connexions vpn (SSTP dans l'exemple) à partir de différentes interfaces de routeur.

Tables de routage supplémentaires :

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.100.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 routing-mark=over-isp3

add dst-address=0.0.0.0/0 gateway=192.168.100.1 distance=1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 distance=2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 distance=3

Marquages ​​de l'emballage :

/ip firewall mangle
add chain=output dst-address=10.10.10.100 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp1 passtrough=no
add chain=output dst-address=10.10.10.101 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp2 passtrough=no
add chain=output dst-address=10.10.10.102 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp3 passtrough=no

Règles NAT simples, sinon le paquet quittera l'interface avec le mauvais Src. adresse:

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade
add chain=srcnat out-interface=ether2 action=masquerade
add chain=srcnat out-interface=ether3 action=masquerade

Analyse:

• Le routeur crée trois processus SSTP
• À l'étape de décision de routage (2), une route est sélectionnée pour ces processus sur la base de la table de routage principale. De la même route, le paquet reçoit Src. Adresse liée à l'interface ether1
• В [Output|Mangle] les paquets provenant de différentes connexions reçoivent des étiquettes différentes
• Les paquets entrent dans les tables correspondant aux étiquettes à l'étape d'ajustement du routage et reçoivent une nouvelle route pour l'envoi des paquets
• Mais les paquets ont toujours Src. Adresse d'ether1, sur scène [Nat|Srcnat] l'adresse est substituée selon l'interface

Fait intéressant, sur le routeur, vous verrez le tableau de connexion suivant :

Connection Tracker fonctionne plus tôt [Mangle] и [Srcnat], donc toutes les connexions proviennent de la même adresse, si vous regardez plus en détail, alors dans Replay Dst. Address il y aura des adresses après NAT :

Sur le serveur VPN (j'en ai un sur le banc de test), vous pouvez voir que toutes les connexions proviennent des bonnes adresses :

Tiens le chemin
Il existe un moyen plus simple, vous pouvez simplement spécifier une passerelle spécifique pour chacune des adresses :

/ip route
add dst-address=10.10.10.100 gateway=192.168.100.1
add dst-address=10.10.10.101 gateway=192.168.200.1
add dst-address=10.10.10.102 gateway=192.168.0.1

Mais ces itinéraires affecteront non seulement le trafic sortant mais aussi le trafic de transit. De plus, si vous n'avez pas besoin de trafic vers le serveur vpn pour passer par des canaux de communication inappropriés, vous devrez ajouter 6 règles supplémentaires à [IP]->[Routes]с type=blackhole. Dans la version précédente - 3 règles dans [IP]->[Route]->[Rules].

Répartition des connexions utilisateurs par canaux de communication

Tâches simples et quotidiennes. Encore une fois, des tables de routage supplémentaires seront nécessaires :

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2

Utilisation [IP]->[Route]->[Rules]

/ip route rules
add src-address=192.168.100.0/25 action=lookup-only-in-table table=over-isp1
add src-address=192.168.100.128/25 action=lookup-only-in-table table=over-isp2

Si utilisation action=lookup, puis lorsque l'un des canaux est désactivé, le trafic ira à la table principale et passera par le canal de travail. Que cela soit nécessaire ou non dépend de la tâche.

En utilisant les marques de [IP]->[Firewall]->[Mangle]
Un exemple simple avec des listes d'adresses IP. En principe, presque toutes les conditions peuvent être utilisées. La seule mise en garde de la couche 7, même lorsqu'elle est associée à des étiquettes de connexion, il peut sembler que tout fonctionne correctement, mais une partie du trafic ira toujours dans le mauvais sens.

/ip firewall mangle
add chain=prerouting src-address-list=users-over-isp1 dst-address-type=!local action=mark-routing new-routing-mark=over-isp1
add chain=prerouting src-address-list=users-over-isp2 dst-address-type=!local action=mark-routing new-routing-mark=over-isp2

Vous pouvez "verrouiller" les utilisateurs dans une table de routage via [IP]->[Route]->[Rules]:

/ip route rules
add routing-mark=over-isp1 action=lookup-only-in-table table=over-isp1
add routing-mark=over-isp2 action=lookup-only-in-table table=over-isp2

Soit par [IP]->[Firewall]->[Filter]:

/ip firewall filter
add chain=forward routing-mark=over-isp1 out-interface=!ether1 action=reject
add chain=forward routing-mark=over-isp2 out-interface=!ether2 action=reject

Retraite pro dst-address-type=!local
Condition supplémentaire dst-address-type=!local il faut que le trafic des utilisateurs atteigne les processus locaux du routeur (dns, winbox, ssh, ...). Si plusieurs sous-réseaux locaux sont connectés au routeur, il est nécessaire de s'assurer que le trafic entre eux ne va pas vers Internet, par exemple en utilisant dst-address-table.

Dans l'exemple utilisant [IP]->[Route]->[Rules] il n'y a pas de telles exceptions, mais le trafic atteint les processus locaux. Le fait est qu'entrer dans le package FIB marqué dans [PREROUTING|Mangle] a une étiquette de route et va dans une table de routage autre que main, où il n'y a pas d'interface locale. Dans le cas des règles de routage, on vérifie d'abord si le paquet est destiné à un processus local et ce n'est qu'à l'étape User PBR qu'il va à la table de routage spécifiée.

Utilisation [IP]->[Firewall]->[Mangle action=route]
Cette action ne fonctionne que dans [Prerouting|Mangle] et vous permet de diriger le trafic vers la passerelle spécifiée sans utiliser de tables de routage supplémentaires, en spécifiant directement l'adresse de la passerelle :

/ip firewall mangle
add chain=prerouting src-address=192.168.100.0/25 action=route gateway=10.10.10.1
add chain=prerouting src-address=192.168.128.0/25 action=route gateway=10.20.20.1

Действие route a une priorité inférieure aux règles de routage ([IP]->[Route]->[Rules]). Dans le cas des marques de route, tout dépend de la position des règles, si la règle avec action=route vaut plus que action=mark-route, alors il sera utilisé (quel que soit le drapeau passtrough), sinon balisage de l'itinéraire.
Il y a très peu d'informations sur le wiki à propos de cette action et toutes les conclusions sont obtenues expérimentalement, en tout cas, je n'ai pas trouvé d'options lorsque l'utilisation de cette option donne des avantages par rapport aux autres.

Équilibrage dynamique basé sur PPC

Per Connection Classifier - est un analogue plus flexible d'ECMP. Contrairement à ECMP, il divise le trafic par connexions de manière plus stricte (ECMP ne sait rien des connexions, mais lorsqu'il est associé à Routing Cache, quelque chose de similaire est obtenu).

PCC prend champs spécifiés à partir de l'en-tête ip, les convertit en une valeur 32 bits et divise par dénominateur. Le reste de la division est comparé avec la valeur spécifiée reste et s'ils correspondent, l'action spécifiée est appliquée. Plus. Cela semble fou, mais cela fonctionne.

Exemple avec trois adresses :

192.168.100.10: 192+168+100+10 = 470 % 3 = 2
192.168.100.11: 192+168+100+11 = 471 % 3 = 0
192.168.100.12: 192+168+100+12 = 472 % 3 = 1

Un exemple de répartition dynamique du trafic par src.address entre trois canaux :

#Таблица маршрутизации
/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=3 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=1 routing-mark=over-isp3

#Маркировка соединений и маршрутов
/ip firewall mangle
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/0 action=mark-connection new-connection-mark=conn-over-isp1
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/1 action=mark-connection new-connection-mark=conn-over-isp2
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/2 action=mark-connection new-connection-mark=conn-over-isp3

add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp1 action=mark-routing new-routing-mark=over-isp1
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp2 action=mark-routing new-routing-mark=over-isp2
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp3 action=mark-routing new-routing-mark=over-isp3

Lors du marquage des itinéraires, il y a une condition supplémentaire : in-interface=br-lan, sans elle sous action=mark-routing le trafic de réponse provenant d'Internet recevra et, conformément aux tables de routage, reviendra au fournisseur.

Changer de canal de communication

Vérifier le ping est un bon outil, mais il ne vérifie que la connexion avec le pair IP le plus proche, les réseaux de fournisseurs se composent généralement d'un grand nombre de routeurs et une rupture de connexion peut se produire en dehors du pair le plus proche, et puis il y a des opérateurs de télécommunications backbone qui peuvent également ont des problèmes, en général, la vérification du ping n'affiche pas toujours des informations à jour sur l'accès au réseau mondial.
Si les fournisseurs et les grandes entreprises disposent du protocole de routage dynamique BGP, les utilisateurs à domicile et au bureau doivent déterminer de manière indépendante comment vérifier l'accès à Internet via un canal de communication spécifique.

En règle générale, des scripts sont utilisés qui, via un certain canal de communication, vérifient la disponibilité d'une adresse IP sur Internet, tout en choisissant quelque chose de fiable, par exemple, Google DNS : 8.8.8.8. 8.8.4.4. Mais dans la communauté Mikrotik, un outil plus intéressant a été adapté pour cela.

Quelques mots sur le routage récursif
Le routage récursif est nécessaire lors de la création de l'appairage BGP multi-sauts et est entré dans l'article sur les bases du routage statique uniquement en raison des utilisateurs rusés de MikroTik qui ont compris comment utiliser des routes récursives associées à une passerelle de vérification pour changer de canal de communication sans scripts supplémentaires.

Il est temps de comprendre les options scope / target scope en termes généraux et comment la route est liée à l'interface :

1. La route recherche une interface pour envoyer le paquet en fonction de sa valeur de portée et de toutes les entrées de la table principale avec des valeurs de portée cibles inférieures ou égales
2. Parmi les interfaces trouvées, celle par laquelle vous pouvez envoyer un paquet à la passerelle spécifiée est sélectionnée
3. L'interface de l'entrée connectée trouvée est sélectionnée pour envoyer le paquet à la passerelle

En présence d'une route récursive, tout se passe de la même manière, mais en deux temps :

• 1-3 Une autre route est ajoutée aux routes connectées, par laquelle la passerelle spécifiée peut être atteinte
• 4-6 Recherche de la route connectée pour la passerelle "intermédiaire"

Toutes les manipulations avec la recherche récursive se produisent dans le RIB, et seul le résultat final est transféré dans le FIB : 0.0.0.0/0 via 10.10.10.1 on ether1.

Un exemple d'utilisation du routage récursif pour changer de route

Configuration:

/ip route
add dst-address=0.0.0.0/0 gateway=8.8.8.8 check-gateway=ping distance=1 target-scope=10
add dst-address=8.8.8.8 gateway=10.10.10.1 scope=10
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

Vous pouvez vérifier que les paquets seront envoyés à 10.10.10.1 :

Vérifiez que la passerelle ne sait rien du routage récursif et envoie simplement des pings à 8.8.8.8, qui (basé sur la table principale) est accessible via la passerelle 10.10.10.1.

S'il y a une perte de communication entre 10.10.10.1 et 8.8.8.8, la route est déconnectée, mais les paquets (y compris les pings de test) vers 8.8.8.8 continuent de passer par 10.10.10.1 :

Si le lien vers ether1 est perdu, une situation désagréable se produit lorsque des paquets antérieurs à 8.8.8.8 passent par le deuxième fournisseur :

C'est un problème si vous utilisez NetWatch pour exécuter des scripts lorsque 8.8.8.8 n'est pas disponible. Si le lien est rompu, NetWatch fonctionnera simplement via le canal de communication de secours et supposera que tout va bien. Résolu en ajoutant une route de filtre supplémentaire :

/ip route
add dst-address=8.8.8.8 gateway=10.20.20.1 distance=100 type=blackhole

Il y a sur habré article, où la situation avec NetWatch est examinée plus en détail.

Et oui, lors de l'utilisation d'une telle réservation, l'adresse 8.8.8.8 sera câblée à l'un des fournisseurs, donc la choisir comme source DNS n'est pas une bonne idée.

Quelques mots sur le routage et le transfert virtuels (VRF)

La technologie VRF est conçue pour créer plusieurs routeurs virtuels au sein d'un routeur physique. Cette technologie est largement utilisée par les opérateurs de télécommunications (généralement en conjonction avec MPLS) pour fournir des services L3VPN aux clients dont les adresses de sous-réseau se chevauchent :

Mais VRF dans Mikrotik est organisé sur la base de tables de routage et présente un certain nombre d'inconvénients, par exemple, les adresses IP locales du routeur sont disponibles à partir de tous les VRF, vous pouvez en savoir plus lien.

exemple de configuration vrf :

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.200.1/24 interface=ether2 network=192.168.200.0

Depuis l'appareil connecté à ether2, nous voyons que ping va à l'adresse du routeur d'un autre vrf (et c'est un problème), alors que ping ne va pas à Internet :

Pour accéder à Internet, vous devez enregistrer une route supplémentaire qui accède à la table principale (dans la terminologie vrf, cela s'appelle une fuite de route) :

/ip route
add distance=1 gateway=172.17.0.1@main routing-mark=vrf1
add distance=1 gateway=172.17.0.1%wlan1 routing-mark=vrf2

Voici deux manières de fuir les routes : en utilisant la table de routage : 172.17.0.1@main et en utilisant le nom de l'interface : 172.17.0.1%wlan1.

Et mettre en place un marquage pour le trafic de retour dans [PREROUTING|Mangle]:

/ip firewall mangle
add chain=prerouting in-interface=ether1 action=mark-connection new-connection-mark=from-vrf1 passthrough=no
add chain=prerouting connection-mark=from-vrf1 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf1 passthrough=no 
add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=from-vrf2 passthrough=no
add chain=prerouting connection-mark=from-vrf2 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf2 passthrough=no 

Sous-réseaux avec la même adresse
Organisation des accès aux sous-réseaux avec le même adressage sur le même routeur à l'aide de VRF et netmap :

Paramétrage de base :

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.100.1/24 interface=ether2 network=192.168.100.0
add address=192.168.0.1/24 interface=ether3 network=192.168.0.0

règles de pare-feu :

#Маркируем пакеты для отправки в правильную таблицу маршрутизации
/ip firewall mangle
add chain=prerouting dst-address=192.168.101.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf1 passthrough=no
add chain=prerouting dst-address=192.168.102.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf2 passthrough=no

#Средствами netmap заменяем адреса "эфимерных" подсетей на реальные подсети
/ip firewall nat
add chain=dstnat dst-address=192.168.101.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24
add chain=dstnat dst-address=192.168.102.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24

Règles de routage pour le trafic de retour :

#Указание имени интерфейса тоже может считаться route leaking, но по сути тут создается аналог connected маршрута
/ip route
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf1
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf2

Ajouter des routes reçues via DHCP à une table de routage donnée
VRF peut être intéressant si vous avez besoin d'ajouter automatiquement une route dynamique (par exemple, à partir d'un client DHCP) à une table de routage spécifique.

Ajout d'une interface à vrf :

/ip route vrf
add interface=ether1 routing-mark=over-isp1

Règles d'envoi du trafic (sortant et transit) via la table sur-isp1:

/ip firewall mangle
add chain=output out-interface=!br-lan action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting in-interface=br-lan dst-address-type=!local action=mark-routing new-routing-mark=over-isp1 passthrough=no

Fausse route supplémentaire pour que le routage sortant fonctionne :

/interface bridge
add name=bare

/ip route
add dst-address=0.0.0.0/0 gateway=bare

Cette route n'est nécessaire que pour que les paquets sortants locaux puissent passer par la décision de routage (2) avant [OUTPUT|Mangle] et obtenir l'étiquette de routage, s'il existe d'autres routes actives sur le routeur avant 0.0.0.0/0 dans la table principale, ce n'est pas obligatoire.

Chaînes connected-in и dynamic-in в [Routing] -> [Filters]

Le filtrage des routes (entrantes et sortantes) est un outil généralement utilisé en conjonction avec les protocoles de routage dynamique (et donc disponible uniquement après l'installation du package routage), mais il y a deux chaînes intéressantes dans les filtres entrants :

• connecté - filtrage des routes connectées
• dynamic-in - filtrage des routes dynamiques reçues par PPP et DCHP

Le filtrage vous permet non seulement de rejeter des itinéraires, mais également de modifier un certain nombre d'options : distance, marque de routage, commentaire, portée, portée cible, ...

C'est un outil très précis et si vous pouvez faire quelque chose sans les filtres de routage (mais pas les scripts), alors n'utilisez pas les filtres de routage, ne vous confondez pas et ceux qui configureront le routeur après vous. Dans le contexte du routage dynamique, les filtres de routage seront utilisés beaucoup plus fréquemment et de manière plus productive.

Définition de la marque de routage pour les routes dynamiques
Un exemple d'un routeur domestique. J'ai deux connexions VPN configurées et le trafic qu'elles contiennent doit être encapsulé conformément aux tables de routage. En parallèle, je souhaite que les routes soient créées automatiquement lors de l'activation de l'interface :

#При создании vpn подключений указываем создание default route и задаем дистанцию
/interface pptp-client
add connect-to=X.X.X.X add-default-route=yes default-route-distance=101 ...
add connect-to=Y.Y.Y.Y  add-default-route=yes default-route-distance=100 ...

#Фильтрами отправляем маршруты в определенные таблицы маршрутизации на основе подсети назначения и дистанции
/routing filter
add chain=dynamic-in distance=100 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn1
add chain=dynamic-in distance=101 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn2

Je ne sais pas pourquoi, probablement un bogue, mais si vous créez un vrf pour l'interface ppp, la route vers 0.0.0.0/0 entrera toujours dans la table principale. Sinon, tout serait encore plus simple.

Désactivation des routes connectées
Parfois, cela est nécessaire :

/route filter
add chain=connected-in prefix=192.168.100.0/24 action=reject

Outils de débogage

RouterOS fournit un certain nombre d'outils pour déboguer le routage :

• [Tool]->[Tourch] - vous permet de visualiser les paquets sur les interfaces
• /ip route check - vous permet de voir à quelle passerelle le paquet sera envoyé, ne fonctionne pas avec les tables de routage
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - ping et trace en utilisant la table de routage spécifiée
• action=log в [IP]->[Firewall] - un excellent outil qui vous permet de tracer le chemin d'un paquet le long du flux de paquets, cette action est disponible dans toutes les chaînes et tables

Source: habr.com