История изменений

Отстаньте вы уже от этих iptables. Хорош уже этот трупик насиловать.

Для такого рода вещей есть nftables и там в аккурат для этих целей идёт libnftnl. И, что самое главное, есть ещё libmnl, которая тоже юзерспейсная, но она позволяет, как сказано в документации:

libmnl is a minimalistic user-space library oriented to Netlink developers. There are a lot of common tasks in parsing, validating, constructing of both the Netlink header and TLVs that are repetitive and easy to get wrong. This library aims to provide simple helpers that allows you to re-use code and to avoid re-inventing the wheel.

Насчёт re-inventing the wheel хорошо сказано, поддерживаю.

Несмотря на то, что чисто теоретически nftables считаются нестабильными в части API, и сам с ними работаю и другим рекомендую.

Надеюсь, этого Вам хватит для решения задачи.

UPD.

На роутере на линукс нужно iptables FORWARD трафик отпралять в user-space, там в своей программе его изменять и отпралять в ядро для дальнейшей отсылки. То есть мне надо научится делать что-то типа прозрачного прокси, изменяющего на определенных портах некоторые данные. Как подойти к такой задаче? Есть для этого API в user space? Если нет, то какое API в ядре надо использовать что бы написать свой драйвер, отпраляющий трафик в user-space и возвращающий данные из него?

Это Вы пытаетесь таким нехитрым образом suricata заново изобрести? Не, не получится. В сурикате для этих целей (весьма похоже на Ваше описание) использовались специализированные модули ядра для сетевых карт, позволяющие из пространства ядра быстро кинуть пакеты в пространство пользователя и там проанализировать, сделав выводы (дропнуть, например, или пропустить).

Заменяйте на nftables, не придумывайте колесо заново, как и сказно выше.

Отстаньте вы уже от этих iptables. Хорош уже этот трупик насиловать.

Для такого рода вещей есть nftables и там в аккурат для этих целей идёт libnftnl. И, что самое главное, есть ещё libmnl, которая тоже юзерспейсная, но она позволяет, как сказано в документации:

libmnl is a minimalistic user-space library oriented to Netlink developers. There are a lot of common tasks in parsing, validating, constructing of both the Netlink header and TLVs that are repetitive and easy to get wrong. This library aims to provide simple helpers that allows you to re-use code and to avoid re-inventing the wheel.

Насчёт re-inventing the wheel хорошо сказано, поддерживаю.

Несмотря на то, что чисто теоретически nftables считаются нестабильными в части API, и сам с ними работаю и другим рекомендую.

Надеюсь, этого Вам хватит для решения задачи.

UPD.

На роутере на линукс нужно iptables FORWARD трафик отпралять в user-space, там в своей программе его изменять и отпралять в ядро для дальнейшей отсылки. То есть мне надо научится делать что-то типа прозрачного прокси, изменяющего на определенных портах некоторые данные. Как подойти к такой задаче? Есть для этого API в user space? Если нет, то какое API в ядре надо использовать что бы написать свой драйвер, отпраляющий трафик в user-space и возвращающий данные из него?

Это Вы пытаетесь таким нехитрым образом suricata изобрести? Не, не получится. В сурикате для этих целей (весьма похоже на Ваше описание) использовались специализированные моули ядра для сетевых карт, позволяющие из пространства ядра быстро кинуть пакеты в пространство пользователя и там проанализировать, сделав выводы (дропнуть, например, или пропустить).

Заменяйте на nftables, не придумывайте колесо заново, как и сказно выше.

Отстаньте вы уже от этих iptables. Хорош уже этот трупик насиловать.

Для такого рода вещей есть nftables и там в аккурат для этих целей идёт libnftnl. И, что самое главное, есть ещё libmnl, которая тоже юзерспейсная, но она позволяет, как сказано в документации:

libmnl is a minimalistic user-space library oriented to Netlink developers. There are a lot of common tasks in parsing, validating, constructing of both the Netlink header and TLVs that are repetitive and easy to get wrong. This library aims to provide simple helpers that allows you to re-use code and to avoid re-inventing the wheel.

Насчёт re-inventing the wheel хорошо сказано, поддерживаю.

Несмотря на то, что чисто теоретически nftables считаются нестабильными в части API, и сам с ними работаю и другим рекомендую.

Надеюсь, этого Вам хватит для решения задачи.