Изменение TCP пакетов прямо перед отправкой

Зачем?

Можно ли так модернизировать код ядра? И в каких файлах это делать?

Да, можно.

Но только не следует заниматься лоботомией исходников ядра, а вместо это сделать свой «гадкий» модуль.

15 лет назад это выглядело примерно так.

Вообщем нужно решить следующую задачу. Есть приложение работающее через TCP (TCP сервер), есть Ethernet интерфейс (скажем eth1 с IP 192.168.1.3). Код сервера менять нельзя. Нужно каким-то образом сделать прослойку между этим интерфейсом и приложением, которая будет добавлять/убирать резервирование пакетов (протокол PRP), при этом особенность в том что интерфейс один, а не два, т. е. оба дубликата нужно слать/принимать через один интерфейс. Т. е. TCP сервер–>?резервирование+добавка хвоста?–>eth1–>сеть–>клиент клиент–>сеть–>eth1–>?убрать резервирование и хвост?->TCP сервер

Дело в том, что не могу придумать как сделать прослойку между TCP сервером и интерфейсом, так чтобы весь трафик проходил через нее и можно было перехватить «сырой трафик» и добалять/убирать хвосты. Пробовал через tap интерфейс, но не очень получилось.

На правах идеи, если кидаешь второй пакет, то почему бы не кидать его с нужной инфой, соответствующей первому пакету.

Но вообще, хочется знать «зачем», может подскажут более интересное решение.

Дело в том, что не могу придумать как сделать прослойку между TCP сервером и интерфейсом, так чтобы весь трафик проходил через нее и можно было перехватить «сырой трафик» и добалять/убирать хвосты. Пробовал через tap интерфейс, но не очень получилось

Написать свой сервер, на приемной стороне и он будет обрубать доп инфу, и уже ее досылать на локальный localhost сервер, где нельзя менять код. Номера портов у кого то придется сменить. Предлагаю ретранслятор.

Наверное только такое решение возможно. Вместе с портом наверное придется менять контрольную сумму IP пакета. Есть ли готовые функции для этого?

Контрольная сумма IP пакета считается легко. Для какого языка надо?

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

А смогу ли я в этом случае изменять те части пакета, которые не относятся к TCP/IP. Т. е. как я понимаю у прокси сервера все сокеты будут TCP/IP, а мне надо на layer 2 менять пакет, т. е. чтобы мои добавления не влияли на IP/TCP заголовок. Или я что-то не понимаю?

В ядро лезть необязательно, можно наваять свою библиотеку с интерфейсом berkley sockets и запускать тот неизменяемый сервер со своей библиотекой, подсунутой через LD_PRELOAD.

eBPF

Дописать и убрать байты из фрейма можно с помощью NFQUEUE. Возможно, чтобы воткнуться на L2, нужно будет выкинуть iptables и заюзать nftables, но iptables и так давно сгнил. Насчёт отправки второго пакета не уверен, надо гуглить.

Не рассматривал вариант с использованием ip-заголовка? Стандартный заголовок 20 байт или 5 слов, а может быть и 31 слово. Там есть где хранить 8 байт.

Раньше для iptables был таргет TEE, он умел дублировать пакеты. Подправить его значительно проще, чем делать с нуля.

NFQUEUE будет полезен на приеме.

eBFP не позволяет модифицировать ничего в ядре.

А что будет с дублированным пакетом? Как клиент на это должен реагировать?

Пруф будет?

https://github.com/xdp-project/xdp-tutorial/tree/master/packet02-rewriting

Это XDP. Увеличить размер пакета в XDP нельзя.

примерно тойже фигней маялся только что ))

sk_buff - внести изменения в пакет ip

Клиент должен отбрасывать. Ну я так понимаю что, TCP и UDP стеки и так умеют это делать (отбрасывать одинаковые пакеты)

Клиент должен отбрасывать. Ну я так понимаю что, TCP и UDP стеки и так умеют это делать (отбрасывать одинаковые пакеты)

А зачем тогда два слать, если есть SACK?

непосредственно перед отправкой в сеть нужно добалять хвост (8 байт)

протокол PRP

PRP trailer занимает не 6 байт?

Пробовал через tap интерфейс, но не очень получилось.

Где именно пошло не так?

Да, вы правы PRP trailer занимает 6 байт. +2 байта для микросхемы-коммутатора для правильной коммутации (для этой микросхемы нужен свой trailer. А что касается tap-интерфейса, то привязывать сервер к виртуальному интерфейсу удается только через IP (чтобы сервер работал только через виртуальный интерфейс), и проблема потом перекидывать пакеты с виртуального интерфейса на реальный, с другим IP, т. е. менять IP, контрольную сумму и т. д., что не очень удобно… Вообще нравиться идея mv с написанием своей библиотеки сокетов и заменой их с помощью LD_PRELOAD. Вопрос только где взять исходный код berkley sockets чтобы не писать с нуля.

Неплохая идея, а где бы взять исходный код berkley sockets, которые используются в моей версии ядра (4.14.40), чтобы не пришлось писать с нуля функции, а просто модернизировать уже готовый код…

Так ты дальше ядру передавай, как сделаешь, что надо. А какие сисколлы не трогаешь, так те и не переопределяй.

т. е. менять IP, контрольную сумму и т. д., что не очень удобно…

Да, разумеется, если нужно заменить содержимое, то кое-что надо будет заменить дополнительно.

Вообще нравиться идея mv с написанием своей библиотеки сокетов и заменой их с помощью LD_PRELOAD. Вопрос только где взять исходный код berkley sockets чтобы не писать с нуля. Но менять код библиотеки мне кажется ещё менее удобным.

На самом деле mv имел ввиду не замену кода, а создание обёртки. Переопределяешь send(), в ней создаёшь новый пакет, копируя всё что тебе нужно из старого и добавляя новое, потом просто вызываешь настоящий send() и всё.

На правах вброса: свитч с мирроринг портом ничем не поможет?

Можно дублировать весь трафик на другое устройство и анализировать/менять его там не трогая трафик до основного сервера.