Вопрос в следующем: есть необходимость поставить дополнительный обработчик TCP-пакетов в ядро.
Суть в следующем - любой пакет, собирающийся отправиться по сетки (независимо от приложения) должен пройти через некий обработчик (в моем случае - шифрование), на обратном конце, ес-но - обратное преобразование.
т.е. если пакет идет в сеть - обработать, если из сети - тоже обработать.
Подскажите, плиз, в каком направлении копать ?
Возможен вариант в принципе организации псевдо-девайса, где это все делать. (аналог - shapecfg например).
Спасибо.
В данный момент вижу несколько путей:
1. Взять исходники драйверов сетевой карты и пропатчить их так, чтобы перед отправкой данных происходила их модификация. В этом случае понятно, что любая передача данных через этот интерфейс вызывает модицикацию данных - что не очень хорошо. Да и привязка к модели карты есть..
2. Изучить процесс виртуального интерфейса (типа tun или shape) и там делать модификацию данных (ес-но с написанием модуля такого интерфейса). В таком случае, полагаю, будет отсутствовать привязка к конкретной сетевой карте, но пока неясен вопрос - а физически это можно будет сделать ? т.е. в этот вирт. интерфейс (в модуль) будут ли передаваться фактические данные ?
3. Поглядеть на ipchains - может там что получится сделать. Неплохо было бы задавать там правила и соответствующую цель, в которой и происходила бы модификация данных. Это практически идеальный вариант.Может кто прокомментировать что по сущестсу дела ?
>В данный момент вижу несколько путей:
>1. Взять исходники драйверов сетевой карты и пропатчить их так, чтобы перед
>отправкой данных происходила их модификация. В этом случае понятно, что любая
>передача данных через этот интерфейс вызывает модицикацию данных - что не
>очень хорошо. Да и привязка к модели карты есть..
>2. Изучить процесс виртуального интерфейса (типа tun или shape) и там делать
>модификацию данных (ес-но с написанием модуля такого интерфейса). В таком случае,
>полагаю, будет отсутствовать привязка к конкретной сетевой карте, но пока неясен
>вопрос - а физически это можно будет сделать ? т.е. в
>этот вирт. интерфейс (в модуль) будут ли передаваться фактические данные ?
>
>3. Поглядеть на ipchains - может там что получится сделать. Неплохо было
>бы задавать там правила и соответствующую цель, в которой и происходила
>бы модификация данных. Это практически идеальный вариант.
>
>Может кто прокомментировать что по сущестсу дела ?мне не кажется - что ipchains - хорошая идея
ничего не получиться
или ты в исходниках собрался ето глядеть?может проще сформировать пакет вручную а потом выкинуть в сеть через raw socket?
также принять рау сокетом
распарсить расшифровать =)
моно не raw socket`ом а libnet/libpcap
или смотри в сторону bpf
Такое вряд ли получится.. кидать в сокет.
так как мне нужно перехватывать все пакеты от всех приложений, которые хотят выйти наружу, и делать над ними определенные действия..
и затем выкидывать наружу...
Ну скажем, выкидывать пакеты - это можно.. а как быть, чтобы ловить те пакеты, которые хоят наружу выйти, и далее их в первичном виде не пускать наружу ?application ---> my function ---> socket
application ----|
.
.
. ^
application ----|
весьма изящный способ - модуль к iptables. можно будет выбирать, что шифровать, например, или, используя owner (man iptables) можно будет по-разному шифровать для разных пользователей.
http://www.netfilter.org/
даже есть dummy модуль - почитать и поправить.
Чем не устраивают реализации IPSEC?
>Вопрос в следующем: есть необходимость поставить дополнительный обработчик TCP-пакетов в ядро.
>Суть в следующем - любой пакет, собирающийся отправиться по сетки (независимо от
>приложения) должен пройти через некий обработчик (в моем случае - шифрование),
>на обратном конце, ес-но - обратное преобразование.
>т.е. если пакет идет в сеть - обработать, если из сети -
>тоже обработать.
>Подскажите, плиз, в каком направлении копать ?
>Возможен вариант в принципе организации псевдо-девайса, где это все делать. (аналог -
>shapecfg например).
>Спасибо.а если через tun интерфейс попробовать? повозиться конечно продется, но imho не так чтобы уж совсем.
man tun
// wbr
Применительно к FreeBSD, например, стандартных вариантов по крайней мере три:1) tun интерфейс (тут все понятно)
2) divert socket (это когда firewall отправляет пакет userland демону - так, например, nat делается)
3) netgraph (с ним не работал)IPSEC там, насколько я знаю, в ядре, но не netgraph, так что это еще один вариант. Нестандартных вариантов можно придумать еще больше - от ковыряния в исходниках ядра до всяких извратов типа ловли пакетов через pcap изменения и отправки измененных, или что-то типа шифрующего прокси.
Правда, возможности у всего этого получатся одинаковые, бо во всех случаях можно весь IP пакет менять, поэтому в извратах необходимости нет - лучше использовать самое простое - один из первых двух вариантов (tun самое логичное). Если же нужна особая скорость, то шифрование необходимо производить в ядре - тут понадобится netgraph или писать модуль.
>Суть в следующем - любой пакет, собирающийся отправиться по сетки (независимо от
>приложения) должен пройти через некий обработчик (в моем случае - шифрование),
>на обратном конце, ес-но - обратное преобразование.а разве это не стандартная задача тунелирования ? Зачем изобретать велосипед, когда можно поднять тунель и заворачивать туда трафик ?!