Début 2019, bpfilter est encore en développement et n’est pas encore utilisable. Le squelette de base est ici et peut même être activé dans les noyaux 4.18 +, mais ne fait pas grand-chose pour l’instant car il n’est pas complet. Le code requis pour traduire les règles iptables en bytecode BPF, bien que soumis avec la RFC d’origine, n’est pas parvenu au noyau pour le moment.

Une fois qu’il est prêt, aucun outillage spécifique ne devrait être requis. Bpfilter sera probablement activé avec quelque chose comme modprobe bpfilter, puis l’idée est de remplacer de manière transparente le back-end, tout en laissant le front-end intact: donc iptables devrait être le seul outil requis pour gérer les règles, sans aucune option particulière requise. De plus, bpftool permet d’inspecter les programmes eBPF (y compris les règles iptables traduites par bpfilter) chargés dans le noyau.

Vous pouvez vérifier cela si vous le souhaitez dans la vidéo suivante (avertissement: par mon entreprise), qui montre comment nous avons utilisé bpfilter avec une règle iptables classique (nous avions corrigé le noyau avec le code de la RFC; et exécuté le bpfilter.ko dans la console ne sera pas nécessaire sur la version finale).

Vous pouvez toujours attacher des programmes BPF au hook XDP (au niveau du pilote), même sans utiliser bpfilter, pour obtenir de bien meilleures performances que ce qu’offre netfilter. Cependant, vous devrez réécrire complètement vos règles en tant que programmes C, les compiler dans eBPF avec clang et les charger avec, par exemple, l’outil ip (à partir d’iproute2). Je ne sais pas si cela correspondrait à votre « ensemble de fonctionnalités ». Selon la force de votre besoin, une autre option radicale pourrait être de déplacer le traitement de vos paquets vers l’espace utilisateur et de réimplémenter votre configuration avec le framework DPDK.