Tiếng Việt
English
中文
Español
हिन्दी
Français
Português
Русский
Deutsch
日本語
한국어
Italiano
Bahasa Indonesia
ไทย
বাংলা
ລາວ
မြန်မာ
العربية
فارسی
اردو
Українська
Română
Azərbaycan
Le goulot d'étranglement de la classification : Les limites des filtres logiciels
Les passerelles VPN d'entreprise et les concentrateurs de trafic à haute densité traitent des volumes considérables de données réseau. Lorsque les liens d'agrégation atteignent 25 Gbps, 40 Gbps ou 100 Gbps, les débits d'arrivée dépassent couramment des dizaines de millions de paquets par seconde (Mpps). À cette échelle, la classification des paquets—qui consiste à analyser les en-têtes pour décider du routage, du filtrage pare-feu, de la limitation de bande passante et de l'affectation aux tunnels—devient le principal facteur limitant du système.
Historiquement, les administrateurs Linux s'appuyaient sur les chaînes de règles iptables ou les premières tables nftables. Bien qu'adaptées aux petits routeurs, ces approches logicielles présentent des contraintes architecturales majeures :
- Parcours séquentiel des règles dans le contexte d'interruption logicielle : Les pare-feu logiciels examinent les listes de règles de manière linéaire. Lorsque les paquets franchissent la pile réseau via les routines d'interruption logicielle
ksoftirqd, le passage en revue de centaines de règles consomme une part considérable des cycles du processeur hôte. Face à un déluge massif de paquets UDP non sollicités visant un port VPN, les cœurs CPU saturent avant même de pouvoir vérifier les charges utiles. - Arithmétique fragile des décalages d'octets avec les anciens classificateurs : L'ancien classificateur
u32du sous-système Linux Traffic Control imposait des calculs manuels de décalage de bits. La variabilité des options d'en-tête IPv4, des extensions IPv6 et des encapsulations imbriquées provoquait régulièrement des désalignements ou des erreurs de traitement. - Congestion du bus mémoire et saturation des mémoires caches : En mode logiciel exclusif, chaque paquet reçu traverse le bus PCIe et alloue une structure de tampon de socket (
sk_buff) en mémoire vive. Sous un trafic intense, les mémoires caches L2 et L3 du processeur sont continuellement purgées, privant les modules cryptographiques ChaCha20-Poly1305 et AES-GCM des ressources de calcul indispensables.
Pour soutenir une cadence de ligne constante et éliminer la saturation des interruptions logicielles, les passerelles VPN nécessitent un classificateur moderne capable de transférer les règles de décision directement dans les puces des adaptateurs réseau : Linux TC Flower (cls_flower).
Architecture du classificateur Linux TC Flower (cls_flower)
Intégré aux versions modernes du noyau Linux, le classificateur Flower (cls_flower) transforme le sous-système de contrôle du trafic (tc) en un moteur de classification de flux hautement performant. Contrairement aux calculs complexes d'octets de u32, Flower s'appuie sur le dissected de flux natif du noyau (net/core/flow_dissector.c) pour analyser de manière structurée les champs des couches 2, 3 et 4.
+-------------------------------------------------------------------------+
| Trame Ethernet entrante (Ingress) |
+-------------------------------------------------------------------------+
|
v
+-------------------------------------------------------------------------+
| Moteur de dissection de flux du noyau |
| - Extraction L2 : Adresses MAC, identifiant VLAN, EtherType |
| - Extraction L3 : Adresses source et destination IPv4/IPv6, DSCP |
| - Extraction L4 : Ports UDP/TCP, drapeaux TCP, types ICMP |
| - Extraction des clés d'encapsulation de tunnel (VNI, Tunnel ID) |
+-------------------------------------------------------------------------+
|
v
+-------------------------------------------------------------------------+
| Table de hachage et masque Flower |
| - Recherche en temps quasi constant O(1) sur les tuples configurés |
+-------------------------------------------------------------------------+
| |
Correspondance Aucune correspondance
| |
v v
+-----------------------+ +-----------------------+
| Action TC assignée | | Traitement par défaut |
| - drop (rejet direct)| | Pile réseau IP |
| - mirred redirect | +-----------------------+
| - police (limitation)|
| - skbedit priority |
+-----------------------+
Avantages techniques déterminants de TC Flower
- Tables de hachage par masque (Mask-and-Match) : Flower regroupe les règles de filtrage selon leurs masques de bits. Au lieu d'analyser les critères un à un, le paquet entrant fait l'objet d'un hachage unique sur les champs d'en-tête ciblés, garantissant une classification instantanée en O(1), quel que soit le volume total de règles.
- Prise en charge native des attributs réseau : Flower reconnaît directement les critères avancés sans script annexe, notamment les balises VLAN (
vlan_id,vlan_prio), les valeurs de priorité DSCP (ip_tos), les drapeaux de négociation TCP (tcp_flags syn) et les signatures de ports UDP. - Actions modulaires combinables : Lorsqu'un flux correspond à une règle, Flower peut lui appliquer diverses actions, telles que la destruction immédiate (
action drop), la redirection matérielle (action mirred egress redirect), le contrôle de débit (action police) ou la modification de priorité dans le tampon (action skbedit).
Pour appliquer un filtre Flower sur une interface, l'administrateur active préalablement la discipline de file ingress :
# Attacher la discipline ingress sur l'interface physique enp1s0f0
tc qdisc add dev enp1s0f0 ingress
# Rejeter immédiatement le trafic UDP non sollicité visant les ports internes
tc filter add dev enp1s0f0 ingress protocol ip prio 10 flower \
ip_proto udp \
dst_port 53 \
action drop
Performance à cadence de ligne grâce au déchargement matériel ASIC
Si Flower offre une classification logicielle rapide en mémoire noyau, sa caractéristique la plus puissante réside dans sa compatibilité native avec le déchargement matériel ASIC (Hardware Offload) via l'architecture switchdev.
Les cartes réseau modernes de classe entreprise (telles que les puces Intel Columbiaville E810 ou Mellanox ConnectX-5/6/7) intègrent des processeurs de paquets configurables dotés de mémoire TCAM (Ternary Content Addressable Memory). Lorsque les indicateurs de déchargement sont spécifiés, le noyau Linux traduit les règles Flower en microcode et les inscrit directement dans les tables matérielles de la carte.
+-------------------------------------------------------------------+
| Liaison par fibre optique physique |
+-------------------------------------------------------------------+
|
v
+-------------------------------------------------------------------+
| Émetteur-récepteur et couche physique MAC/PHY |
+-------------------------------------------------------------------+
|
v
+-------------------------------------------------------------------+
| Processeur matériel et tables de flux TCAM de la carte |
| (Règles TC Flower déchargées en silicium) |
| |
| Règle : Rejet UDP indésirable (skip_sw) --> [SUPPRESSION SILICIUM|
| Règle : Port 51820 RiceGuard --> [DMA VERS CŒURS DÉDIÉS|
+-------------------------------------------------------------------+
| (Seuls les paquets VPN chiffrés valides avancent)
v
+-------------------------------------------------------------------+
| Bus PCIe hôte et mémoire vive (DMA) |
+-------------------------------------------------------------------+
|
v
+-------------------------------------------------------------------+
| Moteur de déchiffrement multi-cœur de RiceGuard |
+-------------------------------------------------------------------+
Les trois modes de déchargement de TC Flower
Lors de l'application d'un filtre, l'administrateur peut définir le niveau d'exécution matérielle :
- Déchargement automatique (Défaut) : Si le pilote matériel prend en charge la règle, le noyau l'installe sur l'ASIC tout en maintenant une réplique en mémoire logicielle. En cas de saturation du silicium, le système bascule automatiquement sur l'exécution logicielle.
- Mode
skip_hw: Limite le filtre à la mémoire du noyau hôte sans consommer les tables de la carte. Pratique pour les règles complexes aux fonctionnalités non supportées par l'ASIC. - Mode
skip_sw(Exécution matérielle exclusive) : Impose que la règle réside uniquement au sein du silicium de la carte réseau. Si le matériel ne peut pas exécuter exactement le masque ou l'action demandée, la commandetcretourne une erreur immédiate.
Exemple de filtrage matériel autonome sur une interface 100 GbE :
# Rejeter les sous-réseaux IP usurpés directement dans le silicium
tc filter add dev enp1s0f0 ingress protocol ip prio 1 flower \
src_ip 198.51.100.0/24 \
skip_sw \
action drop
# Diriger les flux VPN valides vers les files de haute priorité
tc filter add dev enp1s0f0 ingress protocol ip prio 2 flower \
ip_proto udp \
dst_port 51820 \
skip_sw \
action skbedit priority 1
Grâce à skip_sw, les paquets malveillants ou non autorisés sont rejetés dès la couche physique Ethernet de la carte. Aucun octet ne franchit le bus PCIe, aucun tampon sk_buff n'est alloué en mémoire vive et la charge CPU liée aux interruptions logicielles reste strictement nulle.
Mise en œuvre des politiques de sécurité dans l'architecture RiceGuard
Au sein de l'infrastructure distribuée de VPNRice, le moteur RiceGuard associe des primitives cryptographiques de pointe à une gestion matérielle des flux afin de garantir un débit optimal et un cloisonnement rigoureux entre utilisateurs.
+-------------------------------------------------------------------+
| Passerelle périphérique VPNRice |
| |
| +-----------------------------------------------------------+ |
| | Carte réseau physique 100 GbE (Intel / Mellanox) | |
| | Mémoire TCAM : Règles TC Flower (skip_sw) | |
| +-----------------------------------------------------------+ |
| | | |
| [Port 51820 VPN Valide] [Trafic non authentifié]|
| | | |
| v v |
| File RX dédiée en DMA Rejeté par le silicium |
| | (0 % de charge CPU hôte)|
| v |
| +-------------------------------------------------------------+ |
| | Cœur cryptographique RiceGuard | |
| | Déchiffrement ChaCha20-Poly1305 | |
| +-------------------------------------------------------------+ |
| | |
| v |
| +-------------------------------------------------------------+ |
| | Espaces de noms isolés et résolveurs DNS chiffrés | |
| | Protection absolue contre les fuites en clair | |
| +-------------------------------------------------------------+ |
+-------------------------------------------------------------------+
1. Démultiplexage des flux entrants
Au lieu de faire converger l'ensemble des paquets vers une file d'attente logicielle unique, RiceGuard met en place des filtres TC Flower qui distinguent les négociations initiales des flux UDP confirmés. L'ASIC de la carte réseau oriente ces paquets vers des anneaux de réception dédiés couplés aux cœurs CPU via la technologie Receive Side Scaling (RSS), éliminant les conflits de verrous et préservant une latence inférieure à la milliseconde.
2. Protection matérielle contre les flux massifs
Des rafales de paquets non authentifiés peuvent perturber le fonctionnement d'une passerelle VPN en multipliant les calculs de négociation. En utilisant le mécanisme de régulation matérielle (action police rate 100mbit burst 10k drop skip_sw), les nœuds de passerelle imposent un plafond strict aux flux entrants directement dans la puce réseau. Les surcharges sont neutralisées en amont du processeur, permettant aux cœurs de déchiffrement de rester réactifs.
3. Isolation par espaces de noms et étanchéité des données
Chaque environnement client au sein du maillage RiceGuard est isolé dans un espace de noms réseau Linux distinct. Les règles de redirection TC Flower veillent à ce qu'aucun paquet interne non chiffré ne puisse s'échapper vers les interfaces physiques externes. Parallèlement, des relais DNS locaux chiffrés sont déployés dans chaque espace de noms, évitant toute fuite de requêtes DNS et assurant la confidentialité intégrale des flux sous de fortes charges multi-gigabits.
