lokinet
lokinet copied to clipboard
oxen-io
Add support for NetworkManager
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.
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
for users: a quick workaround is to let systemd-resolved manage dns, not network manager.
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
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.
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?
kernel mode dns stub resolver sounds like something xckd would joke about.
kernel mode dns stub resolver sounds like something xckd would joke about.
glibc hook
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
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
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
Can you potentially get behind it all at the kernel with a netfilter rule to redirect?
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
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.
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, 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
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.
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?