@danderson Curious question about Tailscale, is it possible to run tailscaled & tailscale client in a separate network namespace?
(to achieve simultaneous connections to different Tailscale for different work contexts)
(I cannot use fast account switching because I need my main context to be connected to a particular tailscale all the time)
=> More informations about this toot | More toots from raito@nixos.paris
@raito @danderson you can run them in containers which are separate network namespaces, so the answer is surely yes, unless I misunderstand your use case?
=> More informations about this toot | More toots from farcaller@hdev.im
@farcaller @danderson i didn't know it was possible to run them into containers, so awesome :)
=> More informations about this toot | More toots from raito@nixos.paris
@raito @danderson not only you can do that, you can run tailscale in userland too for those extra "peculiar" network setups (when your network ns is actually a k8s pod and its CNI heavily smeared every network bit with ebpfs)
=> More informations about this toot | More toots from farcaller@hdev.im
@farcaller @danderson neat, now I only need to whip up all the magical code to have declarative work contexts attached to a specific tailscale state ig
=> More informations about this toot | More toots from raito@nixos.paris
@raito For context tailscale doesn't support multiple active right now because it risks some privacy/security headaches: multiple source addrs, merged DNS configs, subnet routers in network A stealing traffic from routers in network B, ... Not supporting it is better than screwing it up :/
If the tradeoffs are ok, running one tailscaled in normal tuntap mode and others in userspace mode can be an okay compromise. 1/
=> More informations about this toot | More toots from danderson@hachyderm.io
@raito downside of userspace mode is it's incoming connections only by default, but you can tell tailscaled to run HTTP or SOCKS proxies on localhost to make outbound connections as well.
For tailscale CLI vs. daemon communication across namespaces, that's pretty easy: CLI connects to tailscaled via unix sock, so make /run/tailscale/blahblah available where you want the CLI to work, and magic!
=> More informations about this toot | More toots from danderson@hachyderm.io
@raito tailscaled and CLI both take a socket path argument too, so with some wrapper scripts you can spawn daemons with different listening sockets (maybe in containers/netns/etc.), and have CLI shortcuts for "work tailscale" vs. "personal tailscale" or whatever.
=> More informations about this toot | More toots from danderson@hachyderm.io
@raito if tailscaleds are sharing a filesystem, you probably want to also change --state-dir on tailscaled, otherwise they'll overwrite each others' state and everything will be quite sad.
Once you have nixos or whatever configs, I'm happy to take a look and tell you if I see anything wrong
=> More informations about this toot | More toots from danderson@hachyderm.io This content has been proxied by September (3851b).Proxy Information
text/gemini