Contrôle du trafic sous Linux (tc) : un guide pratique

Contrôle du trafic sous Linux (tc) : un guide pratique

La tc vous permet de contrôler directement la manière dont votre serveur gère le trafic réseau. Vous pouvez limiter la bande passante par service, garantir la réactivité des sessions interactives telles que SSH en cas de pics de transferts en masse, et réguler les flux sortants et entrants à partir d’un seul et même outil. Ce guide aborde les concepts fondamentaux, une configuration HTB opérationnelle, la régulation des flux entrants avec IFB, la priorisation basée sur le DSCP, ainsi que la procédure de débogage en cas de dysfonctionnement.

Fonctionnement de tc

Chaque tc configuration repose sur quatre éléments :

• qdisc (discipline de mise en file d’attente). Le planificateur associé à une interface réseau. Il détermine comment les paquets sont mis en file d’attente et retirés de celle-ci.
• Classe. Une subdivision au sein d’un qdisc avec classes. Considérez-la comme une voie avec sa propre limitation de vitesse.
• Filtre. Il inspecte les en-têtes des paquets (adresses IP, ports, marques) et affecte chaque paquet à une classe.
• Action. Ce qu’il advient d’un paquet une fois qu’il correspond à un critère : transmission, rejet, redirection.

Ces éléments forment une arborescence. Les paquets entrent au niveau du qdisc racine, passent par les filtres, sont triés en classes par un major:minor identifiant, puis finissent en file d’attente au niveau d’un qdisc « feuille » en vue de leur transmission.

Pour tout ce qui est plus complexe qu’une correspondance basée sur le port, marquez les paquets avec iptables ou nftables dans la table « mangle », puis utilisez le fw filtre de la tc pour les classer en fonction de leur marque. Cela offre une bien meilleure évolutivité que d’enchaîner des u32 pour chaque type de trafic.

Sortie vs entrée

Le sens du trafic a son importance. Le noyau peut mettre en mémoire tampon et retarder les paquets sortants, ce qui permet un véritable lissage du débit. Les paquets entrants ont déjà traversé le réseau au moment où vous les voyez ; vous ne pouvez donc que les contrôler (les rejeter au-delà d’un seuil) à moins de les rediriger au préalable vers un périphérique IFB.

Les qdiscs que vous utiliserez concrètement

• HTB (Hierarchical Token Bucket). Avec classes. À utiliser lorsque vous souhaitez garantir une bande passante minimale par service tout en pouvant emprunter de la capacité inutilisée à d’autres classes.
• TBF (Token Bucket Filter). Sans classes. À utiliser lorsque vous avez simplement besoin de limiter l'ensemble d'une interface à un débit unique.
• fq_codel (Fair Queuing Controlled Delay). Combine l'équité par flux avec une gestion active des files d'attente pour éliminer le « bufferbloat ». C'est le qdisc par défaut dans la plupart des distributions Linux depuis systemd 217 et il est fourni par défaut sur RHEL 9. Associez-le toujours en tant que qdisc « feuille » sous des classes HTB, sinon un seul flux gourmand peut monopoliser une classe entière.

Configuration de tc sur un serveur Linux

tc est fourni avec le paquet iproute2. Sous Debian et Ubuntu, installez-le à l'aide de la commande apt-get install iproute2. Sous RHEL et ses dérivés, yum install iproute. Vous aurez besoin des droits root ou de sudo.

Commencez par vérifier le nom correct de l'interface. Une erreur dans le nom de l'interface est la raison la plus courante pour laquelle une configuration ne produit aucun effet :

ip link show

Vérifiez ce qui se trouve déjà sur l'interface, y compris les compteurs en temps réel :

tc -s qdisc show dev eth0

Effacez tout qdisc « root » existant avant d’appliquer une nouvelle configuration, afin d’éviter les RTNETLINK answers: File exists d’erreurs :

tc qdisc del dev eth0 root 2>/dev/null || true

Si vous mettez à jour une règle existante plutôt que de partir de zéro, utilisez replace au lieu de add pour un remplacement atomique.

Les fonctions de déchargement matériel telles que TSO et GSO regroupent les paquets d’une manière qui interfère avec la mise en forme du trafic. Désactivez-les sur l’interface soumise à la mise en forme :

sudo ethtool -K eth0 tso off gso off

Définissez fq_codel comme qdisc par défaut à l'échelle du système pour les nouvelles interfaces :

sysctl -w net.core.default_qdisc=fq_codel

Pour les serveurs très sollicités, associez-le à l’algorithme de contrôle de congestion BBR (noyau 4.9+). Le BBR maintient un débit élevé sans allonger les files d’attente :

sysctl -w net.ipv4.tcp_congestion_control=bbr

Une bonne habitude de sécurité si vous configurez une machine distante via SSH : ouvrez une deuxième session et préparez tc qdisc del dev eth0 root prêt à être collé. Une règle de filtrage incorrecte peut vous bloquer l'accès instantanément.

Régulation du trafic sortant avec HTB

HTB vous permet d’attribuer à chaque service un minimum garanti (rate) et un plafond (ceil). La bande passante inutilisée est redistribuée à ceux qui en ont besoin, par ordre de priorité. Voici une configuration à trois niveaux fonctionnelle pour une liaison montante de 1 Gbit/s.

Créez le qdisc HTB racine. Le default 30 envoie tout paquet non classé vers la classe 1:30 plutôt que de le laisser contourner vos règles :

tc qdisc add dev eth0 root handle 1: htb default 30

Limitez le débit total à 900 Mbps. Réglez toujours la mise en forme légèrement en dessous de la capacité réelle de la liaison, sinon une file d’attente se formera sur un routeur ou un modem en amont que vous ne contrôlez pas :

tc class add dev eth0 parent 1: classid 1:1 htb rate 900mbit ceil 900mbit

Définissez les niveaux de service. Les prio basses bénéficient en priorité de la bande passante inutilisée :

# High priority: web and API traffic
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 500mbit ceil 900mbit prio 1
 
# Medium priority: database replication
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 300mbit ceil 900mbit prio 2
 
# Low priority: bulk and backup traffic
tc class add dev eth0 parent 1:1 classid 1:30 htb rate 100mbit ceil 900mbit prio 3

Ajoutez fq_codel comme qdisc de feuille à chaque classe afin qu’un flux unique ne puisse pas dominer son niveau :

tc qdisc add dev eth0 parent 1:10 handle 10: fq_codel
tc qdisc add dev eth0 parent 1:20 handle 20: fq_codel
tc qdisc add dev eth0 parent 1:30 handle 30: fq_codel

Classifiez maintenant le trafic. Pour une simple correspondance de ports, u32 c'est la méthode la plus rapide :

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
  match ip dport 443 0xffff flowid 1:10

Pour tout ce qui est « stateful », marquez dans iptables et faites correspondre la marque avec fw:

iptables -t mangle -A OUTPUT -p tcp --dport 5432 -j MARK --set-mark 2
tc filter add dev eth0 protocol ip parent 1:0 prio 2 handle 2 fw flowid 1:20

Régulation du trafic entrant avec l’IFB

Il n’est pas possible de réguler nativement le trafic entrant, car au moment où un paquet arrive, il a déjà utilisé votre bande passante. La solution consiste à rediriger le trafic entrant vers une interface virtuelle de type « Intermediate Functional Block » (IFB), où le noyau le traite comme du trafic sortant et vous permet d’appliquer des qdiscs par classe.

Chargez le module et activez l’interface :

modprobe ifb numifbs=1
ip link set dev ifb0 up

Ajoutez un qdisc d’entrée à l’interface physique et redirigez tout vers ifb0:

tc qdisc add dev eth0 ingress handle ffff:
tc filter add dev eth0 parent ffff: protocol all u32 \
  match u32 0 0 action mirred egress redirect dev ifb0

À partir de là, ifb0 se comporte comme n’importe quelle autre interface. Appliquez-y votre arborescence HTB exactement comme vous le feriez pour le trafic sortant :

tc qdisc add dev ifb0 root handle 1: htb default 30
tc class add dev ifb0 parent 1: classid 1:1 htb rate 900mbit ceil 900mbit
tc class add dev ifb0 parent 1:1 classid 1:10 htb rate 500mbit ceil 900mbit prio 1

Priorisation du trafic avec le DSCP

Le DSCP (Differentiated Services Code Point) marque les paquets à l’aide d’une valeur de 6 bits dans l’octet TOS, ce qui permet à vos tc filtres puissent classer les paquets par balise plutôt que de devoir rechercher les ports dans l’ensemble de règles. Lors de la correspondance du DSCP dans tc, décaler la valeur de 2 bits vers la gauche. DSCP EF (46) devient 0xb8. Le masque 0xfc isole les 6 bits DSCP des 2 bits ECN.

Un mappage par défaut judicieux pour les charges de travail des serveurs :

Marquez les paquets sortants dans iptables avant qu’ils n’atteignent vos tc filtres :

iptables -t mangle -A OUTPUT -p tcp --dport 22 -j DSCP --set-dscp 46

Puis, recherchez cette balise dans tc et acheminez-le vers la bonne classe HTB :

# EF (SSH, VoIP) goes to the high-priority class
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
  match ip tos 0xb8 0xfc flowid 1:10
 
# AF41 (web traffic) goes to the medium class
tc filter add dev eth0 protocol ip parent 1:0 prio 2 u32 \
  match ip tos 0x88 0xfc flowid 1:20
 
# CS1 (bulk) goes to the low-priority class
tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 \
  match ip tos 0x20 0xfc flowid 1:30

Surveillance et dépannage

Les trois commandes que vous utiliserez constamment :

tc -s qdisc show dev eth0
tc -s class show dev eth0
tc -s filter show dev eth0

Surveillez le dropped et overlimits . Les paquets perdus indiquent que la file d’attente est saturée ; les dépassements de limites signifient que vous avez atteint le plafond d’une classe et que le noyau a dû retarder ou rejeter du trafic. Pour un aperçu en temps réel :

watch -n 1 'tc -s class show dev eth0'

Ajoutez -d pour les paramètres internes (target, interval, quantum) et -j pour une sortie JSON si vous redirigez les données vers une pile de métriques. Associez-le à ss -tin pour voir les estimations de RTT et les retransmissions au niveau de la couche TCP.

La plupart des défaillances relèvent d’une liste restreinte :

Si jamais vous vous retrouvez bloqué à cause d’une mauvaise configuration, la réinitialisation est simple :

tc qdisc del dev eth0 root

tc on ne peut pas créer de la bande passante que l’on n’a pas, mais sur une liaison montante bien provisionnée, cela fait toute la différence entre des performances prévisibles et un serveur qui s’effondre dès qu’un locataire lance un transfert volumineux. Si vous avez besoin de bande passante brute et de la liberté de la modeler comme bon vous semble, jetez un œil aux serveurs dédiés de FDC.