Le suivi des connexions (« conntrack ») est une fonctionnalité essentielle de la pile réseau du noyau Linux. Il permet au noyau de garder une trace de toutes les connexions ou flux réseau logiques et ainsi d'identifier tous les paquets qui composent chaque flux afin qu'ils puissent être traités ensemble de manière séquentielle.
Conntrack est une fonctionnalité importante du noyau qui est utilisée dans certains cas simples :
- NAT s'appuie sur les informations de conntrack afin de pouvoir traiter tous les paquets du même flux de la même manière. Par exemple, lorsqu'un pod accède à un service Kubernetes, l'équilibreur de charge Kube-proxy utilise NAT pour diriger le trafic vers un pod spécifique au sein du cluster. Conntrack enregistre que pour une connexion donnée, tous les paquets vers le service IP doivent être envoyés au même pod et que les paquets renvoyés par le pod backend doivent être renvoyés par NAT au pod d'où provient la demande.
- Les pare-feu dynamiques tels que Calico s'appuient sur les informations de connecttrack pour mettre sur liste blanche le trafic de « réponse ». Cela vous permet d'écrire une politique réseau indiquant « autoriser mon pod à se connecter à n'importe quelle adresse IP distante » sans avoir à rédiger une politique pour autoriser explicitement le trafic de réponse. (Sans cela, vous devrez ajouter la règle beaucoup moins sécurisée « autoriser les paquets vers mon pod à partir de n'importe quelle adresse IP ».)
De plus, conntrack améliore généralement les performances du système (en réduisant la consommation du processeur et la latence des paquets) puisque seul le premier paquet d'un flux
doit parcourir toute la pile réseau pour déterminer quoi en faire. Voir l'article "" pour voir un exemple de la façon dont cela fonctionne.
Cependant, conntrack a ses limites...
Alors, où est-ce que tout s'est mal passé ?
La table conntrack a une taille maximale configurable, et si elle est pleine, les connexions commencent généralement à être rejetées ou abandonnées. Il y a suffisamment d'espace libre dans la table pour gérer le trafic de la plupart des applications, et cela ne deviendra jamais un problème. Cependant, il existe quelques scénarios dans lesquels vous pouvez envisager d'utiliser la table conntrack :
- Le cas le plus évident est celui où votre serveur gère un nombre extrêmement important de connexions actives simultanément. Par exemple, si votre table de connexion est configurée pour 128 128 entrées, mais que vous avez > XNUMX XNUMX connexions simultanées, vous rencontrerez sûrement un problème !
- Un cas un peu moins évident : si votre serveur traite un très grand nombre de connexions par seconde. Même si les connexions sont de courte durée, elles continuent d'être surveillées par Linux pendant un certain temps (120 s par défaut). Par exemple, si votre table conntrack est configurée pour 128 1100 entrées et que vous essayez de gérer 128 120 connexions par seconde, elles dépasseront la taille de la table conntrack, même si les connexions sont de très courte durée (1092 XNUMX/XNUMX s = XNUMX XNUMX connexions/ s).
Il existe plusieurs types d’applications de niche qui entrent dans ces catégories. De plus, si vous avez beaucoup de mauvais acteurs, remplir la table de connexion de votre serveur avec de nombreuses connexions semi-ouvertes pourrait être utilisé dans le cadre d'une attaque par déni de service (DOS). Dans les deux cas, conntrack peut devenir un goulot d’étranglement limitant dans votre système. Dans certains cas, ajuster les paramètres de la table de connexion peut suffire à répondre à vos besoins - en augmentant la taille ou en réduisant les délais d'attente de connexion (mais si vous le faites mal, vous rencontrerez beaucoup de problèmes). Pour les autres cas il faudra contourner conntrack pour trafic agressif.
Exemple réel
Donnons un exemple spécifique : un grand fournisseur SaaS avec lequel nous avons travaillé disposait d'un certain nombre de serveurs Memcached sur des hôtes (et non des machines virtuelles), chacun traitant plus de 50 XNUMX connexions à court terme par seconde.
Ils ont expérimenté la configuration de conntrack, en augmentant la taille des tables et en réduisant le temps de suivi, mais la configuration n'était pas fiable, la consommation de RAM augmentait considérablement, ce qui était un problème (de l'ordre des Go !), et les connexions étaient si courtes que conntrack ne l'a pas fait. créer son avantage habituel en termes de performances (consommation CPU ou latence des paquets réduite).
Ils se sont tournés vers Calico comme alternative. Les politiques réseau Calico vous permettent de ne pas utiliser conntrack pour certains types de trafic (en utilisant l'option de politique doNotTrack). Cela leur a donné le niveau de performance dont ils avaient besoin, ainsi que le niveau de sécurité supplémentaire fourni par Calico.
Jusqu'où devrez-vous aller pour contourner Conntrack ?
- Les politiques de réseau de non-suivi doivent généralement être symétriques. Dans le cas du fournisseur SaaS : leurs applications s'exécutaient à l'intérieur de la zone protégée et, par conséquent, en utilisant la politique réseau, ils pouvaient mettre sur liste blanche le trafic provenant d'autres applications spécifiques autorisées à accéder à Memcached.
- La politique Do-not-track ne prend pas en compte la direction de la connexion. Ainsi, si le serveur Memcached est piraté, vous pouvez théoriquement essayer de vous connecter à n'importe lequel des clients Memcached, à condition qu'il utilise le bon port source. Cependant, si vous avez correctement défini la politique réseau pour vos clients memcached, alors ces tentatives de connexion seront toujours rejetées côté client.
- La politique de non-suivi est appliquée à chaque paquet, contrairement aux politiques normales, qui s'appliquent uniquement au premier paquet d'un flux. Cela peut augmenter la consommation CPU par paquet car la stratégie doit être appliquée pour chaque paquet. Mais pour les connexions de courte durée, cette dépense est compensée par la réduction de la consommation de ressources pour le traitement des connexions. Par exemple, dans le cas d'un fournisseur SaaS, le nombre de paquets pour chaque connexion était très faible, de sorte que la consommation supplémentaire de CPU lors de l'application des politiques à chaque paquet était justifiée.
Commençons les tests
Nous avons exécuté le test sur un seul pod avec un serveur memcached et plusieurs pods clients memcached exécutés sur des nœuds distants afin de pouvoir exécuter un très grand nombre de connexions par seconde. Le serveur avec le pod de serveur memcached avait 8 cœurs et 512 XNUMX entrées dans la table conntrack (la taille de table configurée standard pour l'hôte).
Nous avons mesuré la différence de performances entre : aucune politique de réseau ; avec la politique Calico régulière ; et la politique de non-suivi de Calico.
Pour le premier test, nous avons fixé le nombre de connexions à 4.000 20 par seconde, afin de pouvoir nous concentrer sur la différence de consommation CPU. Il n'y avait pas de différence significative entre l'absence de politique et la politique normale, mais ne suivez pas l'augmentation de la consommation du processeur d'environ XNUMX % :
Lors du deuxième test, nous avons lancé autant de connexions que nos clients pouvaient générer et mesuré le nombre maximum de connexions par seconde que notre serveur Memcached pouvait gérer. Comme prévu, les cas « pas de politique » et « politique régulière » ont tous deux atteint la limite de connexion de plus de 4,000 512 connexions par seconde (120 4,369 / 60,000 s = XNUMX XNUMX connexions/s). Grâce à une politique de non-suivi, nos clients ont envoyé XNUMX XNUMX connexions par seconde sans aucun problème. Nous sommes sûrs que nous pourrions augmenter ce nombre en ajoutant plus de clients, mais nous pensons que ces chiffres sont déjà suffisants pour illustrer le propos de cet article !
Conclusion
Conntrack est une fonctionnalité importante du noyau. Il fait parfaitement son travail. Il est souvent utilisé par les composants clés du système. Cependant, dans certains scénarios spécifiques, la congestion due à la connexion dépasse les avantages normaux qu'elle procure. Dans ce scénario, les stratégies réseau Calico peuvent être utilisées pour désactiver de manière sélective l'utilisation de conntrack tout en augmentant la sécurité du réseau. Pour tout autre trafic, conntrack continue d’être votre ami !
Lisez également d'autres articles sur notre blog:
Source: habr.com