5 ms·

But you still can't have multiple tailnets. The strategy of "have hobbyists try out the software themselves, like it, then implement it at their work" seems inc

But you still can't have multiple tailnets. The strategy of "have hobbyists try out the software themselves, like it, then implement it at their work" seems incompatible with this fact.

titanomachy 4y ago
Do you use the same Google/Github/Microsoft/whatever account for both work and personal stuff?
- enneff 4y ago
  A lot of people do just use one account for everything. Many smaller companies don’t bother giving people corporate accounts.
  - dx034 4y ago
    That sounds extremely risky. Apart from the fact that it makes it much harder to restrict access for leaving employees, mixing personal and work identities sounds like a recipe for disaster. What happens if a personal account gets banned? How do you enforce security rules? I guess companies where there's not even any identity management, securing your network via tailscale is not your primary concern.
- structural 4y ago
  It's more than just a work/personal split. Even at work, having "development" and "production" tailnets so that things like testing complex ACLs, inhouse apps that use tailscale via its API, etc. are possible without having everyone on the devops team create an unmanaged/non-company email so they can create their own development tailnet, and then deploy a bunch of company IP using this rogue account. It's a pain point.
mdeeks 4y ago
Agreed this is a big limitation. The only way to do it is if you have secondary email address domains. Say mdeeks@company.com and mdeeks@company.team. You can create a separate tailnet for company.team but you also have to roll out additional subnet routers (if you use them) that are authed on that second tailnet. Also you wont be able to easily write rules that interact with things that are not authed onto the second tailnet. They need a first class concept of "canary" or "beta" that applies to ACLs, DNS configs, client versions, and all sorts of other toggles in the UI. It's a hard product problem and I'm not even sure how some of it should work. I just know I need a way to test changes before I roll it out to everyone at the company. Right now there aren't good options for that.
ithkuil 4y ago
I work around this issue by running multiple tailscaled daemons on different state directories and sockets. E.g. I have the Tailscale macos application configured for the work network and then I run another tailscale daemon to connect to other home stuff: $ alias tailscaled tailscaled='sudo tailscaled --socket /Users/mkm/tmp/tailscale-mkm.socket' $ alias tailscale tailscale='tailscale --socket /Users/mkm/tmp/tailscale-mkm.socket' I installed the tailscale binaries from sources with "go install tailscale.com/cmd/tailscale{,d}@main"

But you still can't have multiple tailnets. The strategy of "have hobbyists try out the software themselves, like it, then implement it at their work" seems incompatible with this fact.

titanomachy 4y ago

Do you use the same Google/Github/Microsoft/whatever account for both work and personal stuff?

enneff 4y ago
A lot of people do just use one account for everything. Many smaller companies don’t bother giving people corporate accounts.
- dx034 4y ago
  That sounds extremely risky. Apart from the fact that it makes it much harder to restrict access for leaving employees, mixing personal and work identities sounds like a recipe for disaster. What happens if a personal account gets banned? How do you enforce security rules? I guess companies where there's not even any identity management, securing your network via tailscale is not your primary concern.
structural 4y ago
It's more than just a work/personal split. Even at work, having "development" and "production" tailnets so that things like testing complex ACLs, inhouse apps that use tailscale via its API, etc. are possible without having everyone on the devops team create an unmanaged/non-company email so they can create their own development tailnet, and then deploy a bunch of company IP using this rogue account. It's a pain point.

mdeeks 4y ago

Agreed this is a big limitation. The only way to do it is if you have secondary email address domains. Say mdeeks@company.com and mdeeks@company.team. You can create a separate tailnet for company.team but you also have to roll out additional subnet routers (if you use them) that are authed on that second tailnet. Also you wont be able to easily write rules that interact with things that are not authed onto the second tailnet. They need a first class concept of "canary" or "beta" that applies to ACLs, DNS configs, client versions, and all sorts of other toggles in the UI. It's a hard product problem and I'm not even sure how some of it should work. I just know I need a way to test changes before I roll it out to everyone at the company. Right now there aren't good options for that.

ithkuil 4y ago

I work around this issue by running multiple tailscaled daemons on different state directories and sockets. E.g. I have the Tailscale macos application configured for the work network and then I run another tailscale daemon to connect to other home stuff: $ alias tailscaled tailscaled='sudo tailscaled --socket /Users/mkm/tmp/tailscale-mkm.socket' $ alias tailscale tailscale='tailscale --socket /Users/mkm/tmp/tailscale-mkm.socket' I installed the tailscale binaries from sources with "go install tailscale.com/cmd/tailscale{,d}@main"