BPF уже смотрел?

Вроде как возможно перенаправлять трафик на SOCKS-прокси правилом вида -j REDIRECT --to-ports 1337 (примеры раз (linuxaria.com), два (0day.work)), но не уверен, что это действительно то, что нужно.

Ещё один пример, уже для роутера с NAT.

В общем...

Отстаньте вы уже от этих 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, не придумывайте колесо заново, как и сказно выше.

При использовании IPv6 ip6tables умеет TPROXY для нужд ТС. Как это реализовать на nftables?

nft_tproxy с ядра 4.19.

При использовании IPv6 ip6tables умеет TPROXY для нужд ТС.

https://wiki.nftables.org/wiki-nftables/index.php/Supported_features_compared... И тут не важно для ipv4 или для ipv6.

Как это реализовать на nftables?

Дайте угадаю... Молча? Начав читать документацию? Не? Не оно?

Вы теоретик? Сами писали правила для сетевых экранов?

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

Насколько я помню там для переброса трафика используется NFQUEUE. Сделайте у себя на локалхосте iptables -C INPUT -j NFQUEUE и удивитесь - у вас оказался подгружен «спец. модуль ядра для сетевых карт».

Дайте угадаю... Молча? Начав читать документацию? Не? Не оно?

Дайте угадаю - в реальности вы этого не делали. потому как

TPROXY
nft_tproxy, upcoming release (4.19)

~ # uname -a
Linux Keenetic_Viva 3.4.113 #1 Wed Mar 13 12:06:31 MSK 2019 mips GNU/Linux

Keenetic_Viva 3.4.113

ССЗБ. Они такие слоупоки, что на ближайшие годы недавно выбрали 4.9. И это вина разрабов из Keenetic, а не OpenWRT.

У меня к ним претензий нет. Раз вы их критикуете то предложите промышленное/массовое решение в сфере маршрутизаторов на Linux c поддержкой TPROXY в nftables - будем ориентироваться на них.

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

Мне не важно iptables или nftables. Мне важно что бы любым способом нужный мне трафик можно было ИЗМЕНИТЬ (а не дропнуть или пропустить). Может где есть пример такой hello-world программы?

Проблема классического прозрачного прокси, что трафик передаваемый от прокси к серверу будет иметь dst как IP адрес прокси сервера, а мне бы хотелось что бы было полностью прозрачно.

В общем случае трафик снимаете посредством DNAT(IPv4) или TPROXY (IPv4/IPv6) в iptables или nftables (будут проблемы с TPROXY). В качестве самого прокси можно глянуть tpws из zapret. Там реализована самая простая модификация трафика.

Проблема классического прозрачного прокси, что трафик передаваемый от прокси к серверу будет иметь dst как IP адрес прокси сервера, а мне бы хотелось что бы было полностью прозрачно.

Видимо всё-таки не dst а src. Используйте TPROXY - там IP адреса остаются родными.

Порошенко, перелогинься . (jpg.wtf)

Нет. Не так. Всё не так.

Мне важно что бы любым способом нужный мне трафик можно было ИЗМЕНИТЬ (а не дропнуть или пропустить).

У Вас должен быть «пакет». Который Вы получили из сетевого интерфейса и отправили в user-space на анализ. Если у Вас есть «пакет», то совершенно пофиг что Вы с ним сделаете дальше (измените флаги, поменяете payload, дропните или что ещё, что подскажет фантазия). Достаётся пакет из kernel space в user space через интерфейс netlink. А это именно файервол, оттуда пакет можно выцепить чтобы поменять каким-либо образом. Нельзя так просто выцепить пакеты RAW, т.к. они обрабатываются не файером, а непосредственно приложением. Его мы не рассматриваем.

Здесь я затрудняюсь что-либо конкретное Вам сказать, т.к. словосочетание «трафик можно было бы ИЗМЕНИТЬ» является слишком общим. Как именно Вы собрались менять трафик из этого определения мне не ясно.

В любом случае, если Вы собрались менять трафик на уровне пользовательского приложения, то Вам придётся что в случае с iptables, что в случае nftables работать с netlink. Вот только для nftables есть специальные библиотеки (выше дал названия), которые облегчают эту работу и позволяют как минимум хотя бы не косячить и не рукоблудить лишнего. В случае с iptables Вас ждёт ряд неприятных открытий.

Мне не важно iptables или nftables.

Одним из неприятных открытий будет «скорость» iptables в сравнении с... Так что, оно Вам «не важно» пока Вы не начали писать свой фильтр пакетов для устройства и не столкнулись с тем, что всё реализуется через задницу (для iptables) и всё дико тормозит. Ну и работа с iptables over netlink это ещё то «удовольствие».

Писать здесь проксик? Не уверен, т.к. насколько я понимаю, разговор идёт обо всех пакетах, приходящих на интрефейс, невзирая на их протокол. Тогда это уровень L2 (ну максимум L3), но уж совсем ни как не проксик, который работает на L4. Кто вообще чего-то брякнул про проксирование, я так и не понял, но это и не важно.

Жёсткость моего ответа выше (в удалённых) связана с тем, что я таких... мать его «решений» уже столько навидался, что хоть стой, хоть падай. И когда мне приводят в пример тот же кинетик, то я всегда отвечаю что он (кинетик) уже есть, его можно пойти-купить и второй клон, не несущий в себе ни каких улучшений по отношению к самому кинетику, не нужен в принципе.

Ну а дальше уже дело Ваше. Успехов.

Теперь точно высказался.

Вот программка на 350 строк, которая меняет TCP пакеты: https://github.com/rgerganov/nfqsed

дык setsockopt(fd,SOL_IP, IP_TRANSPARENT) для bind() на не локальные адреса.

учитывая общую тенденцию на безопасность протоколов и шифрование, это наименьшая из проблем. сети устроены так, чтобы кто попало не мог влезть между юзером и сервером. и это, в принципе, правильно.

netsed - network packet-altering stream editor