Embed lokinet

[zn3x]

From here, this still seems like a work in progress.
Is there any current api to integrate lokinet and use it in another program without the need for virtual interface?

[majestrate]

we are currently fixing up the internals right now ( #2141 #2119 ) but the public C api for embedded lokinet is currently defined in C headers: https://github.com/oxen-io/lokinet/tree/dev/include/ (llarp.hpp will be removed, it's a header for internals).

[zn3x]

Thanks, I've taken a look at it.
Is there any way to pass persistent keys to have same address when initializing lokinet's context, the same thing done here to run a mumble service so an application can have it's own hidden service hosted on persistent address

[majestrate]

currently we dont have an API defined for configuration. it's all running with a set of predefined ephemeral defaults. additionally, the UDP api is very likely to change entirely.

[majestrate]

i'll keep this open as a stub issue

[zn3x]

Hello, I've been lately experimenting with adding embedded lokinet to a rust app with C-bindings, repo is here.

As a POC, I want to create a lokinet stream, I first start by creating a new context with lokinet_context_new(), and starting it with lokinet_context_start(), then I keep waiting until context is ready with lokinet_status(), then I create a lokinet stream with lokinet_outbound_stream() which returns a host:port, I create a tcp stream to that host:port tuple, the moment some IO is done, lokinet panicks with an internal errors (full lokinet log here)

I tried different branches dev and dev-next (never managed to compile stable because of no fixed depencies versions). I'm not too sure if I'm doing something wrong, but I have been following this. cmake compilation flags are here

[majestrate]

Hello, I've been lately experimenting with adding embedded lokinet to a rust app with C-bindings, repo is here.

As a POC, I want to create a lokinet stream, I first start by creating a new context with lokinet_context_new(), and starting it with lokinet_context_start(), then I keep waiting until context is ready with lokinet_status(), then I create a lokinet stream with lokinet_outbound_stream() which returns a host:port, I create a tcp stream to that host:port tuple, the moment some IO is done, lokinet panicks with an internal errors (full lokinet log here)

I tried different branches dev and dev-next (never managed to compile stable because of no fixed depencies versions). I'm not too sure if I'm doing something wrong, but I have been following this. cmake compilation flags are here

we have a draft pr for fixing some internals in embedded lokinet, see #2141

[majestrate]

additionally, lokinet is licensed GPL3 (not LGPL3) at the moment. i dont think apache 2 is a compatible license for your rust lib. just a heads up.

[ple1n]

How about adding lokinet support to tun2proxy ?

I'm still working on that per-app-vpn problem. I will use tun2proxy as a component of netns-proxy

[majestrate]

On Tuesday, August 29, 2023 5:45:01 AM EDT plein wrote: How about adding lokinet support to [tun2proxy](tun2proxy/tun2proxy#59) ? I'm still working on that per-app-vpn problem. I will use tun2proxy as a component of netns-proxy

this looks nice, however i am of two minds on this. baking it into lokinet process itself feels like a bad idea from the tech debt perspective. we discussed something around this internally about splitting up lokinet into 2 processes, the lokinet core procsess which does all the non privileged functionality (basically everthing that is not the tun interface) and the tun interface or whatever interface you want to provide. the privileged process would spawn the lokinet core process as a subprocess and read and write ip packets as if it was a tun interface, along with commands for name resolution and other controls and events. using something like gvisor's netstack (golang library) for the userland proxy layer feels like a better choice than some rust library as golang has the a lot of effort put into it to make it work on everything (including the apple hellscape). the amount that it works on iOS is unclear however, but no matter what you do on iOS it's a nightmare so picking your demons on that is wise. the changes to lokinet core wouldn't be that big, we would need to: 1. allow specifying at runtime that the process use a specific file descriptor for the tun fd and another for name resolution 2. bring back configuration via env vars. (idk why that was removed it was great) 3. write a bunch of docs on how it works and write a version that does TUN/DNS and a version that does socks5.

…

-- ~jeff

[spookycheekybreeky]

Hello,

Some example avaible for https://github.com/oxen-io/lokinet/tree/dev/include/lokinet ? :3

[ple1n]

is there any update on this. so i finally got the arcane knowledge about that per-app-vpn niche, namespaces, mounts, etc.

I was writing a ton of bloat. The per-app-vpn (with cases like proxychained Tor + another proxy) should be handled by systemd, which I just started reading about, which gets hate idk.

up to now there is no accessible tool for per-app-vpn on linux, and I'd build such a tool for flatpak, which gets hate idk.

It should be possible to do all these things with user namespaces, passing fds, mounts, w/o root. It means proxychains should not exist.

It's also a better solution than opensnitch, or whatever per-app-routing-firewall, which is bloated therefore insecure, which has python, golang and stuff.

there is no reliable (paranoid-level, or is it really paranoid ?) per-app-vpn tooling on android, either.