vanaf begin 2019 is bpfilter nog in ontwikkeling en nog niet bruikbaar. Het basis skelet is hier en kan zelfs worden geactiveerd in 4.18 + kernels, maar doet niet veel voor nu als het is niet compleet. De code die nodig is voor het vertalen van iptables-regels naar BPF bytecode, is op dit moment nog niet in de kernel terechtgekomen, hoewel deze via de oorspronkelijke RFC is aangeleverd.

zodra het klaar is, zou er geen specifieke tooling nodig moeten zijn. Bpfilter zal waarschijnlijk worden ingeschakeld met iets als modprobe bpfilter, en dan is het hele idee om transparant de back-end te vervangen, terwijl de front-end onaangeroerd blijft: dus iptables zou het enige gereedschap moeten zijn dat nodig is om de regels te hanteren, zonder dat er een specifieke optie vereist is. Daarnaast maakt de bpftool het mogelijk om de eBPF-programma ‘ s (inclusief iptables-regels vertaald door bpfilter) die in de kernel zijn geladen, te inspecteren.

u kunt dit controleren als u wilt in de volgende video (disclaimer: door mijn bedrijf), wat laat zien hoe we bpfilter gebruikten met een klassieke iptables regel (we hadden de kernel gepatcht met de code van de RFC; en het uitvoeren van de bpfilter.ko in de console zal niet nodig zijn op de definitieve versie).

je kunt nog steeds BPF programma ‘ s koppelen aan de XDP hook (op bestuurdersniveau), zelfs zonder bpfilter te gebruiken, om veel betere prestaties te krijgen dan wat netfilter biedt. Echter, je zou je regels volledig moeten herschrijven als C programma ‘ s, ze compileren in eBPF met clang, en ze laden met bijvoorbeeld de ip tool (van iproute2). Ik weet niet of dit zou overeenkomen met uw “feature set”. Afhankelijk van hoe sterk uw behoefte is, zou een andere drastische optie kunnen zijn om uw pakketverwerking naar gebruikersruimte te verplaatsen en uw setup opnieuw in te vullen met het dpdk framework.