LINUX.ORG.RU

userspace router

 , ,


0

3

Не могу сформулировать вопрос гуглу, опишу своими словами, мб кто подскажет.

Нужна библиотека, которая принимает на вход ip пакет, парсит его, достает tcp/udp payload, открывает соответствующий сокет и шлет туда этот payload. и соответственно должна поддерживать соединение (в случае с tcp). полученные из сокета данные должна опять собирать в ip пакет и выдавать наружу.

мне не нужен tuntap, я не хочу инжектить пакеты в стек системы. я хочу использовать этот стек через интерфейс (socket, connect, read, write).

т.е требуется переход network -> session уровнями osi. нутром чую, что половина этой задачи решается через userspace tcp/ip стек (lwip например). но остальное самому писать лень, хочется заюзать готовое. задача по идее не такая уж уникальная, скорее всего ктот уже ее решал.

★★★★★

userspace network stack ?

Для msdos была такая хрень. И в гугле не так давно была новость про NUSE

vel ★★★★★ ()
Ответ на: комментарий от vel

юзерспейс стек это только половина моей задачи. nuse внедряет собранные им пакеты в систему через tuntap. а я не хочу использовать tuntap.

vvviperrr ★★★★★ ()
Ответ на: комментарий от vvviperrr

он умеет делать именно то, что ты хочешь. это одна из задач которую решает балансировщик. например:

# match "Hello\n" in the input stream (\x48 \x65 \x6c \x6c \x6f \x0a)
acl hello payload(0,6) -m bin 48656c6c6f0a

можешь в коде порыться как он это делает.

ukr_unix_user ★★★ ()
Ответ на: комментарий от vvviperrr

через raw/packet сокет хочется ? tun/tap в этом отношении самое безгеморойное решение.

vel ★★★★★ ()
Ответ на: комментарий от vel

через raw/packet сокет хочется

нет. хочется слать ip пакеты в безрутовой, независимой от tuntap среде (точнее не сами ip пакеты, а данные, которые они несут). потрошить пакет, самому открывать обычный tcp/udp сокет, слать payload, получать данные, формировать ip пакет. ДА, таким способом можно обработать только tcp/udp пакеты, но мне для этого случая больше и не надо.

дабы было понятнее:

https://github.com/vvviperrr/SimpleRT

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

vvviperrr ★★★★★ ()
Последнее исправление: vvviperrr (всего исправлений: 4)
Ответ на: комментарий от vvviperrr

безрутовой (без CAP_NET_ADMIN|CAP_NET_RAW) - 2 раза ХАХА!

Для работы с сокетом raw/packet все равно нужно делать bind() на девайс.

Далее тебе приходят пакеты (только на адрес этого интерфейса), ты обрабатываешь их, но при этом нужно недопустить обработку их в ОС. Как это реализовать (без iptables & CAP_NET_ADMIN) ?

vel ★★★★★ ()
Ответ на: комментарий от vel

под безрутовым я не имел ввиду ВООБЩЕ без всяких прав. очевидно что доступ к сети должен быть.

с сокетом raw/packet

да не нужен мне raw/packet сокет! payload ip пакетов хочется слать через обычные, INET сокеты.

vvviperrr ★★★★★ ()
Последнее исправление: vvviperrr (всего исправлений: 1)
Ответ на: комментарий от vvviperrr

т.е. тебе данные приходят через usb/serial интерфейс, а ты дальше хочешь его доставить по адресу назначения через обычные tcp/udp сокеты ?

vel ★★★★★ ()
Ответ на: комментарий от vel

именно. хочется сделать такое, ограниченное решение для случаев, где нет возможности работать с tuntap.

vvviperrr ★★★★★ ()
Ответ на: комментарий от vel

я нашел несколько программ, которые используют эту технику (например https://play.google.com/store/apps/details?id=app.greyshirts.firewall&hl=ru)

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

vvviperrr ★★★★★ ()

Не понятно, почему вас не устраивает tun/tap? Именно оно и делает то что вам хочется — отправляет raw-пакеты, пришедшие на адрес tun/tap интерфейса в прикладную программу. Никакого «инжекта» в стек системы не происходит.

А вообще до сих пор жив SLIRP — user-level IP стек, юзается qemu для user-level сети.

vodz ★★★★ ()
Ответ на: комментарий от vodz

Не понятно, почему вас не устраивает tun/tap

выше сказал

Никакого «инжекта» в стек системы не происходит

а что же происходит, когда ты пишешь ip пакет в tun устройство?

википедия сообщает

Пакет, посылаемый операционной системой через TUN/TAP устройство, обрабатывается программой, которая контролирует это устройство. Сама программа также может отправлять пакеты через TUN/TAP устройство. В таком случае TUN/TAP устройство доставляет (или «внедряет») такой пакет в сетевой стек операционной системы, эмулируя таким образом доставку пакета с внешнего устройства.

А вообще до сих пор жив SLIRP — user-level IP стек

я в самом топике указал, что любой userspace стек решит только половину задачи, а именно - формирование ip пакета из данных. отправку данных ip пакета через INET сокет нужно писать самому. или я не прав?

vvviperrr ★★★★★ ()
Последнее исправление: vvviperrr (всего исправлений: 2)
Ответ на: комментарий от vvviperrr

выше сказал

Для начала стоит пользоваться устоявшейся терминологией, только после этого у вашего «выше» появится смысл.

а что же происходит, когда ты пишешь ip пакет в tun устройство?

Вас не заставляют туда писать. У вас же задача ровно половина от скажем openvnp - получить пакет и его пережевать.

vodz ★★★★ ()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от vvviperrr

Хм. получается хитровыдуманный proxy. Он же только для icmp/udp/tcp?

c udp/icmp все просто, а вот с tcp придется потрудиться.

Удачи тебе :)

vel ★★★★★ ()
Ответ на: комментарий от vvviperrr

Получается посылать пакеты в устройство и принимать пакеты от него ты уже умеешь без рутовых прав. Теперь ты хочешь восстановить из принятых от устройства пакетов tcp потоки и udp дейтаграммы, и спроксировать их в сеть через обычный tcp/udp-сокет, а из ответных потоков и дейтаграмм опять собрать пакеты и послать их в устройство.

Похоже на работу socks прокси. Только socks прокси с обоих сторон работает с сокетами, и ему не нужно восстанавливать потоки/дейтаграммы из пакетов и нарубать ответные потоки/дейтаграммы в пакеты.

Тут нужна библиотека для ip фрагментации/дефрагментации и tcp assembly/reassembly. Вроде есть такое: libntoh, libnids, libtins, libpal, и т.п.

iliyap ★★★★ ()
Ответ на: комментарий от iliyap

Похоже на работу socks прокси.

Не, socks — это user-level nat, причём непрозрачный, а со своим протоколом. Совсем не похоже на задачу ТСа.

vodz ★★★★ ()
Ответ на: комментарий от vodz

ТС упоминал nat, который ему *приходится* делать. Поэтому мне кажется ему нужен именно layer4 прокси, и желательно полностью в юзерспейсе.

iliyap ★★★★ ()

Посмотри на сорцы socat.

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Посмотри на сорцы socat.

А сами вы их смотрели? Это ж не утиль, а какое-то извращение. Автору хотелось всё и сразу и желательно помудрённее. :)

vodz ★★★★ ()
Ответ на: комментарий от vodz

Не, я ток хелп смотрел ну и юзал при оказии.

Но оно же умеет чего надо автору, притом именно, что в юзерспейсе. А уровень говнокода доступного для восприятия он у всех разный, а ещё и меняется со временем :)

Upd: пока писал ответ - вспомнил, что один товарищ с работы поделку патчил под себя и в общем и целом остался доволен.

pon4ik ★★★★★ ()
Последнее исправление: pon4ik (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.