search

oxen-io / lokinet

Lokinet is an anonymous, decentralized and IP based overlay network for the internet.
https://lokinet.org/
GNU General Public License v3.0
1.72k stars 220 forks source link

Add support for NetworkManager #2091

Open jagerman opened 1 year ago

jagerman commented 1 year ago

Linux systems using NetworkManager (which is fairly common) are having a good bit of trouble getting going with Lokinet because the GUI tools for NetworkManager are kind of crappy and don't expose a way to override your DNS settings (you can either append a DNS server, which doesn't help for Lokinet, or not use DHCP at all, which is not very useful).

We should investigate how we can talk to NetworkManager to override DNS settings because, right now, the out-of-the-box experience on NetworkManager systems isn't very good.

XutaxKamay commented 1 year ago

Not sure but shouldn't /etc/resolvconf/resolv.conf.d/base/ or/and /etc/resolvconf/resolv.conf.d/head work fine to override DNS settings since I don't see many people using it anyway? Creating the file when lokinet is running and deleting/set the backup file it when service is down or something..

At worse I guess it could be possible to create also a dns plugin but yeah

majestrate commented 1 year ago

does nm have a dns plugin api?

majestrate commented 1 year ago

for users: a quick workaround is to let systemd-resolved manage dns, not network manager.

necro-nemesis commented 1 year ago

https://networkmanager.dev/docs/api/latest/nm-settings-dbus.html

ipv4 / ipv6 setting.

https://developer-old.gnome.org/NetworkManager/stable/gdbus-org.freedesktop.NetworkManager.html

majestrate commented 1 year ago

i think a nm vpn plugin is going to be a better match to what users expect when using network manager. screwing with network connections sounds like nightmare fuel, i dont think it will do anything but make things worse.

i actively avoid using network manager in general because too many things want to modify connection settings via dbus already. i dont want us to add more of those onto that pile.

XutaxKamay commented 1 year ago

i think a nm vpn plugin is going to be a better match to what users expect when using network manager. screwing with network connections sounds like nightmare fuel, i dont think it will do anything but make things worse.

i actively avoid using network manager in general because too many things want to modify connection settings via dbus already. i dont want us to add more of those onto that pile.

maybe too much overpowered but a kernel driver could work?

majestrate commented 1 year ago

kernel mode dns stub resolver sounds like something xckd would joke about.

XutaxKamay commented 1 year ago

kernel mode dns stub resolver sounds like something xckd would joke about.

glibc hook

majestrate commented 1 year ago

kernel mode dns stub resolver sounds like something xckd would joke about.

glibc hook

there is likely a way to make libnss plugin or something else like that to override dns before resolv.conf

majestrate commented 1 year ago

https://zwischenzugs.com/2018/06/08/anatomy-of-a-linux-dns-lookup-part-i/

there are several levels to the living hell of Dante's Name System

XutaxKamay commented 1 year ago

https://zwischenzugs.com/2018/06/08/anatomy-of-a-linux-dns-lookup-part-i/

there are several levels to the living hell of Dante's Name System

i know, the devil may cry about it

necro-nemesis commented 1 year ago

Can you potentially get behind it all at the kernel with a netfilter rule to redirect?

XutaxKamay commented 1 year ago

Can you potentially get behind it all at the kernel with a netfilter rule to redirect?

netfilter rule on a domain name? hmm sure (hence why majestrate and I was joking about my kernel idea)

basically, DNS is not controlled by kernel at all, it's mostly managed by glibc (nss stuff from what i read)

except for vms of course

and much more complications

let's throw away the osi model

on windows it's a different story though

necro-nemesis commented 1 year ago

I understand but an issue with nm is it's demonstrated itself to be inconsistent in it's behavior from distro to distro. Now whether interaction using an api resolves those inconsistencies remains a question.

majestrate commented 1 year ago

i mean, yea we could make a netfilter shim to hook all dns traffic. it'd be a great way to add this fabled "kill switch" too i guess.

XutaxKamay commented 1 year ago

i mean, yea we could make a netfilter shim to hook all dns traffic. it'd be a great way to add this fabled "kill switch" too i guess.

i mean that'll work probably, except for resolvers that uses dns over https (browsers) or dns over tls i suppose? but yeah for now, i guess that one could work

majestrate commented 1 year ago

i mean that'll work probably, except for resolvers that uses dns over https (browsers) or dns over tls i suppose? but yeah for now, i guess that one could work

we cant do anything about those anyways as we cannot provide local ca certified tls unless we do genuinely harmful things like require the user to add a generated CA to the root CA trust on their machine. that's not going to happen.

XutaxKamay commented 1 year ago

i mean that'll work probably, except for resolvers that uses dns over https (browsers) or dns over tls i suppose? but yeah for now, i guess that one could work

we cant do anything about those anyways as we cannot provide local ca certified tls unless we do genuinely harmful things like require the user to add a generated CA to the root CA trust on their machine. that's not going to happen.

okay well that will work then but what we will do traffic level to know if a packet is a dns query automatically? like do we just assume it runs on udp port 53 or do something else like sniffing the packet and check if its a dns query?