Itinéraire par défaut de Freebsd. Routage dynamique dans FreeBSD, BIRD
Vous devez utiliser la commande route sur un FreeBSD pour manipuler manuellement les tables de routage réseau. Il fournit six commandes comme suit :
Adblock détecté 😱
Mon site Web est rendu possible grâce à l'affichage de publicités en ligne à mes visiteurs. Je comprends! Les publicités sont ennuyeuses mais elles contribuent au bon fonctionnement de ce site Web. Il est difficile de faire fonctionner le site et de produire du nouveau contenu alors que tant de personnes bloquent les publicités. Veuillez envisager de donner de l'argent au nixCraft via Paypal/, ou devenez un supporter utilisant Patreon.
- ajouter: Ajouter un itinéraire.
- flush:Supprimer toutes les routes.
- supprimer: Supprimer un itinéraire spécifique.
- changement: Modifier les aspects d'un itinéraire (comme sa passerelle).
- obtenir: Recherchez et affichez l'itinéraire pour une destination.
- moniteur: Signalez en permanence toute modification apportée à la base d'informations de routage, les échecs de recherche de routage ou les partitionnements de réseau suspectés.
Tâche : Afficher/Afficher la table de routage FreeBSD
Utilisez la commande netstat avec l'option -r comme suit :
$ netstat -r
$ netstat -rn
Exemples de résultats :
| Tables de routage Internet : Indicateurs de passerelle de destination Réfs Utiliser Netif Expire par défaut 61.221 .xx.yy UGS 0 247 em1 10 10.10.110.5 UGS 0 50 em0 10.10.110/26 link#1 UC 0 0 em0 10.10.110.5 00:1b:0d : e6:58 :40 UHLW 2 0 em0 1145 61.221 .xx.yy/29 lien#2 UC 0 0 em1 61.221 .xx.yy 00:1b:0d:e6:57 :c0 UHLW 2 0 em1 1055 61.221 .xx/24 lien n°2 UC 0 0 em1 127.0.0.1 127.0.0.1 UH 0 0 lo0 |
Tables de routage Internet : Indicateurs de passerelle de destination Réfs Utiliser Netif Expire par défaut 61.221.xx.yy UGS 0 247 em1 10 10.10.110.5 UGS 0 50 em0 10.10.110/26 link#1 UC 0 0 em0 10.10.110.5 00:1b:0d : e6:58:40 UHLW 2 0 em0 1145 61.221.xx.yy/29 lien n°2 UC 0 0 em1 61.221.xx.yy 00:1b:0d:e6:57:c0 UHLW 2 0 em1 1055 61.221.xx/24 lien n°2 UC 0 0 em1 127.0.0.1 127.0.0.1 UH 0 0 lo0
Les deux premières lignes affichent les itinéraires par défaut. Pour imprimer simplement la table de routage IPv4, saisissez :
# netstat -4 -r -n
Exemples de résultats :
Pour imprimer simplement la table de routage IPv6, saisissez :
# netstat -6 -r -n
Tâche : FreeBSD Définir un itinéraire par défaut
Tous les paquets réseau qui ne peuvent pas être envoyés selon les entrées précédentes de la table de routage sont envoyés via la passerelle par défaut suivante :
# route ajouter par défaut 192.168.1.254
Comment enregistrer les informations de routage dans un fichier de configuration ?
Si vous redémarrez FreeBSD, la configuration du routage sera perdue, c'est-à-dire les informations de routage ne persisteront pas. Vous devez éditer le fichier /etc/rc.conf pour définir la route par défaut :
# vi /etc/rc.conf
Définissez l'itinéraire par défaut en modifiant la variable defaultrouter :
routeur par défaut="192.168.1.254"
Enregistrez et fermez le fichier.
La distribution Fryukhi est souvent considérée comme la plus adaptée pour résoudre les problèmes de réseau appliqués sur un réseau local. Aujourd'hui, nous allons résoudre l'un des problèmes de réseau : configurer une passerelle sur Freebsd 10 pour accéder à Internet depuis une zone locale. Il s'agit d'une fonctionnalité de serveur simple, populaire et recherchée qui peut être étendue avec des fonctionnalités supplémentaires.
Nous utiliserons la version suivante du système pour résoudre notre tâche de configuration d'une passerelle :
# uname -v FreeBSD 10.2-RELEASE-p8 #0 r292756M : samedi 26 décembre 22:49:34 MSK 2015 root@freebsd:/usr/obj/usr/src/sys/GENERIC
Le serveur dispose de 2 cartes réseau installées :
- hn0— interface externe, reçoit Internet du fournisseur, paramètres via DHCP
- hn1— réseau local, adresse 10.20.30.1, définie manuellement
Notre tâche de configuration d'un routeur logiciel freebsd comprendra la configuration du routage sur le serveur, l'installation et la configuration d'ipfw, l'activation de nat, la configuration d'un serveur DHCP et DNS local.
Préparation du serveur pour configurer la passerelle
Les informations sur les baux DHCP émis du serveur Dnsmasq peuvent être consultées dans le fichier /var/db/dnsmasq.leases.
Analyser l'activité réseau dans Freebsd à l'aide d'iftop
Parfois, vous voulez voir ce qui se passe sur le routeur et qui utilise Internet en ce moment. Par défaut, le système ne dispose pas d'un outil prêt à l'emploi pour obtenir ces informations. Un simple programme iftop nous viendra en aide, qui permet de visualiser l'activité sur l'interface réseau en temps réel.
Installer sitopà la passerelle Freebsd configurée :
# paquet installant iftop
On lance iftop en indiquant l'interface et en affichant les ports utilisés :
# iftop -i hn1 -P
Nous voyons une image intéressante : qui grimpe où, par quel port et à quelle vitesse.
A titre d'exemple, j'ai lancé un générateur de trafic Internet sur l'un des ordinateurs. Cela occupait presque tout le canal et cela devenait clairement visible sur le routeur utilisant iftop. Bien sûr, cet utilitaire simple ne résout pas tous les problèmes liés à la surveillance de l'activité du réseau, mais il convient pour présenter l'image actuelle si vous n'avez besoin de rien de plus.
Conclusion
Résumons ce que nous avons fait. En peu de temps, nous avons mis en place une passerelle à part entière (essentiellement un routeur logiciel) basée sur Freebsd 10 pour fournir un accès Internet aux clients derrière le serveur. Dans le même temps, la réception automatique des réglages était assurée. Même sur un modeste serveur virtuel, une telle passerelle est capable de traiter un trafic assez important.
L'ensemble de la configuration prend littéralement 10 à 15 minutes. La plupart du temps est consacré à l’assemblage du noyau. Plus la version de Freebsd est élevée, plus la construction prend du temps, malgré le fait que les vitesses matérielles augmentent considérablement.
Passons en revue les points et voyons ce que nous avons fait exactement :
- Nous avons préparé le serveur pour configurer la passerelle.
- Nous avons reconstruit le noyau avec les paramètres nécessaires.
- Nous avons configuré ipfw et nat et activé le routage.
- Dnsmasq installé et configuré pour distribuer les paramètres réseau via le serveur DHCP et DNS.
- Nous avons installé iftop pour une analyse simple de l'activité réseau sur l'interface externe.
C'est suffisant pour que la passerelle fonctionne pleinement sur Freebsd 10. S'il est nécessaire de compter le trafic des utilisateurs ou de restreindre l'accès à certaines ressources, vous pouvez l'utiliser.
Tôt ou tard, dans un réseau comportant plusieurs routeurs, le besoin d'un routage dynamique se fait sentir. Je ne vous dirai pas ce qu'est le routage dynamique et pourquoi il est nécessaire, car ce sont les bases que vous pouvez lire sur Internet ; ce sujet portera sur les logiciels de routage dynamique ;
L’un des programmes les plus connus pour proposer un routage dynamique est certainement le fameux quagga. interface console style cisco (wow, quelle misérable chose), support RIP, OSPF, BGP, ISIS,... Oui, le produit est connu. Mais il présente un certain nombre d'inconvénients, par exemple :
- ne prend pas en charge plusieurs tables de routage (une parodie du type table n'est qu'une parodie) ;
- FreeBSD, que j'aime tant, présente un certain nombre de problèmes sérieux. Par exemple, le protocole OSPF est rompu depuis la version 0.99.16. S'il y a plusieurs tables de routage dans le système, le quaga analyse tout, ce qui provoque des jambages désagréables par rapport à son objectif ;
- la seule façon de contrôler un quaga depuis le runtime est d'utiliser sa console ;
- API quasi inexistante pour les développeurs.
Cela fonctionne certainement mieux sous Linux, mais il n'y a toujours pas de support pour plusieurs tables de routage...
Donc, aujourd’hui, nous allons parler d’un projet comme BIRD.
Et immédiatement l'annonce du produit depuis la page principale du projet :
Que prenons-nous en charge : - IPv4 et IPv6 (utilisez --enable-ipv6 lors de la configuration) - Plusieurs tables de routage - BGP - RIP - OSPF - Routes statiques - Protocole inter-tables - Interface de ligne de commande (en utilisant le client `birdc" ; pour obtenir de l'aide, appuyez simplement sur `?") - Reconfiguration douce -- pas de commandes en ligne pour modifier la configuration de manière très limitée, éditez simplement le fichier de configuration et émettez une commande `configure" ou envoyez SIGHUP et BIRD commencera à utiliser le nouvelle configuration, éventuellement redémarrage des protocoles affectés par les changements de configuration Langage puissant pour le filtrage des routes
Bravo - « Tables de routage multiples », « Protocole inter-tables » ?
Juste une digression lyrique, dans FreeBSD plusieurs tables de routage sont apparues dans la version 7.1 déjà en 2008, ce qui est très tard. Par exemple, ils sont déjà apparus sous Linux en 1999. Malheureusement, BIRD ne sait pas travailler avec les tables de routage FreeBSD et a donc dû être légèrement modifié. Cela s’est terminé facilement. Le code est facile à lire et possède une excellente couverture API.
Nous avons ainsi BIRD avec prise en charge de plusieurs tables de routage dans FreeBSD.
Parlons maintenant un peu de la fonctionnalité « Protocole inter-tables » de BIRD. Qu'est-ce que c'est? Dans BIRD, il existe un concept de « table de routage », non, ce n'est pas une table de routage système, c'est une table BIRD interne dans laquelle les routes livrées à BIRD sont stockées d'une manière ou d'une autre. Et vous pouvez les livrer comme ceci : publicité statique des routes, importation depuis la table de routage du système, routes arrivant via OSPF/BFP/RIP/...
Toutes ces routes se trouvent dans la table BIRD, appelée « table de routage ».
Comment déclarer une table ? Facilement:
tableau fib0 ; tableau fib2 ;
Cela créera deux tables de routage dans BIRD, "fib0" et "fib2".
Mais les tables vides ne nous intéressent guère ; remplissons-les de routes statiques. Cela se fait très facilement (voici des exemples d'un fichier de configuration fonctionnel) :
protocole statique ( table fib0 ; route 10.0.0.0/8 via 10.2.2.1 ; route 193.33.62.0/23 via 10.2.2.1 ; route 91.202.20.0/22 via 10.2.2.1 ; route 93.186.96.0/20 via "ng0 "; route 193.203.60.0/22 via "ng0"; route 78.132.128.0/17 via "ng0"; route 213.135.128.0/19 via "ng0"; route 82.179.144.0/20 via "ng0"; via " ng0"; ) protocole statique (table fib2; route 0.0.0.0/0 via 192.168.130.2; )
Comme vous pouvez le constater, nous avons rempli les tableaux avec certains itinéraires. De plus, il est clair que la passerelle peut être spécifiée comme adresse IP, ou comme interface (dans le cas de « ng0 »). De plus, rien ne vous empêche de spécifier des itinéraires par défaut.
Nous avons donc rempli nos panneaux avec des itinéraires. Une question raisonnable : comment combiner les itinéraires de ces panneaux avec ce qu'il y a dans le système ? Il existe un protocole noyau pour cela, exemple :
noyau de protocole ( table fib0 ; temps d'analyse 20 ; importer aucun ; exporter tout ; table du noyau 0 ; ) noyau de protocole ( table fib2 ; temps d'analyse 20 ; importer aucun ; exporter tout ; table du noyau 2 ; )
Ici, nous lions fib0 à la table de routage système 0 (c'est la table par défaut pour FreeBSD) et fib2 à la table système 2.
import - dit que nous importerons de la table système 0 vers fib0 (dans cet exemple, nous n'importerons rien), et export - indique que nous écrirons de fib0 vers la table de routage système 0 (dans cet exemple, nous écrirons tout fib2 à la table de routage du système).
Pour fib2, tout est similaire. Je pense qu'aucune autre question ne devrait se poser ici.
temps d'analyse - à quelle fréquence nous synchroniserons ces tables. 20 secondes. Que signifient ces 20 secondes ? Le fait est qu'il est possible que BIRD ne puisse pas recevoir d'événement du système concernant une modification de la table de routage du système. Pour éviter cette situation, le tableau est relu une fois toutes les 20 secondes. Oui, cela peut être désactivé.
Parlons maintenant du « protocole Inter-table », de ce que c'est et pourquoi il est réellement nécessaire.
Jusqu'à présent, nous avons retenu le fait que fib0 est lié à la table de routage système 0 et fib2 est lié à la table 2. Et si nous devions donner certaines des routes de fib0 à fib2 ? cette opération entraînera non seulement le transfert des routes de fib0 vers fib2, mais aussi, par conséquent, l'entrée des routes de fib0 dans la table de routage du système 2. Ceci se réalise tout aussi facilement, le protocole pipe, exemple :
canal de protocole (table fib2; table homologue fib0; exporter aucun; importer tout; )
La table fib2 est connectée à fib0, mais elle n'exporte rien vers fib0, mais importe toutes les routes de fib0. C'est un protocole tellement délicat.
Mais tout cela serait ennuyeux et pourrait être résolu sereinement et sans BIRD, sans un « mais ». Mais il y a deux routeurs voisins avec lesquels nous échangeons des routes :) Nous communiquons avec nos voisins via BGP. Exemple:
protocole bgp ( table fib0 ; local comme 64602 ; voisin 192.168.135.2 comme 64603 ; filtre d'exportation rfc1918_reject ; filtre d'importation rfc1918_reject ; ) protocole bgp ( table fib0 ; local comme 64602 ; voisin 192.168.135.10 comme 64604 ; rejet du filtre d'exportation ; filtre d'importation rfc1 918_rejeter ; )
Alors qu’est-ce que tout cela signifie ? Notre AS porte le numéro 64602, les voisins 64603 et 64604. Chaque voisin a son propre protocole BGP annoncé. Chacun de ces protocoles est lié à la table fib0 - c'est-à-dire de toutes les routes arrivant/envoyant via bgp seront écrits/envoyés vers/depuis fib0. Je pense qu'il n'y a aucune question à ce sujet. Ainsi, notre table fib0 contient déjà à la fois des routes statiques et bgp.
Il y a également eu un changement dans les paramètres d'exportation/importation - filtre rfc1918_reject. Nous verrons ci-dessous comment les filtres sont écrits, mais pour l'instant je dirai que ce filtre interdit l'exportation/importation de routes depuis les réseaux déclarés dans RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/ 16).
Exemple de filtre pour ce qui précède :
# rejeter le filtre rfc1918 filter rfc1918_reject ( si net ~ [ 10.0.0.0/8+, 172.16.0.0/12+, 192.168.0.0/16+ ] alors rejeter ; sinon accepter ; )
BIRD utilise son propre langage de description pour écrire des filtres et des fonctions. La syntaxe peut être trouvée dans la documentation officielle. Dans ce cas, si la route appartient à l’un des sous-réseaux déclarés entre crochets, alors elle sera rejetée. 10.0.0.0/8+ - signifie que toute route appartenant à 10.0.0.0/8 ainsi que les sous-réseaux de ce réseau seront rejetés.
Eh bien, je vais maintenant donner un exemple complet de fichier de configuration :
log syslog ( débogage, trace, info, distant, avertissement, erreur, authentification, fatal, bug ); journal stderr tout ; # Remplacer l'ID du routeur 0.0.0.10 ; # Définir une autre table de routage table fib0; tableau fib2 ; # rejeter le filtre rfc1918 filter rfc1918_reject ( if net ~ [ 10.0.0.0/8+, 172.16.0.0/12+, 192.168.0.0/16+ ] puis rejeter ; sinon accepter ; ) # Activer le débogage global de tous les protocoles, déboguer tous les protocoles ; noyau de protocole ( table fib0 ; temps d'analyse 20 ; importer aucun ; exporter tout ; table du noyau 0 ; ) noyau de protocole ( table fib2 ; temps d'analyse 20 ; importer aucun ; exporter tout ; table du noyau 2 ; ) protocole statique ( table fib0 ; route 10.0 .0.0/8 via 10.2.2.1 ; route 193.33.62.0/23 via 10.2.2.1 ; route 91.202.20.0/22 via 10.2.2.1 ; ng0" ; route 78.132.128.0/17 via "ng0" ; route 213.135. 128.0/19 via « ng0 » ; route 82.179.144.0/20 via « ng0 » ; route 195.19.96.0/19 via « ng0 » ; ) protocole statique ( table fib2 ; route 0.0.0.0/0 via 192.168.130.2 ; ) pipe ( table fib2 ; table homologue fib0 ; exporter aucun ; importer tout ; ) protocole bgp ( table fib0 ; local comme 64602 ; voisin 192.168.135.6 comme 64601 ; filtre d'exportation rfc1918_reject ; filtre d'importation rfc1918_reject ; ) protocole bgp ( table fib0 ; local comme 64602 ; voisin 192.168.135.2 comme 64603 ; filtre d'exportation rfc1918_reject ; filtre d'importation rfc1918_reject ) protocole bgp ( table fib0 ; local comme 64602 ; voisin 192 .168.135.10 comme 64604 ;
filtre d'exportation rfc1918_reject ;
filtre d'importation rfc1918_reject ; ) # Ce pseudo-protocole surveille tous les événements de montée/descente de l'interface. périphérique de protocole (temps d'analyse 10 ; # interfaces d'analyse toutes les 10 secondes)
Tous les éléments ont été discutés ci-dessus, mais je vais simplement résumer ce que fait cette configuration :
1. Deux tables de routage BIRD sont créées (fib0 et fib2) ;
2. Les tables de l'étape 1 sont liées respectivement aux tables de routage système 0 et 2 ;
3. La pagination des routes de fib0 à fib2 est autorisée ;
4. La table fib0 contient également des routes provenant de BGP.
mira# uname FreeBSD mira# birdc affiche les protocoles tous prêts pour BIRD 1.2.5. nom état de la table proto depuis info kernel1 Noyau fib0 up 22:01 Préférence : 10 Filtre d'entrée : REJECT Filtre de sortie : ACCEPT Routes : 0 importé, 13 exporté, 0 préféré Statistiques de changement de route : reçu rejeté filtré ignoré accepté Mises à jour d'importation : 0 0 0 0 0 Retrait de l'importation : 0 0 --- 0 0 Mises à jour de l'exportation : 16 0 0 --- 16 Retrait de l'exportation : 2 --- --- --- 2 kernel2 Kernel fib2 up 22:01 Préférence : 10 Filtre d'entrée : REJECT Sortie filtre : ACCEPTER Itinéraires : 0 importé, 14 exporté, 0 préféré Stats de changement d'itinéraire : reçu rejeté filtré ignoré accepté Mises à jour d'importation : 0 0 0 0 0 Retraits d'importation : 0 0 --- 0 0 Mises à jour d'exportation : 17 0 0 --- 17 Exportation retirée : 2 --- --- --- 2 static1 Statique fib0 jusqu'à 22h01 Préférence : 200 Filtre d'entrée : ACCEPTER Filtre de sortie : REJETER Itinéraires : 9 importés, 0 exportés, 18 préférés Stats de changement d'itinéraire : reçu rejeté filtré ignoré acceptées Mises à jour d'importation : 9 0 0 0 9 Retraits d'importation : 0 0 --- 0 0 Mises à jour d'exportation : 0 0 0 --- 0 Retraits d'exportation : 0 --- --- --- 0 static2 Static fib2 up 22:01 Préférence : 200 Filtre d'entrée : ACCEPTER Filtre de sortie : REJETER Itinéraires : 1 importé, 0 exporté, 1 préféré Stats de changement d'itinéraire : reçu rejeté filtré ignoré accepté Importer les mises à jour : 1 0 0 0 1 Importer les retraits : 0 0 --- 0 0 Exporter les mises à jour : 0 0 0 --- 0 Export retiré : 0 --- --- --- 0 pipe1 Pipe fib2 up 22:01 => fib0 Préférence : 70 Filtre d'entrée : ACCEPT Filtre de sortie : REJECT Routes : 16 importées, 0 exportées Statistiques de changement d'itinéraire : reçu rejeté filtré ignoré accepté Mises à jour d'importation : 28 0 0 9 19 Retraits d'importation : 3 0 --- 0 3 Mises à jour d'exportation : 20 19 1 0 0 Retraits d'exportation : 3 0 --- 0 0 bgp1 BGP fib0 up 22 :01 Préférence établie : 100 Filtre d'entrée : rfc1918_reject Filtre de sortie : rfc1918_reject Itinéraires : 5 importés, 9 exportés, 6 préférés Stats de changement d'itinéraire : reçu rejeté filtré ignoré accepté Mises à jour d'importation : 5 0 0 0 5 Retraits d'importation : 0 0 --- 0 0 Mises à jour d'exportation : 16 3 1 --- 12 Retraits d'exportation : 2 --- --- --- 3 État BGP : Session établie : AS voisin AS4 externe : 64601 ID de voisin : 192.168.135.6 Adresse du voisin : 192.168.135.6 Nexthop adresse : 192.168.135.6 Adresse source : 192.168.135.5 Caps voisins : actualiser AS4 Minuterie de maintien : 102/180 Minuterie Keepalive : 10/60 bgp2 BGP fib0 up 22:01 Préférence établie : 100 Filtre d'entrée : rfc1918_reject Filtre de sortie : rfc1918_reject Routes : 2 importé, 11 exporté, 2 préférés Statistiques de changement d'itinéraire : reçu rejeté filtré ignoré accepté Mises à jour d'importation : 5 0 0 0 5 Retraits d'importation : 3 0 --- 0 3 Mises à jour d'exportation : 16 4 1 --- 11 Retraits d'exportation : 2 -- - --- --- 0 État BGP : Session établie : AS voisin AS4 externe : 64603 ID de voisin : 0. 0.0.50 Adresse du voisin : 192.168.135.2 Adresse du prochain saut : 192.168.135.2 Adresse source : 192.168.135.1 Caps du voisin : actualiser Minuterie de maintien AS4 : 87/180 Minuterie Keepalive : 45/60 bgp3 BGP fib0 start 22:01 Erreur BGP inactive : Mauvaise Identifiant BGP Préférence : 100 Filtre d'entrée : rfc1918_reject Filtre de sortie : rfc1918_reject Routes : 0 importé, 0 exporté, 0 préféré Statistiques de changement de route : reçu rejeté filtré ignoré accepté Mises à jour d'importation : 0 0 0 0 0 Retraits d'importation : 0 0 --- 0 0 Mises à jour d'exportation : 0 0 0 --- 0 Retraits d'exportation : 0 --- --- --- 0 État BGP : Inactif Attente d'erreur : 43/60 Dernière erreur : Erreur BGP : identifiant BGP incorrect périphérique 1 Maître de l'appareil activé 22 :01 Préférence : 240 Filtre d'entrée : ACCEPTER Filtre de sortie : REJETER Itinéraires : 0 importé, 0 exporté, 0 préféré Stats de changement d'itinéraire : reçu rejeté filtré ignoré accepté Importer les mises à jour : 0 0 0 0 0 Importer les retraits : 0 0 --- 0 0 Exporter les mises à jour : 0 0 0 --- 0 Exportation retirée : 0 --- --- --- 0