Système de gestion de configuration du réseau de filtrage Qrator

TL;DR: Description de l'architecture client-serveur de notre système interne de gestion de configuration de réseau, QControl. À la base se trouve un protocole de transport à deux niveaux, fonctionnant avec des messages compressés en gzip sans décompression entre les points de terminaison. Des routeurs distribués et des points de terminaison reçoivent des mises à jour de configuration, et le protocole permet l'installation de relais intermédiaires localisés. Le système est construit selon le principe de sauvegarde différentielle ('recent-stable', expliqué ci-dessous) et utilise le langage de requêtes JMESpath avec le moteur de modèles Jinja pour le rendu des fichiers de configuration.

Qrator Labs gère un réseau mondial distribué de neutralisation des attaques. Notre réseau fonctionne sur le principe de l'anycast, et les sous-réseaux sont annoncés via BGP. En tant que réseau BGP anycast, physiquement situé dans plusieurs régions du monde, nous pouvons traiter et filtrer le trafic illicite plus près du cœur d'Internet - auprès des opérateurs Tier-1.

D'un autre côté, être un réseau géographiquement distribué n'est pas simple. La communication entre les points de présence du réseau est cruciale pour le fournisseur de services de sécurité afin de maintenir une configuration cohérente de tous les nœuds du réseau, en les mettant à jour en temps utile. Par conséquent, afin de fournir le niveau de service principal maximum possible pour le consommateur, nous devions trouver un moyen de synchroniser de manière fiable les données de configuration entre les continents.

Au commencement était le Verbe. Il est rapidement devenu un protocole de communication nécessitant une mise à jour.

La pierre angulaire de l'existence de QControl et la principale raison de la dépense considérable de temps et de ressources pour la mise en place d'un tel protocole est la nécessité d'obtenir une source de configuration unique et autorisée, et finalement de synchroniser nos points de présence avec celle-ci. Le stockage lui-même n'était qu'une des nombreuses exigences lors du développement de QControl. De plus, nous avions également besoin d'intégrations avec les services existants et prévus sur les points de présence (PP), des méthodes intelligentes (et configurables) de validation des données, ainsi qu'une gestion des accès. En outre, nous voulions également gérer ce système par des commandes, plutôt que par des modifications directes dans les fichiers. Avant QControl, les données étaient envoyées aux points de présence presque manuellement. Si l'un des points de présence était indisponible, et que nous oubliions de le mettre à jour plus tard, la configuration devenait désynchronisée — ce qui nous obligeait à investir du temps pour la remettre en état.

En fin de compte, nous avons élaboré le schéma suivant :

Le serveur de configuration est responsable de la validation des données et du stockage, le routeur possède plusieurs points de terminaison qui reçoivent et retransmettent les mises à jour de configuration des clients et de l'équipe de support vers le serveur, et du serveur vers les points de présence.

La qualité de la connexion Internet varie encore considérablement dans différentes régions du monde — pour illustrer cette thèse, examinons un simple MTR de Prague, République tchèque vers Singapour et Hong Kong.

MTR de Prague à Singapour

Le même trajet vers Hong Kong

Des latences élevées signifient une vitesse réduite. De plus, il y a perte de paquets. La bande passante ne compense pas ce problème, qui doit toujours être pris en compte lors de la construction de systèmes décentralisés.

La configuration complète d'un point de présence représente un volume important de données à transmettre à de nombreux destinataires via des connexions peu fiables. Heureusement, bien que la configuration change constamment, cela se fait par petites portions.

Conception recent-stable

On peut dire que la construction d'un réseau distribué selon le principe des mises à jour incrémentielles est une solution assez évidente. Mais il y a de nombreux problèmes associés aux diffs. Nous devons conserver tous les diffs entre les points de référence, ainsi que pouvoir les envoyer à nouveau si quelqu'un a manqué une partie des données. Chaque point de destination doit les appliquer dans un ordre strictement défini. Habituellement, dans le cas de plusieurs points de destination, une telle opération peut prendre beaucoup de temps. Le destinataire doit également être en mesure de demander les parties manquantes et, bien sûr, la partie centrale doit répondre à cette demande de manière appropriée, en envoyant uniquement les données manquantes.

Au final, nous en sommes arrivés à une solution assez intéressante : nous avons un seul niveau de référence, fixe, que nous appellerons stable, et un seul diff pour cela — recent. Chaque recent est basé sur le dernier stable formé et est suffisant pour reconstruire les données de configuration. Une fois qu'un recent frais arrive à destination, l'ancien n'est plus nécessaire.

Il ne reste plus qu'à envoyer de temps en temps une nouvelle configuration stable, par exemple parce que le recent est devenu trop volumineux. Un autre point important ici est que nous diffusons toutes ces mises à jour en mode broadcast/multicast, sans nous soucier des destinataires individuels et de leur capacité à rassembler les morceaux de données. Une fois que nous sommes sûrs que tout le monde a un stable correct, nous envoyons uniquement les nouveaux recent. Faut-il préciser que cela fonctionne ? Ça fonctionne. Le stable est mis en cache sur le serveur de configuration et sur les destinataires, le recent est créé si nécessaire.

Architecture de transport à deux niveaux

Pourquoi avons-nous construit notre transport sur deux niveaux ? La réponse est assez simple : nous voulions séparer le routage de la logique de haut niveau, en nous inspirant du modèle OSI avec son niveau de transport et son niveau d'application. Pour le protocole de transport, nous avons choisi Thrift, et pour le format élevé des messages de contrôle — le format de sérialisation msgpack. C'est pourquoi le routeur (effectuant multicast/broadcast/relay) ne regarde pas à l'intérieur de msgpack, ne décompresse pas et ne recompresse pas le contenu, et ne fait que le transfert des données.

Thrift (de l'anglais « thrift », prononcé comme [θrift]) est un langage de description des interfaces utilisé pour définir et créer des services dans différents langages de programmation. Il constitue un cadre pour les appels de procédures à distance (RPC). Il combine un pipeline de programmation avec un moteur de génération de code pour développer des services qui fonctionnent efficacement et facilement entre les langages.

Nous avons choisi le cadre Thrift en raison de la RPC et du support de nombreux langages. Comme d'habitude, les parties les plus simples étaient le client et le serveur. Cependant, le routeur s'est révélé être un véritable défi, en partie à cause de l'absence de solution prête à l'emploi durant notre développement.

Il existe d'autres options, comme protobuf / gRPC, cependant, lorsque nous avons commencé notre projet, gRPC était encore relativement jeune et nous n'avons pas osé l'intégrer.

Bien sûr, nous aurions pu (et en fait, cela aurait été la bonne chose à faire) créer notre propre solution. Il aurait été plus simple de créer un protocole correspondant à nos besoins, car l'architecture client-serveur est relativement directe à mettre en œuvre par rapport à la construction d'un routeur sur Thrift. Quoi qu'il en soit, les protocoles auto-écrits et les mises en œuvre de bibliothèques populaires font souvent l'objet d'un préjugé traditionnel, de plus, la question revient toujours : « Comment allons-nous le porter sur d'autres langages ? ». Par conséquent, nous avons rapidement écarté l'idée du vélo.

Msgpack est analogue à JSON, mais plus rapide et plus léger. Il s'agit d'un format binaire de sérialisation de données qui permet d'échanger des données entre de nombreux langages.

Au premier niveau, nous avons Thrift avec le minimum d'informations nécessaires au routeur pour transmettre un message. Au deuxième niveau, nous avons les structures empaquetées de msgpack.

Nous avons choisi msgpack car il est plus rapide et plus compact par rapport à JSON. Mais ce qui est encore plus important, c'est qu'il prend en charge les types de données personnalisés, nous permettant d'utiliser des fonctionnalités intéressantes telles que la transmission de binaires bruts ou d'objets spéciaux représentant l'absence de données, ce qui était crucial pour notre schéma « recent-stable ».

JMESPath
JMESPath est un langage de requêtes pour JSON.
C'est ainsi que se présente la description que nous obtenons de la documentation officielle de JMESPath, mais en réalité, il offre bien plus. JMESPath permet de rechercher et de filtrer des sous-arbres dans une structure arborescente quelconque, ainsi que d'appliquer des modifications aux données à la volée. De plus, il permet d'ajouter des filtres spéciaux et des procédures de transformation des données. Bien qu'il nécessite sans aucun doute un certain effort de compréhension.

Jinja
Pour certains utilisateurs, nous devons transformer la configuration en fichier — c'est pourquoi nous utilisons un moteur de modèles et Jinja est un choix évident. Grâce à cela, nous générons un fichier de configuration à partir d'un modèle et des données reçues à la destination.

Pour générer le fichier de configuration, nous avons besoin d'une requête JMESPath, d'un modèle pour l'emplacement du fichier dans le système de fichiers, et d'un modèle pour le fichier de configuration lui-même. À ce stade, il est également utile de préciser les permissions d'accès au fichier. Tout cela a réussi à être combiné avec succès dans un seul fichier — avant le début du modèle de configuration, nous plaçons un en-tête au format YAML, décrivant le reste.

Par exemple :

---
sélecteur : "[@][?@.fft._meta.version == `42`] | items([0].fft_config || `{}`)"
nom_fichier_destination : "fft/{{ match[0] }}.json"
mode_fichier : 0644
recharger_daemons : [fft]
...
{{ dict(match[1]) | json(indent=2, sort_keys=True) }}


Pour créer un fichier de configuration pour un nouveau service, il suffit d'ajouter un nouveau fichier modèle. Aucune modification du code source ou du logiciel aux points de présence n'est nécessaire.

Qu'est-ce qui a changé après l'introduction de QControl dans les opérations ? La première et la plus importante — une livraison cohérente et fiable des mises à jour de configuration sur tous les nœuds du réseau. Deuxièmement, obtenir un puissant outil de vérification de configuration et de modifications par notre équipe de support, ainsi que par les consommateurs du service.

Tout cela a été possible en utilisant le schéma de mises à jour recent-stable pour simplifier la communication entre le serveur de configuration et les destinataires de la configuration. En utilisant un protocole à deux niveaux pour maintenir une méthode de routage des données indépendante du contenu. Nous avons réussi à intégrer un moteur de génération de configuration basé sur Jinja dans un réseau distribué de filtrage. Ce système prend en charge un large éventail de méthodes de configuration pour notre périphérie distribuée et hétérogène.

Merci pour votre aide dans la rédaction de ce matériel. VolanDamrod, serenheit, NoN.

Version anglaise post.

Source : habr.com