La traçabilité des connexions (“conntrack”) est une fonctionnalité clé de la pile réseau du noyau Linux. Elle permet au noyau de suivre toutes les connexions ou flux réseau logiques et d'identifier ainsi tous les paquets qui composent chaque flux, permettant leur traitement séquentiel ensemble.
Conntrack est une fonctionnalité importante du noyau, utilisée dans plusieurs cas d'utilisation fondamentaux :
- NAT s'appuie sur les informations de conntrack pour traiter de manière cohérente tous les paquets d'un même flux. Par exemple, lorsque un pod accède à un service Kubernetes, le répartiteur de charge kube-proxy utilise NAT pour rediriger le trafic vers un pod spécifique dans le cluster. Conntrack enregistre que pour une connexion donnée, tous les paquets destinés à l'IP du service doivent être envoyés au même pod, et que les paquets renvoyés par le pod backend doivent être redirigés par NAT vers le pod d'où la requête est venue.
- Les pare-feu avec suivi d'état, tels que Calico, s'appuient sur les informations de conntrack pour ajouter le trafic “retour” à la liste blanche. Cela vous permet d'écrire une politique réseau qui dit : « autoriser mon pod à se connecter à n'importe quelle adresse IP distante » sans avoir à rédiger une politique pour autoriser explicitement le trafic de retour. (Sans cela, vous auriez dû ajouter une règle beaucoup moins sécurisée comme « autoriser les paquets à mon pod depuis n'importe quelle IP ».)
De plus, conntrack améliore généralement les performances du système (réduisant la consommation de temps processeur et le temps de latence des paquets), car seul le premier paquet d'un flux doit passer par l'intégralité du traitement de la pile réseau pour déterminer ce qu'il faut en faire. Voir le post «
Comparaison des modes kube-proxyCependant, conntrack a ses limites…
Alors, où tout a-t-il mal tourné ?
La table conntrack a une taille maximale configurable, et si elle est pleine, les connexions commencent généralement à être rejetées ou interrompues. Pour la plupart des applications, il y a généralement suffisamment d'espace libre dans la table, et cela ne devient jamais un problème. Cependant, il existe quelques scénarios où il vaut la peine de réfléchir à l'utilisation de la table conntrack :
Таблица conntrack имеет настраиваемый максимальный размер, и, если она заполняется, соединения обычно начинают отклоняться или прерываться. Для обработки трафика большинства приложений в таблице достаточно свободного места, и это никогда не превратится в проблему. Тем не менее, есть несколько сценариев, при которых стоит задуматься об использовании таблицы conntrack:
- Le cas le plus évident est lorsque votre serveur gère un nombre extrêmement élevé de connexions actives simultanées. Par exemple, si votre table conntrack est configurée pour 128k enregistrements, mais que vous avez plus de 128k connexions simultanées, vous serez sûrement confronté à un problème !
- Un cas un peu moins évident : si votre serveur gère un très grand nombre de connexions par seconde. Même si les connexions sont temporaires, elles continuent d'être suivies par Linux pendant un certain temps (par défaut 120s). Par exemple, si votre table conntrack est configurée pour 128k enregistrements et que vous essayez de traiter 1100 connexions par seconde, elles dépasseront la taille de la table conntrack, même si les connexions sont de très courte durée (128k / 120s = 1092 connexions / s).
Il existe plusieurs types d'applications de niche qui relèvent de ces catégories. De plus, si vous avez de nombreux attaquants, le remplissage de la table conntrack de votre serveur avec un grand nombre de connexions semi-ouvertes peut ê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 dans votre système. Dans certains cas, ajuster les paramètres de la table conntrack peut suffire à répondre à vos besoins — en augmentant la taille ou en réduisant les délais de conntrack (mais si vous le faites mal, vous rencontrerez de grandes difficultés). Dans d'autres cas, il sera nécessaire de contourner conntrack pour le trafic agressif.
Un exemple concret
Prenons un exemple : un grand fournisseur SaaS avec lequel nous avons travaillé avait plusieurs serveurs memcached sur des hôtes (pas des machines virtuelles), chacun gérant plus de 50 000 connexions temporaires par seconde.
Ils ont expérimenté avec la configuration de conntrack, augmentant les tailles de tables et réduisant le temps de suivi, mais la configuration était instable, la consommation de RAM a considérablement augmenté, ce qui était un problème (de l'ordre de plusieurs Go !), et les connexions étaient si brèves que conntrack ne réalisait pas son gain habituel en performance (réduction de la consommation CPU ou des latences de paquets).
En alternative, ils se sont tournés vers Calico. Les politiques réseau de Calico permettent de ne pas utiliser conntrack pour certains types de trafic (en utilisant l'option doNotTrack pour les politiques). Cela leur a donné le niveau de performance nécessaire, ainsi qu'un niveau supplémentaire de sécurité fourni par Calico.
Que faudra-t-il faire pour contourner conntrack ?
- Les politiques réseau do-not-track doivent généralement être symétriques. Dans le cas d'un fournisseur SaaS : leurs applications fonctionnaient à l'intérieur d'une zone protégée et, de ce fait, grâce à la politique réseau, ils pouvaient mettre sur liste blanche le trafic 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, en cas de piratage d'un serveur memcached, on pourrait théoriquement essayer de se connecter à n'importe quel client memcached, à condition d'utiliser le bon port source. Cependant, si vous avez correctement défini la politique réseau pour vos clients memcached, ces tentatives de connexion seront tout de même rejetées du côté client.
- La politique do-not-track s'applique à chaque paquet, contrairement aux politiques normales qui ne s'appliquent qu'au premier paquet du flux. Cela peut augmenter la consommation de ressources CPU pour un paquet, car la politique doit être appliquée à chaque paquet. Mais pour des connexions de courte durée, cette dépense est compensée par la réduction des ressources nécessaires pour traiter conntrack. Par exemple, dans le cas d'un fournisseur SaaS, le nombre de paquets pour chaque connexion était très faible, donc la consommation supplémentaire de ressources CPU lors de l'application des politiques à chaque paquet était justifiée.
Passons aux tests
Nous avons effectué le test sur un pod avec un serveur memcached et plusieurs pods clients memcached, exécutés sur des nœuds distants, afin de pouvoir générer un très grand nombre de connexions par seconde. Le serveur avec le pod du serveur memcached avait 8 cœurs et 512k entrées dans la table conntrack (taille de table standard configurée pour l'hôte).
Nous avons mesuré la différence de performance entre : sans politique réseau ; avec une politique Calico normale ; et avec la politique Calico do-not-track.
Pour le premier test, nous avons fixé le nombre de connexions à 4 000 par seconde, afin de pouvoir nous concentrer sur la différence de consommation CPU. Il n'y avait pas de différences notables entre l'absence de politique et la politique normale, mais la politique do-not-track a augmenté la consommation CPU d'environ 20 % :
Lors du deuxième test, nous avons lancé autant de connexions que nos clients pouvaient générer et avons mesuré le nombre maximum de connexions par seconde que notre serveur memcached pouvait gérer. Comme prévu, dans le cas de 'sans politiques' et de 'politique normale', les deux ont atteint la limite conntrack de plus de 4 000 connexions par seconde (512k / 120s = 4 369 connexions/s). Avec la politique do-not-track, nos clients ont envoyé 60 000 connexions par seconde sans aucun problème. Nous sommes convaincus que nous pourrions augmenter ce chiffre en connectant un plus grand nombre de clients, mais nous estimons que ces chiffres sont déjà suffisants pour illustrer le message de cet article !
Conclusion
Conntrack est une fonctionnalité essentielle du noyau. Il remplit parfaitement son rôle. Souvent, il est utilisé par des composants clés du système. Cependant, dans certaines situations spécifiques, la surcharge due à conntrack l'emporte sur les avantages normaux qu'il apporte. Dans ce scénario, les politiques réseau Calico peuvent être utilisées pour désactiver sélectivement l'utilisation de conntrack tout en améliorant le niveau de sécurité réseau. Pour tout le reste du trafic, conntrack reste votre allié !
Lisez aussi d'autres articles sur notre blog :
Source : habr.com
