ToFoIn v 1. Réservation de passerelles et commutation entre canaux externes dans FreeBSD

Annotation

Dans un article précédent, l'organisation de la redondance des passerelles LAN a été envisagée. Comme solution, un script a été proposé qui à l'époque résolvait le problème, mais présentait un certain nombre d'inconvénients. Après un certain temps, il s'est avéré éliminer ces lacunes, réécrire partiellement le code et obtenir quelque chose d'acceptable à la sortie. Maintenant, nous pouvons dire que les scripts sont suffisamment testés pour être appelés stables. Pour simplifier la compréhension de l'ensemble du système, les principaux points de mise en place des services secondaires (en termes de sujet de l'article) seront partiellement reproduits ci-dessous. La raison est simple - pendant ce temps, les règles ipfw ont également été retravaillées, dns est allé vivre dans AD sur Samba4 avec un bind-frontend et des enregistrements mis à jour en toute sécurité depuis isc-dhcpd en utilisant kerberos, ainsi que des serveurs DNS secondaires comme bind sur les passerelles, CARP configuré ... En général, il est devenu beaucoup plus intéressant, mais en savoir plus sur quoi et comment cela fonctionne est ci-dessous. Tout ce qui peut être donné avec des références à la source sera conçu de manière à ne pas produire d'essence. Ce qui a été pris ailleurs, mais qui n'est plus disponible, sera donné ici avec les commentaires pertinents.

Présentation

Ainsi, il existe deux manières d'augmenter l'immunité au bruit du canal de communication avec le monde extérieur de la part du consommateur: sauvegarde de la passerelle et réservation du point de connexion. En d'autres termes, dans le premier cas, une deuxième passerelle est mise en place, qui sera activée si la première échoue, dans le second cas, un canal Internet de secours sera organisé en cas de problème avec le principal, et plus ils traversent, mieux c'est, évidemment. Si CARP résout la première tâche pour FreeBSD, alors la seconde, après avoir organisé le deuxième canal externe, peut, encore une fois, être résolue de plusieurs manières. Au minimum, vous pouvez organiser l'équilibrage du trafic ou la commutation entre les canaux. En raison de la grande différence dans la bande passante des canaux externes, la première option ne me convenait pas, donc le principal coupable de la publication a été écrit: ToFoIn - un ensemble de scripts bash qui vise à résoudre les problèmes de diagnostic et à passer à un canal externe fonctionnel. Après raffinement, il peut être appliqué à n passerelles et m canaux. La situation est faible, où n et m sont supérieurs à 2, mais les scripts ci-dessous devraient fonctionner jusqu'à de grandes valeurs de n et m, car Logiquement, la limite n'est pas fixée. En général, je soupçonne qu'en utilisant ces scripts, il est possible de résoudre un éventail assez large de tâches, selon l'état de la connexion, limité, peut-être, uniquement par l'imagination.


Une telle topologie réseau suppose approximativement sous la forme la plus simple l'utilisation d'un ensemble de scripts ToFoIn. Bien sûr, les scripts devraient fonctionner dans le cas d'un seul routeur, mais dans ce cas, vous devrez changer le module Daemon pour supprimer la dépendance de la séquence d'actions sur l'état CARP, qui sera simplement absent dans le système. La réservation ultérieure de ces nœuds et d'autres ne dépend que du degré d'importance des services correspondants.

Buts et objectifs

L'objectif du projet, comme précédemment, est de créer un progiciel universel et facilement évolutif axé sur l'identification des problèmes dans les connexions externes et internes et le passage automatique à des connexions exploitables. En termes généraux, la logique est la suivante:

• Il y a n «routeurs» avec m canaux externes sur chacun. De plus, tous les n «routeurs» sont dans une hiérarchie stricte et sont connectés les uns aux autres en utilisant CARP sur toutes les interfaces nécessaires.
• Un agent travaille indépendamment sur chaque machine, dont la tâche est basée sur le statut CARP actuel de sa machine:
  
  • Si sauvegarde - détectez et configurez la machine sur un routeur qui est actuellement le maître;
  • Si maître - vérifiez l'état des connexions au moment actuel et, si nécessaire, basculez entre les canaux externes.

Solution

Le réseau interne dispose de CARP, qui fournit des passerelles de sauvegarde et vous permet de ne pas modifier les paramètres des autres périphériques réseau sur le réseau interne lors du changement de canal.

Dhcpd fonctionne en mode primaire-secondaire et, en général, peu importe les autres rôles joués par sa machine - la connexion entre dhcpd se produit sur le réseau interne, que les routeurs regardent toujours.

La liaison principale est supprimée dans AD, qui est masquée dans le réseau local, tandis que les serveurs de liaison secondaires travaillent sur les routeurs de la passerelle sur un pied d'égalité.

Les règles ipfw diffèrent selon le canal considéré comme le canal principal à un moment donné et sont redémarrées par le module Daemon lors du changement de rôle.

Enfin sur les scripts eux-mêmes. Maintenant, les fichiers sont situés dans les répertoires appropriés, fonctionnent à partir de leur utilisateur et ont un script de démarrage dans rc.d. Les tâches qui nécessitent un accès root sont résolues par sudo. Il existe un script d'installation qui prend en compte la présence éventuelle d'une version installée, ainsi qu'un fichier de paramètres assez détaillé. Les modules sont les mêmes avec des changements mineurs, certains n'ont presque pas changé de fonctionnalité:

Le démon - comme son nom l'indique - est le processus principal qui exécute les modules de test et de commutation sur une minuterie, et surveille également CARP.
Testeur - teste toujours les communications externes à l'aide de la commande ping. (s'il est en marche, il considère que la machine a CARP à l'état maître)
Juge - sur la base des résultats du test, détermine quel canal externe fonctionne et si la commutation est nécessaire, effectue la commutation (s'il est en cours d'exécution, il considère que la machine a CARP à l'état maître).
Scout est un nouveau module. Il démarre lorsque CARP est en état de sauvegarde. Il est nécessaire de déterminer lequel des routeurs restants est actuellement le principal.
Logger - responsable de la journalisation des événements. Il est nécessaire pour que les informations sur les événements ne soient pas dupliquées et que le magazine soit plus facile à lire.
Watchdog - fonctionne selon le calendrier de crontab. Il détermine les «gels» de tous les modules et (dans la mesure du possible) essaie de résoudre les problèmes qui se sont posés. C'est-à-dire clouer tout le monde, tout simplement.

En plus des scripts eux-mêmes, il convient de considérer certains fichiers plus importants:

Tofoin.conf - un seul fichier de paramètres.
Tofoin.log - un seul fichier journal des événements.
Result_ <numéro de canal interne> est le fichier de travail, les résultats des tests sont ajoutés ici, créés dans / tmp à côté de .pid et d'autres fichiers de travail.

Je peux volontiers répondre aux questions concernant le fonctionnement des modules, en expliquant les solutions dans les commentaires.

Partie technique

Équipement

Par rapport à la période précédente, les passerelles sont passées à P4, ont reçu 1536 Mo de RAM et trois disques durs de 40 Go (miroir + disque de rechange). Les cartes réseau sont toujours PCI, les PSU sont normales, naturellement en présence d'un onduleur.
L'augmentation de la capacité est associée au fer libéré et à la mise à jour trop fastidieuse de la source, mais surtout la première. OS FreeBSD 11.1, FS zfs.

Paramètres des composants du système

Logiciels tiers

Un peu sur ToFoIn

Tout le texte du projet ainsi que le script d'installation sont disponibles sur gitlab .

Résumé

Il s'est avéré être un ensemble de scripts entièrement fonctionnel et fiable qui répond bien à la tâche de basculer vers le canal de travail dans le cas de 2 routeurs avec 2 canaux de communication externes.

Plans

Mes plans pour ce projet concernent, peut-être, la réécriture de bash en pure sh pour se débarrasser des logiciels inutiles sur le serveur. D'un autre côté, maintenant tout fonctionne à merveille et je n'ai vraiment pas envie d'interférer dans ce processus, en plus, passer à sh est lourd de constructions de langage plus terribles nécessaires pour obtenir le même résultat.
Pour le reste, probablement, il vaudrait la peine d'envisager la meilleure implémentation des modules de test.

Références:

← Article précédent
→ Page du projet ToFoIn sur gitlab