I tried to use similar LD_PRELOAD solutions but I always ended up finding some programs that don't go through libc, so they bypassed the VPN.
badvpn-tun2socks works with everything I wanted, but it's not as easy to control the processes that go through the VPN. It should be possible with network namespaces or tagging packets with cgroups but it's a pain to get it all set up.
> it's not as easy to control the processes that go through the VPN. It should be possible with network namespaces or tagging packets with cgroups but it's a pain to get it all set up.
I don't remember exactly, but I believe I was related to Java, probably trying to debug some Java app with IntelliJ. I'm not 100% sure if the problem was due to some intrinsic LD_PRELOAD/libc limitation or something related to the tools I tried, but trying to find what the problem was with something so gigantic seemed impossible so I went the tun2socks way which is more transparent for applications.
hmm. that's super weird. at the very least i would expect them to use the low level syscall wrappers in the libc. unless they're avoiding linking libc at all, it seems super weird to be making syscalls directly from application code.
i mean, what are they doing? implementing the syscall gate by hand. why would anybody do that?
anyway the reason i bring it up is that i've been toying with the idea of lightweight ld_preload "containers" which patch the relevant syscalls to mount additional filesystem and network resources in a safe and extremely high performance manner by bypassing the kernel completely.
ahh. i see now.. portability... i bet it would be possible to bypass/patch sysenter to achieve the same aim even if they're implementing their own syscall gates.
badvpn-tun2socks works with everything I wanted, but it's not as easy to control the processes that go through the VPN. It should be possible with network namespaces or tagging packets with cgroups but it's a pain to get it all set up.