Ab Anfang 2019 ist bpfilter noch in der Entwicklung und noch nicht nutzbar. Das Grundgerüst ist hier und kann sogar in 4.18+ -Kerneln aktiviert werden, tut aber vorerst nicht viel, da es nicht vollständig ist. Der Code, der für die Übersetzung von iptables-Regeln in BPF-Bytecode erforderlich ist, obwohl er entlang des ursprünglichen RFC eingereicht wurde, hat es zu diesem Zeitpunkt noch nicht in den Kernel geschafft.

Sobald es fertig ist, sollte kein spezifisches Werkzeug erforderlich sein. Bpfilter wird wahrscheinlich mit etwas wie modprobe bpfilter aktiviert, und dann besteht die ganze Idee darin, das Backend transparent zu ersetzen, während das Frontend unberührt bleibt: Also iptables sollte das einzige Werkzeug sein, das für die Handhabung der Regeln erforderlich ist, ohne dass eine bestimmte Option erforderlich ist. Zusätzlich erlaubt das bpftool die Überprüfung der im Kernel geladenen eBPF-Programme (einschließlich der von bpfilter übersetzten iptables-Regeln).

Sie können dies überprüfen, wenn Sie im folgenden Video möchten (Haftungsausschluss: von meiner Firma), die zeigt, wie wir bpfilter mit einer klassischen iptables-Regel verwendet haben (wir hatten den Kernel mit dem Code aus dem RFC gepatcht; und Ausführen des bpfilter.ko in der Konsole ist in der endgültigen Version nicht erforderlich).

Sie können weiterhin BPF-Programme an den XDP-Hook anhängen (auf Treiberebene), auch ohne bpfilter zu verwenden, um eine viel bessere Leistung als netfilter zu erzielen. Sie müssten Ihre Regeln jedoch vollständig als C-Programme umschreiben, sie mit clang in eBPF kompilieren und sie z. B. mit dem Tool ip (von iproute2) laden. Ich weiß nicht, ob dies zu Ihrem „Feature-Set“ passen würde. Je nachdem, wie stark Ihr Bedarf ist, könnte eine andere drastische Option darin bestehen, Ihre Paketverarbeitung in den Benutzerbereich zu verschieben und Ihr Setup mit dem DPDK-Framework neu zu implementieren.